From jgammons@gmail.com Fri Jul 1 08:44:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE60E11E80D1 for ; Fri, 1 Jul 2011 08:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMf3a4F9Qi9K for ; Fri, 1 Jul 2011 08:44:26 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B993C11E80B6 for ; Fri, 1 Jul 2011 08:44:25 -0700 (PDT) Received: by qwc23 with SMTP id 23so2749365qwc.31 for ; Fri, 01 Jul 2011 08:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=4f36s3QCS5Cos4Fvmv7bJHuAGiFdzT0aXX6tFGn8U+M=; b=sknc53WZ+71nP0ya2XscZB9yE+aCXKNQPTNRJGi81Gon6FfEikEVMh351aoIdJ5tIF aOGWcv1RzV7oUZshPLsh8zi839Rs8f+uzpH6QDcJmaDWVmLPR6nhVE6mSMtQsR37GeDd DZrZGOJzXIwAPHSq7EA+NB9Rg/k6uJTSK3pu0= Received: by 10.229.43.2 with SMTP id u2mr2560565qce.215.1309535058798; Fri, 01 Jul 2011 08:44:18 -0700 (PDT) Received: from [192.168.0.10] ([68.0.0.153]) by mx.google.com with ESMTPS id u15sm2643775qcq.12.2011.07.01.08.44.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 08:44:17 -0700 (PDT) From: John Gammons Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2011 11:44:09 -0400 Message-Id: To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-v6ops-ipv6-cpe-router-bis@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-cpe-router-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 15:44:26 -0000 First off, overall, this is a great draft and a much needed one at that. = A few thoughts that might be considered overly complex, but I thought = I'd throw out there for potential talking points by the group. =20 CGN/LSN(NAT44) environment -=20 What if the WAN interface was provided an RFC1918 address (or = potentially draft-weil-shared-transition-space-request-01/ARIN 2011-5 = space), the CPE would accept this address as a management IP only, and = fallback to bridge operation. The thought here being, that rather than = downstream CPE operating in a NAT444 environment, they would then be = only NAT44. This would obviously require that the provider no longer = deliver only a single v4 address, but an unlimited number for any = subscriber routed through a CGN/LSN. There are numerous other potential = implications which would need further discussion, but the thought being, = all of those _could_ be more preferred over the NAT444 implications. = Essentially it would be "moving" the existing NAT44 to a more = advantageous v4 location where overloading can be performed, rather than = adding an additional layer. =20 No WAN IPv4 address - If, the CPE is delegated a prefix, but does not receive an IPv4 address = (public or private) on its WAN interface, and it does not receive a = DS-Lite configuration, then it may be beneficial to fallback into a = NAT46 operation (draft-liu-behave-nat46). The main benefit here is that = if no WAN side IPv4 connectivity is available (due to provider = configuration or some failure), legacy IPv4 only devices, would still = have some means of Internet reachability. It would also require some = implementation of DNS46 proxy (draft-xli-behave-dns46-for-stateless). = Potentially being paired with a provider NAT64 solution to provide = NAT464 connectivity. =20 My intent is not to make this draft so incredibly complex that no vendor = ever implements it, but from my own discussions regarding transition = technologies, and my own testing performed thus far surrounding NAT444, = I am curious to hear others thoughts. =20 Thanks, John= From iesg-secretary@ietf.org Fri Jul 1 09:13:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43B51F0C47; Fri, 1 Jul 2011 09:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLZ5ACpjElBx; Fri, 1 Jul 2011 09:13:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF561F0C54; Fri, 1 Jul 2011 09:13:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110701161309.16673.51593.idtracker@ietfa.amsl.com> Date: Fri, 01 Jul 2011 09:13:09 -0700 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'Advisory Guidelines for 6to4 Deployment' to Informational RFC (draft-ietf-v6ops-6to4-advisory-02.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 16:13:10 -0000 The IESG has approved the following document: - 'Advisory Guidelines for 6to4 Deployment' (draft-ietf-v6ops-6to4-advisory-02.txt) as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-advisory/ Technical Summary This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers, including those that do not yet support IPv6, and to Content Providers. Some advice to implementers is also included. The intention of the advice is to minimise both user dissatisfaction and help desk calls. Working Group Summary The IPv6 Operations Working Group discussed this in the first half of 2011. There is general consensus that the guidelines for improving 6to4 behavior are reasonable and helpful. Document Quality The document was written by the original author of 6to4. Many of the people that commented in support of it observed that it was well written and informative. There are numerous 6to4 implementations; the issue in this context is that 6to4 was intended to have operational support when designed, and has been implemented largely without that operational support. As a result, it often doesn't perform as intended. This was discussed in Geoff Huston's talk in v6ops at IETF-80. Personnel Fred Baker is shepherd. From Fred.L.Templin@boeing.com Fri Jul 1 15:55:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD20611E81F9 for ; Fri, 1 Jul 2011 15:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsJ5i1LBRA7u for ; Fri, 1 Jul 2011 15:55:03 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id BE51B11E8206 for ; Fri, 1 Jul 2011 15:55:03 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p61MsuWr023033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jul 2011 15:54:56 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p61Msu6l009023; Fri, 1 Jul 2011 15:54:56 -0700 (PDT) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p61MstxL009018 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 1 Jul 2011 15:54:55 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Fri, 1 Jul 2011 15:54:43 -0700 From: "Templin, Fred L" To: Joel Jaeggli Date: Fri, 1 Jul 2011 15:54:41 -0700 Thread-Topic: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? Thread-Index: AcwtJ7+vRpD6lZYVTg2di+8xEeOXSwDxF7swAdTs5DA= Message-ID: References: <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C6B30E217XCHNW01Vnwnos_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 22:55:04 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C6B30E217XCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joel, Me again. There have have been others who have also expressed concerns about DHCPv6 and other "undocumented features" on ISATAP links, so I decided to split the document into two pieces. The new piece is now called: "ISATAP Updates" and I guess might be more appropriate for some other working group. The other piece retains the original name and is strictly about operational aspects of widely-deployed implementations: http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-12.txt What should we do next - ask the wg for comments? Thanks - Fred ________________________________ From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= emplin, Fred L Sent: Wednesday, June 22, 2011 8:13 AM To: Joel Jaeggli Cc: v6ops@ietf.org Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? Hi Joel, Thanks for your comments, and see below for responses: ________________________________ From: Joel Jaeggli [mailto:joelja@bogus.com] Sent: Friday, June 17, 2011 12:50 PM To: Templin, Fred L Cc: v6ops@ietf.org Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote: Hello, Significant improvements have been made to this document (below) based on comments received and new observations. IMHO, this is an important document for enabling transition to IPv6 within IPv4 sites; hence, I would like to call for working group adoption at this time. Thanks - Fred fred.l.templin@boeing.com Replying to this message as a way to maintain the threading. these notes ar= e relative to the current version of the draft which I reviewed last week: http://tools.ietf.org/html/draft-templin-v6ops-isops-10 So I tried for a while to separate the operational advice that could be app= lied to my 2005 era knowledge of isatap and there's quite a few things tha= t jive with that (tunnel loops for example). OK. In other cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what im= plementations are capable of doing that? Are we recommending that they do i= t? do they already? I can't speak for current implementations, but the DHCPv6 approach is based on the fact that address and prefix assignment on IPv6 interfaces are seperable functions. IPv6 prefixes assigned to ISATAP interfaces can only be used for autoconfiguration of ISATAP addresses and not ordinary IPv6 addresses. However, an ordinary IPv6 address can be assigned to an ISATAP interface the same as for any other IPv6 interface as long as it is not covered by a prefix assigned to the interface. Regarding aero (section 4.6) that looks pretty much like new work or an ext= ension to the specification. AERO is a new but backwards-compatible method of doing redirection of an on-link neighbor to another on-link neighbor. However, ISATAP interfaces can still use standards ICMPv6 Redirect messages the same as for any IPv6 interface. Advertising ISATAP routers should only send ICMPv6 redirects when they are certain that the redirected ISATAP node can tunnel packets directly to the target of the redirect, however. Perhaps a few more words saying explicitly that standards ICMPv6 redirects are still supported would help? Are there participants with extant isatap deployements or host implementati= ons or knowledge fresher than mine that would care to comment on this draft= . There are certainly vendors who are shipping ISATAP in their products today. Perhaps they can comment. section 9 alternative approaches, there's some consensus that rfc 3056 was = never really deployed so the reference to 6to4 should probably be to 3068 OK - I can fix this. Thanks - Fred fred.l.templin@boeing.com --_000_E1829B60731D1740BB7A0626B4FAF0A65C6B30E217XCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Joel,
 
Me again. There have have been others who have a= lso=20 expressed
concerns about DHCPv6 and other "undocumented featur= es"=20 on
ISATAP links, so I decided to split the document= into=20 two pieces.
 
The new piece is=20 now called: "ISATAP Updates" and I guess might
be more appropriate for some other working group.=20 The other piece
retains the original name and is strictly about= =20 operational aspects
of widely-deployed implementations= :
 
http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-12.txt=  
What should we do next - ask the wg for=20 comments?
 
Thanks - Fred

From: v6ops-bounces@ietf.org=20 [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred=20 L
Sent: Wednesday, June 22, 2011 8:13 AM
To: Joel=20 Jaeggli
Cc: v6ops@ietf.org
Subject: Re: [v6ops]=20 'draft-templin-v6ops-isops' as v6ops wg item?

Hi Joel,
 
Thanks for your comments, and see below for=20 responses:

From: Joel Jaeggli [mailto:joelja@b= ogus.com]=20
Sent: Friday, June 17, 2011 12:50 PM
To: Templin, = Fred=20 L
Cc: v6ops@ietf.org
Subject: Re: [v6ops]=20 'draft-templin-v6ops-isops' as v6ops wg item?

On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote:

Hello,

Significant improvements have been made to this=20 document
(below) based on comments received and new=20 observations.
IMHO, this is an important document for enabling=20 transition
to IPv6 within IPv4 sites; hence, I would like to call= =20 for
working group adoption at this time.

Thanks - Fred
<= A=20 href=3D"mailto:fred.l.templin@boeing.com">fred.l.templin@boeing.com


Replying=20 to this message as a way to maintain the threading. these notes are rel= ative=20 to the current version of the draft which I reviewed last week:

http:/= /tools.ietf.org/html/draft-templin-v6ops-isops-10

So= I tried=20 for a while to separate the operational advice that could be applied to= my=20 2005 era knowledge of isatap and there's  quite a few things that = jive=20 with that (tunnel loops for example).<= FONT=20 face=3DArial color=3D#0000ff size=3D2> 
=
OK.  
In= other=20 cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what=20 implementations are capable of doing that? Are we recommending that the= y do=20 it? do they already? 
I can't speak for= =20 current implementations, but the DHCPv6 approach=20 is
based on the fact = that=20 address and prefix assignment on IPv6 interfaces
are seperable func= tions. IPv6=20 prefixes assigned to ISATAP interfaces can
only be used for=20 autoconfiguration of ISATAP addresses and not=20 ordinary
IPv6 addresses. Ho= wever, an=20 ordinary IPv6 address can be assigned to
an ISATAP interfac= e the same=20 as for any other IPv6 interface as long as
it is not covered = by a prefix=20 assigned to the interface.
Re= garding=20 aero (section 4.6) that looks pretty much like new work or an extension= to=20 the specification. 
AERO is a new but= =20 backwards-compatible method of doing redirection
of an on-link neig= hbor to=20 another on-link neighbor. However, ISATAP
interfaces can sti= ll use=20 standards ICMPv6 Redirect messages the same
as for any IPv6=20 interface. Advertising ISATAP routers should only=20 send
ICMPv6 redirects w= hen they=20 are certain that the redirected ISATAP node
can tunnel pa= ckets=20 directly to the target of the redirect, however.=20 Perhaps
a few more words s= aying=20 explicitly that standards ICMPv6 redirects are
still supported wo= uld=20 help? 
Ar= e there=20 participants with extant isatap deployements or host implementations or= =20 knowledge fresher than mine that would care to comment on this draft. 
 
There are certainl= y vendors=20 who are shipping ISATAP in their products
today. Perhaps the= y can=20 comment. 
se= ction 9=20 alternative approaches, there's some consensus that rfc 3056 was never= =20 really deployed so the reference to 6to4 should probably be to 3068 
 
OK - I can fix=20 this.
 
Thanks -=20 Fred
fred.l.templin@boeing.com
--_000_E1829B60731D1740BB7A0626B4FAF0A65C6B30E217XCHNW01Vnwnos_-- From rbonica@juniper.net Sat Jul 2 09:38:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E0E11E80AC; Sat, 2 Jul 2011 09:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.126 X-Spam-Level: X-Spam-Status: No, score=-106.126 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+HvRaWHUaWu; Sat, 2 Jul 2011 09:38:26 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 82E2C11E808C; Sat, 2 Jul 2011 09:38:26 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTg9Jgiw+T/SvYqTY0/hYPSXulrBMqvql@postini.com; Sat, 02 Jul 2011 09:38:26 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 2 Jul 2011 09:36:07 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sat, 2 Jul 2011 12:36:06 -0400 From: Ronald Bonica To: "v6ops@ietf.org" , IETF Discussion Date: Sat, 2 Jul 2011 12:36:05 -0400 Thread-Topic: draft-ietf-v6ops-6to4-to-historic Thread-Index: Acw41iMv6/qWspvgTzCQB463JqIp+A== Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 16:38:27 -0000 Folks, Whereas there has been considerable controversy regarding draft-ietf-v6ops-= 6to4-to-historic, the v6ops chairs and document author have agreed to the f= ollowing course of action: - the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-t= o-historic - The author will introduce a new draft, intended for standards track publi= cation. The new draft will update RFCs 3056 and 3068. It will say that if 6= -to-4 is implemented, it must be turned off by default.=20 - In order for the new draft to be published, it must achieve both V6OPS WG= and IETF consensus If anyone objects to this course of action, please speak up soon. Ron From lorenzo@google.com Sat Jul 2 11:55:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2FC1F0C55 for ; Sat, 2 Jul 2011 11:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.376 X-Spam-Level: X-Spam-Status: No, score=-105.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4WZiW1p2IEa for ; Sat, 2 Jul 2011 11:55:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id A5CC41F0C59 for ; Sat, 2 Jul 2011 11:55:13 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p62ItCo0012862 for ; Sat, 2 Jul 2011 11:55:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309632913; bh=q4CaM8rtSFf68OpzZDgzc7zKcyQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=JdvFRU63BU9Nsp88FfuAwns3rJhLGfh5QKEPQAcpBnO5c+4TVBDeA6TEiV85P2xRK qFw+GvNvti1HIlV1Ha9Hw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=IMqv09Vs0kEXTdxjbkzspjiJ73Lyxv7bsDa121PFMe02SJbYEvo4I3Iv1y8w48IQt Za4BMeIiWvyy7dogNBj8g== Received: from gyc15 (gyc15.prod.google.com [10.243.49.143]) by hpaq11.eem.corp.google.com with ESMTP id p62ItAaL013556 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 2 Jul 2011 11:55:11 -0700 Received: by gyc15 with SMTP id 15so2106257gyc.24 for ; Sat, 02 Jul 2011 11:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=168jUnzc9zdoyIzQ+OAv9EjuGbo4CjljzeCOtLShr4Y=; b=TuxS0QygBItzOPeNXFXAa3Rz4r4hqoOlwaz8vS6jZEZouJ6hMGYzpHUe7Qgf0z82GX i7PrODxEpGIkiZTspMKA== Received: by 10.150.116.1 with SMTP id o1mr3844893ybc.321.1309632910148; Sat, 02 Jul 2011 11:55:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.14 with HTTP; Sat, 2 Jul 2011 11:54:50 -0700 (PDT) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> From: Lorenzo Colitti Date: Sat, 2 Jul 2011 20:54:50 +0200 Message-ID: To: Ronald Bonica Content-Type: multipart/alternative; boundary=000e0cd3b04065468304a71aacb2 X-System-Of-Record: true Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 18:55:14 -0000 --000e0cd3b04065468304a71aacb2 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica wrote: > - In order for the new draft to be published, it must achieve both V6OPS WG > and IETF consensus > > If anyone objects to this course of action, please speak up soon. > Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with "welcome to the IETF" :-) --000e0cd3b04065468304a71aacb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica <rbonica@juniper.= net> wrote:
- In order for the new draft to be published, it must achieve both V6OPS WG= and IETF consensus

If anyone objects to this course of action, please speak up soon.

Great, back to square one.

<= div>Is the reasoning behind the decision explained somewhere?=A0My reading = of the threads on the subject in v6ops was that the opposition to 6to4-hist= oric was a small but vocal minority, and I thought that qualified as rough = consensus. But perhaps I missed some discussion.

Also, why do the author and the chairs think that the n= ew draft will do any better than 6to4-historic? I would assume that the sam= e people who spoke up against 6to4-historic will speak up against the new d= ocument, and since that level of opposition was sufficient to prevent the p= ublication of=A06to4-historic, it may be sufficient to prevent publication = of the new document as well.=A0If so, we will have spent 3-6 months arguing= about it for naught.

Please, nobody answer this question with "welcome = to the IETF" :-)
--000e0cd3b04065468304a71aacb2-- From cb.list6@gmail.com Sat Jul 2 12:21:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DBF21F85A3; Sat, 2 Jul 2011 12:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDUPI3u9+Jbp; Sat, 2 Jul 2011 12:21:39 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57D9021F85A0; Sat, 2 Jul 2011 12:21:39 -0700 (PDT) Received: by wyj26 with SMTP id 26so3199946wyj.31 for ; Sat, 02 Jul 2011 12:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mTapDQ5YaVBLKKvebEItCJwFK3aFFm8RVm+YoDP0K4k=; b=lVgv5ZxWa0QVQDhM0oAtk9JyT0QANsLVbh6bwnlvfcaFh+94+nsMvmDieixQ2URRoZ 8L4TW/NfY6HxCHxxALnSxhz0fu5Qg8frqM4uOLmsEfAfPxS7A5dEpqKFAVUZEeK++IIc yI6wkDQd3jjQv1ODFGygUcnQ7ld9AXmkM192g= MIME-Version: 1.0 Received: by 10.216.63.131 with SMTP id a3mr3780289wed.64.1309634496662; Sat, 02 Jul 2011 12:21:36 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Sat, 2 Jul 2011 12:21:36 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Sat, 2 Jul 2011 12:21:36 -0700 (PDT) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> Date: Sat, 2 Jul 2011 12:21:36 -0700 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=000e0cdfd8bcf58cff04a71b0aa7 Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 19:21:40 -0000 --000e0cdfd8bcf58cff04a71b0aa7 Content-Type: text/plain; charset=ISO-8859-1 On Jul 2, 2011 11:55 AM, "Lorenzo Colitti" wrote: > > On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica wrote: >> >> - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus >> >> If anyone objects to this course of action, please speak up soon. > > > Great, back to square one. > > Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. > I saw the same thing. It is a shame that work that directly removes barriers to REAL ipv6 deployment gets shouted down by a few people not involved in REAL ipv6 deployment. Welcome to the ietf indeed. Cb > Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. > > Please, nobody answer this question with "welcome to the IETF" :-) > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000e0cdfd8bcf58cff04a71b0aa7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 2, 2011 11:55 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica <rbonica@juniper.net> wrote:
>>
>> - In order for the new draft to be published, it must achieve both= V6OPS WG and IETF consensus
>>
>> If anyone objects to this course of action, please speak up soon.<= br> >
>
> Great, back to square one.
>
> Is the reasoning behind the decision explained somewhere?=A0My reading= of the threads on the subject in v6ops was that the opposition to 6to4-his= toric was a small but vocal minority, and I thought that qualified as rough= consensus. But perhaps I missed some discussion.
>

I saw the same thing. It is a shame that work that directly removes barr= iers to REAL ipv6 deployment gets shouted down by a few people not involved= in REAL ipv6 deployment.

Welcome to the ietf indeed.

Cb

> Also, why do the author and the chairs think that the new draft wil= l do any better than 6to4-historic? I would assume that the same people who= spoke up against 6to4-historic will speak up against the new document, and= since that level of opposition was sufficient to prevent the publication o= f=A06to4-historic, it may be sufficient to prevent publication of the new d= ocument as well.=A0If so, we will have spent 3-6 months arguing about it fo= r naught.
>
> Please, nobody answer this question with "welcome to the IETF&quo= t; :-)
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--000e0cdfd8bcf58cff04a71b0aa7-- From robert@raszuk.net Sat Jul 2 12:28:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EEE228011; Sat, 2 Jul 2011 12:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWthvaIJesaS; Sat, 2 Jul 2011 12:28:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id BC23122800F; Sat, 2 Jul 2011 12:28:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGVwD06rRDoG/2dsb2JhbABSqAF3iHqjNp0ghjYEkjaEeItA X-IronPort-AV: E=Sophos;i="4.65,465,1304294400"; d="scan'208";a="473996241" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 02 Jul 2011 19:28:20 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p62JSIfT017667; Sat, 2 Jul 2011 19:28:19 GMT Message-ID: <4E0F7156.4010307@raszuk.net> Date: Sat, 02 Jul 2011 21:28:22 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Lorenzo Colitti References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 19:28:21 -0000 Very well said Lorenzo. +1 Unless Ron describes exactly one by one real reasons to give up on draft-ietf-v6ops-6to4-to-historic and majority of v6ops WG agrees with those reasons IMHO the document should proceed as is. > It will say that if 6-to-4 is implemented, it must be turned > off by default. Last ... if something is turned on or off by default is an implementation choice and last time I checked IETF was not in business to mandate any implementation choice. Thx, R. > On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica > wrote: > > - In order for the new draft to be published, it must achieve both > V6OPS WG and IETF consensus > > If anyone objects to this course of action, please speak up soon. > > > Great, back to square one. > > Is the reasoning behind the decision explained somewhere? My reading of > the threads on the subject in v6ops was that the opposition to > 6to4-historic was a small but vocal minority, and I thought that > qualified as rough consensus. But perhaps I missed some discussion. > > Also, why do the author and the chairs think that the new draft will do > any better than 6to4-historic? I would assume that the same people who > spoke up against 6to4-historic will speak up against the new document, > and since that level of opposition was sufficient to prevent the > publication of 6to4-historic, it may be sufficient to prevent > publication of the new document as well. If so, we will have spent 3-6 > months arguing about it for naught. > > Please, nobody answer this question with "welcome to the IETF" :-) > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From moore@network-heretics.com Sat Jul 2 13:03:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4436C11E8167; Sat, 2 Jul 2011 13:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGZ-Xs8hx5ma; Sat, 2 Jul 2011 13:03:06 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9511C11E8101; Sat, 2 Jul 2011 13:03:06 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 388F120993; Sat, 2 Jul 2011 16:03:06 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Sat, 02 Jul 2011 16:03:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=hUu01AXkvMIq+ZetFsoCH7tVWog=; b=Vxz3h0rEhnDQUpgb6maYIEi3835gVX6Xk6j2Qeuv/agxPeICX0TGWFMC1bmU0AYIftQyhfERlwhh55MUpEsLdcCPwX+ebQal3EqpUYBcciWs7CZ7enVaXCaRy7EQPpLg9+nkG5z0O0XbuLE654A5/9U5D+DUTvygB5oMB94FIbI= X-Sasl-enc: l/PVn8LFmu7XCa6u+pGgXJRbLJkgmPQFp7TFnz8LkcYm 1309636985 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 2DEDF404E9A; Sat, 2 Jul 2011 16:03:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Sat, 2 Jul 2011 16:02:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 20:03:07 -0000 > Is the reasoning behind the decision explained somewhere? My reading = of the threads on the subject in v6ops was that the opposition to = 6to4-historic was a small but vocal minority, and I thought that = qualified as rough consensus.=20 Even if there was rough consensus within v6ops, rough consensus of v6ops = does not equate to rough consensus of the entire IETF community.=20 > Also, why do the author and the chairs think that the new draft will = do any better than 6to4-historic? I would assume that the same people = who spoke up against 6to4-historic will speak up against the new = document, and since that level of opposition was sufficient to prevent = the publication of 6to4-historic, it may be sufficient to prevent = publication of the new document as well. If so, we will have spent 3-6 = months arguing about it for naught. I hope that the author(s) of the new document and the v6ops WG will = understand that their task is to craft a document that can earn = community-wide consensus, not merely the approval of v6ops. As long as = the document is brief and to-the-point, I don't see any problem. I = personally don't have any objection to the notion that 6to4 should be = off by default and should require explicit configuration to enable it. Keith From robert@raszuk.net Sat Jul 2 13:22:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF0511E80C1; Sat, 2 Jul 2011 13:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUq9RGwI5FdS; Sat, 2 Jul 2011 13:22:40 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id F02FB11E80A6; Sat, 2 Jul 2011 13:22:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANt8D06rRDoJ/2dsb2JhbABSqAF3iHqjCJ0bhjYEkjaEeItA X-IronPort-AV: E=Sophos;i="4.65,465,1304294400"; d="scan'208";a="288777999" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-4.cisco.com with ESMTP; 02 Jul 2011 20:22:39 +0000 Received: from [192.168.1.66] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p62KMchj011052; Sat, 2 Jul 2011 20:22:38 GMT Message-ID: <4E0F7E12.8060901@raszuk.net> Date: Sat, 02 Jul 2011 22:22:42 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Keith Moore References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 20:22:40 -0000 Hi Keith, > I personally don't have any objection to the notion that 6to4 should > be off by default and should require explicit configuration to enable > it. Is there any feature (perhaps other then netboot) on commercial or open source routers which is not off by default and which would require explicit configuration to enable it ? Thx, R. From moore@network-heretics.com Sat Jul 2 13:25:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A7F11E80C1; Sat, 2 Jul 2011 13:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+Z3pdJOAV6E; Sat, 2 Jul 2011 13:25:55 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id BA65411E80A6; Sat, 2 Jul 2011 13:25:55 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 614B8206BE; Sat, 2 Jul 2011 16:25:55 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Sat, 02 Jul 2011 16:25:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=cwcqUjGIVfUhdmfVrFqiDYA/mr0=; b=at8VwFCOv+npiRw3gIjoxtNLENbTH8SbyhtWTRT1q6B0aKiAv5MIY9hR5D8DMXgM9Ui2paugkYUFBJ603lMezsdC8j2qhRrZy/nw1pYFWKOqKOUHBlKoi1bgOjKk8zzcX9V87squKYgzPFTKInRk1Yq/BCJCc+u0nDxFWFBnPBE= X-Sasl-enc: I7Rm47nxU3NLYf1OrycGESP4bUNkrguOZizvTTQSRxVn 1309638355 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 7F52940C8DF; Sat, 2 Jul 2011 16:25:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E0F7E12.8060901@raszuk.net> Date: Sat, 2 Jul 2011 16:25:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3D17B847-7424-4A31-8072-761DDFDCA5B1@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <4E0F7E12.8060901@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 20:25:56 -0000 On Jul 2, 2011, at 4:22 PM, Robert Raszuk wrote: > Hi Keith, >=20 >> I personally don't have any objection to the notion that 6to4 should >> be off by default and should require explicit configuration to enable >> it. >=20 > Is there any feature (perhaps other then netboot) on commercial or = open source routers which is not off by default and which would require = explicit configuration to enable it ? I have understood that in the past there were a few routers that enabled = 6to4 by default, though I don't know whether this is the case any = longer. =20 I also believe that there are currently hosts that enable 6to4 by = default if there is no native v6 connectivity and the host has a public = IPv4 address. Keith From pch-b2B3A6689@u-1.phicoh.com Sat Jul 2 14:18:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745EB11E80DE; Sat, 2 Jul 2011 14:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VIrWml1GoeA; Sat, 2 Jul 2011 14:18:58 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id AE63C11E80D9; Sat, 2 Jul 2011 14:18:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qd7aY-0001hHC; Sat, 2 Jul 2011 23:18:54 +0200 Message-Id: To: Keith Moore From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> In-reply-to: Your message of "Sat, 2 Jul 2011 16:02:47 -0400 ." Date: Sat, 02 Jul 2011 23:18:52 +0200 Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 21:18:58 -0000 In your letter dated Sat, 2 Jul 2011 16:02:47 -0400 you wrote: > >> Is the reasoning behind the decision explained somewhere? My reading of the >threads on the subject in v6ops was that the opposition to 6to4-historic was a > small but vocal minority, and I thought that qualified as rough consensus. > >Even if there was rough consensus within v6ops, rough consensus of v6ops does >not equate to rough consensus of the entire IETF community. Is there any summary of the IETF community consensus? I sort of can't imagine that ISPs want to continue operating 6to4 relays longer than strictly necessary. So I'm curious what the IETF community at large considers the future of 6to4 in it's default-disabled mode. From randy@psg.com Sat Jul 2 14:35:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B714221F85B2; Sat, 2 Jul 2011 14:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJHqrKW2PwKi; Sat, 2 Jul 2011 14:35:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2F66921F84EB; Sat, 2 Jul 2011 14:35:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qd7qC-000EHg-S5; Sat, 02 Jul 2011 21:35:05 +0000 Date: Sun, 03 Jul 2011 06:35:03 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 21:35:07 -0000 >> If anyone objects to this course of action, please speak up soon. i object. as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot. it is damaging to the users and to the users' view of ipv6. > Great, back to square one. > > Is the reasoning behind the decision explained somewhere? My reading of the > threads on the subject in v6ops was that the opposition to 6to4-historic was > a small but vocal minority, and I thought that qualified as rough consensus. perhaps that minority was also vocal in the back room > But perhaps I missed some discussion. > > Also, why do the author and the chairs think that the new draft will do any > better than 6to4-historic? I would assume that the same people who spoke up > against 6to4-historic will speak up against the new document, yes, but that will be a year from now. in the ietf, delay is one form of death. > and since that level of opposition was sufficient to prevent the > publication of 6to4-historic, it may be sufficient to prevent > publication of the new document as well. If so, we will have spent 3-6 > months arguing about it for naught. > > Please, nobody answer this question with "welcome to the IETF" :-) this is nutso. but this is normal. welcome to the ietf randy From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Jul 2 17:38:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4290D11E80DE; Sat, 2 Jul 2011 17:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMV5UKTkdx0I; Sat, 2 Jul 2011 17:38:51 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 73ACC11E809D; Sat, 2 Jul 2011 17:38:51 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QdAhy-0007Mt-7a; Sun, 03 Jul 2011 10:08:46 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 519D13B33E; Sun, 3 Jul 2011 10:08:45 +0930 (CST) Date: Sun, 3 Jul 2011 10:08:44 +0930 From: Mark Smith To: Lorenzo Colitti Message-ID: <20110703100844.68eb8b7d@opy.nosense.org> In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 00:38:52 -0000 On Sat, 2 Jul 2011 20:54:50 +0200 Lorenzo Colitti wrote: > On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica wrote: > > > - In order for the new draft to be published, it must achieve both V6OPS WG > > and IETF consensus > > > > If anyone objects to this course of action, please speak up soon. > > > > Great, back to square one. > > Is the reasoning behind the decision explained somewhere? My reading of the > threads on the subject in v6ops was that the opposition to 6to4-historic was > a small but vocal minority, and I thought that qualified as rough consensus. > But perhaps I missed some discussion. > > Also, why do the author and the chairs think that the new draft will do any > better than 6to4-historic? I would assume that the same people who spoke up > against 6to4-historic will speak up against the new document, and since that > level of opposition was sufficient to prevent the publication > of 6to4-historic, it may be sufficient to prevent publication of the new > document as well. If so, we will have spent 3-6 months arguing about it for > naught. > I don't object to what has been proposed, yet I object to "6to4-historic" because I'm an extremely happy anycast 6to4 user and have been for many years (I just recently looked at the date in the script I wrote to bring it up, and was quite surprised it was dated 2002). Unfortunately people do judge books by their cover - if there is an RFC that says 6to4 is historic, people would likely consider it something that can't be used. We know it can operate correctly and reliably if it is configured correctly. If the criteria for declaring a technology historic is that some people can't operate it correctly and reliably, then they'll have to be plenty of other -historic RFCs. Perhaps declaring 6to4 deprecated rather than historic would have a better chance of consensus. > Please, nobody answer this question with "welcome to the IETF" :-) From lorenzo@google.com Sat Jul 2 18:03:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EF622801C for ; Sat, 2 Jul 2011 18:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.376 X-Spam-Level: X-Spam-Status: No, score=-105.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtzijmiVMmw4 for ; Sat, 2 Jul 2011 18:03:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 08CD022801B for ; Sat, 2 Jul 2011 18:03:38 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p6313bMj032235 for ; Sat, 2 Jul 2011 18:03:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309655018; bh=LryEdj20RqyvNUT6d+2maFsjv9w=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=K0i8XSvzMh8eVEghX8RujhY2m4mTF/8dH7iORSJKSGntqCZamh+zb+Ft5uL9zQAV+ edLTqyjRoVdla2rmu7w+g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=nTN6IGf+jGEp+YQsszwXZsKYWngM4EPzQJXGA3CxHJQYdnaSQxGhEyUM1Cd7Gq2ve Adclhjsr9FixpNq1Yw4Jg== Received: from gxk9 (gxk9.prod.google.com [10.202.11.9]) by hpaq13.eem.corp.google.com with ESMTP id p6313Zia012177 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 2 Jul 2011 18:03:36 -0700 Received: by gxk9 with SMTP id 9so2027441gxk.12 for ; Sat, 02 Jul 2011 18:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OfMW9y8g4+KdXIPqVEN7LiOXzg54dhcivmRYMK81yp0=; b=tomIPCBFbEQ+4gdqHWTZJYbUd7GjI6+VK62iKwk7S7xVLiIvhPs2lyt4fG4WHT7LjQ TVJRP8naI+ppgVg8lPhQ== Received: by 10.150.61.21 with SMTP id j21mr3973922yba.378.1309655015353; Sat, 02 Jul 2011 18:03:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.14 with HTTP; Sat, 2 Jul 2011 18:03:15 -0700 (PDT) In-Reply-To: <20110703100844.68eb8b7d@opy.nosense.org> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703100844.68eb8b7d@opy.nosense.org> From: Lorenzo Colitti Date: Sun, 3 Jul 2011 03:03:15 +0200 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=000e0cd4b5d2f7ef2d04a71fd1a8 X-System-Of-Record: true Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 01:03:39 -0000 --000e0cd4b5d2f7ef2d04a71fd1a8 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith < ipng@69706e6720323030352d30312d31340a.nosense.org> wrote: > We know it can operate correctly and reliably if it > is configured correctly. ... and in networks where there are public IP addresses and no firewalling, and... etc. etc. But we already had this discussion on v6ops, and since the consensus of the WG was that the draft should be published, there's no point having it again. --000e0cd4b5d2f7ef2d04a71fd1a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>= wrote:
We know it can operate correctly and reliab= ly if it
is configured correctly.

... and in networks whe= re there are public IP addresses and no firewalling, and... etc. etc.
=

But we alre= ady had this discussion on v6ops, and since the consensus of the WG was tha= t the draft should be published, there's no point having it again. --000e0cd4b5d2f7ef2d04a71fd1a8-- From dougb@dougbarton.us Sat Jul 2 18:04:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A440611E80A9 for ; Sat, 2 Jul 2011 18:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEWHquuGqY4x for ; Sat, 2 Jul 2011 18:04:35 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id D187E11E808D for ; Sat, 2 Jul 2011 18:04:34 -0700 (PDT) Received: (qmail 4969 invoked by uid 399); 3 Jul 2011 01:04:33 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 3 Jul 2011 01:04:33 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E0FC01B.7010709@dougbarton.us> Date: Sat, 02 Jul 2011 18:04:27 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Cameron Byrne References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 01:04:35 -0000 On 07/02/2011 12:21, Cameron Byrne wrote: > > On Jul 2, 2011 11:55 AM, "Lorenzo Colitti" > wrote: > > > > On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica > wrote: > >> > >> - In order for the new draft to be published, it must achieve both > V6OPS WG and IETF consensus > >> > >> If anyone objects to this course of action, please speak up soon. > > > > > > Great, back to square one. > > > > Is the reasoning behind the decision explained somewhere? My reading > of the threads on the subject in v6ops was that the opposition to > 6to4-historic was a small but vocal minority, and I thought that > qualified as rough consensus. But perhaps I missed some discussion. > > > > I saw the same thing. It is a shame that work that directly removes > barriers to REAL ipv6 deployment gets shouted down by a few people not > involved in REAL ipv6 deployment. I can't speak to the "REAL" bit, but I agree that this is a very disappointing turn of events. Consensus is not the same as "universal agreement," and I don't think the fact that a few people are repeating the same marginally-relevant-at-best points over and over again should have sidetracked this process. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From ek@google.com Sat Jul 2 18:10:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E15A21F851A for ; Sat, 2 Jul 2011 18:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d-R9sdtkcwY for ; Sat, 2 Jul 2011 18:10:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 79EDD21F84CC for ; Sat, 2 Jul 2011 18:10:10 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p631A534006589 for ; Sat, 2 Jul 2011 18:10:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309655405; bh=OaNIdD7RLY/s/nzS8KCAJJnKuK8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=CIjB2rdpp2wOLFY8XSx/BT9vbprSm75/ek/fcmxkj1zQrXy0NWCjTT5zbZ9A7yQlY r5hZP3lgcTR4WJAjV4uIg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=KYgTR9phkpJZwBeb5neDKUq89A8JtZfrdm2wVxHT7+bUog6zKPag5itex2LvpC/yo tNOlzh4DvVFnBXN3/ZpnA== Received: from pzk27 (pzk27.prod.google.com [10.243.19.155]) by wpaz9.hot.corp.google.com with ESMTP id p631A4S2001847 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 2 Jul 2011 18:10:04 -0700 Received: by pzk27 with SMTP id 27so1849198pzk.13 for ; Sat, 02 Jul 2011 18:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zIWEw0Ka1pq8K+2nDAQpwwFVcYfmad+NUMgS1ZUiW6I=; b=qUpUbmYqaZzcbrmAz+yye3NHHoUBKuiVrjzeOoBEyUmXs1mpHCnja8HkKKIrEnvGUe CRwPjvkG6TYKQXJ19n3g== MIME-Version: 1.0 Received: by 10.142.121.15 with SMTP id t15mr2230844wfc.324.1309655403736; Sat, 02 Jul 2011 18:10:03 -0700 (PDT) Received: by 10.142.179.17 with HTTP; Sat, 2 Jul 2011 18:10:03 -0700 (PDT) In-Reply-To: <20110703100844.68eb8b7d@opy.nosense.org> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703100844.68eb8b7d@opy.nosense.org> Date: Sun, 3 Jul 2011 10:10:03 +0900 Message-ID: From: Erik Kline To: Mark Smith Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 01:10:11 -0000 All, > Perhaps declaring 6to4 deprecated rather than historic would have a > better chance of consensus. Pardon my ignorance, but where is the document describing the implications of historic{,al} vs deprecated? This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known: """ A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. (Purists have suggested that the word should be "Historical"; however, at this point the use of "Historic" is historical.) Note: Standards track specifications normally must not depend on other standards track specifications which are at a lower maturity level or on non standards track specifications other than referenced specifications from other standards bodies. (See Section 7.) """ I don't know where similar explanatory language about "Deprecated" might be (I'm sure I just didn't search correctly or long enough). From lorenzo@google.com Sat Jul 2 18:43:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157181F0C41 for ; Sat, 2 Jul 2011 18:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.376 X-Spam-Level: X-Spam-Status: No, score=-105.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afkq3NBLMAtG for ; Sat, 2 Jul 2011 18:43:12 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 396C61F0C36 for ; Sat, 2 Jul 2011 18:43:11 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p631Abqc005822 for ; Sat, 2 Jul 2011 18:10:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309655438; bh=tC51SSlsa08/fg8IsM/Ckfnp2Tk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=SomqA4gHWCY2L/3jfRUO+9rJ0RwrAHXKFrKY1AJKGcWBi0ghGlsP7U7VXUlpY+Exo KJKOfUUBVz8JTs8mYzPrg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=c7s6vGb3ZyWHxyvRqT806Icd58gPuBo1xOryzDMJtsMrsDy5a+/2hCwc1q0KJ2tRY ORBQg32/nvDxttSY3M55Q== Received: from ywb26 (ywb26.prod.google.com [10.192.2.26]) by wpaz17.hot.corp.google.com with ESMTP id p631AZ9u031349 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 2 Jul 2011 18:10:36 -0700 Received: by ywb26 with SMTP id 26so2076113ywb.0 for ; Sat, 02 Jul 2011 18:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kVMhOhtA6nvvRqLlM+60LESlYV0TdqAap/xhFK//F4E=; b=u4uEIyFzWpGL6vtIRNo2a4XMYfNEvXaz31Qar9xkut9rEAzJHXmCER5b1gIN4rh+PQ GEU6texPNdly4Lo1973Q== Received: by 10.150.183.3 with SMTP id g3mr4000949ybf.264.1309655435184; Sat, 02 Jul 2011 18:10:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.14 with HTTP; Sat, 2 Jul 2011 18:10:15 -0700 (PDT) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> From: Lorenzo Colitti Date: Sun, 3 Jul 2011 03:10:15 +0200 Message-ID: To: Keith Moore Content-Type: multipart/alternative; boundary=000e0cd6ecd8fe0b5004a71fea11 X-System-Of-Record: true Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 01:43:13 -0000 --000e0cd6ecd8fe0b5004a71fea11 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 2, 2011 at 10:02 PM, Keith Moore wrote: > > Is the reasoning behind the decision explained somewhere? My reading of > the threads on the subject in v6ops was that the opposition to 6to4-historic > was a small but vocal minority, and I thought that qualified as rough > consensus. > > Even if there was rough consensus within v6ops, rough consensus of v6ops > does not equate to rough consensus of the entire IETF community. > And who says that "rough consensus of the entire IETF community" is that this draft should not be published? Were there public discussions to that effect that came to this conclusion? --000e0cd6ecd8fe0b5004a71fea11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 2, 2011 at 10:02 PM, Keith Moore <moore@netw= ork-heretics.com> wrote:
> Is the reasoning behind the decision explained somew= here? My reading of the threads on the subject in v6ops was that the opposi= tion to 6to4-historic was a small but vocal minority, and I thought that qu= alified as rough consensus.

Even if there was rough consensus within v6ops, rough consensus of v6= ops does not equate to rough consensus of the entire IETF community.

And who says that "rough consensus of th= e entire IETF community"=A0is that this draft should not be published?= Were there public discussions to that effect that came to this conclusion?=
--000e0cd6ecd8fe0b5004a71fea11-- From randy@psg.com Sat Jul 2 18:47:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B5D21F8674; Sat, 2 Jul 2011 18:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeqjtgbyeGGt; Sat, 2 Jul 2011 18:47:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A3F2321F8673; Sat, 2 Jul 2011 18:47:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QdBmF-000FMg-7I; Sun, 03 Jul 2011 01:47:15 +0000 Date: Sun, 03 Jul 2011 10:47:13 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "v6ops@ietf.org" , Keith Moore , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 01:47:20 -0000 > And who says that "rough consensus of the entire IETF community" is > that this draft should not be published? Were there public discussions > to that effect that came to this conclusion? that is usually determined when the iesg last calls the document after the wg has passed it to the iesg. the ipv6 heads are amazingly immune to reality. 6to4 has been measured and clearly demonstrated to have failed in the field. yes, it could work. but it doesn't. we need to get over it. randy From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Jul 2 18:50:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F2B21F8674; Sat, 2 Jul 2011 18:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdSVT3KqeyRi; Sat, 2 Jul 2011 18:50:56 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 72BC421F8673; Sat, 2 Jul 2011 18:50:55 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QdBph-0000mM-Jl; Sun, 03 Jul 2011 11:20:49 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 18B663B33E; Sun, 3 Jul 2011 11:20:49 +0930 (CST) Date: Sun, 3 Jul 2011 11:20:48 +0930 From: Mark Smith To: Cameron Byrne Message-ID: <20110703112048.4a3c7111@opy.nosense.org> In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 01:50:57 -0000 On Sat, 2 Jul 2011 12:21:36 -0700 Cameron Byrne wrote: > On Jul 2, 2011 11:55 AM, "Lorenzo Colitti" wrote: > > > > On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica wrote: > >> > >> - In order for the new draft to be published, it must achieve both V6OPS > WG and IETF consensus > >> > >> If anyone objects to this course of action, please speak up soon. > > > > > > Great, back to square one. > > > > Is the reasoning behind the decision explained somewhere? My reading of > the threads on the subject in v6ops was that the opposition to 6to4-historic > was a small but vocal minority, and I thought that qualified as rough > consensus. But perhaps I missed some discussion. > > > > I saw the same thing. It is a shame that work that directly removes barriers > to REAL ipv6 deployment Where is the evidence that 6to4 is holding back native IPv6 deployment? > gets shouted down by a few people not involved in > REAL ipv6 deployment. > How do you know that? > Welcome to the ietf indeed. > > Cb > > > Also, why do the author and the chairs think that the new draft will do > any better than 6to4-historic? I would assume that the same people who spoke > up against 6to4-historic will speak up against the new document, and since > that level of opposition was sufficient to prevent the publication > of 6to4-historic, it may be sufficient to prevent publication of the new > document as well. If so, we will have spent 3-6 months arguing about it for > naught. > > > > Please, nobody answer this question with "welcome to the IETF" :-) > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Jul 2 18:54:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B21A1F0C55; Sat, 2 Jul 2011 18:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMgCGBw82k+I; Sat, 2 Jul 2011 18:54:22 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id DA3781F0C51; Sat, 2 Jul 2011 18:54:21 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QdBt6-0000qE-Nm; Sun, 03 Jul 2011 11:24:20 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 64AD73B33E; Sun, 3 Jul 2011 11:24:20 +0930 (CST) Date: Sun, 3 Jul 2011 11:24:20 +0930 From: Mark Smith To: Erik Kline Message-ID: <20110703112420.3fcaa58c@opy.nosense.org> In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703100844.68eb8b7d@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 01:54:22 -0000 On Sun, 3 Jul 2011 10:10:03 +0900 Erik Kline wrote: > All, > > > Perhaps declaring 6to4 deprecated rather than historic would have a > > better chance of consensus. > > Pardon my ignorance, but where is the document describing the > implications of historic{,al} vs deprecated? > > This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known: > > """ > A specification that has been superseded by a more recent > specification or is for any other reason considered to be obsolete is > assigned to the "Historic" level. (Purists have suggested that the > word should be "Historical"; however, at this point the use of > "Historic" is historical.) > > Note: Standards track specifications normally must not depend on > other standards track specifications which are at a lower maturity > level or on non standards track specifications other than referenced > specifications from other standards bodies. (See Section 7.) > """ > > I don't know where similar explanatory language about "Deprecated" > might be (I'm sure I just didn't search correctly or long enough). Since 6rd depends on 6to4, as it is a variant of it, would 6to4 being declared historic also mean that 6rd needs to become historic as well? From ek@google.com Sat Jul 2 19:00:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CAD11E8085 for ; Sat, 2 Jul 2011 19:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0s7kp7CPYb1 for ; Sat, 2 Jul 2011 19:00:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3CC1F0C36 for ; Sat, 2 Jul 2011 19:00:41 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p6320eiM011267 for ; Sat, 2 Jul 2011 19:00:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309658441; bh=RHYbPHLdiRpmSUib6HEkRsyXkxI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=GP5h6+yUOypaM0jCrkZ22wf1rK3h1jGefVfO8Hi9DEnDCyjJCsZ55dmfi95zFAuOx x5HfhJIWW1wpi2GnTI+2g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=TtGloGCxujR/tYVRtkUCPZm7b/LYaowL83t9mQbErpHCaUVMvGNCdaVCEdov+JITw Lysdhj4mzcZzu1MMjeY9g== Received: from pzk5 (pzk5.prod.google.com [10.243.19.133]) by hpaq14.eem.corp.google.com with ESMTP id p6320bKl028246 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 2 Jul 2011 19:00:39 -0700 Received: by pzk5 with SMTP id 5so5409998pzk.31 for ; Sat, 02 Jul 2011 19:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+LWpW1yNEPfYSUd+y7it3jBW8fRPZxJa7WJa+kkWGak=; b=vw7iJgGYzOXKeMCigggStEPB68dD/SXIfb2Tw8UwMLvdxYNdefHD53uvNVmvo3XjZi XeH8APx3KRuuvSNKOzlw== MIME-Version: 1.0 Received: by 10.142.128.1 with SMTP id a1mr2159780wfd.438.1309658437337; Sat, 02 Jul 2011 19:00:37 -0700 (PDT) Received: by 10.142.179.17 with HTTP; Sat, 2 Jul 2011 19:00:37 -0700 (PDT) In-Reply-To: <20110703112420.3fcaa58c@opy.nosense.org> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703100844.68eb8b7d@opy.nosense.org> <20110703112420.3fcaa58c@opy.nosense.org> Date: Sun, 3 Jul 2011 11:00:37 +0900 Message-ID: From: Erik Kline To: Mark Smith Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 02:00:41 -0000 >> > Perhaps declaring 6to4 deprecated rather than historic would have a >> > better chance of consensus. >> >> Pardon my ignorance, but where is the document describing the >> implications of historic{,al} vs deprecated? >> >> This (http://tools.ietf.org/html/rfc2026#section-4.2.4) is well known: >> >> """ >> =C2=A0 =C2=A0A specification that has been superseded by a more recent >> =C2=A0 =C2=A0specification or is for any other reason considered to be o= bsolete is >> =C2=A0 =C2=A0assigned to the "Historic" level. =C2=A0(Purists have sugge= sted that the >> =C2=A0 =C2=A0word should be "Historical"; however, at this point the use= of >> =C2=A0 =C2=A0"Historic" is historical.) >> >> =C2=A0 =C2=A0Note: Standards track specifications normally must not depe= nd on >> =C2=A0 =C2=A0other standards track specifications which are at a lower m= aturity >> =C2=A0 =C2=A0level or on non standards track specifications other than r= eferenced >> =C2=A0 =C2=A0specifications from other standards bodies. =C2=A0(See Sect= ion 7.) >> """ >> >> I don't know where similar explanatory language about "Deprecated" >> might be (I'm sure I just didn't search correctly or long enough). > > Since 6rd depends on 6to4, as it is a variant of it, would 6to4 being > declared historic also mean that 6rd needs to become historic as well? http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05 Section 1, in which the draft clarifies that 6rd supersedes 6to4, which meets the qualification in the first paragraph of the "Historic" term. With 6rd we clearly don't need to have anything built on top of 6to4 in the future, addressing the 2nd paragraph. From rbonica@juniper.net Sat Jul 2 19:27:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6F611E80B5; Sat, 2 Jul 2011 19:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.284 X-Spam-Level: X-Spam-Status: No, score=-106.284 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBFSrj-ZXm8q; Sat, 2 Jul 2011 19:27:03 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id D2CC211E8085; Sat, 2 Jul 2011 19:27:01 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTg/TdYx9PcSLjmb0OL3Sosif+bm1WQt0@postini.com; Sat, 02 Jul 2011 19:27:02 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 2 Jul 2011 19:22:34 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sat, 2 Jul 2011 22:22:33 -0400 From: Ronald Bonica To: Lorenzo Colitti Date: Sat, 2 Jul 2011 22:22:32 -0400 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic Thread-Index: Acw46ZSDGm+GNc0bSFSdbCjnIAF0mQAPKgmw Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3507F08@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456D3F3507F08EMBX01WFjnprn_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 02:27:04 -0000 --_000_13205C286662DE4387D9AF3AC30EF456D3F3507F08EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lorenzo, You pose very reasonable questions. I will try to reiterate them: 1) What are the criteria for determining consensus? What makes you thi= nk that there was no consensus on 6-to-4-historic? 2) What makes you think that the new draft is just as good? 3) What makes you think that the new draft will do any better than 6-t= o-4-historic? Responses follow: 1) Because we do not vote in the IETF, the process for determining con= sensus is squishy. A simple majority does not win the day. A few strongly h= eld objections backed by even a scintilla of technical rational can increas= e the size of the super-majority required to declare consensus. While it wa= s not clear that the IETF has achieved consensus regarding 6-to-4-historic,= it also was not clear that the IETF had not achieved consensus. In this c= ase, we had a choice between spending cycles arguing about consensus, or fi= nding a solution that everybody could live with. 2) IMHO, the new draft will not be as good as 6-to-4-historic. However= , it solves the operational problem by disabling 6-to-4 by default. That's = much better than nothing. 3) I have been working behind the scenes with a few of those who objec= ted to 6-to-4-historic. They didn't object to the new draft. However, I inv= ite those people to speak for themselves. = Ron From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: Saturday, July 02, 2011 2:55 PM To: Ronald Bonica Cc: v6ops@ietf.org; IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica > wrote: - In order for the new draft to be published, it must achieve both V6OPS WG= and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the= threads on the subject in v6ops was that the opposition to 6to4-historic w= as a small but vocal minority, and I thought that qualified as rough consen= sus. But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any= better than 6to4-historic? I would assume that the same people who spoke u= p against 6to4-historic will speak up against the new document, and since t= hat level of opposition was sufficient to prevent the publication of 6to4-h= istoric, it may be sufficient to prevent publication of the new document as= well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with "welcome to the IETF" :-) --_000_13205C286662DE4387D9AF3AC30EF456D3F3507F08EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lorenzo,<= o:p>

 

You pose very reasonable questions.  I w= ill try to reiterate them:

 

1) &= nbsp;    What are the = criteria for determining consensus? What makes you think that there was no = consensus on 6-to-4-historic?

2)      What makes you think that the new draft is just as good?=

3)    &n= bsp; What makes you think that the ne= w draft will do any better than 6-to-4-historic?

 

Responses follow:

 

1)  &= nbsp;   Because we do not v= ote in the IETF, the process for determining consensus is squishy. A simple= majority does not win the day. A few strongly held objections backed by ev= en a scintilla of technical rational can increase the size of the super-maj= ority required to declare consensus. While it was not clear that the IETF h= as achieved consensus regarding 6-to-4-historic, it also was not clear that= the IETF had not achieved consensus.  In this case, we had a choice b= etween spending cycles arguing about consensus, or finding a solution that = everybody could live with.

= 2)      IMHO, the new draft will not be as good as 6-to-4-historic. However, i= t solves the operational problem by disabling 6-to-4 by default. That’= ;s much better than nothing.

3)      = I have been working behind the scenes with a few of those who object= ed to 6-to-4-historic. They didn’t object to the new draft. However, = I invite those people to speak for themselves.

 

            &= nbsp;           &nbs= p;             =             &nb= sp;            =             &nb= sp;            =             &nb= sp;        Ron

 

 

From: Lorenzo Colitti [mailto:lorenzo@google.com]
<= b>Sent: Saturday, July 02, 2011 2:55 PM
To: Ronald Bonica
= Cc: v6ops@ietf.org; IETF Discussion
Subject: Re: [v6ops] d= raft-ietf-v6ops-6to4-to-historic

 

On Sat, Jul 2, 2011 at 6:36 PM, Ronald Boni= ca <rbonica@juniper.net> w= rote:

- In or= der for the new draft to be published, it must achieve both V6OPS WG and IE= TF consensus

If anyone objects to this course of action, please spea= k up soon.

 

Great, back to square one.

 

Is the reasoning behind the decisio= n explained somewhere? My reading of the threads on the subject in v6o= ps was that the opposition to 6to4-historic was a small but vocal minority,= and I thought that qualified as rough consensus. But perhaps I missed some= discussion.

 

Also, why do the author and the chairs think that the new d= raft will do any better than 6to4-historic? I would assume that the same pe= ople who spoke up against 6to4-historic will speak up against the new docum= ent, and since that level of opposition was sufficient to prevent the publi= cation of 6to4-historic, it may be sufficient to prevent publication o= f the new document as well. If so, we will have spent 3-6 months argui= ng about it for naught.

 

Please, nobody answer this question with "w= elcome to the IETF" :-)

= --_000_13205C286662DE4387D9AF3AC30EF456D3F3507F08EMBX01WFjnprn_-- From frnkblk@iname.com Sat Jul 2 19:27:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3771F0C58; Sat, 2 Jul 2011 19:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViYyfHk7VeOg; Sat, 2 Jul 2011 19:27:30 -0700 (PDT) Received: from premieronline.net (smtp1-1.premieronline.net [96.31.0.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB5F1F0C51; Sat, 2 Jul 2011 19:27:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from BULKFAMLAPTOP (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 28002088-1729245 for multiple; Sat, 02 Jul 2011 21:27:29 -0500 From: "Frank Bulk" To: "'Keith Moore'" , References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <4E0F7E12.8060901@raszuk.net> <3D17B847-7424-4A31-8072-761DDFDCA5B1@network-heretics.com> In-Reply-To: <3D17B847-7424-4A31-8072-761DDFDCA5B1@network-heretics.com> Date: Sat, 2 Jul 2011 21:27:21 -0500 Message-ID: <000901cc3928$bcecc390$36c64ab0$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acw49ktlhIzQhtzbRsGEtIMtvA8XQgAMOZyg Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (useraccess) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=0 Friend=278 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 847, in=13000838, out=61735, spam=0 Known=true ip=199.120.69.26 Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 02:27:31 -0000 Yes, the Linksys E2000, E3000, E4200, WRT610N, and a small batch of Apple Airports had 6to4 on by default, but the latest firmware versions turn that off. Frank -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Keith Moore Sent: Saturday, July 02, 2011 3:26 PM To: robert@raszuk.net Cc: v6ops@ietf.org; IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic On Jul 2, 2011, at 4:22 PM, Robert Raszuk wrote: > Hi Keith, > >> I personally don't have any objection to the notion that 6to4 should >> be off by default and should require explicit configuration to enable >> it. > > Is there any feature (perhaps other then netboot) on commercial or open source routers which is not off by default and which would require explicit configuration to enable it ? I have understood that in the past there were a few routers that enabled 6to4 by default, though I don't know whether this is the case any longer. I also believe that there are currently hosts that enable 6to4 by default if there is no native v6 connectivity and the host has a public IPv4 address. Keith _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From dougb@dougbarton.us Sat Jul 2 19:39:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69D821F8670 for ; Sat, 2 Jul 2011 19:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6irNInbA9db for ; Sat, 2 Jul 2011 19:39:13 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0C50321F866F for ; Sat, 2 Jul 2011 19:39:12 -0700 (PDT) Received: (qmail 7012 invoked by uid 399); 3 Jul 2011 02:39:07 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 3 Jul 2011 02:39:07 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E0FD649.6000305@dougbarton.us> Date: Sat, 02 Jul 2011 19:39:05 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ronald Bonica References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D3F3507F08@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3507F08@EMBX01-WF.jnpr.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 02:39:14 -0000 On 07/02/2011 19:22, Ronald Bonica wrote: > 1)Because we do not vote in the IETF, the process for determining > consensus is squishy. A simple majority does not win the day. A few > strongly held objections backed by even a scintilla of technical > rational can increase the size of the super-majority required to declare > consensus. While it was not clear that the IETF has achieved consensus > regarding 6-to-4-historic, it also was not clear that the IETF had not > achieved consensus. In this case, we had a choice between spending > cycles arguing about consensus, or finding a solution that everybody > could live with. IMO that is the wrong goal. Consensus does not mean universal agreement. Trying to get "a solution that everybody could live with" all too often results in a product with no operational value. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From dougb@dougbarton.us Sat Jul 2 19:44:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A9C21F84FA for ; Sat, 2 Jul 2011 19:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe0KjuwZu1QK for ; Sat, 2 Jul 2011 19:44:27 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id B344421F84F7 for ; Sat, 2 Jul 2011 19:44:26 -0700 (PDT) Received: (qmail 10313 invoked by uid 399); 3 Jul 2011 02:44:25 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 3 Jul 2011 02:44:25 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E0FD788.3000305@dougbarton.us> Date: Sat, 02 Jul 2011 19:44:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mark Smith References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> In-Reply-To: <20110703112048.4a3c7111@opy.nosense.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 02:44:27 -0000 On 07/02/2011 18:50, Mark Smith wrote: > Where is the evidence that 6to4 is holding back native IPv6 > deployment? It's been discussed ad nauseum in numerous fora. Bad 6to4 (which almost all of it is) results in a poor user experience when the largest content providers enable AAAA records. Thus, they are less inclined to enable them. I realize that there are a lot of people that dismiss both the evidence that's been put forward and the rationale, but it's been presented and discussed pretty thoroughly. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jnc@mercury.lcs.mit.edu Sat Jul 2 20:05:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D0921F86A1; Sat, 2 Jul 2011 20:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYvsS+EmyH6p; Sat, 2 Jul 2011 20:05:51 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id B413021F868E; Sat, 2 Jul 2011 20:05:51 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7BF9618C1BA; Sat, 2 Jul 2011 23:05:48 -0400 (EDT) To: ietf@ietf.org, v6ops@ietf.org Message-Id: <20110703030548.7BF9618C1BA@mercury.lcs.mit.edu> Date: Sat, 2 Jul 2011 23:05:48 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:05:52 -0000 > From: Cameron Byrne > It is a shame that work that directly removes barriers to REAL ipv6 > deployment gets shouted down So, perhaps you can explain something to me, since nobody else has been able to. I think there is pretty much complete consensus that i) 6to4 doesn't work in several very common environments (behind a NAT, etc, etc), and that therefore, ii) at the very least, it should be disabled by default (and therefore only turned on by knowledgeable users who know they are not in one of those situations). Given and assuming a document that makes all that formal, _what else_ does the _additional_ step of making 6to4 historic buy? Are you thinking that people will see this knob called '6to4' and turn it on, and cause support issues? This seems unlikely to me - e.g. they don't seem to commonly turn off DHCP on their NAT boxes (a switch most NAT boxes seem to provide). Or perhaps the concept is that nuking 6to4 will help force ISPs to deploy native IPv6, since it removes one way for users to get IPv6 if their provider doesn't supply it? If so, why not ditch Teredo, too? (Not to mention that 'mandate it and they will come' hasn't worked to well so far.) In short, I just cannot fathom what concrete benefit the _additional_ step of marking the protocol 'historic' provides, _over and above_ just issuing the 'do not enable 6to4 automatically because it has problems' document. Can you point to such a benefit? Noel From moore@network-heretics.com Sat Jul 2 20:11:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1354A21F86BF; Sat, 2 Jul 2011 20:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPEVMZ8t9pho; Sat, 2 Jul 2011 20:11:06 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 71B4721F86BA; Sat, 2 Jul 2011 20:11:06 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 24914207EF; Sat, 2 Jul 2011 23:11:06 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Sat, 02 Jul 2011 23:11:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=42755ZXt8T0wBFyoIcKDMRMdMdk=; b=YkVijo4vVOpUYQksklAJ0OnNzICsxuGuuxj3dhElwbW9pHCmp+0gTKzHRIA1FHVQ9FwVDNI+O3Gmn4ICwkV3CGJN3Mrv8XSbIwJGOJlZgju2vgxqh5+7K0tt7KtCphvJmxadGZbfhFk6ALmX/FRiAinLrAN3o3bXQupWro3BlA8= X-Sasl-enc: oSMYFF5J/NcilPC+4NdTMxfOua8GRvvEfbkURmMuINqb 1309662665 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 05C55400782; Sat, 2 Jul 2011 23:11:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-111-642965515 From: Keith Moore In-Reply-To: Date: Sat, 2 Jul 2011 23:10:47 -0400 Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:11:07 -0000 --Apple-Mail-111-642965515 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 2, 2011, at 3:21 PM, Cameron Byrne wrote: > I saw the same thing. It is a shame that work that directly removes = barriers to REAL ipv6 deployment gets shouted down by a few people not = involved in REAL ipv6 deployment >=20 I find myself wondering what you mean by REAL IPv6. For me, REAL IPv6 = is code that uses the IPv6 programming model, 128 bit addresses, = end-to-end transparency, no NATs. 6to4 certainly qualifies. Keith --Apple-Mail-111-642965515 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I saw the = same thing. It is a shame that work that directly removes barriers to = REAL ipv6 deployment gets shouted down by a few people not involved in = REAL ipv6 deployment


I find myself = wondering what you mean by REAL IPv6.  For me, REAL IPv6 is code = that uses the IPv6 programming model, 128 bit addresses, end-to-end = transparency, no NATs.  6to4 certainly = qualifies.

Keith

= --Apple-Mail-111-642965515-- From moore@network-heretics.com Sat Jul 2 20:12:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D00721F86E3; Sat, 2 Jul 2011 20:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1aGcJU7+DGw; Sat, 2 Jul 2011 20:12:05 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7919E21F86E4; Sat, 2 Jul 2011 20:12:02 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 2DFE5207B5; Sat, 2 Jul 2011 23:12:02 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 02 Jul 2011 23:12:02 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=4dY+MfqvK0OjceVca2gdYy8l5YE=; b=ieefxvqlOno4eAnt4yjMG0Qz0UCYlSs/84ow3fzS5ZQG6XsHMd8MLNx+NcmCisiANQHi+nwOvJO6H8WEyIzv0PsT5i9xVPfRDgJIhuTqzABpVaT+z2XXCUTPT2awD/IeFcpjHnnYprbBJFjXONiSGyXPintEb5t+rS6yayoagiY= X-Sasl-enc: WObtovw2RtEQF+AMrYn8+KbANYsHa5xpXf6c5HTRysIp 1309662721 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 1B8EA400782; Sat, 2 Jul 2011 23:12:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-112-643022195 From: Keith Moore In-Reply-To: Date: Sat, 2 Jul 2011 23:11:43 -0400 Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:12:05 -0000 --Apple-Mail-112-643022195 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 2, 2011, at 9:10 PM, Lorenzo Colitti wrote: > On Sat, Jul 2, 2011 at 10:02 PM, Keith Moore = wrote: > > Is the reasoning behind the decision explained somewhere? My reading = of the threads on the subject in v6ops was that the opposition to = 6to4-historic was a small but vocal minority, and I thought that = qualified as rough consensus. >=20 > Even if there was rough consensus within v6ops, rough consensus of = v6ops does not equate to rough consensus of the entire IETF community. >=20 > And who says that "rough consensus of the entire IETF community" is = that this draft should not be published? Were there public discussions = to that effect that came to this conclusion? There's clearly a lack of consensus to support it. Keith --Apple-Mail-112-643022195 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 2, 2011, at 9:10 PM, Lorenzo Colitti wrote:

On Sat, Jul 2, 2011 at 10:02 PM, Keith Moore <moore@network-heretics.com> wrote:
> Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus.

Even if there was rough consensus within v6ops, rough consensus of v6ops does not equate to rough consensus of the entire IETF community.

And who says that "rough consensus of the entire IETF community" is that this draft should not be published? Were there public discussions to that effect that came to this conclusion?

There's clearly a lack of consensus to support it.

Keith

--Apple-Mail-112-643022195-- From moore@network-heretics.com Sat Jul 2 20:15:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2319821F86F9; Sat, 2 Jul 2011 20:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFme1Tun3G5z; Sat, 2 Jul 2011 20:15:12 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9512521F86EA; Sat, 2 Jul 2011 20:15:12 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 4B07B20834; Sat, 2 Jul 2011 23:15:12 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Sat, 02 Jul 2011 23:15:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=fYMKkohlyBAoTkhZurh9g5VFceY=; b=UbcKQx1RHKLKJ9t3EAIiWfRFl1GgzT4DeQKViQEB7U9/xRd5oIPzpKLspPXiDPGOHGFQqg21FUeP7HF+LF5lQkc29xtnQseyO53L2NHGyMk5E/VeGNK8JY2DJIw49DYyzaqwsFnNvFXN+YoEzKcQMAQOuaT7tqrqBQCyfxxS50Q= X-Sasl-enc: sS74L6oRMJzubBc9XT2FGhPy3HVVTxbt84h/Nw/hpkD3 1309662911 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 335AF402C3F; Sat, 2 Jul 2011 23:15:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-113-643211734 From: Keith Moore In-Reply-To: Date: Sat, 2 Jul 2011 23:14:53 -0400 Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703100844.68eb8b7d@opy.nosense.org> <20110703112420.3fcaa58c@opy.nosense.org> To: Erik Kline X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:15:13 -0000 --Apple-Mail-113-643211734 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Jul 2, 2011, at 10:00 PM, Erik Kline wrote: >> Since 6rd depends on 6to4, as it is a variant of it, would 6to4 being >> declared historic also mean that 6rd needs to become historic as well? > > http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05 > Section 1, in which the draft clarifies that 6rd supersedes 6to4, which is of course completely incorrect. Keith --Apple-Mail-113-643211734 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Since 6rd depends on 6to4, as it is a variant of it, would = 6to4 being
declared historic = also mean that 6rd needs to become historic as = well?

h= ttp://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05
Sect= ion 1, in which the draft clarifies that 6rd supersedes = 6to4,

which is of course = completely = incorrect.

Keith


= --Apple-Mail-113-643211734-- From moore@network-heretics.com Sat Jul 2 20:20:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3978321F86F5; Sat, 2 Jul 2011 20:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.214 X-Spam-Level: X-Spam-Status: No, score=-3.214 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4M31d8-W+iIn; Sat, 2 Jul 2011 20:20:57 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7CD21F86C0; Sat, 2 Jul 2011 20:20:57 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 175EB2074C; Sat, 2 Jul 2011 23:20:57 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Sat, 02 Jul 2011 23:20:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=yu0HP7mIftKZwNl/Je9pW3TqftE=; b=sFjKx0xINnNsnOshAjHe52+so4bH/iG3Ngv0WlsF1NzNIsXViy4h4FBEE6CGdSCuZG8diH/PTD93DT54pzeKPzqfGdpPkmIdx4qUK01gSzDaj6nC2RzQp0MRDfOg2UNdfs+0V/TKysc8mU99rJ53j3pyVx4avpE1vYI6SCSkee4= X-Sasl-enc: Sni4OBGbe9THY2gQTHljkohdDIescHVSTj0VsbwBhnbI 1309663256 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id A62BD4033D6; Sat, 2 Jul 2011 23:20:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-114-643556105 From: Keith Moore In-Reply-To: <4E0FD649.6000305@dougbarton.us> Date: Sat, 2 Jul 2011 23:20:37 -0400 Message-Id: <99063FC4-467D-477A-A369-D22AA60881FD@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D3F3507F08@EMBX01-WF.jnpr.net> <4E0FD649.6000305@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:20:59 -0000 --Apple-Mail-114-643556105 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 2, 2011, at 10:39 PM, Doug Barton wrote: > On 07/02/2011 19:22, Ronald Bonica wrote: >> 1)Because we do not vote in the IETF, the process for determining >> consensus is squishy. A simple majority does not win the day. A few >> strongly held objections backed by even a scintilla of technical >> rational can increase the size of the super-majority required to = declare >> consensus. While it was not clear that the IETF has achieved = consensus >> regarding 6-to-4-historic, it also was not clear that the IETF had = not >> achieved consensus. In this case, we had a choice between spending >> cycles arguing about consensus, or finding a solution that everybody >> could live with. >=20 > IMO that is the wrong goal. Consensus does not mean universal = agreement. Trying to get "a solution that everybody could live with" all = too often results in a product with no operational value. IMO you're thinking about this the wrong way. if a document is to be = published with IETF's imprimatur, it needs to adhere to IETF's rules. = Those rules require, for a standards action, at least rough = community-wide consensus. =20 When a narrowly focused working group declares consensus within itself, = that clearly doesn't speak for the whole IETF. The fact that the = consensus was quite rough even within the v6ops group should have been = understood as a sign that the proposed action might not win consensus = overall - especially given that several of the objections came from = non-operators who are not well represented in v6ops. Keith --Apple-Mail-114-643556105 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = 07/02/2011 19:22, Ronald Bonica wrote:
1)Because we do not vote in the IETF, the process for = determining
consensus is = squishy. A simple majority does not win the day. A = few
strongly held objections = backed by even a scintilla of technical
rational can increase the size of the super-majority = required to declare
consensus. = While it was not clear that the IETF has achieved = consensus
regarding = 6-to-4-historic, it also was not clear that the IETF had = not
achieved consensus. =  In this case, we had a choice between = spending
cycles arguing about = consensus, or finding a solution that = everybody
could live = with.

IMO that is the wrong goal. Consensus does not = mean universal agreement. Trying to get "a solution that everybody could = live with" all too often results in a product with no operational = value.

IMO = you're thinking about this the wrong way.  if a document is to be = published with IETF's imprimatur, it needs to adhere to IETF's rules. =  Those rules require, for a standards action, at least rough = community-wide consensus.  

When a = narrowly focused working group declares consensus within itself, that = clearly doesn't speak for the whole IETF.  The fact that the = consensus was quite rough even within the v6ops group should have been = understood as a sign that the proposed action might not win consensus = overall - especially given that several of the objections came from = non-operators who are not well represented in = v6ops.

Keith

= --Apple-Mail-114-643556105-- From melinda.shore@gmail.com Sat Jul 2 20:08:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC21B21F86B2; Sat, 2 Jul 2011 20:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLrgKm128EQx; Sat, 2 Jul 2011 20:08:57 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35E0E21F86B1; Sat, 2 Jul 2011 20:08:57 -0700 (PDT) Received: by pzk5 with SMTP id 5so5441275pzk.31 for ; Sat, 02 Jul 2011 20:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tr5nBUmA0YlgeOd/Rt6/Kt8PJ42ZDOYwRmJBnKWlJ6g=; b=AVMDY4ooN65lRDiyAbX4BO9ORCcXPqk0UYNohbyjuQsrcWGoqAYCAW5sMm2DO3QgBS ZoVKklbSJcMejIfOpx1hvgE4wu4muI4ZOIm5wQuGiACEezyNhRg/TXopukEMnXTzKjSZ iV+lmpfWA31TXJea61S8xrPuA4hq2NTRjAESc= Received: by 10.142.249.4 with SMTP id w4mr2221507wfh.118.1309662536748; Sat, 02 Jul 2011 20:08:56 -0700 (PDT) Received: from polypro.local (216-67-41-245-rb1.fai.dsl.dynamic.acsalaska.net [216.67.41.245]) by mx.google.com with ESMTPS id w24sm3171876wfd.17.2011.07.02.20.08.54 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 02 Jul 2011 20:08:55 -0700 (PDT) Message-ID: <4E0FDD44.2030207@gmail.com> Date: Sat, 02 Jul 2011 19:08:52 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Doug Barton References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D3F3507F08@EMBX01-WF.jnpr.net> <4E0FD649.6000305@dougbarton.us> In-Reply-To: <4E0FD649.6000305@dougbarton.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 02 Jul 2011 20:27:11 -0700 Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:08:57 -0000 On 7/2/11 6:39 PM, Doug Barton wrote: > IMO that is the wrong goal. Consensus does not mean universal agreement. > Trying to get "a solution that everybody could live with" all too often > results in a product with no operational value. "Everybody can live with" is pretty much the universal operating definition of "consensus" in organizations that use consensus decision-making. I've got some concerns, as well, that effort is being put into technologies that there's no incentive to use, but in terms of *process* Ron is spot-on. Melinda From michel@arneill-py.sacramento.ca.us Sat Jul 2 20:21:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2236921F861C; Sat, 2 Jul 2011 20:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQAL3H4z3+Ab; Sat, 2 Jul 2011 20:21:47 -0700 (PDT) Received: from arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [69.12.226.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA6721F85D9; Sat, 2 Jul 2011 20:21:47 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Date: Sat, 2 Jul 2011 20:21:47 -0700 Message-ID: <392CB277BC2EAE4FB83C1206954BA6CEF5DD@newserver.arneill-py.local> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-v6ops-6to4-to-historic Thread-Index: Acw41iMv6/qWspvgTzCQB463JqIp+AAWaB7g References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> From: "Michel Py" To: "Ronald Bonica" , , "IETF Discussion" X-Mailman-Approved-At: Sat, 02 Jul 2011 20:27:11 -0700 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:21:48 -0000 Subject to reading the not-available-yet text, I support this approach. It appears to be reasonable political compromise. Michel. -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Saturday, July 02, 2011 9:36 AM To: v6ops@ietf.org; IETF Discussion Subject: draft-ietf-v6ops-6to4-to-historic Folks, Whereas there has been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have agreed to the following course of action: - the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-to-historic - The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default.=20 - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Ron _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From rbonica@juniper.net Sat Jul 2 20:36:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505D921F865C; Sat, 2 Jul 2011 20:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.268 X-Spam-Level: X-Spam-Status: No, score=-106.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3KUJgzpGn3A; Sat, 2 Jul 2011 20:36:37 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F067821F8652; Sat, 2 Jul 2011 20:36:34 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTg/jwcvfip3vVp0DtyymeNJgLTBDDd44@postini.com; Sat, 02 Jul 2011 20:36:37 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 2 Jul 2011 20:31:58 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sat, 2 Jul 2011 23:31:57 -0400 From: Ronald Bonica To: Randy Bush , Lorenzo Colitti Date: Sat, 2 Jul 2011 23:31:55 -0400 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic Thread-Index: Acw4/+4kG+zoOyaUR+WA27uNwTu/kgALaaKQ Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3507F14@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:36:38 -0000 Randy, You have three points that deserve to be addressed. These are: 1) "as measured on the real internet, not the ietf bar, 6to4 sucks caterpil= lar snot" 2) "perhaps that minority was also vocal in the back room" 3) "yes, but that will be a year from now. in the ietf, delay is one form = of death" Responses follow: 1) While not stated so colorfully, draft-ietf-v6ops-6to4-advisory made this= point. It has been approved for publication. 2) While there was no back-room activity, an appeal had been filed at the W= G level. Since WG consensus was stronger than IETF consensus, it is reasona= ble to assume that the appeal would be escalated to the IESG level if it wa= s not approved at the WG level. So, any way you look at it, there would be = delays. 3) The new document may not take a year to publish. Since it is a short dra= ft, it could be produced in a few days. Once it is produced, we could immed= iately initiate a WG last call and an IETF last call immediately after that= . So, we might be talking about a six-week delay. Now, I have a question for you, Lorenzo and Doug. If our goal is to take 6-= to-4 off of the Internet, does not disabling it by default solve most of th= e problem? AFAIKS, very few users would enable it and service providers wou= ld not be economically incented to support 6-to-4 relay routers.=20 Comments? Ron =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of R= andy Bush Sent: Saturday, July 02, 2011 5:35 PM To: Lorenzo Colitti Cc: IPv6 Ops WG; IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic >> If anyone objects to this course of action, please speak up soon. i object. as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot. it is damaging to the users and to the users' view of ipv6. > Great, back to square one. >=20 > Is the reasoning behind the decision explained somewhere? My reading of t= he > threads on the subject in v6ops was that the opposition to 6to4-historic = was > a small but vocal minority, and I thought that qualified as rough consens= us. perhaps that minority was also vocal in the back room > But perhaps I missed some discussion. >=20 > Also, why do the author and the chairs think that the new draft will do a= ny > better than 6to4-historic? I would assume that the same people who spoke = up > against 6to4-historic will speak up against the new document, yes, but that will be a year from now. in the ietf, delay is one form of death. > and since that level of opposition was sufficient to prevent the > publication of 6to4-historic, it may be sufficient to prevent > publication of the new document as well. If so, we will have spent 3-6 > months arguing about it for naught. >=20 > Please, nobody answer this question with "welcome to the IETF" :-) this is nutso. but this is normal. welcome to the ietf randy _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Sat Jul 2 20:41:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674BB21F8622; Sat, 2 Jul 2011 20:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLytmaxKRLlP; Sat, 2 Jul 2011 20:41:11 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 89C1621F861E; Sat, 2 Jul 2011 20:41:10 -0700 (PDT) Received: from [192.168.11.127] (c-76-115-172-69.hsd1.wa.comcast.net [76.115.172.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p633euuE024477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 3 Jul 2011 03:40:57 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8-644769954 From: Joel Jaeggli In-Reply-To: Date: Sat, 2 Jul 2011 20:40:51 -0700 Message-Id: <8EB62DB6-1073-40F1-AC26-071958FA9080@bogus.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703100844.68eb8b7d@opy.nosense.org> <20110703112420.3fcaa58c@opy.nosense.org> To: Keith Moore X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 03 Jul 2011 03:40:58 +0000 (UTC) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:41:11 -0000 --Apple-Mail-8-644769954 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 2, 2011, at 8:14 PM, Keith Moore wrote: > On Jul 2, 2011, at 10:00 PM, Erik Kline wrote: >=20 >>> Since 6rd depends on 6to4, as it is a variant of it, would 6to4 = being >>> declared historic also mean that 6rd needs to become historic as = well? >>=20 >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05 >> Section 1, in which the draft clarifies that 6rd supersedes 6to4, >=20 > which is of course completely incorrect. While 6rd shares a mechanism with 6 to 4 and can be implemented by = reusing code, it is a mistake to conclude a standards action that = impacts the later would impact the former, or that they are = substitutable for each other. > Keith >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --Apple-Mail-8-644769954 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jul 2, 2011, at = 10:00 PM, Erik Kline wrote:

Since 6rd depends on 6to4, as it is a variant of it, would = 6to4 being
declared historic = also mean that 6rd needs to become historic as = well?

h= ttp://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-05
Sect= ion 1, in which the draft clarifies that 6rd supersedes = 6to4,

which is of course = completely incorrect.

While = 6rd shares a mechanism with 6 to 4 and can be implemented by reusing = code, it is a mistake to conclude a standards action that impacts the = later would impact the former, or that they are substitutable for each = other.

Keith


____________________= ___________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/m= ailman/listinfo/ietf

= --Apple-Mail-8-644769954-- From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Jul 2 20:49:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C0621F8678; Sat, 2 Jul 2011 20:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqsvqoYUrGIB; Sat, 2 Jul 2011 20:49:24 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id AB9DC21F8677; Sat, 2 Jul 2011 20:49:23 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QdDgJ-0003Mr-BE; Sun, 03 Jul 2011 13:19:15 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 297233B33E; Sun, 3 Jul 2011 13:19:14 +0930 (CST) Date: Sun, 3 Jul 2011 13:19:13 +0930 From: Mark Smith To: Doug Barton Message-ID: <20110703131913.28142ec0@opy.nosense.org> In-Reply-To: <4E0FD788.3000305@dougbarton.us> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:49:24 -0000 On Sat, 02 Jul 2011 19:44:24 -0700 Doug Barton wrote: > On 07/02/2011 18:50, Mark Smith wrote: > > Where is the evidence that 6to4 is holding back native IPv6 > > deployment? > > It's been discussed ad nauseum in numerous fora. Discussion isn't evidence, as people usually don't post any data to support their assertions. Since posting that question I remembered RFC6036 - "Emerging Service Provider Scenarios for IPv6 Deployment". Here's what is says about ISPs' views on 6to4. I don't think it supports the assertion that 6to4 is holding back native deployment - "2.5. IPv6 Technologies Turning to technology choices, the overwhelming choice of approach (94%) is a dual-stack routing backbone, and the reason given is simplicity and cost. 39% run, or plan to run, a 6to4 relay as well, and 16% run or plan a Teredo server. " "Diffusions of Innovations" discusses attributes of innovations that influence their adoption. One of those attributes is trialability, meaning how hard or easy is it to trial the innovation. If a innovation requires a high level of commitment to trial, then it is less likely to be trialed and therefore adopted. Once an residential ISP as IPv6 transit, 6to4 is a simple and much lower cost way of trialing IPv6 services and gaining experience with IPv6, before and during the development and deployment of native IPv6 services and the required supporting infrastructure, such as AAA, helpdesk training etc. Declaring 6to4 to be historic might encourage native IPv6 deployment, but I think it will also make trialing IPv6 much harder. Bad 6to4 (which almost >> all of it is) results in a poor user experience when the largest content > providers enable AAAA records. Thus, they are less inclined to enable them. > The involvement in World IPv6 day by large content providers and the apparent lack of significant problems would be suggest the opposite is now the case. Google continuing to provide youtube video content to 6to4 tunnel users (such as myself), nearly a month later, suggests that any problems with it are tractable. 6to4 users are easy to spot by the 2002::/16 prefix, so if Google needed to they could probably quite easily limit their IPv6 content delivery to native only IPv6 users. So, in other words, Google now consider 6to4 to be reliable enough to continue to deliver content using it for one of their high profile content sites. > I realize that there are a lot of people that dismiss both the evidence > that's been put forward and the rationale, but it's been presented and > discussed pretty thoroughly. > In Geoff Huston's report (Dec 2010), he says that he measured a 13% failure rate with 6to4. A number of things have happened since then - IANA has run out of IPv4 addresses, and World IPv6 day. Those two events have increased the interest in IPv6 (the residential IPv6 trial I was working on gained more participants due to these events), which would have created an incentive for people to improve the quality of their 6to4 operation, or possibly deploy a trial 6to4 relay. An update on that data would be useful. Regards, Mark. From cb.list6@gmail.com Sat Jul 2 21:02:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37A921F86A3; Sat, 2 Jul 2011 21:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_00=-2.599, MANGLED_SONATA=2.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cbc9Ka3SWd8K; Sat, 2 Jul 2011 21:02:05 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BFBEF21F86A1; Sat, 2 Jul 2011 21:02:04 -0700 (PDT) Received: by wwe5 with SMTP id 5so2839559wwe.13 for ; Sat, 02 Jul 2011 21:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ceWeITE2q0ONf7eHtHLii56jFmdL0ZO9Vt18y1kvF3o=; b=bQKEeG1uQqQWTdi/otK7NPw3etspKd9w1vZTTo7873Yd8WbAO/zmsl+1hMMlz2UBNr efdHmLVFBNsdHze/IICiweTjPURP5UphKDObZ2kcGCFiZINeosioGySxFGrUiM4uEpZv ex2aPF9auZqIYUgTYlkAZqyJgzZpFsDCSPKfE= MIME-Version: 1.0 Received: by 10.216.63.131 with SMTP id a3mr3978240wed.64.1309665722780; Sat, 02 Jul 2011 21:02:02 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Sat, 2 Jul 2011 21:02:02 -0700 (PDT) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> Date: Sat, 2 Jul 2011 21:02:02 -0700 Message-ID: From: Cameron Byrne To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 04:02:05 -0000 On Sat, Jul 2, 2011 at 8:10 PM, Keith Moore wr= ote: > On Jul 2, 2011, at 3:21 PM, Cameron Byrne wrote: > > I saw the same thing. It is a shame that work that directly removes barri= ers > to REAL ipv6 deployment gets shouted down by a few people not involved in > REAL ipv6 deployment > > I find myself wondering what you mean by REAL IPv6. =A0For me, REAL IPv6 = is > code that uses the IPv6 programming model, 128 bit addresses, end-to-end > transparency, no NATs. =A06to4 certainly qualifies. That's not what it means to me. REAL IPv6 is a replacement for IPv4 and can address greater than 100s of billions of endpoint and is suitable for very large traffic loads. As an access network provider, i need content on native IPv6. It does not make sense to anyone in my organization or industry to deploy IPv6 unilaterally. There is no benefit in this approach vs just doing NAT444. If there is IPv6 content on a meaningful scale ( by the numbers that means for "my network": Google, Facebook, Yahoo and their CDNs ...), then i have a solid business case for IPv6 access networks. Full Stop. If the content guys say 6to4 is a pain, and they do, then i need to help them find a way to solve that pain. I operate in an address exhausted world, so NAT44 is my only IPv4 tool for growth. In the meantime, i null route the 6to4 anycast address because it creates half open state in my CGN. Been doing that for at least 5 years. My next step is filtering AAAA over IPv4 access because 6to4 client brokeness won't die on its own, that will be rolled out in a few months. Operating a network means making the tweeks that keep the wheels rolling, and we don't find many technology purist in my line of work. Other access providers like 6to4 so much that they want to NAT it. This is the reason why historic is the proper term. http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunn= el-02 I look forward to that discussion on ietf@ Cameron > Keith > From dougb@dougbarton.us Sat Jul 2 21:26:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596A621F86E2 for ; Sat, 2 Jul 2011 21:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ySbSPZLpWI7 for ; Sat, 2 Jul 2011 21:26:40 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE9421F86E0 for ; Sat, 2 Jul 2011 21:26:40 -0700 (PDT) Received: (qmail 15530 invoked by uid 399); 3 Jul 2011 04:26:36 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 3 Jul 2011 04:26:36 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E0FEF7A.4060606@dougbarton.us> Date: Sat, 02 Jul 2011 21:26:34 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ronald Bonica References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D3F3507F14@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3507F14@EMBX01-WF.jnpr.net> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 04:26:41 -0000 On 07/02/2011 20:31, Ronald Bonica wrote: > Randy, > > You have three points that deserve to be addressed. These are: > > 1) "as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot" > 2) "perhaps that minority was also vocal in the back room" > 3) "yes, but that will be a year from now. in the ietf, delay is one form of death" > > Responses follow: > > 1) While not stated so colorfully, draft-ietf-v6ops-6to4-advisory made this point. It has been approved for publication. > 2) While there was no back-room activity, You yourself mentioned that you were in private discussion with some who objected to the "historic" draft. There's nothing wrong with that, it's how the world works, and personally I would expect it of you. But please don't then turn around and say that it's not happening. :) > an appeal had been filed at the WG level. Since WG consensus was stronger than IETF consensus, it is reasonable to assume that the appeal would be escalated to the IESG level if it was not approved at the WG level. So, any way you look at it, there would be delays. > 3) The new document may not take a year to publish. Since it is a short draft, it could be produced in a few days. Once it is produced, we could immediately initiate a WG last call and an IETF last call immediately after that. So, we might be talking about a six-week delay. > > Now, I have a question for you, Lorenzo and Doug. If our goal is to take 6-to-4 off of the Internet, does not disabling it by default solve most of the problem? AFAIKS, very few users would enable it and service providers would not be economically incented to support 6-to-4 relay routers. Speaking for myself, my goal is not to take STF off the Internet. My goal is to do everything we can to get the best possible IPv6 deployed in the most places as fast as possible. STF is a hindrance to that goal, so I'd like it to go away. As I've said in the past, I was in the extreme wing of the WG that would have preferred to that we came down on the "turn it off, yesterday" side. So can I accept "off by default on the client side" as a step in the right direction? Sure, why not. But as others have pointed out the difference between that and "historic" is that the latter gives vendors active DIScouragement to support it at all. IMO that would be better. Much better. Hope I answered your question, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From moore@network-heretics.com Sat Jul 2 21:40:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDC811E8091; Sat, 2 Jul 2011 21:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+noIjNvzYLT; Sat, 2 Jul 2011 21:40:19 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id DFECB11E8088; Sat, 2 Jul 2011 21:40:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 9227A20878; Sun, 3 Jul 2011 00:40:15 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Sun, 03 Jul 2011 00:40:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=vz86DUjx02iRxD8sOKn1UuvyGJI=; b=ftQIdYjUD8rvHftXBtKR/dsA8ma1xk+hNo7Ph6jbTFe0id2yrotLzMaobru1QcGz41w//NyX40Jd6gyEH9hlG72z4zi/KwaFxLK9J/FRRJkW4Ia0w5/HRU0qbkvpF/ixp40TLUzp/gM3vNPFC3PLvbCYCLJkc7HQCXn6Cpf2VX0= X-Sasl-enc: SBToi3IeGhuUR6VO2jr2W1YgXvVsgvflkRQF4Urlpkcb 1309668014 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 634BC404F8E; Sun, 3 Jul 2011 00:40:14 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 00:39:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 04:40:20 -0000 On Jul 3, 2011, at 12:02 AM, Cameron Byrne wrote: > On Sat, Jul 2, 2011 at 8:10 PM, Keith Moore = wrote: >> On Jul 2, 2011, at 3:21 PM, Cameron Byrne wrote: >>=20 >> I saw the same thing. It is a shame that work that directly removes = barriers >> to REAL ipv6 deployment gets shouted down by a few people not = involved in >> REAL ipv6 deployment >>=20 >> I find myself wondering what you mean by REAL IPv6. For me, REAL = IPv6 is >> code that uses the IPv6 programming model, 128 bit addresses, = end-to-end >> transparency, no NATs. 6to4 certainly qualifies. >=20 > That's not what it means to me. REAL IPv6 is a replacement for IPv4 > and can address greater than 100s of billions of endpoint and is > suitable for very large traffic loads. As an access network provider, > i need content on native IPv6. It does not make sense to anyone in my > organization or industry to deploy IPv6 unilaterally. There is no > benefit in this approach vs just doing NAT444. If there is IPv6 > content on a meaningful scale ( by the numbers that means for "my > network": Google, Facebook, Yahoo and their CDNs ...), then i have a > solid business case for IPv6 access networks. Full Stop. Chicken-and-egg. You can't justify widespread deployment of IPv6 until = there are a lot of content/people/applications using it, and there won't = be a lot of content/people/applications using it until it's widely = available. The whole purpose of mechanisms like 6to4 is to help break that logjam. = We need to fix the existing mechanisms, and/or provide better ones, = rather than killing things that work... even if they only work in corner = cases. (Basing the argument entirely on "content", IMO, is misguided, because = it neglects significant potential drivers of IPv6 adoption, and because = there's still no incentive to move to v6 as long as the same content is = available on v4.) > If the content guys say 6to4 is a pain, and they do, then i need to > help them find a way to solve that pain. =20 So you want to help the "content" guys at the expense of other = legitimate uses of 6to4. Frankly, I don't think that's reasonable. = The net doesn't exist just for content delivery. > In the meantime, i null route the 6to4 anycast address because it > creates half open state in my CGN. Been doing that for at least 5 > years. My next step is filtering AAAA over IPv4 access because 6to4 > client brokeness won't die on its own, that will be rolled out in a > few months. So you admit you're sabotaging the network? Keith From moore@network-heretics.com Sat Jul 2 21:41:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A0A21F8432; Sat, 2 Jul 2011 21:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zN2b3WqUU8p4; Sat, 2 Jul 2011 21:41:45 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 35A0721F8587; Sat, 2 Jul 2011 21:41:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id D60702016E; Sun, 3 Jul 2011 00:41:26 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Sun, 03 Jul 2011 00:41:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=XPG3l+CzHTFwweWqD8c2d/5SbSw=; b=BdRX6MNzyIhA3QSSIrus1H2hgEsJvOuhjRBy4eETbhhRlOXxahK5OwUVF2VNC8kna+sMvSzogIFv7R6+kt/PUYlKyyMZuMFOknlWDtvCmrJXcPoP2uilwHWJ7/U6bcHZ6CwnMvAa8xWnRiKDFIsCc9V8TQRvjIGcLyQZNMIf9/Q= X-Sasl-enc: 5IHrhDPiw+LjzichACPBkCH7Uxk4nk5iRz+V4l8DWTvn 1309668086 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id ABEDF4051FC; Sun, 3 Jul 2011 00:41:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E0FEF7A.4060606@dougbarton.us> Date: Sun, 3 Jul 2011 00:41:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D3F3507F14@EMBX01-WF.jnpr.net> <4E0FEF7A.4060606@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 04:41:46 -0000 On Jul 3, 2011, at 12:26 AM, Doug Barton wrote: > Speaking for myself, my goal is not to take STF off the Internet. My = goal is to do everything we can to get the best possible IPv6 deployed = in the most places as fast as possible. STF is a hindrance to that goal, = so I'd like it to go away. STF is also helping that goal.=20 Keith From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Jul 2 21:45:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5CC11E809E; Sat, 2 Jul 2011 21:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ5d6Z0gXW34; Sat, 2 Jul 2011 21:45:24 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 59A0711E8078; Sat, 2 Jul 2011 21:45:23 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QdEYa-0004kz-Rw; Sun, 03 Jul 2011 14:15:20 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id A51C03B33E; Sun, 3 Jul 2011 14:15:19 +0930 (CST) Date: Sun, 3 Jul 2011 14:15:19 +0930 From: Mark Smith To: Cameron Byrne Message-ID: <20110703141519.1bb90022@opy.nosense.org> In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Keith Moore , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 04:45:24 -0000 On Sat, 2 Jul 2011 21:02:02 -0700 Cameron Byrne wrote: > In the meantime, i null route the 6to4 anycast address because it > creates half open state in my CGN. Been doing that for at least 5 > years. So, to be clear, you're not making an observation that 6to4 is broken, based on measurement or actual use, you're actively breaking it. > My next step is filtering AAAA over IPv4 access because 6to4 > client brokeness won't die on its own, that will be rolled out in a > few months. Operating a network means making the tweeks that keep the > wheels rolling, and we don't find many technology purist in my line of > work. > I think the root cause of your issues is the deployment of IPv4 CGN in the first place before IANA and the RIRs ran out of IPv4 addresses by the sounds of it. I think then means that any protocol that your customers try to use that would create unwanted state in your IPv4 CGN should be, by your definition, declared "historic", not just 6to4. When a customer signs up to your service, are they informed as to which protocols and applications they are allowed to use? My opinion is that if there are restrictions on what protocols and applications customers can operate then their service is not a real Internet service. The majority of, if not all, residential broadband service providers in my market hold the same belief - it seems to be the "pure" mobile carriers that commonly don't. > Other access providers like 6to4 so much that they want to NAT it. > This is the reason why historic is the proper term. > > http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 > > I look forward to that discussion on ietf@ > > Cameron > > > > Keith > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Sat Jul 2 21:59:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A004D21F8683; Sat, 2 Jul 2011 21:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.256 X-Spam-Level: X-Spam-Status: No, score=-102.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDGMJH2TLzqB; Sat, 2 Jul 2011 21:59:43 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A876321F8688; Sat, 2 Jul 2011 21:59:42 -0700 (PDT) Received: from [192.168.11.127] (c-76-115-172-69.hsd1.wa.comcast.net [76.115.172.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p634xTLY025922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 3 Jul 2011 04:59:30 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <20110703141519.1bb90022@opy.nosense.org> Date: Sat, 2 Jul 2011 21:59:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703141519.1bb90022@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 03 Jul 2011 04:59:30 +0000 (UTC) Cc: IETF Discussion , "v6ops@ietf.org" , Keith Moore Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 04:59:43 -0000 This line of discussion is not productive...=20 Between them the 4 largest north american wireless carriers need ~18 /8s = to assign public ipv4 addresses to their wireless cpe... they don't have = that and there's no-where to get it, then there's the rest of the world. =20 On Jul 2, 2011, at 9:45 PM, Mark Smith wrote: > On Sat, 2 Jul 2011 21:02:02 -0700 > Cameron Byrne wrote: >=20 > >> In the meantime, i null route the 6to4 anycast address because it >> creates half open state in my CGN. Been doing that for at least 5 >> years. >=20 >=20 > So, to be clear, you're not making an observation that 6to4 is broken, > based on measurement or actual use, you're actively breaking it. >=20 >> My next step is filtering AAAA over IPv4 access because 6to4 >> client brokeness won't die on its own, that will be rolled out in a >> few months. Operating a network means making the tweeks that keep = the >> wheels rolling, and we don't find many technology purist in my line = of >> work. >>=20 >=20 > I think the root cause of your issues is the deployment of IPv4 CGN in > the first place before IANA and the RIRs ran out of IPv4 addresses by > the sounds of it. I think then means that any protocol that your > customers try to use that would create unwanted state in your IPv4 CGN > should be, by your definition, declared "historic", not just 6to4. = When > a customer signs up to your service, are they informed as to which > protocols and applications they are allowed to use? My opinion is that > if there are restrictions on what protocols and applications customers > can operate then their service is not a real Internet service. The > majority of, if not all, residential broadband service providers in my > market hold the same belief - it seems to be the "pure" mobile > carriers that commonly don't. >=20 >> Other access providers like 6to4 so much that they want to NAT it. >> This is the reason why historic is the proper term. >>=20 >> = http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tun= nel-02 >>=20 >> I look forward to that discussion on ietf@ >>=20 >> Cameron >>=20 >>=20 >>> Keith >>>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From randy@psg.com Sat Jul 2 22:06:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5774021F8734; Sat, 2 Jul 2011 22:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVrOghwHmuaX; Sat, 2 Jul 2011 22:06:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B10FD21F8733; Sat, 2 Jul 2011 22:06:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QdEtC-000Foo-0O; Sun, 03 Jul 2011 05:06:38 +0000 Date: Sun, 03 Jul 2011 14:06:36 +0900 Message-ID: From: Randy Bush To: Ronald Bonica In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3507F14@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <13205C286662DE4387D9AF3AC30EF456D3F3507F14@EMBX01-WF.jnpr.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 05:06:42 -0000 > 1) "as measured on the real internet, not the ietf bar, 6to4 sucks caterpillar snot" > 2) "perhaps that minority was also vocal in the back room" > 3) "yes, but that will be a year from now. in the ietf, delay is one form of death" > > Responses follow: > > 1) While not stated so colorfully, draft-ietf-v6ops-6to4-advisory made > this point. It has been approved for publication. but then do we not draw the conclusion that therefore publishing draft-ietf-v6ops-6to4-to-disgusting is the correct approach? > 2) While there was no back-room activity, an appeal had been filed at > the WG level. Since WG consensus was stronger than IETF consensus, > it is reasonable to assume that the appeal would be escalated to > the IESG level if it was not approved at the WG level. so these days people who do not get their way use the nuclear option? we raised kids. when those tactics resulted in "we are so sorry you do not like the result, but that's the result" they soon stopped. > So, any way you look at it, there would be delays. welcome to the ietf, where process is our most important product. > 3) The new document may not take a year to publish. Since it is a > short draft, it could be produced in a few days. Once it is > produced, we could immediately initiate a WG last call and an IETF > last call immediately after that. So, we might be talking about a > six-week delay. so process this one in six weeks, please. > Now, I have a question for you, Lorenzo and Doug. If our goal is to > take 6-to-4 off of the Internet, does not disabling it by default > solve most of the problem? AFAIKS, very few users would enable it and > service providers would not be economically incented to support 6-to-4 > relay routers. the economic incentive to half-assed service providers is that it gives an excuse not to deploy ipv6. the response of these folk will be web pages instructing their users how to turn 6to4 on. randy From lorenzo@google.com Sat Jul 2 22:23:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2DB21F8759 for ; Sat, 2 Jul 2011 22:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.751 X-Spam-Level: X-Spam-Status: No, score=-105.751 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh2NyeV093cS for ; Sat, 2 Jul 2011 22:23:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 602F721F8756 for ; Sat, 2 Jul 2011 22:23:26 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p635NPhV005504 for ; Sat, 2 Jul 2011 22:23:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309670606; bh=UGT2guVZNqhexTwrCs2UMMhXdMQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hSBEFyfTgCjVeGSHXYsaK6iqzrr1smW/rBdYDTZCjshdeyacU8Iqn7fRDq/emM16t rANN7ESzK/89k7MV7ZjUA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=JTb2piv+k8e8HOfDShqnBWd2Nsmr7WGbyfGtlVXN6gjIm2WpgItnWZMzt1WFgOSio QmiMW4T6q6vA4xJ5Zc3tg== Received: from ywt2 (ywt2.prod.google.com [10.192.20.2]) by hpaq7.eem.corp.google.com with ESMTP id p635MoZU013688 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 2 Jul 2011 22:23:24 -0700 Received: by ywt2 with SMTP id 2so2227053ywt.2 for ; Sat, 02 Jul 2011 22:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RQetuOXemeZzQdy6ZMqJM/Kp24eTJGaOBKdf4TAfxaY=; b=pVGQVr6xlRut7D8ta3dIdN2PTEd+bIz5jYpwQ8qf9OlXso7FWPLO2JaZ+v1kI/WGj5 ggHLsbOpE0bFPPx5/KEw== Received: by 10.151.21.20 with SMTP id y20mr4364696ybi.150.1309670604223; Sat, 02 Jul 2011 22:23:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.14 with HTTP; Sat, 2 Jul 2011 22:23:03 -0700 (PDT) In-Reply-To: <20110703030548.7BF9618C1BA@mercury.lcs.mit.edu> References: <20110703030548.7BF9618C1BA@mercury.lcs.mit.edu> From: Lorenzo Colitti Date: Sun, 3 Jul 2011 07:23:03 +0200 Message-ID: To: Noel Chiappa Content-Type: multipart/alternative; boundary=000e0cd4b31e2335e704a7237362 X-System-Of-Record: true Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 05:23:28 -0000 --000e0cd4b31e2335e704a7237362 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 3, 2011 at 5:05 AM, Noel Chiappa wrote: > I think there is pretty much complete consensus that i) 6to4 doesn't work > in several very common environments (behind a NAT, etc, etc), and that > therefore, ii) at the very least, it should be disabled by default (and > therefore only turned on by knowledgeable users who know they are not in > one of those situations). > > Given and assuming a document that makes all that formal, _what else_ does > the _additional_ step of making 6to4 historic buy? > Compared to the alternative of publishing 6to4-historic now, it: a) Delays the time of any statement made by the IETF on the question by at least a number of months, while vendors and home gateways are *still shipping* products that implement 6to4 and enable it by default. I have personally seen this in beta home gateway products with "new IPv6 firmware" that aren't even released yet. b) Even assuming it were to gain consensus in any sort of reasonable timescale, it would provide a less clear statement, and thus be less of an incentive for implementors such as home gateway manufacturers to do the right thing and remove it. We have heard in the working group from real implementors like Apple, who have said that even 6to4-historic may not go far enough for them to justify actions such as removing support from their products. We have heard, also, that when implementors such as home gateway manufacturers are asked to remove 6to4 or disable it because it harms user experience, they say that they don't see why they should do work to remove a feature, in the absence of any guidance from the IETF. Time is important, because over time, 6to4's reliability will get worse, not better, as ISPs do things like use bogon IPv4 space plus carrier-grade NAT for their users, because implementations will think they have public IPv4 addresses and thus turn on 6to4 (which will never work, because it's behind a NAT). Or perhaps the concept is that nuking 6to4 will help force ISPs to deploy > native IPv6, since it removes one way for users to get IPv6 if their > provider doesn't supply it? If so, why not ditch Teredo, too? (Not to > mention that 'mandate it and they will come' hasn't worked to well so far.) > Normal users will not get IPv6 unless their ISP gives it to them. Period, end of story. I think it's clear by now that the vast majority of users don't know what IPv6 is, and that they do not ask for it. For a normal user, having 6to4 is more a liability than an asset. Normal users don't rely on 6to4 to give them IPv6 connectivity, because they don't use or need IPv6; everything they do today can be done with higher performance and higher reliability using IPv4 and NAT traversal. However, if they get it "for free" in the form of 6to4, then far from gaining a benefit (reliable IPv6 connectivity), they get something that only works 80% of the time, and 20% of the time breaks dual-stack websites. By "users" I explicitly do not include the tiny percentage of users on this list who are technical enough to know that 6to4 exists and rely on it to get IPv6 connectivity. Compared to the overwhelming number of users who have no idea what IPv6 even is, they are so far away from the mainstream that they don't matter at all, and they are knowledgeable enough to deploy other solutions, such as managed tunnels, which in my experience are typically lower latency and higher reliability (pretty much everything is higher reliability than a 20% failure rate). The only way you can incentivize ISPs to deploy IPv6 is to provide IPv6 content that they can use to justify the investment (for example, reduce the load on the NATs that they will be deploying). ISPs have been saying for years, and are still saying, that one of the reasons tha they are not deploying IPv6 because there is no point, since so little content is available over IPv6. Now we are hearing clearly from content providers that they *do not want* 6to4, because its 80% failure rate is a concern for them, and that in fact, its existence is one of the major barriers to lack of adoption on the part of content providers. --000e0cd4b31e2335e704a7237362 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 3, 2011 at 5:05 AM, Noel Chiappa <jnc@mercury.l= cs.mit.edu> wrote:
I think there is pretty much complete consensus that i) 6to4 doesn't wo= rk
in several very common environments (behind a NAT, etc, etc), and that
therefore, ii) at the very least, it should be disabled by default (and
therefore only turned on by knowledgeable users who know they are not in one of those situations).

Given and assuming a document that makes all that formal, _what else_ does<= br> the _additional_ step of making 6to4 historic buy?
Compared to the alternative of publishing 6to4-historic now, it= :

a) Delays the time of any statement made by the = IETF on the question by at least a number of months, while vendors and home= gateways are *still shipping* products that implement 6to4 and enable it b= y default. I have personally seen this in beta home gateway products with &= quot;new IPv6 firmware" that aren't even released yet.
b) Even assuming it were to gain consensus in any sort of reasonable t= imescale, it would provide a less clear statement, and thus be less of an i= ncentive for implementors such as home gateway manufacturers to do the righ= t thing and remove it. We have heard in the working group from real impleme= ntors like Apple, who have said that even 6to4-historic may not go far enou= gh for them to justify actions such as removing support from their products= .=A0We have heard, also, that when implementors such as home gateway manufa= cturers are asked to remove 6to4 or disable it because it harms user experi= ence, they say that they don't see why they should do work to remove a = feature, in the absence of any guidance from the IETF.

Time is important, because over time, 6to4's reliab= ility will get worse, not better, as ISPs do things like use bogon IPv4 spa= ce plus carrier-grade NAT for their users, because implementations will thi= nk they have public IPv4 addresses and thus turn on 6to4 (which will never = work, because it's behind a NAT).

Or perhaps the concept is th= at nuking 6to4 will help force ISPs to deploy
native IPv6, since it removes one way for users to get IPv6 if their
provider doesn't supply it? If so, why not ditch Teredo, too? (Not to mention that 'mandate it and they will come' hasn't worked to w= ell so far.)

Normal users will not get = IPv6 unless their ISP gives it to them. Period, end of story. I think it= 9;s clear by now that the vast majority of users don't know what IPv6 i= s, and that they do not ask for it. For a normal user, having 6to4 is more = a liability than an asset. Normal users don't rely on 6to4 to give them= IPv6 connectivity, because they don't use or need IPv6; everything the= y do today can be done with higher performance and higher reliability using= IPv4 and NAT traversal. However, if they get it "for free" in th= e form of 6to4, then far from gaining a benefit (reliable IPv6 connectivity= ), they get something that only works 80% of the time, and 20% of the time = breaks dual-stack websites.

By "users" I explicitly do not include the ti= ny percentage of users on this list who are technical enough to know that 6= to4 exists and rely on it to get IPv6 connectivity. Compared to the overwhe= lming number of users who have no idea what IPv6 even is, they are so far a= way from the mainstream that they don't matter at all, and they are kno= wledgeable enough to deploy other solutions, such as managed tunnels, which= in my experience are typically lower latency and higher reliability (prett= y much everything is higher reliability than a 20% failure rate).

The only way you can incentivize ISPs to deploy IPv6 is= to provide IPv6 content that they can use to justify the investment (for e= xample, reduce the load on the NATs that they will be deploying). ISPs have= been saying for years, and are still saying, that one of the reasons tha t= hey are not deploying IPv6 because there is no point, since so little conte= nt is available over IPv6. Now we are hearing clearly from content provider= s that they *do not want* 6to4, because its 80% failure rate is a concern f= or them, and that in fact, its existence is one of the major barriers to la= ck of adoption on the part of content providers.
--000e0cd4b31e2335e704a7237362-- From lorenzo@google.com Sat Jul 2 22:29:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342D721F873A for ; Sat, 2 Jul 2011 22:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.376 X-Spam-Level: X-Spam-Status: No, score=-105.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAd3pqgodNgf for ; Sat, 2 Jul 2011 22:29:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 952B321F8703 for ; Sat, 2 Jul 2011 22:29:32 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p635TVhh001274 for ; Sat, 2 Jul 2011 22:29:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309670972; bh=G14LFzpNITRh1GPgoeJ61vJbOrQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=kRfcifDFCy7Qyo+PSaRZWVHvj02UWtLNM32O4ujY1e1CGfkY68IXs1GwGMU/NAsr7 8vWFo9eZ/5DZRDguUBtPA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=SmG/klzHM2RclTye6jyDGI1jxXkQwC/hHuCOqo8gQdO/AWwdzv4vv5pHc7WH/OkIZ DT5+eqQztmK44Cof/H3xw== Received: from gyf1 (gyf1.prod.google.com [10.243.50.65]) by kpbe12.cbf.corp.google.com with ESMTP id p635TUO7023478 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 2 Jul 2011 22:29:30 -0700 Received: by gyf1 with SMTP id 1so1768799gyf.9 for ; Sat, 02 Jul 2011 22:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Bt9XrncfUjxvoxMvUytd7YypN0QAVMBKjJqU/6QhfvI=; b=eaxHEcZrYC5stync2D3D1EwgjHaah/DGRfnA5Qr4G4+e5xl3wRNAYFAn2XNeMqa73I LudQSw7huQqpgIEFUknw== Received: by 10.150.183.3 with SMTP id g3mr4067930ybf.264.1309670970151; Sat, 02 Jul 2011 22:29:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.14 with HTTP; Sat, 2 Jul 2011 22:29:10 -0700 (PDT) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> From: Lorenzo Colitti Date: Sun, 3 Jul 2011 07:29:10 +0200 Message-ID: To: Keith Moore Content-Type: multipart/alternative; boundary=000e0cd6ecd8f2d45704a723883b X-System-Of-Record: true Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 05:29:33 -0000 --000e0cd6ecd8f2d45704a723883b Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 3, 2011 at 5:11 AM, Keith Moore wrote: > And who says that "rough consensus of the entire IETF community" is that > this draft should not be published? Were there public discussions to that > effect that came to this conclusion? > > There's clearly a lack of consensus to support it. > Nope. The v6ops chairs saw consensus in v6ops to support it. Can you point to significant strength of opinion of the wider IETF community, but not in v6ops, that has reason to oppose it? If all you can point to is the same people that were opposing it in v6ops, then I think they don't count, because the rough consensus in v6ops was that the document should be published. So, I ask again: where are the statements made in opposition of this proposal made outside of v6ops? Can you point to them? --000e0cd6ecd8f2d45704a723883b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 3, 2011 at 5:11 AM, Keith Moore <moore@netwo= rk-heretics.com> wrote:
=
And who says that= "rough consensus of the entire IETF community"=A0is that this dr= aft should not be published? Were there public discussions to that effect t= hat came to this conclusion?
There's clearly a lack of con= sensus to support it.

Nope. The= v6ops chairs saw consensus in v6ops to support it. Can you point to signif= icant strength of opinion of the wider IETF community, but not in v6ops, th= at has reason to oppose it? If all you can point to is the same people that= were opposing it in v6ops, then I think they don't count, because the = rough consensus in v6ops was that the document should be published.

So, I ask again: where are the statements made in oppos= ition of this proposal made outside of v6ops? Can you point to them?
<= /div> --000e0cd6ecd8f2d45704a723883b-- From moore@network-heretics.com Sat Jul 2 22:47:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A41221F86C3; Sat, 2 Jul 2011 22:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZE8NxCOhrMB; Sat, 2 Jul 2011 22:47:34 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id EE01921F86A0; Sat, 2 Jul 2011 22:47:30 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 699FE20615; Sun, 3 Jul 2011 01:47:30 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 03 Jul 2011 01:47:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=VSASbIj3b0tPYjvAL716FYNlZqo=; b=KKl6RpIKDoqgWWPzIcRaYRoKZ7rg94je0b6iNTWZokZTXdbBGPU5mD5uRbvwj+cWvhh998YYWjujWlRPradCyH2X7dK5KjtyWAx8gZ0JP96YgBbDLDfTu6qXFWkIdwrid0tiI9rPC2rdXX4L4jsKEIs6Gdj8fftMjeRyNBsf42k= X-Sasl-enc: JQJUsz6WSxtPLJphUBh2B3bFh9/j3Gm9nMf5N6dfKeWL 1309672049 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 2702E40C8F8; Sun, 3 Jul 2011 01:47:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-115-652349629 From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 01:47:11 -0400 Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 05:47:35 -0000 --Apple-Mail-115-652349629 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2011, at 1:29 AM, Lorenzo Colitti wrote: > On Sun, Jul 3, 2011 at 5:11 AM, Keith Moore = wrote: >> And who says that "rough consensus of the entire IETF community" is = that this draft should not be published? Were there public discussions = to that effect that came to this conclusion? >=20 > There's clearly a lack of consensus to support it. >=20 > Nope. The v6ops chairs saw consensus in v6ops to support it. Can you = point to significant strength of opinion of the wider IETF community, = but not in v6ops, that has reason to oppose it? That's not how it works. You have to get consensus in IETF, not in = v6ops. (And it doesn't matter what you think of other people's reasons = to oppose -historic.) > If all you can point to is the same people that were opposing it in = v6ops, then I think they don't count, because the rough consensus in = v6ops was that the document should be published. Your logic is flawed. When you separately sample two dissimilar groups = it isn't statistically valid to combine the two samples. The correct = way to think about it is that the consensus was very rough already in = v6ops (even the official writeup says so), and it only moved further = away from rough consensus when the comments from outside of v6ops were = taken into account. I agree that the people who objected on v6ops and also objected on the = ietf list shouldn't be counted twice as opposing the standards action. = But when I did the tally, I found only a small amount of overlap between = people opposing -historic in v6ops, and people opposing it on the ietf = list. > So, I ask again: where are the statements made in opposition of this = proposal made outside of v6ops? Can you point to them? Some of them were posted to the IETF list. IESG may have received = others privately. That is permitted by our process. Keith --Apple-Mail-115-652349629 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Sun, Jul 3, 2011 at 5:11 AM, Keith Moore <moore@network-heretics.com&= gt; wrote:
And who says that "rough consensus of the = entire IETF community" is that this draft should not be published? = Were there public discussions to that effect that came to this = conclusion?
There's clearly a lack of = consensus to support = it.

Nope. The v6ops chairs = saw consensus in v6ops to support it. Can you point to significant = strength of opinion of the wider IETF community, but not in v6ops, that = has reason to oppose it?

That's = not how it works.  You have to get consensus in IETF, not in v6ops. =  (And it doesn't matter what you think of other people's reasons to = oppose -historic.)

If all you can point to is the same people = that were opposing it in v6ops, then I think they don't count, because = the rough consensus in v6ops was that the document should be = published.

Your logic is = flawed.   When you separately sample two dissimilar groups it isn't = statistically valid to combine the two samples.   The correct way = to think about it is that the consensus was very rough already in v6ops = (even the official writeup says so), and it only moved further away from = rough consensus when the comments from outside of v6ops were taken into = account.

I agree that the people who objected = on v6ops and also objected on the ietf list shouldn't be counted twice = as opposing the standards action.   But when I did the tally, I = found only a small amount of overlap between people opposing -historic = in v6ops, and people opposing it on the ietf = list.

So, I ask again: where are the statements made in opposition of = this proposal made outside of v6ops? Can you point to them?

Some of them were posted to the IETF list. =  IESG may have received others privately.  That is permitted = by our = process.

Keith


= --Apple-Mail-115-652349629-- From lorenzo@google.com Sat Jul 2 22:54:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E14A21F8750 for ; Sat, 2 Jul 2011 22:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olmbihobArHS for ; Sat, 2 Jul 2011 22:54:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6338921F8741 for ; Sat, 2 Jul 2011 22:54:09 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p635s7pl029321 for ; Sat, 2 Jul 2011 22:54:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309672448; bh=lrBnYxKWUAOOGV0P9mdsVLu/gsQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=sUqKr1e9xwbpZWZaj6crwPBTgB/EMPkW2ODWjaIrX4B55SBhsvWIbXuRkBoBjrjHt oKuImw2G9XbTyzCp4DAug== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=G9Z5XwVqdZ4vcDnas0A9VnO2fxA7kuPEN8ngX34fpz0eE2x17YpocjQKzHG9rguPd +OiQjTvaIUnU+4h5oSIBw== Received: from yie19 (yie19.prod.google.com [10.243.66.19]) by kpbe11.cbf.corp.google.com with ESMTP id p635rq8R018328 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 2 Jul 2011 22:54:06 -0700 Received: by yie19 with SMTP id 19so2472120yie.39 for ; Sat, 02 Jul 2011 22:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YUajFiSWCVNNPgE/+ZBgOp5wHLI32mFqQyuIQaOZN/0=; b=bGrVPrAxlPXMCWseVoCYM0d2HQgM5Qtdtx3EPJzdpT7X93MkJp9h7Yxbv1U10j8wut LtbPEuMUGxmLq8a15c+w== Received: by 10.151.21.20 with SMTP id y20mr4372922ybi.150.1309672446234; Sat, 02 Jul 2011 22:54:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.14 with HTTP; Sat, 2 Jul 2011 22:53:46 -0700 (PDT) In-Reply-To: <20110703131913.28142ec0@opy.nosense.org> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> From: Lorenzo Colitti Date: Sun, 3 Jul 2011 07:53:46 +0200 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=000e0cd4b31eee12e904a723e025 X-System-Of-Record: true Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 05:54:10 -0000 --000e0cd4b31eee12e904a723e025 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 3, 2011 at 5:49 AM, Mark Smith < ipng@69706e6720323030352d30312d31340a.nosense.org> wrote: > Declaring 6to4 to be historic might encourage native IPv6 deployment, > but I think it will also make trialing IPv6 much harder. > We don't need to trial the IPv6 protocol. There are hundreds of thousands of native users accessing production-grade IPv6 services, like Google's, every day. We know the IPv6 protocol works. ISPs do need to trial IPv6 deployment. But 6to4 does not help there, because 6to4 is not deployed by ISPs. They will need to trial native deployments, or 6rd. If *users* want to trial IPv6 until native IPv6 is available, then they can use configured tunnels. > The involvement in World IPv6 day by large content providers and the > apparent lack of significant problems would be suggest the opposite is > now the case. Google continuing to provide youtube video content to 6to4 > tunnel users (such as myself), nearly a month later, suggests that any > problems with it are tractable. I would assert that the problems with 6to4 are not tractable without disabling 6to4. Our IPv6 brokenness statistics for before and after World IPv6 Day are very similar. > 6to4 users are easy to spot by the 2002::/16 prefix, so if Google needed to > they could probably quite easily limit their IPv6 content delivery to native > only IPv6 users. No, that's not how it works. There is no problem with 6to4 when it works as well as IPv4. The problem is that 6to4 only works *at all* (never mind works "as well as IPv4") 80% of the time. Unfortunately, in the 20% of the time that it's not working, Google has no idea that the user has a 2002::/16 address. Google only knows, after the fact, that the user suffered a 20 or 75-second timeout and was not happy. So it would serve no purpose to avoid serving users that successfully connect from 2002::/16 addresses; once the AAAA record is handed out, the damage is done. What Google could do, however, is stop handing out AAAA records to networks that have significant number of 6to4 users in the future. We're considering this. An update on that data would be useful. > As I said before, our data on IPv6 brokenness did not change significantly after World IPv6 Day. Can you take that as a proxy that 6to4 has not improved? --000e0cd4b31eee12e904a723e025 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 3, 2011 at 5:49 AM, Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.= org> wrote:
Declaring 6to4 to be historic might enc= ourage native IPv6 deployment,
but I think it will also make trialing IPv6 much harder.

We don't need to trial the IPv6 protocol. There are h= undreds of thousands of native users accessing production-grade IPv6 servic= es, like Google's, every day. We know the IPv6 protocol works.=A0ISPs d= o need to trial IPv6 deployment. But 6to4 does not help there, because 6to4= is not deployed by ISPs. They will need to trial native deployments, or 6r= d.=A0If *users* want to trial IPv6 until native IPv6 is available, then the= y can use configured tunnels.
=A0
The involvement in World IPv6 day by large content providers and the apparent lack of significant problems would be suggest the opposite is
now the case. Google continuing to provide youtube video content to 6to4 tunnel users (such as myself), nearly a month later, suggests that any
problems with it are tractable.

I would ass= ert that the problems with 6to4 are not tractable without disabling 6to4. O= ur IPv6 brokenness statistics for before and after World IPv6 Day are very = similar.
=A0
6to4 users are easy to spot by= the=A02002::/16 prefix, so if Google needed to they could probably quite= =A0easily limit their IPv6 content delivery to native only IPv6 users.

No, that's not how it works. There is no problem wi= th 6to4 when it works as well as IPv4. The problem is that 6to4 only works = *at all* (never mind works "as well as IPv4") 80% of the time.

Unfortunately, in the 20% of the time that it's not= working, Google has no idea that the user has a 2002::/16 address. Google = only knows, after the fact, that the user suffered a 20 or 75-second timeou= t and was not happy. So it would serve no purpose to avoid serving users th= at successfully connect from 2002::/16 addresses; once the AAAA record is h= anded out, the damage is done. What Google could do, however, is stop handi= ng out AAAA records to networks that have significant number of 6to4 users = in the future. We're considering this.

An=A0update on that data woul= d be useful.

As I said before, our data= on IPv6 brokenness did not change significantly after World IPv6 Day. Can = you take that as a proxy that 6to4 has not improved?
--000e0cd4b31eee12e904a723e025-- From lorenzo@google.com Sat Jul 2 22:59:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF87721F8685 for ; Sat, 2 Jul 2011 22:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.847 X-Spam-Level: X-Spam-Status: No, score=-105.847 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZQXAh5rId6S for ; Sat, 2 Jul 2011 22:59:21 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 39EAC21F865F for ; Sat, 2 Jul 2011 22:59:21 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p635xKs3002851 for ; Sat, 2 Jul 2011 22:59:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309672760; bh=qUkxC99frbwGJwhukAiAmrXStjA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=bQptOfllxZbiel3jFYvTVolRKU0Yb1tS4tt5SiWu3M3U74ihq9NAeqZ+yAxxf/29W UQpK+1Ebj9JAPrLnhZimQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=sSTcQ2N7cwoHRlLnQ2pziAPU6qmFCAbNz/v/56VBSR1g+rcijltxERMseY9sqEjeN OWBSkdyj8R4QF0DYpQg9g== Received: from yia27 (yia27.prod.google.com [10.243.65.27]) by hpaq7.eem.corp.google.com with ESMTP id p635xILI032477 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 2 Jul 2011 22:59:19 -0700 Received: by yia27 with SMTP id 27so2149065yia.5 for ; Sat, 02 Jul 2011 22:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=16bmiS/mHyMG0vOZYq3YEBvePs3ZmoBLGG0y+8kcPcI=; b=I9KUi74piJqG8/RetFlJImD8DW0hsEtuJ6tCshLCJQ/fAONYckW8JkGWECfd1Z+QdJ uwDrBr6nTERLTmcBSloA== Received: by 10.151.24.10 with SMTP id b10mr4179543ybj.93.1309672758195; Sat, 02 Jul 2011 22:59:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.157.14 with HTTP; Sat, 2 Jul 2011 22:58:58 -0700 (PDT) In-Reply-To: <20110703100844.68eb8b7d@opy.nosense.org> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703100844.68eb8b7d@opy.nosense.org> From: Lorenzo Colitti Date: Sun, 3 Jul 2011 07:58:58 +0200 Message-ID: To: Mark Smith Content-Type: multipart/alternative; boundary=000e0cd23ef68634c004a723f393 X-System-Of-Record: true Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 05:59:22 -0000 --000e0cd23ef68634c004a723f393 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith < ipng@69706e6720323030352d30312d31340a.nosense.org> wrote: > I don't object to what has been proposed, yet I object to > "6to4-historic" because I'm an extremely happy anycast 6to4 user "It works for me, so there's obviously no problem". When you think of 6to4-historic, please think of the 20% of anycast 6to4 users that are broken. We know it can operate correctly and reliably if it is configured correctly. But we also know that it's not configured correctly, to such an extent that it does not work at all in 20% of cases (Geoff's data). And we know of no reason why that would improve, though we do know of reasons why it would get worse (e.g., due to ISPs giving bogon public space to their users). --000e0cd23ef68634c004a723f393 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>= wrote:
I don't object to what has been propose= d, yet I object to
"6to4-historic" because I'm an extremely happy anycast 6to4 u= ser

"It works for me, so there's o= bviously no problem". When you think of 6to4-historic, please think of= the 20% of anycast 6to4 users that are broken.

We know it can operate corre= ctly and reliably if it=A0is configured correctly.

But we also know that it's not configured correctly, to such an ex= tent that it does not work at all in 20% of cases (Geoff's data). And w= e know of no reason why that would improve, though we do know of reasons wh= y it would get worse (e.g., due to ISPs giving bogon public space to their = users).
--000e0cd23ef68634c004a723f393-- From moore@network-heretics.com Sat Jul 2 23:15:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9A121F8758; Sat, 2 Jul 2011 23:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PuRarBtiXYR; Sat, 2 Jul 2011 23:15:06 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9AA21F8755; Sat, 2 Jul 2011 23:15:06 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id E58122083F; Sun, 3 Jul 2011 02:15:05 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 03 Jul 2011 02:15:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=KHGkkWETEOdB651nariamhZNqqM=; b=C4lVTdMsStdwLUj0hRLssjBCNdkkyBI4hhYtgPLX//Dut8nwsf1afkmIl9ciT+ConqZ7jqTe2K8LCeg2vFktrI1tfLik0kCb0IovXOAejpbW2wg3f94EdeqbMk5CUBFAtW/vbcZiw0uvH5wGUJm/exq8Rx6KYEfz3dUMKy40yCI= X-Sasl-enc: Mbwup/AebCXZjtv0raEHZm4omCN7rWm3bLcnBZDVW2jx 1309673705 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id C3EC240BBA9; Sun, 3 Jul 2011 02:15:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 02:14:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2A012002-999D-44BD-B243-B0147967F05B@network-heretics.com> References: <20110703030548.7BF9618C1BA@mercury.lcs.mit.edu> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, Noel Chiappa , ietf@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 06:15:09 -0000 On Jul 3, 2011, at 1:23 AM, Lorenzo Colitti wrote: > I think it's clear by now that the vast majority of users don't know = what IPv6 is, and that they do not ask for it. No, but they do want their applications to work well. That's constantly = getting more difficult in IPv4. The workarounds for NATs and other = forms of brain damage in the network keep changing, and each application = requires not only its own code but also its own infrastructure to deal = with that brain damage. So a solution that allows applications to = use IPv6 whether or not all of the networks between the peers support = native v6, is very badly needed. We can't wait for ISPs to give = everybody IPv6 before applications start using it. And I agree that most users don't know what IPv6 is, at the moment. But = if they learn that it will help their apps work better, they'll want it.=20= (I also remember when most people didn't know what the Internet was. = And then, almost in an instant, everybody knew, and a cartoon in the New = Yorker magazine about the internet and a dog was something everybody = could understand. Users will understand IPv6 also, soon enough.) Keith p.s. I often wear a t-shirt that says "there's no place like ::1". = Non-computer people ask me what it means, and in response, I tell them = it's the address of their own machine in IPv6. So far, nobody has = asked me what IPv6 means. Everyone who has asked me about the shirt = has heard of IPv6 and understood at some level that it's the next = version of the Internet. If anything, there seems to be a disconnect = between what "ordinary users" know about IPv6 and what their ISPs are = telling them - because for the most part, the ISPs seem to keep publicly = pretending that it doesn't exist. From v6ops@globis.net Sat Jul 2 23:23:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85A421F8775; Sat, 2 Jul 2011 23:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZpDDSMIu1MF; Sat, 2 Jul 2011 23:23:44 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 12C5021F876E; Sat, 2 Jul 2011 23:23:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9E3168700DE; Sun, 3 Jul 2011 08:23:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFGH-9O0g9p4; Sun, 3 Jul 2011 08:23:07 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 382B3870030; Sun, 3 Jul 2011 08:23:07 +0200 (CEST) Message-ID: <4E100ACB.70907@globis.net> Date: Sun, 03 Jul 2011 08:23:07 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Keith Moore , "v6ops@ietf.org WG" , IETF Discussion Content-Type: multipart/alternative; boundary="------------040205010300000606020905" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 06:23:45 -0000 This is a multi-part message in MIME format. --------------040205010300000606020905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > Subject: > Re: [v6ops] draft-ietf-v6ops-6to4-to-historic > From: > Keith Moore > Date: > Sat, 2 Jul 2011 23:10:47 -0400 > > To: > Cameron Byrne > CC: > "v6ops@ietf.org" , IETF Discussion > > Precedence: > list > MIME-Version: > 1.0 (Apple Message framework v1084) > References: > <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> > > > In-Reply-To: > > Message-ID: > > Content-Type: > multipart/alternative; boundary=Apple-Mail-111-642965515 > Message: > 2 > > > > I find myself wondering what you mean by REAL IPv6. For me, REAL IPv6 > is code that uses the IPv6 programming model, 128 bit addresses, > end-to-end transparency, no NATs. 6to4 certainly qualifies. > > Keith Many people have many more requirements. For example, an SLA for availability and latency, low support costs, firewall security, DSCP quality of service, ability to log end point communications, intrusion detection, WAN acceleration, a deployment model that does not rely on allocating even more IPv4 addresses (that many don't have or won't have) or the good nature of other providers to provide a working relay ....... 6to4 fails to meet many of those requirements. Granted, it isn't the only transition mechanism that fails to do so. IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. Having said all that, 6to4 has also caused me issues with traffic predictability, and cost significant engineering time. Turning 6to4 off by default would not be the ideal solution in my view, but it should address many if not all of my own particular issues. If that's all that's on offer, I'll take it. regards, RayH --------------040205010300000606020905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Subject:
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
From:
Keith Moore <moore@network-heretics.com>
Date:
Sat, 2 Jul 2011 23:10:47 -0400
To:
Cameron Byrne <cb.list6@gmail.com>
CC:
"v6ops@ietf.org" <v6ops@ietf.org>, IETF Discussion <ietf@ietf.org>
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1084)
References:
<13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <CAKD1Yr2Smvm0RY5iV2y06wD=RRz-uW4VbaaairnoAkSR7zLdtg@mail.gmail.com> <BANLkTimpRDNQKc1XTafSkKOo5dCX3Gc8Yw@mail.gmail.com>
In-Reply-To:
<BANLkTimpRDNQKc1XTafSkKOo5dCX3Gc8Yw@mail.gmail.com>
Message-ID:
<E817A524-9DB7-4553-A76F-25A9907E7C2D@network-heretics.com>
Content-Type:
multipart/alternative; boundary=Apple-Mail-111-642965515
Message:
2


I find myself wondering what you mean by REAL IPv6.  For me, REAL IPv6 is code that uses the IPv6 programming model, 128 bit addresses, end-to-end transparency, no NATs.  6to4 certainly qualifies.

Keith
Many people have many more requirements. For example, an SLA for availability and latency, low support costs, firewall security, DSCP quality of service, ability to log end point communications, intrusion detection, WAN acceleration, a deployment model that does not rely on allocating even more IPv4 addresses (that many don't have or won't have) or the good nature of other providers to provide a working relay .......

6to4 fails to meet many of those requirements. Granted, it isn't the only transition mechanism that fails to do so.

IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet.

Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces.

Having said all that, 6to4 has also caused me issues with traffic predictability, and cost significant engineering time. Turning 6to4 off by default would not be the ideal solution in my view, but it should address many if not all of my own particular issues. If that's all that's on offer, I'll take it.

regards,
RayH
--------------040205010300000606020905-- From moore@network-heretics.com Sat Jul 2 23:27:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB93221F8772; Sat, 2 Jul 2011 23:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPTgvmIOBRPo; Sat, 2 Jul 2011 23:27:33 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 001F121F8767; Sat, 2 Jul 2011 23:27:32 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id AC50F2078B; Sun, 3 Jul 2011 02:27:32 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Sun, 03 Jul 2011 02:27:32 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=OXMxgsQYEAvYkdTR95gUJc/WtHY=; b=La2i/3b8c0gLKlqw2mTYB/mGkRH+ky9mdp7eVgHcpUP5QzSF43KCOY76+ZZd/NWAZvtgTxTuUOhnkUOTrnU4vzS0fbzlmedbXRH5sG4s3jgME3LHFfapBTsW4V3ym4cEct0MWFtEJxbcmmRQU+Ym71mHuYfvyefoeY4La/fLrzQ= X-Sasl-enc: 7E6o3u2lgB4H4DTp4uFYmBMmFYbDNC2jkL5A1qaKq0ad 1309674451 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 30D1440BAF2; Sun, 3 Jul 2011 02:27:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-116-654751406 From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 02:27:13 -0400 Message-Id: <9BDD213D-A4A4-4999-B64C-E66AFB7254B6@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 06:27:33 -0000 --Apple-Mail-116-654751406 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2011, at 1:53 AM, Lorenzo Colitti wrote: > On Sun, Jul 3, 2011 at 5:49 AM, Mark Smith = wrote: > Declaring 6to4 to be historic might encourage native IPv6 deployment, > but I think it will also make trialing IPv6 much harder. >=20 > We don't need to trial the IPv6 protocol. There are hundreds of = thousands of native users accessing production-grade IPv6 services, like = Google's, every day. We know the IPv6 protocol works. ISPs do need to = trial IPv6 deployment. But 6to4 does not help there, because 6to4 is not = deployed by ISPs. 6to4 allows applications to use IPv6 even when ISPs don't support it. = The idea is to allow application deployment, and use of IPv6, to develop = independently of ISP deployment of native IPv6. > They will need to trial native deployments, or 6rd. If *users* want to = trial IPv6 until native IPv6 is available, then they can use configured = tunnels. Uh, no. If you're an application developer, shipping code that requires = every single user to set up a tunnel is a nonstarter. And as well all = know, configured tunnels often route very suboptimally. In many cases = 6to4 works better. It's not as if the only applications that matter are those that are = layered over HTTP. > The involvement in World IPv6 day by large content providers and the > apparent lack of significant problems would be suggest the opposite is > now the case. Google continuing to provide youtube video content to = 6to4 > tunnel users (such as myself), nearly a month later, suggests that any > problems with it are tractable. >=20 > I would assert that the problems with 6to4 are not tractable without = disabling 6to4. Our IPv6 brokenness statistics for before and after = World IPv6 Day are very similar. The only unfixable problem that 6to4 has is its inability to work with = NATs, including LSN. Some of those fixes would require code updates = to host implementations, but disabling 6to4 would also require code = updates. > 6to4 users are easy to spot by the 2002::/16 prefix, so if Google = needed to they could probably quite easily limit their IPv6 content = delivery to native only IPv6 users. >=20 > No, that's not how it works. There is no problem with 6to4 when it = works as well as IPv4. The problem is that 6to4 only works *at all* = (never mind works "as well as IPv4") 80% of the time. That figure is not based on a representative sample of all 6to4 use, so = it's hard to know how much confidence to have in it. Keith --Apple-Mail-116-654751406 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Sun, Jul 3, 2011 at 5:49 AM, = Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>= ; wrote:
Declaring 6to4 to = be historic might encourage native IPv6 deployment,
but I think it will also make trialing IPv6 much = harder.

We don't need to trial the = IPv6 protocol. There are hundreds of thousands of native users accessing = production-grade IPv6 services, like Google's, every day. We know the = IPv6 protocol works. ISPs do need to trial IPv6 deployment. But = 6to4 does not help there, because 6to4 is not deployed by ISPs. =

6to4 allows applications to = use IPv6 even when ISPs don't support it.   The idea is to allow = application deployment, and use of IPv6, to develop independently of ISP = deployment of native IPv6.

They will need to trial native deployments, = or 6rd. If *users* want to trial IPv6 until native IPv6 is = available, then they can use configured = tunnels.

Uh, no.  If you're = an application developer, shipping code that requires every single user = to set up a tunnel is a nonstarter.  And as well all know, = configured tunnels often route very suboptimally.   In many cases = 6to4 works better.

It's not as if the only = applications that matter are those that are layered over = HTTP.

The involvement in World IPv6 day by large content providers and = the
apparent lack of significant problems would be suggest the opposite = is
now the case. Google continuing to provide youtube video content to = 6to4
tunnel users (such as myself), nearly a month later, suggests that = any
problems with it are tractable.

I would = assert that the problems with 6to4 are not tractable without disabling = 6to4. Our IPv6 brokenness statistics for before and after World IPv6 Day = are very similar.

The only = unfixable problem that 6to4 has is its inability to work with NATs, = including LSN.     Some of those fixes would require code = updates to host implementations, but disabling 6to4 would also require = code updates.

6to4 users are easy to = spot by the 2002::/16 prefix, so if Google needed to they could = probably quite easily limit their IPv6 content delivery to native = only IPv6 users.

No, that's not how it works. There is no problem = with 6to4 when it works as well as IPv4. The problem is that 6to4 only = works *at all* (never mind works "as well as IPv4") 80% of the = time.

That figure is not = based on a representative sample of all 6to4 use, so it's hard to know = how much confidence to have in = it.

Keith

= --Apple-Mail-116-654751406-- From randy@psg.com Sat Jul 2 23:29:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E290421F8798; Sat, 2 Jul 2011 23:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNj6Bqhnwr55; Sat, 2 Jul 2011 23:29:44 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4946D21F8795; Sat, 2 Jul 2011 23:29:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QdGBY-000G0P-NV; Sun, 03 Jul 2011 06:29:40 +0000 Date: Sun, 03 Jul 2011 15:29:39 +0900 Message-ID: From: Randy Bush To: Keith Moore In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 06:29:45 -0000 >> Nope. The v6ops chairs saw consensus in v6ops to support it. Can you >> point to significant strength of opinion of the wider IETF community, >> but not in v6ops, that has reason to oppose it? > > That's not how it works. You have to get consensus in IETF, not in > v6ops. when it is last called. and you can dos that mailing list then, and threaten, and bluster. randy From moore@network-heretics.com Sat Jul 2 23:30:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B88F21F8796; Sat, 2 Jul 2011 23:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9dfpI9RUvzZ; Sat, 2 Jul 2011 23:30:32 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 566F821F8795; Sat, 2 Jul 2011 23:30:32 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 0CDF220870; Sun, 3 Jul 2011 02:30:32 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Sun, 03 Jul 2011 02:30:32 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=BgkXrRNxO3W+H7KUp49KgYW7rIQ=; b=T3lgvTcf2++FoqQRVtHabd85ssHz8nEcWs8tmKW+rZYeALBON9gNOmxIksHBRzZtHQrT09F9FPBxXlTTcuis3GnI1Qrq/DUv74Sg4fqGXptjD12d2NP9ZUzBS+xbLpn4ZpA4j6XRz6oy7/8TAobWBfN0uAL5ByVUMyyG2p2Aaq8= X-Sasl-enc: 9kkdES1T+bMCcXd0izcd+gXGkTWQQ0k/gJX9f4ddhSe1 1309674631 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id E007A4002AB; Sun, 3 Jul 2011 02:30:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-117-654931490 From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 02:30:13 -0400 Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703100844.68eb8b7d@opy.nosense.org> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 06:30:33 -0000 --Apple-Mail-117-654931490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2011, at 1:58 AM, Lorenzo Colitti wrote: > On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith = wrote: > I don't object to what has been proposed, yet I object to > "6to4-historic" because I'm an extremely happy anycast 6to4 user >=20 > "It works for me, so there's obviously no problem". When you think of = 6to4-historic, please think of the 20% of anycast 6to4 users that are = broken. 6to4 used to be far less reliable than that, but has improved as = additional relays were deployed. It's reasonable to expect that the = publication of -advisory will improve the situation further. Keith --Apple-Mail-117-654931490 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 3, 2011, at 1:58 AM, Lorenzo Colitti wrote:

On Sun, Jul 3, 2011 at 2:38 AM, Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> wrote:
I don't object to what has been proposed, yet I object to
"6to4-historic" because I'm an extremely happy anycast 6to4 user

"It works for me, so there's obviously no problem". When you think of 6to4-historic, please think of the 20% of anycast 6to4 users that are broken.

6to4 used to be far less reliable than that, but has improved as additional relays were deployed.   It's reasonable to expect that the publication of -advisory will improve the situation further.

Keith

--Apple-Mail-117-654931490-- From moore@network-heretics.com Sat Jul 2 23:36:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD60C21F86DA; Sat, 2 Jul 2011 23:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+53AYMgxYDj; Sat, 2 Jul 2011 23:36:44 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 36C5721F8679; Sat, 2 Jul 2011 23:36:44 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id DE86B20725; Sun, 3 Jul 2011 02:36:43 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 03 Jul 2011 02:36:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=MVPV9YsY3THaeLYd8FuQGAiAL+A=; b=DFfT3t0DBGwllUpKW8/AQ8iL1hxCy/jWr7LyFHbvMxuiesbxFxHb+Z8XwahCBkagkQOIRk42YTUFFsS2dAtG1d0YWZbpMe6dOn3kZeOtZwdX7diaP2A22kgwVQiQPv15izmc9BCxFn/wwVIT3tQST4rUeKOVDdv7R+9jnCYUhmQ= X-Sasl-enc: neAXyusjyDZ8YY42WS3LePGDZ5khSmY3RjUIZ+1FoX9u 1309675003 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id E87B940BF83; Sun, 3 Jul 2011 02:36:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E100ACB.70907@globis.net> Date: Sun, 3 Jul 2011 02:36:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <806331F9-2A3D-459C-8774-BED1346C475F@network-heretics.com> References: <4E100ACB.70907@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 06:36:44 -0000 On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote: > IMHO Right now, we need services with native IPv6 based interfaces, = with equivalent performance and equivalent features and equivalent price = that we have today with IPv4. Anything that detracts from the roll out = of native IPv6 based service interfaces at this time is a bad move IMVHO = and hastens the day that the Internet fragments into a bunch of CGN = zones, that is dominated by businesses that can afford to buy public = IPv4 addresses for their servers or services, or whose business model = relies on NAT traversal being difficult. I personally don't want that = sort of Internet. Right now, applications developers need to be able to write and ship = code that uses IPv6 and can talk to other application instances using = IPv6. Anything that detracts from the ability of applications to use = IPv6 at this time is a bad move IMHO and decreases the chance that there = will ever be sufficient use of IPv6 (of any kind) to justify widespread = deployment of native IPv6. > Given that development and engineering support time is finite, I'd = much rather that 6to4 was declared historic so that developers and = engineers could spend more time on deployment of native IPv6 service = interfaces. I have a better suggestion: let's declare NAT historic. That would free = up lots of developers and engineers to spend time on both native v6 and = better v6 transition mechanisms. Not only would they not need to = engineer new NATs, applications developers wouldn't need to engineer new = workarounds for new NATs. Everybody would win. Keith From Ted.Lemon@nominum.com Sat Jul 2 23:37:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB03121F87AF; Sat, 2 Jul 2011 23:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq-rdIi2v5o8; Sat, 2 Jul 2011 23:37:49 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 83FF121F87A7; Sat, 2 Jul 2011 23:37:48 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKThAOOzubqJWMhuO1JxIcYO92VZMnssDh@postini.com; Sat, 02 Jul 2011 23:37:48 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A3C5E1B8338; Sat, 2 Jul 2011 23:37:47 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8D3BC190052; Sat, 2 Jul 2011 23:37:47 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.1.289.1; Sat, 2 Jul 2011 23:37:47 -0700 Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 2 Jul 2011 23:37:47 -0700 MIME-Version: 1.0 (Apple Message framework v1242) Content-Type: multipart/alternative; boundary="Apple-Mail=_FD3C3BE2-5B2E-4A4C-B13C-935095499B5E" From: Ted Lemon In-Reply-To: Date: Sun, 3 Jul 2011 02:37:43 -0400 Message-ID: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> To: IETF Discussion X-Mailer: Apple Mail (2.1242) Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 06:37:49 -0000 --Apple-Mail=_FD3C3BE2-5B2E-4A4C-B13C-935095499B5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" On Jul 3, 2011, at 1:47 AM, Keith Moore wrote: > Some of them were posted to the IETF list. IESG may have received = others privately. That is permitted by our process. This is a frustrating conversation. Everybody who supported the = consensus in v6ops is an IETF participant, and their wishes count toward = the IETF consensus. The draft is good. It encourages people to do = the right things: keep 6to4 relays active, but not ship products with = 6to4 enabled by default. This works for everyone=97for people like me = who are using 6to4 for our IPv6 connectivity, it works because the = relays stay up. For people who do not have global IPv4 addresses, they = do not wind up with IPv6 routes that go nowhere. It certainly serves = Keith Moore's needs, no matter how vehemently, nor how often, he may = insist that it does not. So this really does look like another IETF night of long knives, where a = good draft gets scuttled in secret because a few very loud people manage = to create enough of a fuss to make the person or persons calling the = consensus feel like they're going to get fricasseed if they call the = consensus in favor of the draft. Have we actually had a formal consensus call for the IETF? Who called = the consensus? Can we have a summary? I haven't seen one. --Apple-Mail=_FD3C3BE2-5B2E-4A4C-B13C-935095499B5E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252"
Some of = them were posted to the IETF list.  IESG may have received others = privately.  That is permitted by our = process.

This is a frustrating = conversation.   Everybody who supported the consensus in v6ops is = an IETF participant, and their wishes count toward the IETF consensus. =   The draft is good.   It encourages people to do the right = things: keep 6to4 relays active, but not ship products with 6to4 enabled = by default.  This works for everyone=97for people like me who are = using 6to4 for our IPv6 connectivity, it works because the relays stay = up.   For people who do not have global IPv4 addresses, they do not = wind up with IPv6 routes that go nowhere.   It certainly serves = Keith Moore's needs, no matter how vehemently, nor how often, he may = insist that it does not.

So this really does = look like another IETF night of long knives, where a good draft gets = scuttled in secret because a few very loud people manage to create = enough of a fuss to make the person or persons calling the consensus = feel like they're going to get fricasseed if they call the consensus in = favor of the draft.

Have we actually had a = formal consensus call for the IETF?   Who called the consensus? =   Can we have a summary?   I haven't seen = one.

= --Apple-Mail=_FD3C3BE2-5B2E-4A4C-B13C-935095499B5E-- From moore@network-heretics.com Sat Jul 2 23:56:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0B621F8728; Sat, 2 Jul 2011 23:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GafZlTtI90ko; Sat, 2 Jul 2011 23:56:02 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE8921F8727; Sat, 2 Jul 2011 23:56:02 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id C5399206CF; Sun, 3 Jul 2011 02:56:01 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 03 Jul 2011 02:56:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=BC8rc0+wani4ljDmz/LKziHJX7w=; b=heBa7CcWlj4BMWLI57u7zeHO2FL7JHm78VlP11UUTEVmeIrp0jgSh1jq8NHKNu7hb4qIZ3RSEIo7ug5dS4R0ZbB4T8LtBhow/MnDudXH2trRP1Klz8gvPuqL7YNc4pbV+Rz96Ufl9QuCgplr7oBB8Fov1/jHNzNlB8a6DJyIAkM= X-Sasl-enc: b/bBEFvt1+LFQXaApuoA5jgCaC6K5PBoTFA+YWlhL/Na 1309676160 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 5CD384009CD; Sun, 3 Jul 2011 02:56:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-118-656460945 From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 02:55:42 -0400 Message-Id: <703700EE-07B8-473A-ACFC-E712F44481A0@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org Operations" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 06:56:03 -0000 --Apple-Mail-118-656460945 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 3, 2011, at 2:37 AM, Ted Lemon wrote: > On Jul 3, 2011, at 1:47 AM, Keith Moore wrote: >> Some of them were posted to the IETF list. IESG may have received = others privately. That is permitted by our process. >=20 > This is a frustrating conversation. Everybody who supported the = consensus in v6ops is an IETF participant, and their wishes count toward = the IETF consensus. =20 Yes their wishes do count. But the consensus was marginal even in = v6ops, and v6ops isn't representative of the breadth of interests in the = entire IETF. It should hardly be surprising that a very rough = consensus within a working group doesn't translate to a rough consensus = within IETF as a whole. v6ops isn't special in this regard. The same is true for any other = working group. Unfortunately, it's really easy for a working group that = is focused on a particular set of concerns, to neglect concerns from the = wider community. > The draft is good. It encourages people to do the right things: keep = 6to4 relays active, but not ship products with 6to4 enabled by default. = This works for everyone=97for people like me who are using 6to4 for our = IPv6 connectivity, it works because the relays stay up. For people who = do not have global IPv4 addresses, they do not wind up with IPv6 routes = that go nowhere. It certainly serves Keith Moore's needs, no matter = how vehemently, nor how often, he may insist that it does not. You are not in a good position to evaluate what I need. > So this really does look like another IETF night of long knives, where = a good draft gets scuttled in secret because a few very loud people = manage to create enough of a fuss to make the person or persons calling = the consensus feel like they're going to get fricasseed if they call the = consensus in favor of the draft. No, it's not a good draft. It's misleading in many places. And the = label of Historic is simply inappropriate for something that is still = quite useful for many people and for which no good replacement yet = exists. =20 The "right things" that you refer to get obscured by the overall message = of the Historic label. And the -advisory draft says the "right things" = much better. > Have we actually had a formal consensus call for the IETF? Who = called the consensus? Can we have a summary? I haven't seen one. That's what the IETF Last Call was. IESG is supposed to evaluate = consensus as well as technical merit in its balloting. Keith --Apple-Mail-118-656460945 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Jul 3, 2011, at = 1:47 AM, Keith Moore wrote:
Some of = them were posted to the IETF list.  IESG may have received others = privately.  That is permitted by our = process.

This is a frustrating = conversation.   Everybody who supported the consensus in v6ops is = an IETF participant, and their wishes count toward the IETF consensus. =  

Yes their wishes do = count.   But the consensus was marginal even in v6ops, and v6ops = isn't representative of the breadth of interests in the entire IETF. =   It should hardly be surprising that a very rough consensus within = a working group doesn't translate to a rough consensus within IETF as a = whole.

v6ops isn't special in this regard. =  The same is true for any other working group.  Unfortunately, = it's really easy for a working group that is focused on a particular set = of concerns, to neglect concerns from the wider = community.

The draft is good.   = It encourages people to do the right things: keep 6to4 relays active, = but not ship products with 6to4 enabled by default.  This works for = everyone=97for people like me who are using 6to4 for our IPv6 = connectivity, it works because the relays stay up.   For people who = do not have global IPv4 addresses, they do not wind up with IPv6 routes = that go nowhere.   It certainly serves Keith Moore's needs, no = matter how vehemently, nor how often, he may insist that it does = not.

You are not in a good = position to evaluate what I need.

So this really does = look like another IETF night of long knives, where a good draft gets = scuttled in secret because a few very loud people manage to create = enough of a fuss to make the person or persons calling the consensus = feel like they're going to get fricasseed if they call the consensus in = favor of the draft.

No, it's not = a good draft.  It's misleading in many places.  And the label = of Historic is simply inappropriate for something that is still quite = useful for many people and for which no good replacement yet exists. =  

The "right things" that you refer to get = obscured by the overall message of the Historic label.  And the = -advisory draft says the "right things" much = better.

Have we actually had a = formal consensus call for the IETF?   Who called the consensus? =   Can we have a summary?   I haven't seen = one.

That's what the IETF Last = Call was.   IESG is supposed to evaluate consensus as well as = technical merit in its = balloting.

Keith

= --Apple-Mail-118-656460945-- From dougb@dougbarton.us Sat Jul 2 23:58:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5110621F8792 for ; Sat, 2 Jul 2011 23:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBNzD+5Yb6aF for ; Sat, 2 Jul 2011 23:58:57 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA2A21F8791 for ; Sat, 2 Jul 2011 23:58:57 -0700 (PDT) Received: (qmail 9437 invoked by uid 399); 3 Jul 2011 06:58:56 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 3 Jul 2011 06:58:56 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E10132E.3050902@dougbarton.us> Date: Sat, 02 Jul 2011 23:58:54 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mark Smith References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> In-Reply-To: <20110703131913.28142ec0@opy.nosense.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 06:58:58 -0000 On 07/02/2011 20:49, Mark Smith wrote: > On Sat, 02 Jul 2011 19:44:24 -0700 > Doug Barton wrote: > >> On 07/02/2011 18:50, Mark Smith wrote: >>> Where is the evidence that 6to4 is holding back native IPv6 >>> deployment? >> >> It's been discussed ad nauseum in numerous fora. > > Discussion isn't evidence, as people usually don't post any data to > support their assertions. And yet, they did. This whole thing is getting silly, and I'm tired of repeating myself. I think Lorenzo did a great job of explaining some more of the downsides of 6to4 and I don't have anything useful to add beyond what I've already said. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jul 3 00:04:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E9421F879E; Sun, 3 Jul 2011 00:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLoDARWKoUHq; Sun, 3 Jul 2011 00:04:47 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBB321F879A; Sun, 3 Jul 2011 00:04:46 -0700 (PDT) Received: from 114-30-101-21.ip.adam.com.au ([114.30.101.21] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QdGjM-00005z-Bb; Sun, 03 Jul 2011 16:34:36 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id E80563B33E; Sun, 3 Jul 2011 16:34:35 +0930 (CST) Date: Sun, 3 Jul 2011 16:34:35 +0930 From: Mark Smith To: Joel Jaeggli Message-ID: <20110703163435.681cdfe3@opy.nosense.org> In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703141519.1bb90022@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IETF Discussion , "v6ops@ietf.org" , Keith Moore Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 07:04:48 -0000 On Sat, 2 Jul 2011 21:59:24 -0700 Joel Jaeggli wrote: > This line of discussion is not productive... > > Between them the 4 largest north american wireless carriers need ~18 /8s to assign public ipv4 addresses to their wireless cpe... > they don't have that and there's no-where to get it, then there's the > rest of the world. That's now, but what about when they chose to implement IPv4 CGN, likely to be years ago. > Cameron is choosing to blame 6to4 for a problem that any of the stateless and/or unidirectional Internet protocols could cause on a IPv4 CGN. His arguments to make 6to4 historic are not based on issues specific to 6to4. If 6to4 is made historic, does he then start lobbying for UDP-historic? > On Jul 2, 2011, at 9:45 PM, Mark Smith wrote: > > > On Sat, 2 Jul 2011 21:02:02 -0700 > > Cameron Byrne wrote: > > > > > >> In the meantime, i null route the 6to4 anycast address because it > >> creates half open state in my CGN. Been doing that for at least 5 > >> years. > > > > > > So, to be clear, you're not making an observation that 6to4 is broken, > > based on measurement or actual use, you're actively breaking it. > > > >> My next step is filtering AAAA over IPv4 access because 6to4 > >> client brokeness won't die on its own, that will be rolled out in a > >> few months. Operating a network means making the tweeks that keep the > >> wheels rolling, and we don't find many technology purist in my line of > >> work. > >> > > > > I think the root cause of your issues is the deployment of IPv4 CGN in > > the first place before IANA and the RIRs ran out of IPv4 addresses by > > the sounds of it. I think then means that any protocol that your > > customers try to use that would create unwanted state in your IPv4 CGN > > should be, by your definition, declared "historic", not just 6to4. When > > a customer signs up to your service, are they informed as to which > > protocols and applications they are allowed to use? My opinion is that > > if there are restrictions on what protocols and applications customers > > can operate then their service is not a real Internet service. The > > majority of, if not all, residential broadband service providers in my > > market hold the same belief - it seems to be the "pure" mobile > > carriers that commonly don't. > > > >> Other access providers like 6to4 so much that they want to NAT it. > >> This is the reason why historic is the proper term. > >> > >> http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02 > >> > >> I look forward to that discussion on ietf@ > >> > >> Cameron > >> > >> > >>> Keith > >>> > >> _______________________________________________ > >> 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 sm@resistor.net Sun Jul 3 00:14:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BC821F87A2; Sun, 3 Jul 2011 00:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghetzTGn2u+S; Sun, 3 Jul 2011 00:14:40 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6E521F879E; Sun, 3 Jul 2011 00:14:40 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p637ESau001018; Sun, 3 Jul 2011 00:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1309677274; bh=DFT9PczvGme1UWrWTchcNy++eVwCzNWDybcxaAxFSEk=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=zks8WDCWQxSlln/c/t50FcI1b2rH1iLLEphh1q/9c3ObGD2Fr7sPhlqHNSnxecW/Q HnqxsX9V0fxxj24Drl/mTQrGFU+LsZ+g6uPJxoCUBntHFVzlHYkydUXDvaTUZj0bVr ehIWGxf5MXgYXmU0Bw6QxwjpjirfGeOfZeOgsrxA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1309677274; bh=DFT9PczvGme1UWrWTchcNy++eVwCzNWDybcxaAxFSEk=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=TMuBtt0W3rsXvJXE/N5h3ZDA8vr3MwgjfWmOqXZ8gUt1tBU4oSkmljZnHz0WNPx0Z zT2IhfiIETu9kqkHdELAPJb17e6WR2EH5qBOLxNegp2sz71Oemb8iDYUeRqh6HcBz1 pEKYaB6TanKiPJ3X8ZMPIP/fjHe2T0A7dmwfzWks= Message-Id: <6.2.5.6.2.20110702232627.0350a6d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 02 Jul 2011 23:29:58 -0700 To: IETF Discussion From: SM In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703141519.1bb90022@opy.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 07:14:46 -0000 At 21:59 02-07-2011, Joel Jaeggli wrote: >Between them the 4 largest north american wireless carriers need ~18 >/8s to assign public ipv4 addresses to their wireless cpe... they >don't have that and there's no-where to get it, then there's the >rest of the world. http://aboba.drizzlehosting.com/IAB/arin.txt Regards, -sm From v6ops@globis.net Sun Jul 3 00:16:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D1521F87C9; Sun, 3 Jul 2011 00:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmyIZ4MLCoF5; Sun, 3 Jul 2011 00:16:36 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5839F21F86FD; Sun, 3 Jul 2011 00:16:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8D6328700DE; Sun, 3 Jul 2011 09:16:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SENpc0eC544z; Sun, 3 Jul 2011 09:15:59 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 524AF870021; Sun, 3 Jul 2011 09:15:59 +0200 (CEST) Message-ID: <4E10172F.3070105@globis.net> Date: Sun, 03 Jul 2011 09:15:59 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Keith Moore References: <4E100ACB.70907@globis.net> <806331F9-2A3D-459C-8774-BED1346C475F@network-heretics.com> In-Reply-To: <806331F9-2A3D-459C-8774-BED1346C475F@network-heretics.com> Content-Type: multipart/alternative; boundary="------------030700020500050306040409" Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 07:16:38 -0000 This is a multi-part message in MIME format. --------------030700020500050306040409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Keith Moore wrote: > On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote: > > >> IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. >> > > Right now, applications developers need to be able to write and ship code that uses IPv6 and can talk to other application instances using IPv6. Anything that detracts from the ability of applications to use IPv6 at this time is a bad move IMHO and decreases the chance that there will ever be sufficient use of IPv6 (of any kind) to justify widespread deployment of native IPv6. > > >> Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. >> > > I have a better suggestion: let's declare NAT historic. That would free up lots of developers and engineers to spend time on both native v6 and better v6 transition mechanisms. Not only would they not need to engineer new NATs, applications developers wouldn't need to engineer new workarounds for new NATs. Everybody would win. > > Keith > > I'm presuming your second comment was facetious. I'm also presuming from your first comment that you will thus oppose the proposal to turn off 6to4 by default. Am I correct? regards RayH, --------------030700020500050306040409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Keith Moore wrote: 
On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote:

  
IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet.
    

Right now, applications developers need to be able to write and ship code that uses IPv6 and can talk to other application instances using IPv6.   Anything that detracts from the ability of applications to use IPv6 at this time is a bad move IMHO and decreases the chance that there will ever be sufficient use of IPv6 (of any kind) to justify widespread deployment of native IPv6.

  
Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces.
    

I have a better suggestion: let's declare NAT historic.  That would free up lots of developers and engineers to spend time on both native v6 and better v6 transition mechanisms.  Not only would they not need to engineer new NATs, applications developers wouldn't need to engineer new workarounds for new NATs.  Everybody would win.

Keith
I'm presuming your second comment was facetious.

I'm also presuming from your first comment that you will thus oppose the proposal to turn off 6to4 by default.

Am I correct?

regards
RayH,
--------------030700020500050306040409-- From moore@network-heretics.com Sun Jul 3 00:17:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35C611E8081; Sun, 3 Jul 2011 00:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZXvqSFk2T7S; Sun, 3 Jul 2011 00:17:20 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id D7ECA21F87CF; Sun, 3 Jul 2011 00:17:19 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 5FF462061D; Sun, 3 Jul 2011 03:17:19 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Sun, 03 Jul 2011 03:17:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=82yFeWwDQRzelBxU7NTqfDtI2cw=; b=eiYvY2hpHNLkOLc1rQnJNw+ksIc3GsuT0spIJ1XXaE1Z0Pi9QVDwSiJWpVnxPX3eKB8smI9pPlDMlB2JZ+7wqjTiBgd6XFMISE2UFpukwfAoL/QbNEbzHV7IjEmA5FvoJNCtu02lxtxpFM3PZExrFTA6+yEFFSq/uGyrslZtqys= X-Sasl-enc: z2yE0UA4tI14u6CzbJx0fO/Z6Mw7m87BffOZe8DRyaoD 1309677438 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 3DBEE40CC1C; Sun, 3 Jul 2011 03:17:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E10132E.3050902@dougbarton.us> Date: Sun, 3 Jul 2011 03:17:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <240CA88D-961E-4ECC-A2AA-A7829B409B75@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> <4E10132E.3050902@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 07:17:21 -0000 On Jul 3, 2011, at 2:58 AM, Doug Barton wrote: > On 07/02/2011 20:49, Mark Smith wrote: >> On Sat, 02 Jul 2011 19:44:24 -0700 >> Doug Barton wrote: >>=20 >>> On 07/02/2011 18:50, Mark Smith wrote: >>>> Where is the evidence that 6to4 is holding back native IPv6 >>>> deployment? >>>=20 >>> It's been discussed ad nauseum in numerous fora. >>=20 >> Discussion isn't evidence, as people usually don't post any data to >> support their assertions. >=20 > And yet, they did. I think it's been adequately supported that the interaction of 6to4 with = (a) misconfigured relay routers and/or (b) protocol 41 filters, hinders = one kind of native v6 deployment - i.e. providing the same content via = both v4 and v6, where the client's host prefers v6 (including 6to4) = destinations over v4 destinations. There's clearly a disincentive to a = content provider to advertise v6 addresses for its domains, if use of = those v6 addresses will result in significantly slower or less reliable = access for any significant set of users. That much should be obvious. However, that's not the only kind of IPv6 deployment that matters. Meanwhile misconfigured relay routers can be fixed, or their = advertisements filtered; and hosts can and should be updated to prefer = IPv4 destinations over 6to4 destinations. 6to4, even when enabled, = should be a "last resort". =20 All of these fixes should be implemented. But that last fix alone = should address (no pun intended) the v4/v6 content providers' concerns = while still preserving use of 6to4 for cases where IPv6 is really = needed. And that last fix can be deployed much more quickly than the = "nuclear option" of trying to get 6to4 support removed from products. Keith From randy@psg.com Sun Jul 3 00:23:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D8611E80C4; Sun, 3 Jul 2011 00:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDHDnhCUfolH; Sun, 3 Jul 2011 00:23:50 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 84B4E11E8079; Sun, 3 Jul 2011 00:23:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QdH1u-000G8f-5C; Sun, 03 Jul 2011 07:23:46 +0000 Date: Sun, 03 Jul 2011 16:23:45 +0900 Message-ID: From: Randy Bush To: Doug Barton In-Reply-To: <4E10132E.3050902@dougbarton.us> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> <4E10132E.3050902@dougbarton.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 07:23:50 -0000 >> Discussion isn't evidence, as people usually don't post any data to >> support their assertions. > > And yet, they did. > > This whole thing is getting silly, and I'm tired of repeating myself. I > think Lorenzo did a great job of explaining some more of the downsides > of 6to4 and I don't have anything useful to add beyond what I've already > said. geoff's presos show the 6to4 train wreck pretty clearly. and it ain't pretty. yes, a few geeks such as rob austein, keith moore, ... who desperately want to test ipv6 can manage to get it working. big whoopie doo. it is a disaster for a significant percentage of the end users. it needs to be stopped. randy From moore@network-heretics.com Sun Jul 3 00:29:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7E121F87E4; Sun, 3 Jul 2011 00:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, MANGLED_WANT=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrzHAkPsscqg; Sun, 3 Jul 2011 00:29:40 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id C215D21F87E3; Sun, 3 Jul 2011 00:29:40 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 61D5620A21; Sun, 3 Jul 2011 03:29:40 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 03 Jul 2011 03:29:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=6O3TkT4AUABAeZqpfCRBdWmOEvo=; b=LNN33/7jJGk7XoWO1Ym3JqpyUn2ig4ShFnLy8Zx2Sa8dB35v9tnVgMkMocBMa/pvHrv8K5z4KzZ3EhOzkEo+ZLvv1Yf+CtoIg5fRwfVPfJoUbfqrDD3UVJ4V3WUJVzcfp8Rpch1FR9J4wyntgvy4Spm3JnhSAqbjiVgbVlGxBws= X-Sasl-enc: XuZq3qwW8Gt/W1NiS3CwtfjGwsO6ogGCxImbvbk5UJ7u 1309678179 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 58CD440348E; Sun, 3 Jul 2011 03:29:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E10172F.3070105@globis.net> Date: Sun, 3 Jul 2011 03:29:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9601ECDE-CFBF-498A-B12D-86A1D1EE4EAC@network-heretics.com> References: <4E100ACB.70907@globis.net> <806331F9-2A3D-459C-8774-BED1346C475F@network-heretics.com> <4E10172F.3070105@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 07:29:41 -0000 On Jul 3, 2011, at 3:15 AM, Ray Hunter wrote: > Keith Moore wrote: >>=20 >> On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote: >>=20 >> =20 >>> IMHO Right now, we need services with native IPv6 based interfaces, = with equivalent performance and equivalent features and equivalent price = that we have today with IPv4. Anything that detracts from the roll out = of native IPv6 based service interfaces at this time is a bad move IMVHO = and hastens the day that the Internet fragments into a bunch of CGN = zones, that is dominated by businesses that can afford to buy public = IPv4 addresses for their servers or services, or whose business model = relies on NAT traversal being difficult. I personally don't want that = sort of Internet. >>> =20 >>=20 >> Right now, applications developers need to be able to write and ship = code that uses IPv6 and can talk to other application instances using = IPv6. Anything that detracts from the ability of applications to use = IPv6 at this time is a bad move IMHO and decreases the chance that there = will ever be sufficient use of IPv6 (of any kind) to justify widespread = deployment of native IPv6. >>=20 >> =20 >>> Given that development and engineering support time is finite, I'd = much rather that 6to4 was declared historic so that developers and = engineers could spend more time on deployment of native IPv6 service = interfaces. >>> =20 >>=20 >> I have a better suggestion: let's declare NAT historic. That would = free up lots of developers and engineers to spend time on both native v6 = and better v6 transition mechanisms. Not only would they not need to = engineer new NATs, applications developers wouldn't need to engineer new = workarounds for new NATs. Everybody would win. >>=20 >> Keith >>=20 >> =20 > I'm presuming your second comment was facetious. Mostly. Though I do think that declaring NAT historic is absolutely as = valid as declaring 6to4 historic. Both 6to4 and NAT are things that = are useful in some cases and cause harm in others. Except that 6to4 = doesn't actually cause harm except in conjunction with other dubious = practices (bogus anycast route advertisements, protocol 41 filtering, = use public IPv4 addresses behind LSN) which are outside of 6to4's scope, = whereas NAT inherently causes harm. But it wan't a serious suggestion, just an analogy. > I'm also presuming from your first comment that you will thus oppose = the proposal to turn off 6to4 by default. >=20 > Am I correct? I've already said on several occasions that I agree that 6to4 should be = off by default. It's mostly the Historic label that I have the problem = with. (I have other objections to the document also, but those are = just places where I think the wording is misleading. The label is the = big thing.) Keith From gert@space.net Sun Jul 3 04:10:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9D721F856F for ; Sun, 3 Jul 2011 04:10:53 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B+OOplHOQU0 for ; Sun, 3 Jul 2011 04:10:53 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 34D0621F856E for ; Sun, 3 Jul 2011 04:10:50 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 5B917F8519 for ; Sun, 3 Jul 2011 13:10:47 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 321E2F850C for ; Sun, 3 Jul 2011 13:10:47 +0200 (CEST) Received: (qmail 55907 invoked by uid 1007); 3 Jul 2011 13:10:47 +0200 Date: Sun, 3 Jul 2011 13:10:47 +0200 From: Gert Doering To: Keith Moore Message-ID: <20110703111047.GB2304@Space.Net> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> 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.21 (2010-09-15) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 11:10:55 -0000 Hi, On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: > There's clearly a lack of consensus to support it. There's two very vocal persons opposing it and a much larger number of people that support it, but have not the time to write a similarily large amount of e-mails. For me, this is enough for "rough consensus". (And I second everything Lorenzo, Randy and Cameron said - there's theoretical possibilities, and real world. 6to4 fails the real-world test. Get over it, instead of attacking people that run real-world networks for the decisions they need to do to keep the networks running in a world without enough IPv4 addresses). Gert Doering -- Operator -- did you enable 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 (89) 32356-444 USt-IdNr.: DE813185279 From pch-b2B3A6689@u-1.phicoh.com Sun Jul 3 04:17:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0898E21F8699; Sun, 3 Jul 2011 04:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMXplb5l4rAs; Sun, 3 Jul 2011 04:17:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 84CCE21F856E; Sun, 3 Jul 2011 04:17:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QdKfr-0001jNC; Sun, 3 Jul 2011 13:17:15 +0200 Message-Id: To: Lorenzo Colitti From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> In-reply-to: Your message of "Sun, 3 Jul 2011 07:53:46 +0200 ." Date: Sun, 03 Jul 2011 13:17:14 +0200 Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 11:17:21 -0000 In your letter dated Sun, 3 Jul 2011 07:53:46 +0200 you wrote: >Unfortunately, in the 20% of the time that it's not working, Google has no >idea that the user has a 2002::/16 address. Google only knows, after the >fact, that the user suffered a 20 or 75-second timeout and was not happy. So >it would serve no purpose to avoid serving users that successfully connect >from 2002::/16 addresses; once the AAAA record is handed out, the damage is >done. What Google could do, however, is stop handing out AAAA records to >networks that have significant number of 6to4 users in the future. We're >considering this. I think this clearly illustrates why the IETF should issue a strong statement that no new 6to4 installation should be deplayed and the existing 6to4 users should migrate to other tunneling techniques (if native is not available). The problem with 6to4 is it was rolled out on a relatively large scale when there was essentially no IPv6 content. As a result, the people who had a broken 6to4 setup would only find out when content providers would start adding AAAA records. In other words, it was ticking time bomb. This time bomb has been defused mostly because most operating system now prefer any kind of IPv4 over a 6to4 address. So once again people can have a broken 6to4 setup without noticing it. What worries me is that people will start using 6to4 for bittorrent. Bittorrent will of course completely hide broken setups and worse, it will also hide broken 6to4 relays. So we may end up with a sizable group people who have an IPv6 setup that completely doesn't work. And they don't know it. Which will create all kinds of headaches for IPv6-only content because you have to explain to users that yes, they have an IPv6 address and no, it is not going to work. And all of this, because a few hobbyists are afraid that declaring 6to4 as historic will require them to search a bit harder in the furture for a router that supports 6to4. From cb.list6@gmail.com Sun Jul 3 05:32:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACA721F87AC; Sun, 3 Jul 2011 05:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MANGLED_WANT=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4FpSYqV0Jod; Sun, 3 Jul 2011 05:32:33 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 999A421F876A; Sun, 3 Jul 2011 05:32:24 -0700 (PDT) Received: by wyj26 with SMTP id 26so3426223wyj.31 for ; Sun, 03 Jul 2011 05:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Opp2cZ1zmtuZwRhX16bpqEZ87wCKJmobHMDB5uYD5Zs=; b=di+cdXj8nmLe6U/d/vrlOl/9QZiCKezLyNlcgLBwo+hqBGFi+Qy2gp1w+UHNzMdg3D 4wNzPZljWyi4Go31YEqtmtxcdfSQJQv/FUTX6pA2s+HOvS8UEPowvYWnmrw9czWFmouU RV8OmxRo7mf4FiKNDor3dJPrqHK8youxd43rQ= MIME-Version: 1.0 Received: by 10.216.198.146 with SMTP id v18mr884886wen.94.1309696343497; Sun, 03 Jul 2011 05:32:23 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Sun, 3 Jul 2011 05:32:23 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Sun, 3 Jul 2011 05:32:23 -0700 (PDT) In-Reply-To: <9601ECDE-CFBF-498A-B12D-86A1D1EE4EAC@network-heretics.com> References: <4E100ACB.70907@globis.net> <806331F9-2A3D-459C-8774-BED1346C475F@network-heretics.com> <4E10172F.3070105@globis.net> <9601ECDE-CFBF-498A-B12D-86A1D1EE4EAC@network-heretics.com> Date: Sun, 3 Jul 2011 05:32:23 -0700 Message-ID: From: Cameron Byrne To: Keith Moore Content-Type: multipart/alternative; boundary=0016e6d59e1b515c5704a72971fa Cc: Ray Hunter , "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 12:32:34 -0000 --0016e6d59e1b515c5704a72971fa Content-Type: text/plain; charset=ISO-8859-1 On Jul 3, 2011 12:29 AM, "Keith Moore" wrote: > > > On Jul 3, 2011, at 3:15 AM, Ray Hunter wrote: > > > Keith Moore wrote: > >> > >> On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote: > >> > >> > >>> IMHO Right now, we need services with native IPv6 based interfaces, with equivalent performance and equivalent features and equivalent price that we have today with IPv4. Anything that detracts from the roll out of native IPv6 based service interfaces at this time is a bad move IMVHO and hastens the day that the Internet fragments into a bunch of CGN zones, that is dominated by businesses that can afford to buy public IPv4 addresses for their servers or services, or whose business model relies on NAT traversal being difficult. I personally don't want that sort of Internet. > >>> > >> > >> Right now, applications developers need to be able to write and ship code that uses IPv6 and can talk to other application instances using IPv6. Anything that detracts from the ability of applications to use IPv6 at this time is a bad move IMHO and decreases the chance that there will ever be sufficient use of IPv6 (of any kind) to justify widespread deployment of native IPv6. > >> > >> > >>> Given that development and engineering support time is finite, I'd much rather that 6to4 was declared historic so that developers and engineers could spend more time on deployment of native IPv6 service interfaces. > >>> > >> > >> I have a better suggestion: let's declare NAT historic. That would free up lots of developers and engineers to spend time on both native v6 and better v6 transition mechanisms. Not only would they not need to engineer new NATs, applications developers wouldn't need to engineer new workarounds for new NATs. Everybody would win. > >> > >> Keith > >> > >> > > I'm presuming your second comment was facetious. > > Mostly. Though I do think that declaring NAT historic is absolutely as valid as declaring 6to4 historic. Both 6to4 and NAT are things that are useful in some cases and cause harm in others. Except that 6to4 doesn't actually cause harm except in conjunction with other dubious practices (bogus anycast route advertisements, protocol 41 filtering, use public IPv4 addresses behind LSN) which are outside of 6to4's scope, whereas NAT inherently causes harm. > Right. Because you are not accountable for growing the internet or customer experience. The people that say kill 6to4 are. I hope that is clear to iesg. Please look closely at the motives. Cb > But it wan't a serious suggestion, just an analogy. > > > I'm also presuming from your first comment that you will thus oppose the proposal to turn off 6to4 by default. > > > > Am I correct? > > I've already said on several occasions that I agree that 6to4 should be off by default. It's mostly the Historic label that I have the problem with. (I have other objections to the document also, but those are just places where I think the wording is misleading. The label is the big thing.) > > Keith > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --0016e6d59e1b515c5704a72971fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 3, 2011 12:29 AM, "Keith Moore" <moore@network-heretics.com> wrote:
>
>
> On Jul 3, 2011, at 3:15 AM, Ray Hunter wrote:
>
> > Keith Moore wrote:
> >>
> >> On Jul 3, 2011, at 2:23 AM, Ray Hunter wrote:
> >>
> >>
> >>> IMHO Right now, we need services with native IPv6 based i= nterfaces, with equivalent performance and equivalent features and equivale= nt price that we have today with IPv4. Anything that detracts from the roll= out of native IPv6 based service interfaces at this time is a bad move IMV= HO and hastens the day that the Internet fragments into a bunch of CGN zone= s, that is dominated by businesses that can afford to buy public IPv4 addre= sses for their servers or services, or whose business model relies on NAT t= raversal being difficult. I personally don't want that sort of Internet= .
> >>>
> >>
> >> Right now, applications developers need to be able to write a= nd ship code that uses IPv6 and can talk to other application instances usi= ng IPv6. =A0 Anything that detracts from the ability of applications to use= IPv6 at this time is a bad move IMHO and decreases the chance that there w= ill ever be sufficient use of IPv6 (of any kind) to justify widespread depl= oyment of native IPv6.
> >>
> >>
> >>> Given that development and engineering support time is fi= nite, I'd much rather that 6to4 was declared historic so that developer= s and engineers could spend more time on deployment of native IPv6 service = interfaces.
> >>>
> >>
> >> I have a better suggestion: let's declare NAT historic. = =A0That would free up lots of developers and engineers to spend time on bot= h native v6 and better v6 transition mechanisms. =A0Not only would they not= need to engineer new NATs, applications developers wouldn't need to en= gineer new workarounds for new NATs. =A0Everybody would win.
> >>
> >> Keith
> >>
> >>
> > I'm presuming your second comment was facetious.
>
> Mostly. =A0 Though I do think that declaring NAT historic is absolutel= y as valid as declaring 6to4 historic. =A0 =A0Both 6to4 and NAT are things = that are useful in some cases and cause harm in others. =A0Except that 6to4= doesn't actually cause harm except in conjunction with other dubious p= ractices (bogus anycast route advertisements, protocol 41 filtering, use pu= blic IPv4 addresses behind LSN) which are outside of 6to4's scope, wher= eas NAT inherently causes harm.
>

Right. Because you are not accountable for growing the internet or custo= mer experience. The people that say kill 6to4 are. I hope that is clear to = iesg. Please look closely at the motives.

Cb

> But it wan't a serious suggestion, just an analogy.
>
> > I'm also presuming from your first comment that you will thus= oppose the proposal to turn off 6to4 by default.
> >
> > Am I correct?
>
> I've already said on several occasions that I agree that 6to4 shou= ld be off by default. =A0 It's mostly the Historic label that I have th= e problem with. =A0 (I have other objections to the document also, but thos= e are just places where I think the wording is misleading. =A0The label is = the big thing.)
>
> Keith
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--0016e6d59e1b515c5704a72971fa-- From moore@network-heretics.com Sun Jul 3 06:01:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8350721F87F6; Sun, 3 Jul 2011 06:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bc+v4wBPoAxd; Sun, 3 Jul 2011 06:01:50 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id C978521F87E6; Sun, 3 Jul 2011 06:01:50 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 792682354E; Sun, 3 Jul 2011 09:01:50 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 03 Jul 2011 09:01:50 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=TCbl8boC0QZnqNndqR1+78kCkI0=; b=JpNP7njdGkM0ZGwSGeFENVtd3SzOn2GUIr4wk49LGEjLr/LHnFWlXd9wHSnI01lDjS4HWHWPQQWaoxhX4NgKKoNntb0ux75kkIlmvd2DKSn1NAk5rwFEq68lplPOA/OkISaJKEvGWA9z+W9ZuhQOcBUzYI3g9H8bacpZMPv9x+o= X-Sasl-enc: 4sy93sHtML0Cxa4TtKDsu5Spqkdkh/84WQCXezRnp/Tv 1309698109 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F42B400556; Sun, 3 Jul 2011 09:01:49 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110703111047.GB2304@Space.Net> Date: Sun, 3 Jul 2011 09:01:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1F8EDDA8-21A8-4C6C-93D1-F8852245E173@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703111047.GB2304@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 13:01:51 -0000 On Jul 3, 2011, at 7:10 AM, Gert Doering wrote: > On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: >> There's clearly a lack of consensus to support it. >=20 > There's two very vocal persons opposing it and a much larger number of > people that support it, but have not the time to write a similarily > large amount of e-mails. For me, this is enough for "rough = consensus". There were several people opposing it at Last Call - enough that no = amount of emails in favor would result in rough consensus. What this = is, is an attempt to railroad this through IETF without getting = consensus. > (And I second everything Lorenzo, Randy and Cameron said - there's=20 > theoretical possibilities, and real world. 6to4 fails the real-world > test. Get over it, instead of attacking people that run real-world > networks for the decisions they need to do to keep the networks = running > in a world without enough IPv4 addresses). In the real world, there are lots of people successfully using 6to4, and = there's no good replacement for it. Keith From moore@network-heretics.com Sun Jul 3 06:14:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A77F21F86D3; Sun, 3 Jul 2011 06:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRYzrSQUsftQ; Sun, 3 Jul 2011 06:14:35 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 37CF921F86D2; Sun, 3 Jul 2011 06:14:35 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id E1E10295AE; Sun, 3 Jul 2011 09:14:33 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 03 Jul 2011 09:14:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=sVMVYztyxl8bZOt29/PC57A+kmE=; b=TF1z8zrqHPoVu8TebqvM0PE4Tad35twTud5EDG/lwuao2Udw11wNjwh/PuTjfLO2HCk04qYoJXDSuoLKhgvq+viiby0MjgCxq6zzi/7Jv6NISniNQ8g1LicIf4S5ICErCVYsL27A/rIIPb4Q8MnYnW9YwjZ3SFEd65COLtB/m6s= X-Sasl-enc: BpmkNjQ55xNalyIGL4G+1bojexTzV9K5n0VZ8ciXk9jO 1309698873 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id BF63A40034F; Sun, 3 Jul 2011 09:14:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-119-679173293 From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 09:14:14 -0400 Message-Id: <94253014-42C1-467F-9752-42ED4231DDB6@network-heretics.com> References: <4E100ACB.70907@globis.net> <806331F9-2A3D-459C-8774-BED1346C475F@network-heretics.com> <4E10172F.3070105@globis.net> <9601ECDE-CFBF-498A-B12D-86A1D1EE4EAC@network-heretics.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter , "v6ops@ietf.org WG" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 13:14:36 -0000 --Apple-Mail-119-679173293 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2011, at 8:32 AM, Cameron Byrne wrote: > > > I'm presuming your second comment was facetious. > > > > Mostly. Though I do think that declaring NAT historic is = absolutely as valid as declaring 6to4 historic. Both 6to4 and NAT are = things that are useful in some cases and cause harm in others. Except = that 6to4 doesn't actually cause harm except in conjunction with other = dubious practices (bogus anycast route advertisements, protocol 41 = filtering, use public IPv4 addresses behind LSN) which are outside of = 6to4's scope, whereas NAT inherently causes harm. > > >=20 > Right. Because you are not accountable for growing the internet or = customer experience. The people that say kill 6to4 are. I hope that is = clear to iesg. Please look closely at the motives. >=20 Note that the ONLY substantive thing we're arguing about here is the = Historic label. I don't see any significant disagreement about the = technical details. Keith --Apple-Mail-119-679173293 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 3, 2011, at 8:32 AM, Cameron Byrne wrote:

> > I'm presuming your second comment was facetious.
>
> Mostly.   Though I do think that declaring NAT historic is absolutely as valid as declaring 6to4 historic.    Both 6to4 and NAT are things that are useful in some cases and cause harm in others.  Except that 6to4 doesn't actually cause harm except in conjunction with other dubious practices (bogus anycast route advertisements, protocol 41 filtering, use public IPv4 addresses behind LSN) which are outside of 6to4's scope, whereas NAT inherently causes harm.
>

Right. Because you are not accountable for growing the internet or customer experience. The people that say kill 6to4 are. I hope that is clear to iesg. Please look closely at the motives.

Note that the ONLY substantive thing we're arguing about here is the Historic label.    I don't see any significant disagreement about the technical details.

Keith

--Apple-Mail-119-679173293-- From moore@network-heretics.com Sun Jul 3 06:59:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC2721F86EA; Sun, 3 Jul 2011 06:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTr7lLimmtYU; Sun, 3 Jul 2011 06:59:50 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id BEAEB21F86E7; Sun, 3 Jul 2011 06:59:50 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id E1E4523ACF; Sun, 3 Jul 2011 09:59:49 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 03 Jul 2011 09:59:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=5N7vBNX+REBdp2bIu6p2Xnf9G6M=; b=LeDN7+adZ5OG0hp+kuDfbg5FZ/iHQipUyKeGQ9A77iBqhALeOGFqjjia6/mW3687Uj5m9j6pf9vE++MYfjGp01+iZsFyH0V5VmipVdTVBj/r4UpIotChkFcANLhdiJ1b8+GgyxKLOXdEIBQT+k94oHO76ZKOFvLcPelFMu8mFHY= X-Sasl-enc: IWIHsdIm4tFZIX3W8+UkF4PFLfN+EcZCmpOVJx/bmBLW 1309701589 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 0AF90400537; Sun, 3 Jul 2011 09:59:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 09:59:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2DBDB375-BA46-47B5-A170-8B564CD811A7@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> <4E10132E.3050902@dougbarton.us> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 13:59:51 -0000 On Jul 3, 2011, at 3:23 AM, Randy Bush wrote: > geoff's presos show the 6to4 train wreck pretty clearly. and it ain't > pretty. >=20 > yes, a few geeks such as rob austein, keith moore, ... who desperately > want to test ipv6 can manage to get it working. big whoopie doo.=20 I don't understand the desire to dismiss applications developers or = existing 6to4 users as "a few geeks", but it's clearly a = misrepresentation. > it is a disaster for a significant percentage of the end users. it = needs to be stopped. no, it needs to be fixed. and many of the fixes have nothing to do with = 6to4 implementations, but rather, with operators. Keith From jnc@mercury.lcs.mit.edu Sun Jul 3 07:07:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B889221F86EF; Sun, 3 Jul 2011 07:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0FZ+yhhWmWq; Sun, 3 Jul 2011 07:07:40 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 4700E21F86EC; Sun, 3 Jul 2011 07:07:40 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 08F5C18C13C; Sun, 3 Jul 2011 10:07:39 -0400 (EDT) To: ietf@ietf.org Message-Id: <20110703140739.08F5C18C13C@mercury.lcs.mit.edu> Date: Sun, 3 Jul 2011 10:07:39 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: v6ops@ietf.org, jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 14:07:40 -0000 > From: Lorenzo Colitti > Compared to the alternative of publishing 6to4-historic now, it: > a) Delays the time of any statement made by the IETF on the question > by at least a number of months, while vendors and home gateways are > *still shipping* products that implement 6to4 and enable it by > default. draft-ietf-v6ops-6to4-advisory - which already exists, and which nobody is objecting to - already contains text which tells manufacturers of both home routers and hosts to disable 6to4 by default, etc, etc. If acting ASAP is desirable, that ID could be approved just as quickly as draft-ietf-v6ops-6to4-to-historic-05.txt could be (to be later updated by the new document mentioned in the recent announcement). > b) Even assuming it were to gain consensus in any sort of reasonable > timescale, it would provide a less clear statement, and thus be less > of an incentive for implementors such as home gateway manufacturers > to do the right thing and remove it. First, killing 6to4 is an additional goal, above and beyond 'stop 6to4 from causing problems'. The only conceivable reason I can think of for that additional step seems to be the possibility that somehow 6to4 will cause problems anyway, even if it is normally disabled? This seems unlikely to me. Is there any reason beyond that to kill 6to4? Second, what reason is there to believe that a document that says 'remove 6to4' is going to meet with greater/faster compliance from vendors than a document that says 'disable it'? I would argue that the former takes more engineering time, and is actually marginally less likely to be timely responded to. Noel From jnc@mercury.lcs.mit.edu Sun Jul 3 07:12:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7749721F866E; Sun, 3 Jul 2011 07:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9bmU8A6hEY4; Sun, 3 Jul 2011 07:12:12 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 07CA321F85BB; Sun, 3 Jul 2011 07:12:09 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6B3BD18C13C; Sun, 3 Jul 2011 10:12:09 -0400 (EDT) To: ietf@ietf.org Message-Id: <20110703141209.6B3BD18C13C@mercury.lcs.mit.edu> Date: Sun, 3 Jul 2011 10:12:09 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: v6ops@ietf.org, jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 14:12:12 -0000 > From: Doug Barton > Bad 6to4 (which almost all of it is) draft-ietf-v6ops-6to4-advisory says: The experiment conducted by Aben recorded a failure rate of between 9% and 20% of all 6to4 connection attempts. The experiment conducted by Huston has recorded a failure rate of between 9% and 19% of all 6to4 clients. 20% != "almost all of it". > I realize that there are a lot of people that dismiss both the > evidence that's been put forward This is again a complete misrepresentation of the actual situation. Please name _one_ person who thinks that automatically enabled 6to4 is not causing any problems. Noel From moore@network-heretics.com Sun Jul 3 07:12:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A42621F8722; Sun, 3 Jul 2011 07:12:31 -0700 (PDT) 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=[AWL=1.104, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn8b1xPBJ25s; Sun, 3 Jul 2011 07:12:30 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7B10F21F8713; Sun, 3 Jul 2011 07:12:30 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 3394F293E9; Sun, 3 Jul 2011 10:12:30 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 03 Jul 2011 10:12:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=hFHhoS8/PCpbJzQAOSVEoV+KIP4=; b=odgPwfuT69SC9J0rZNNxF5zy65R5VyQvRiy58rME3rHjajuIPGjBcV5BD1ohirIf8DsfsS8Ys5UHurcRvMjUdeYUIAVTB3ucfm6tDTyixN6SJdPUGAaK+3OyYJc3a/9FO7xjx7oBJ0wiOs3qksNAy1I/T5uuv4vE1H3NKqUkHc4= X-Sasl-enc: QrgxGVXaHBrJfuKYWwqs2HbYyJL7+aJwR9jLxm8+RNZ+ 1309702349 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id E9E3E401B68; Sun, 3 Jul 2011 10:12:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 10:12:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 14:12:31 -0000 On Jul 3, 2011, at 7:17 AM, Philip Homburg wrote: > In your letter dated Sun, 3 Jul 2011 07:53:46 +0200 you wrote: >> Unfortunately, in the 20% of the time that it's not working, Google = has no >> idea that the user has a 2002::/16 address. Google only knows, after = the >> fact, that the user suffered a 20 or 75-second timeout and was not = happy. So >> it would serve no purpose to avoid serving users that successfully = connect >> from 2002::/16 addresses; once the AAAA record is handed out, the = damage is >> done. What Google could do, however, is stop handing out AAAA records = to >> networks that have significant number of 6to4 users in the future. = We're >> considering this. >=20 > I think this clearly illustrates why the IETF should issue a strong = statement > that no new 6to4 installation should be deplayed and the existing 6to4 = users > should migrate to other tunneling techniques (if native is not = available). I think this clearly illustrates why IETF should issue a strong = statement that a) operators of 6to4 relays should not advertise those relays via BGP = unless they're routing traffic for all of 2002://16 or native v6, = respectively b) operators should not filter protocol 41traffic c) (maybe) operators using LSN should use RFC 1918 addresses behind = those NATs unless/until there's another address range that 6to4 host = implementations know about d) 6to4 should be disabled by default in both hosts and routers e) host implementations should prefer native v4 destinations over 6to4 = destinations when both are available and the application can use either = IPv4 or IPv6 Saying that no new 6to4 installation should be deployed and that = existing 6to4 users should migrate to other tunneling techniques assumes = that all installations and users have the same needs, namely, to access = content over IPv6 that is also available over IPv4. > The problem with 6to4 is it was rolled out on a relatively large scale = when=20 > there was essentially no IPv6 content. As a result, the people who had = a > broken 6to4 setup would only find out when content providers would = start > adding AAAA records.=20 >=20 > In other words, it was ticking time bomb. The label "broken 6to4 setup" is misleading. Most of the time, the = thing that breaks 6to4 is not the user's "setup"; it's an ISP somewhere = that is either (a) advertising a bad relay or (b) filtering protocol 41. = (If the problem were the users' setups, the providers could just say = "not our problem; fix your 6to4 setup") > What worries me is that people will start using 6to4 for bittorrent. = Bittorrent > will of course completely hide broken setups and worse, it will also = hide=20 > broken 6to4 relays.=20 =46rom my understanding of bittorrent, it will just find other routes. > And all of this, because a few hobbyists are afraid that declaring = 6to4 as > historic will require them to search a bit harder in the furture for a > router that supports 6to4. You completely misunderstand both the situation, and the size and = diversity of 6to4 users. =20 Keith From moore@network-heretics.com Sun Jul 3 07:22:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C11A21F8722; Sun, 3 Jul 2011 07:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF9lkCBYQeMo; Sun, 3 Jul 2011 07:22:57 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7806421F870B; Sun, 3 Jul 2011 07:22:54 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 3136129546; Sun, 3 Jul 2011 10:22:54 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 03 Jul 2011 10:22:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=RozvxWDOR7rE4WYhIiKMnefS0vA=; b=aBZqiZVS652UfbBHtH7dw9+g6s+JJSur93/u2DpOpIn+cjesjpJsTl9Yuw5YQ/tYwEA2jsaXAqrhEzA6Onvm0wLhfbb7OtOysJI7gDSylgQsMhoUQ1pw/6ag1zLbSTW4j/u7n6Qb3nJoG+KZ67sA4bCvQXXZXzuRGHUPNwBNcro= X-Sasl-enc: dkCFA6qusTVA8lQcuKdK7zTu8poGz4GDTxkgTCVVEXQo 1309702973 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 68BA540471B; Sun, 3 Jul 2011 10:22:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110703140739.08F5C18C13C@mercury.lcs.mit.edu> Date: Sun, 3 Jul 2011 10:22:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110703140739.08F5C18C13C@mercury.lcs.mit.edu> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 14:22:57 -0000 On Jul 3, 2011, at 10:07 AM, Noel Chiappa wrote: > draft-ietf-v6ops-6to4-advisory - which already exists, and which = nobody is > objecting to - already contains text which tells manufacturers of both > home routers and hosts to disable 6to4 by default, etc, etc. If acting > ASAP is desirable, that ID could be approved just as quickly as > draft-ietf-v6ops-6to4-to-historic-05.txt could be (to be later updated = by > the new document mentioned in the recent announcement). It's already been approved. The announcement went out on July 1. = Though to be fair, the document is Informational rather than an update = to a standards track document. Keith From cb.list6@gmail.com Sun Jul 3 07:32:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB011F0C64; Sun, 3 Jul 2011 07:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=1.429, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2S33+16RRlWN; Sun, 3 Jul 2011 07:32:35 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 186C81F0C65; Sun, 3 Jul 2011 07:32:34 -0700 (PDT) Received: by wyj26 with SMTP id 26so3460063wyj.31 for ; Sun, 03 Jul 2011 07:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UPpl7RuX5cLitJ4smKzinUamUAvqFFg/r8fK+Z7b/w8=; b=gundcwjWFqN8VMWexhjPcHhux2oEkA1ICzOFSoK9PweEBwK03QmtOChmTOf3yJUudM /6Qv56CNg4gfjQG/gztapKd5MRc7v2n+uVD/jVXLoMEqh8BzIBkcoikJK2OoTV/I0eqk 3xcXIhG8vBznBY9xy1ZvGWyyCBI2lau05R5LU= MIME-Version: 1.0 Received: by 10.216.63.131 with SMTP id a3mr4261316wed.64.1309703553084; Sun, 03 Jul 2011 07:32:33 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Sun, 3 Jul 2011 07:32:32 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Sun, 3 Jul 2011 07:32:32 -0700 (PDT) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> Date: Sun, 3 Jul 2011 07:32:32 -0700 Message-ID: From: Cameron Byrne To: Keith Moore Content-Type: multipart/alternative; boundary=000e0cdfd8bc0aec8504a72b1f2b Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 14:32:36 -0000 --000e0cdfd8bc0aec8504a72b1f2b Content-Type: text/plain; charset=ISO-8859-1 On Jul 3, 2011 7:14 AM, "Keith Moore" wrote: > > On Jul 3, 2011, at 7:17 AM, Philip Homburg wrote: > > > In your letter dated Sun, 3 Jul 2011 07:53:46 +0200 you wrote: > >> Unfortunately, in the 20% of the time that it's not working, Google has no > >> idea that the user has a 2002::/16 address. Google only knows, after the > >> fact, that the user suffered a 20 or 75-second timeout and was not happy. So > >> it would serve no purpose to avoid serving users that successfully connect > >> from 2002::/16 addresses; once the AAAA record is handed out, the damage is > >> done. What Google could do, however, is stop handing out AAAA records to > >> networks that have significant number of 6to4 users in the future. We're > >> considering this. > > > > I think this clearly illustrates why the IETF should issue a strong statement > > that no new 6to4 installation should be deplayed and the existing 6to4 users > > should migrate to other tunneling techniques (if native is not available). > > I think this clearly illustrates why IETF should issue a strong statement that > > a) operators of 6to4 relays should not advertise those relays via BGP unless they're routing traffic for all of 2002://16 or native v6, respectively > b) operators should not filter protocol 41traffic > c) (maybe) operators using LSN should use RFC 1918 addresses behind those NATs unless/until there's another address range that 6to4 host implementations know about > d) 6to4 should be disabled by default in both hosts and routers > e) host implementations should prefer native v4 destinations over 6to4 destinations when both are available and the application can use either IPv4 or IPv6 > You will not get "consensus" on these statements in the IETF or by the various companies that implement gear and networks in the REAL world. Can we let this thread die now? If the ietf will not kill 6to4, there are several other methods to deal with it in the REAL world (dns whitelisting, null routes, rfp's, blocking aaaa on ipv4 ....). Just like the NAT debacle of years past , the IETF has once again proven its irrelevance. Thanks for your time and have a great weekend. Cb > Saying that no new 6to4 installation should be deployed and that existing 6to4 users should migrate to other tunneling techniques assumes that all installations and users have the same needs, namely, to access content over IPv6 that is also available over IPv4. > > > The problem with 6to4 is it was rolled out on a relatively large scale when > > there was essentially no IPv6 content. As a result, the people who had a > > broken 6to4 setup would only find out when content providers would start > > adding AAAA records. > > > > In other words, it was ticking time bomb. > > The label "broken 6to4 setup" is misleading. Most of the time, the thing that breaks 6to4 is not the user's "setup"; it's an ISP somewhere that is either (a) advertising a bad relay or (b) filtering protocol 41. (If the problem were the users' setups, the providers could just say "not our problem; fix your 6to4 setup") > > > What worries me is that people will start using 6to4 for bittorrent. Bittorrent > > will of course completely hide broken setups and worse, it will also hide > > broken 6to4 relays. > > From my understanding of bittorrent, it will just find other routes. > > > And all of this, because a few hobbyists are afraid that declaring 6to4 as > > historic will require them to search a bit harder in the furture for a > > router that supports 6to4. > > You completely misunderstand both the situation, and the size and diversity of 6to4 users. > > Keith > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --000e0cdfd8bc0aec8504a72b1f2b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 3, 2011 7:14 AM, "Keith Moore" <moore@network-heretics.com> wrote:
>
> On Jul 3, 2011, at 7:17 AM, Philip Homburg wrote:
>
> > In your letter dated Sun, 3 Jul 2011 07:53:46 +0200 you wrote: > >> Unfortunately, in the 20% of the time that it's not worki= ng, Google has no
> >> idea that the user has a 2002::/16 address. Google only knows= , after the
> >> fact, that the user suffered a 20 or 75-second timeout and wa= s not happy. So
> >> it would serve no purpose to avoid serving users that success= fully connect
> >> from 2002::/16 addresses; once the AAAA record is handed out,= the damage is
> >> done. What Google could do, however, is stop handing out AAAA= records to
> >> networks that have significant number of 6to4 users in the fu= ture. We're
> >> considering this.
> >
> > I think this clearly illustrates why the IETF should issue a stro= ng statement
> > that no new 6to4 installation should be deplayed and the existing= 6to4 users
> > should migrate to other tunneling techniques (if native is not av= ailable).
>
> I think this clearly illustrates why IETF should issue a strong statem= ent that
>
> a) operators of 6to4 relays should not advertise those relays via BGP = unless they're routing traffic for all of 2002://16 or native v6, respe= ctively
> b) operators should not filter protocol 41traffic
> c) (maybe) operators using LSN should use RFC 1918 addresses behind th= ose NATs unless/until there's another address range that 6to4 host impl= ementations know about
> d) 6to4 should be disabled by default in both hosts and routers
> e) host implementations should prefer native v4 destinations over 6to4= destinations when both are available and the application can use either IP= v4 or IPv6
>

You will not get "consensus" on these statements in the IETF o= r by the various companies that implement gear and networks in the REAL wor= ld.

Can we let this thread die now? If the ietf will not kill 6to4, there ar= e several other methods to deal with it in the REAL world (dns whitelisting= , null routes, rfp's, blocking aaaa on ipv4 ....). Just like the NAT de= bacle of years past , the IETF has once again proven its irrelevance.

Thanks for your time and have a great weekend.

Cb

> Saying that no new 6to4 installation should be deployed and that ex= isting 6to4 users should migrate to other tunneling techniques assumes that= all installations and users have the same needs, namely, to access content= over IPv6 that is also available over IPv4.
>
> > The problem with 6to4 is it was rolled out on a relatively large = scale when
> > there was essentially no IPv6 content. As a result, the people wh= o had a
> > broken 6to4 setup would only find out when content providers woul= d start
> > adding AAAA records.
> >
> > In other words, it was ticking time bomb.
>
> The label "broken 6to4 setup" is misleading. =A0 Most of the= time, the thing that breaks 6to4 is not the user's "setup"; = it's an ISP somewhere that is either (a) advertising a bad relay or (b)= filtering protocol 41. =A0 (If the problem were the users' setups, the= providers could just say "not our problem; fix your 6to4 setup")=
>
> > What worries me is that people will start using 6to4 for bittorre= nt. Bittorrent
> > will of course completely hide broken setups and worse, it will a= lso hide
> > broken 6to4 relays.
>
> From my understanding of bittorrent, it will just find other routes. >
> > And all of this, because a few hobbyists are afraid that declarin= g 6to4 as
> > historic will require them to search a bit harder in the furture = for a
> > router that supports 6to4.
>
> You completely misunderstand both the situation, and the size and dive= rsity of 6to4 users.
>
> Keith
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--000e0cdfd8bc0aec8504a72b1f2b-- From moore@network-heretics.com Sun Jul 3 07:41:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2046221F85B4; Sun, 3 Jul 2011 07:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqnb8ruJHMaH; Sun, 3 Jul 2011 07:41:13 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 46A7721F85AE; Sun, 3 Jul 2011 07:41:13 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id F3A79296E5; Sun, 3 Jul 2011 10:41:12 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 03 Jul 2011 10:41:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=Lga1f8m1Rj5X3iNY6RrCUUc47a8=; b=WD1I8kr8a1pakPn1kny8zEfO3h7/1KU6iULm2cM1F0JgRF319WZVkVGoW0tIniWmR+YmoTm/Jj44XNEwc3Iz0TkuC7T+NjulLhRwfO1rN0oWtMaa/MKyatHtD7ojXrM0fHZZ9EhI7jXJ5cx6wn0qBObKV/jS2LIerywS9BHpRSU= X-Sasl-enc: czp1FHzGwYZ045GXhT7RV+fdtWsp6OHFplxyfPdJGKh+ 1309704072 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 90808404889; Sun, 3 Jul 2011 10:41:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-122-684372071 From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 10:40:53 -0400 Message-Id: <100DA5A2-0276-45B8-A8CD-AB7B0D947AC4@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 14:41:14 -0000 --Apple-Mail-122-684372071 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2011, at 10:32 AM, Cameron Byrne wrote: > > > > > > I think this clearly illustrates why the IETF should issue a = strong statement > > > that no new 6to4 installation should be deplayed and the existing = 6to4 users > > > should migrate to other tunneling techniques (if native is not = available). > > > > I think this clearly illustrates why IETF should issue a strong = statement that > > > > a) operators of 6to4 relays should not advertise those relays via = BGP unless they're routing traffic for all of 2002://16 or native v6, = respectively > > b) operators should not filter protocol 41traffic > > c) (maybe) operators using LSN should use RFC 1918 addresses behind = those NATs unless/until there's another address range that 6to4 host = implementations know about > > d) 6to4 should be disabled by default in both hosts and routers > > e) host implementations should prefer native v4 destinations over = 6to4 destinations when both are available and the application can use = either IPv4 or IPv6 > > >=20 > You will not get "consensus" on these statements in the IETF or by the = various companies that implement gear and networks in the REAL world. >=20 why not? all of those recommendations are clearly appropriate and = desirable, with the possible exception of (c) because ISP use of RFC = 1918 addresses is likely to conflict with customer user of the same = address ranges. > Can we let this thread die now? If the ietf will not kill 6to4, there = are several other methods to deal with it in the REAL world (dns = whitelisting, null routes, rfp's, blocking aaaa on ipv4 ....). Just like = the NAT debacle of years past , the IETF has once again proven its = irrelevance. >=20 and the attitude from v6ops reminds me of nothing so much as a lynch = mob. it has gotten way out of hand.=20 Keith --Apple-Mail-122-684372071 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 3, 2011, at 10:32 AM, Cameron Byrne wrote:

> >
> > I think this clearly illustrates why the IETF should issue a strong statement
> > that no new 6to4 installation should be deplayed and the existing 6to4 users
> > should migrate to other tunneling techniques (if native is not available).
>
> I think this clearly illustrates why IETF should issue a strong statement that
>
> a) operators of 6to4 relays should not advertise those relays via BGP unless they're routing traffic for all of 2002://16 or native v6, respectively
> b) operators should not filter protocol 41traffic
> c) (maybe) operators using LSN should use RFC 1918 addresses behind those NATs unless/until there's another address range that 6to4 host implementations know about
> d) 6to4 should be disabled by default in both hosts and routers
> e) host implementations should prefer native v4 destinations over 6to4 destinations when both are available and the application can use either IPv4 or IPv6
>

You will not get "consensus" on these statements in the IETF or by the various companies that implement gear and networks in the REAL world.

why not?  all of those recommendations are clearly appropriate and desirable, with the possible exception of (c) because ISP use of RFC 1918 addresses is likely to conflict with customer user of the same address ranges.

Can we let this thread die now? If the ietf will not kill 6to4, there are several other methods to deal with it in the REAL world (dns whitelisting, null routes, rfp's, blocking aaaa on ipv4 ....). Just like the NAT debacle of years past , the IETF has once again proven its irrelevance.

and the attitude from v6ops reminds me of nothing so much as a lynch mob.   it has gotten way out of hand. 

Keith

--Apple-Mail-122-684372071-- From arturo.servin@gmail.com Sun Jul 3 07:58:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64A811E807C; Sun, 3 Jul 2011 07:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1FA8musbaob; Sun, 3 Jul 2011 07:58:41 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F74011E8074; Sun, 3 Jul 2011 07:58:41 -0700 (PDT) Received: by vxi40 with SMTP id 40so4010471vxi.31 for ; Sun, 03 Jul 2011 07:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=sQxxmDt6IKlD7LQ7K1/XV+XAnqjHH1EIQyQsSQBYbHk=; b=Xpq9rRIJGjNsNQegtZKacUeSZhEkxcc4OOxJfyATPO8oVhuiwdAk8bSmx9++Afq0n1 CW2tOvJcR4ZPvd//WIdG/3aJkVo57VVq1YGqaWaJZQZX0zUbAwejVF92Oj4qdSZJ3FKk VlhrA7zw3s97e1gUJZPaNuGSMltf1/tzv2Tds= Received: by 10.52.115.130 with SMTP id jo2mr7297909vdb.43.1309705120391; Sun, 03 Jul 2011 07:58:40 -0700 (PDT) Received: from [192.168.1.103] (r186-48-230-104.dialup.adsl.anteldata.net.uy [186.48.230.104]) by mx.google.com with ESMTPS id l18sm3042634vby.14.2011.07.03.07.58.37 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jul 2011 07:58:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-167-685434716 From: Arturo Servin In-Reply-To: <100DA5A2-0276-45B8-A8CD-AB7B0D947AC4@network-heretics.com> Date: Sun, 3 Jul 2011 11:58:36 -0300 Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> <100DA5A2-0276-45B8-A8CD-AB7B0D947AC4@network-heretics.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) Cc: IETF Discussion , Keith Moore Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 14:58:42 -0000 --Apple-Mail-167-685434716 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii And b. And probably it is too much effort for something that will go = away (probably sooner that we expect) with the exhaustion of IPv4 = addresses for each ISP's customer (6to4 does not work with NATs, and = they are here). -as On 3 Jul 2011, at 11:40, Keith Moore wrote: >> > I think this clearly illustrates why IETF should issue a strong = statement that >> > >> > a) operators of 6to4 relays should not advertise those relays via = BGP unless they're routing traffic for all of 2002://16 or native v6, = respectively >> > b) operators should not filter protocol 41traffic >> > c) (maybe) operators using LSN should use RFC 1918 addresses behind = those NATs unless/until there's another address range that 6to4 host = implementations know about >> > d) 6to4 should be disabled by default in both hosts and routers >> > e) host implementations should prefer native v4 destinations over = 6to4 destinations when both are available and the application can use = either IPv4 or IPv6 >> > >>=20 >> You will not get "consensus" on these statements in the IETF or by = the various companies that implement gear and networks in the REAL = world. >>=20 > why not? all of those recommendations are clearly appropriate and = desirable, with the possible exception of (c) because ISP use of RFC = 1918 addresses is likely to conflict with customer user of the same = address ranges. --Apple-Mail-167-685434716 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii And = b.

And probably it is too much = effort for something that will go away (probably sooner that we expect) = with the exhaustion of IPv4 addresses for each ISP's customer (6to4 does = not work with NATs, and they are = here).

-as

On 3 Jul 2011, at = 11:40, Keith Moore wrote:

> I think this clearly illustrates why IETF should = issue a strong statement that
>
> a) operators of 6to4 = relays should not advertise those relays via BGP unless they're routing = traffic for all of 2002://16 or native v6, = respectively
> b) operators should not filter protocol = 41traffic
> c) (maybe) operators using LSN should use RFC 1918 = addresses behind those NATs unless/until there's another address range = that 6to4 host implementations know about
> d) 6to4 should be = disabled by default in both hosts and routers
> e) host = implementations should prefer native v4 destinations over 6to4 = destinations when both are available and the application can use either = IPv4 or IPv6
>

You will not get "consensus" on these = statements in the IETF or by the various companies that implement gear = and networks in the REAL world.

why not?  all of = those recommendations are clearly appropriate and desirable, with the = possible exception of (c) because ISP use of RFC 1918 addresses is = likely to conflict with customer user of the same address = ranges.

= --Apple-Mail-167-685434716-- From moore@network-heretics.com Sun Jul 3 08:11:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2969A21F85AB; Sun, 3 Jul 2011 08:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZZ+8HvPqnQV; Sun, 3 Jul 2011 08:11:12 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id D67B621F859E; Sun, 3 Jul 2011 08:11:10 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id BAFEF2960B; Sun, 3 Jul 2011 11:11:08 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Sun, 03 Jul 2011 11:11:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=mD7BoE/R745i9a1pDSRsos/mIf4=; b=Xn5ltpWg6ColQUQPv5gESsM5po+XjPasJV0AZQW/vefRt+W/Mgc9eKWPcSM2uUD8YnCFg+2shbEAmnc9It/HjBnoxeY2JBu9hu8FWGSnb8TRgODWjKRUI5V/bXlESMSsLTiuRs8ufFAkdAWjVV/M9J+fMXApxWGNTPbgP5ZXlY8= X-Sasl-enc: p9iR6dDrKTWi1HFYa+X4Zx/dfSJ4u5726rExbOQjZHLF 1309705867 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 443D1404EB9; Sun, 3 Jul 2011 11:11:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-123-686167784 From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 11:10:49 -0400 Message-Id: <746A967B-16AF-4428-8424-298AF8001F87@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> <100DA5A2-0276-45B8-A8CD-AB7B0D947AC4@network-heretics.com> To: Arturo Servin X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 15:11:13 -0000 --Apple-Mail-123-686167784 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2011, at 10:58 AM, Arturo Servin wrote: > On 3 Jul 2011, at 11:40, Keith Moore wrote: >=20 >>> > I think this clearly illustrates why IETF should issue a strong = statement that >>> > >>> > a) operators of 6to4 relays should not advertise those relays via = BGP unless they're routing traffic for all of 2002://16 or native v6, = respectively >>> > b) operators should not filter protocol 41traffic >>> > c) (maybe) operators using LSN should use RFC 1918 addresses = behind those NATs unless/until there's another address range that 6to4 = host implementations know about >>> > d) 6to4 should be disabled by default in both hosts and routers >>> > e) host implementations should prefer native v4 destinations over = 6to4 destinations when both are available and the application can use = either IPv4 or IPv6 >>> > >>>=20 >>> You will not get "consensus" on these statements in the IETF or by = the various companies that implement gear and networks in the REAL = world. >>>=20 >> why not? all of those recommendations are clearly appropriate and = desirable, with the possible exception of (c) because ISP use of RFC = 1918 addresses is likely to conflict with customer user of the same = address ranges. >=20 >=20 > And b. >=20 > And probably it is too much effort for something that will go = away (probably sooner that we expect) with the exhaustion of IPv4 = addresses for each ISP's customer (6to4 does not work with NATs, and = they are here). It's clearly inappropriate for operators to be filtering protocol 41. = Not only does this break 6to4, it also breaks other tunneling = mechanisms. More generally, it's inappropriate for operators to be = favoring one kind of traffic over another. The ISPs I've talked to tell me that they see no reason why static, = public IPv4 addresses cannot continue to be given to those that request = them, indefinitely, as long as they're paying for business service.=20 If the overriding concern is that imposition of LSN will break 6to4 even = more and thus generate even more support calls, that's understandable. = However: - LSN will break a lot more than 6to4, and generate support calls for = many other reasons, and this shouldn't surprise anyone. - declaring 6to4 Historic will not reduce the number of support calls, = while the above measures will. The most effective single measure that I can see to reduce the number of = 6to4 support calls is to get OS vendors to patch their customers' = systems to implement (e), and perhaps (d), ASAP. That shouldn't break = 6to4 for anyone who is using it as a means of supporting IPv6 apps, and = it should reduce the largest source of complaints both from users and = content providers. =20 (The reason I say "perhaps" (d) is that (d) would break those who are = currently depending on 6to4. "Off by default" is perfectly appropriate = for new installations, but not necessarily so for automatic updates.) Keith --Apple-Mail-123-686167784 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 3 Jul 2011, at = 11:40, Keith Moore wrote:

> I think this clearly illustrates why IETF should = issue a strong statement that
>
> a) operators of 6to4 = relays should not advertise those relays via BGP unless they're routing = traffic for all of 2002://16 or native v6, = respectively
> b) operators should not filter protocol = 41traffic
> c) (maybe) operators using LSN should use RFC 1918 = addresses behind those NATs unless/until there's another address range = that 6to4 host implementations know about
> d) 6to4 should be = disabled by default in both hosts and routers
> e) host = implementations should prefer native v4 destinations over 6to4 = destinations when both are available and the application can use either = IPv4 or IPv6
>

You will not get "consensus" on these = statements in the IETF or by the various companies that implement gear = and networks in the REAL world.

why not?  all of = those recommendations are clearly appropriate and desirable, with the = possible exception of (c) because ISP use of RFC 1918 addresses is = likely to conflict with customer user of the same address = ranges.

And = b.

And probably it is too much = effort for something that will go away (probably sooner that we expect) = with the exhaustion of IPv4 addresses for each ISP's customer (6to4 does = not work with NATs, and they are = here).

It's clearly inappropriate = for operators to be filtering protocol 41.   Not only does this = break 6to4, it also breaks other tunneling mechanisms.  More = generally, it's inappropriate for operators to be favoring one kind of = traffic over another.

The ISPs I've talked to = tell me that they see no reason why static, public IPv4 addresses cannot = continue to be given to those that request them, indefinitely, as long = as they're paying for business = service. 

If the overriding concern is = that imposition of LSN will break 6to4 even more and thus generate even = more support calls,  that's understandable. =  However:

- LSN will break a lot more than = 6to4, and generate support calls for many other reasons, and this = shouldn't surprise anyone.
- declaring 6to4 Historic will not = reduce the number of support calls, while the above measures = will.

The most effective single measure that I = can see to reduce the number of 6to4 support calls is to get OS vendors = to patch their customers' systems to implement (e), and perhaps (d), = ASAP.   That shouldn't break 6to4 for anyone who is using it as a = means of supporting IPv6 apps, and it should reduce the largest source = of complaints both from users and content providers. =  

(The reason I say "perhaps" (d) is that = (d) would break those who are currently depending on 6to4.  "Off by = default"  is perfectly appropriate for new installations, but not = necessarily so for automatic = updates.)

Keith

= --Apple-Mail-123-686167784-- From tjc@ecs.soton.ac.uk Sun Jul 3 09:10:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AF321F857B; Sun, 3 Jul 2011 09:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYlKaDpFZRVa; Sun, 3 Jul 2011 09:10:49 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 0F58521F8578; Sun, 3 Jul 2011 09:10:46 -0700 (PDT) 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 p63GAgK9013280; Sun, 3 Jul 2011 17:10:42 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p63GAgK9013280 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1309709442; bh=qc2jzdagHeL6DKNXgINdUb7yqsE=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=FNcz3ULf18cwSNDzW4TP7Im/28zXG23ClE2DCbbcupxnA2Y05h3mGDpOtOgcfapft a9HhvDW7RxN3pUlP1tENgB4p9pHWIXNrRHEp4ysGB2szU0a/GATtwgH6kiYxH+4JUa 27j4DZrEJEdITOAIvHZ/GhEKK8/J915VEODCeWf8= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n62HAg0366129716Ga ret-id none; Sun, 03 Jul 2011 17:10:42 +0100 Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p63G9KUh002645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 3 Jul 2011 17:09:21 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Tim Chown In-Reply-To: <20110703111047.GB2304@Space.Net> Date: Sun, 3 Jul 2011 17:09:20 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703111047.GB2304@Space.Net> <04B2CF82-78EC-4A2B-A681-7710E3EFCDBE@ecs.soton.ac.uk> To: IPv6 Operations , IETF Discussion X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n62HAg036612971600; tid=n62HAg0366129716Ga; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p63GAgK9013280 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 16:10:53 -0000 On 3 Jul 2011, at 12:10, Gert Doering wrote: > On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: >> There's clearly a lack of consensus to support it. >=20 > There's two very vocal persons opposing it and a much larger number of > people that support it, but have not the time to write a similarily > large amount of e-mails. For me, this is enough for "rough = consensus". >=20 > (And I second everything Lorenzo, Randy and Cameron said - there's=20 > theoretical possibilities, and real world. 6to4 fails the real-world > test. Get over it, instead of attacking people that run real-world > networks for the decisions they need to do to keep the networks = running > in a world without enough IPv4 addresses). I'm with Gert, Lorenzo, Randy and others here.=20 It seemed that both the -advisory and -historic drafts had strong = support in v6ops, which isn't just any WG, it's the WG that anyone with = a vested interest in IPv6 deployment takes part. Thus its view on IPv6 = deployment practices should be given due regard. The opposition on the = IETF list seemed to be a vocal minority, and of course one person seemed = to post a disproportionate number of replies. The problems with 6to4 (20% minimum failure rate, and poor performance = when it does connect) are well documented and have led to various = 'counter measures' from the IETF, including: a) 6to4 off by default, as per 6to4-advisory b) IPv4 being preferred to 6to4 transport, as per 3484-bis (widely = implemented already) c) a fast fallback mechanism from IPv6 to IPv4, as per happy eyeballs (a = simplistic version is already in Chrome) Those measures indicate how bad a problem 6to4 creates. If we're going = to the trouble of coming up with all these measures, there seems to be a = good case for 6to4 to Historic, which would be a steer to implementors = to no longer include 6to4 support at all. I do agree however that the = most important point is publishing the -advisory text. As a provider of a (not large) enterprise, I know that a fraction of 1% = of connections to our site suffer a 10 second+ delay to a dual-stack web = site where they suffer no delay to an IPv4-only one. There's no way to = know for sure how much of that 'IPv6 brokenness' is 6to4, but measures = (a), (b), and (c) should minimise that figure. Having said that, less = than 1% of users who connect to our site over IPv6 use 6to4, so we = wouldn't be aggrieved to see it disappear in terms of loss of users, as = those users could almost certainly still reach us over IPv4. Our own = users who want IPv6 connectivity when offsite use tunnel brokers, which = provide a much better (and more predictable) service, one that also = works from behind a NAT, which in the reality of home, hotel, and other = hotspot networks is quite important. =20 As for operators 'fixing' 6to4, well, I'd rather see operators invest = that effort in deploying IPv6, rather than making 6to4 work better, for = some value of 'better'. Tim= From joelja@bogus.com Sun Jul 3 09:26:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4148021F8629 for ; Sun, 3 Jul 2011 09:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOVHSSJcHBRj for ; Sun, 3 Jul 2011 09:26:00 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0E21F8627 for ; Sun, 3 Jul 2011 09:26:00 -0700 (PDT) Received: from [192.168.11.127] (c-76-115-172-69.hsd1.wa.comcast.net [76.115.172.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p63GPwbl037918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 3 Jul 2011 16:25:58 GMT (envelope-from joelja@bogus.com) From: Joel Jaeggli Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26-690670394" Date: Sun, 3 Jul 2011 09:25:51 -0700 In-Reply-To: <100DA5A2-0276-45B8-A8CD-AB7B0D947AC4@network-heretics.com> To: "v6ops@ietf.org WG" References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> <100DA5A2-0276-45B8-A8CD-AB7B0D947AC4@network-heretics.com> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 03 Jul 2011 16:25:59 +0000 (UTC) Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic - About to be Moderated. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 16:26:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-26-690670394 Content-Type: multipart/alternative; boundary=Apple-Mail-25-690670337 --Apple-Mail-25-690670337 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2011, at 7:40 AM, Keith Moore wrote: > On Jul 3, 2011, at 10:32 AM, Cameron Byrne wrote: >> Can we let this thread die now? If the ietf will not kill 6to4, there = are several other methods to deal with it in the REAL world (dns = whitelisting, null routes, rfp's, blocking aaaa on ipv4 ....). Just like = the NAT debacle of years past , the IETF has once again proven its = irrelevance. >>=20 >=20 > and the attitude from v6ops reminds me of nothing so much as a lynch = mob. it has gotten way out of hand.=20 >=20 > Keith You can let this thread die now. you can stop ccing the IETF Discuss list, the IETF LC is over. 108 messages in two days in this thread has added precisely zero new = viewpoints to the discussion, we know where all of you stand.=20 If you live in the US enjoy the holiday, if you live in the northern = hemisphere it's time to go outside. joel --Apple-Mail-25-690670337 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jul 3, 2011, at = 10:32 AM, Cameron Byrne wrote:

Can we = let this thread die now? If the ietf will not kill 6to4, there are = several other methods to deal with it in the REAL world (dns = whitelisting, null routes, rfp's, blocking aaaa on ipv4 ....). Just like = the NAT debacle of years past , the IETF has once again proven its = irrelevance.

and the attitude from v6ops = reminds me of nothing so much as a lynch mob.   it has gotten way = out of = hand. 

Keith

You can let this thread die now.

you = can stop ccing the IETF Discuss list, the IETF LC is = over.

108 messages in two days in this thread has = added precisely zero new viewpoints to the discussion, we know where all = of you stand. 

If you live in the US enjoy the = holiday, if you live in the northern hemisphere it's time  to go = outside.

joel


= = --Apple-Mail-25-690670337-- --Apple-Mail-26-690670394 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk4QmBAACgkQ8AA1q7Z/VrLq+ACcC7uANXPY9HvNV+UCiCZe80sO aJUAn1UV95nFH8UsuOaRcVve00KK07AS =GyEq -----END PGP SIGNATURE----- --Apple-Mail-26-690670394-- From moore@network-heretics.com Sun Jul 3 11:13:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584A821F85DF; Sun, 3 Jul 2011 11:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l27amNnMF9jI; Sun, 3 Jul 2011 11:13:19 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7828B21F85DC; Sun, 3 Jul 2011 11:13:19 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 257E52351D; Sun, 3 Jul 2011 14:13:19 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 03 Jul 2011 14:13:19 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=l7063sh1wj+YzNHeZo9YmMErWOc=; b=deARNsgwrtXTxxcbHIjttfkCofLKoz7bWb8Ha+dHEFCLp6BuageQ9Ns3cjdPcmug2+zH/SthfiSgDLRxBYVLHl/6AXpvtGhVeJgwf1ugNpX0tGh5dwYlVx8gTXGMU1SRAN7mus9unIyRxqax/02yNRw24mE2fKmyWHw3IqRx3tk= X-Sasl-enc: SGgqJHhvVe+d8U6JftrBi7+qn4mklWrAZKk4TU35HdOy 1309716798 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id D79C6405054; Sun, 3 Jul 2011 14:13:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 14:13:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703111047.GB2304@Space.Net> <04B2CF82-78EC-4A2B-A681-7710E3EFCDBE@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 18:13:20 -0000 On Jul 3, 2011, at 12:09 PM, Tim Chown wrote: > It seemed that both the -advisory and -historic drafts had strong = support in v6ops, which isn't just any WG, it's the WG that anyone with = a vested interest in IPv6 deployment takes part. That's simply false. For instance, both users and applications = developers are drastically underrepresented in that group. =20 The interests of operators are certainly important and should be given = due regard, but they are not the only interests that need to be = considered. > Thus its view on IPv6 deployment practices should be given due = regard. The opposition on the IETF list seemed to be a vocal minority, = and of course one person seemed to post a disproportionate number of = replies. One person's view should only be counted as one person's view, no matter = how many messages he sends. And yet, when even one person speaks up = for the interests of an under-represented group, the merit of his = arguments should be considered. The reason we make decisions by consensus in IETF, rather than by = voting, is that there's no way to have a representative sample of all = interests. And yes, a vocal minority can be sufficient to cause IETF to fail to = reach consensus. That's intentional. > The problems with 6to4 (20% minimum failure rate, and poor performance = when it does connect) are well documented and have led to various = 'counter measures' from the IETF, including: > a) 6to4 off by default, as per 6to4-advisory > b) IPv4 being preferred to 6to4 transport, as per 3484-bis (widely = implemented already) > c) a fast fallback mechanism from IPv6 to IPv4, as per happy eyeballs = (a simplistic version is already in Chrome) >=20 > Those measures indicate how bad a problem 6to4 creates. False. The problems associated with 6to4 were not created by 6to4; = they were created by dubious operational practices. =20 But I note that all of the counter measures you cite are widely agreed = on and well on their way to being reality. Making 6to4 Historic in = addition to these will not help; it will only hurt users who are = successfully using it now. > If we're going to the trouble of coming up with all these measures, = there seems to be a good case for 6to4 to Historic, which would be a = steer to implementors to no longer include 6to4 support at all. In other words, it's an attempt to sabotage 6to4 for those who are = currently successfully using it, and without giving them a viable = replacement. It's an attempt to shift the pain from the operators to = the users, for problems that were mostly caused by operators. > As for operators 'fixing' 6to4, well, I'd rather see operators invest = that effort in deploying IPv6, rather than making 6to4 work better, for = some value of 'better'. 6to4 might need fixing, but it's not up to operators to fix it. I = think it's just fine if operators do things that they should normally be = doing, i.e.: make a best effort to deliver all traffic (including = protocol 41); make sure that routers work properly; make sure that = route advertisements are accurate. Of course, if 6to4 could be replaced with something better, that would = be a win for everyone. For operators, I think that means deploying some = form of v6 concurrently with LSN. But I don't think the net can afford = to trust that all operators will do this. Keith From trejrco@gmail.com Sun Jul 3 11:53:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A506421F85CE; Sun, 3 Jul 2011 11:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3DENVfjL4LF; Sun, 3 Jul 2011 11:53:37 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4EE21F85C7; Sun, 3 Jul 2011 11:53:36 -0700 (PDT) Received: by bwb17 with SMTP id 17so4363327bwb.31 for ; Sun, 03 Jul 2011 11:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=knM6DIyAgPsSyQEb48FI63BA51LRK00V2+/jvJAnLW4=; b=mjgoV3uxxE/PMhPjOpQs3Gebj7z/l8TNk7M5MwzQjd4K1nW4tZqf4yIjz9ivwlglrI VZ2rVV5NM5fkNUSjJ5e1IoCGJShKGp8nqhtkFtFIILCP3BgNPcHsPM2eG1ZIchZ1LF+s n2xfDdTKGr6tTs9jAOayh+dAgXETKwTr9RA7g= Received: by 10.204.122.210 with SMTP id m18mr4792144bkr.138.1309719215178; Sun, 03 Jul 2011 11:53:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.81.163 with HTTP; Sun, 3 Jul 2011 11:53:15 -0700 (PDT) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> From: TJ Date: Sun, 3 Jul 2011 14:53:15 -0400 Message-ID: To: "v6ops@ietf.org" , IETF Discussion Content-Type: multipart/alternative; boundary=0016e6d6419d93841504a72ec40c Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: trejrco@gmail.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 18:53:37 -0000 --0016e6d6419d93841504a72ec40c Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 2, 2011 at 15:21, Cameron Byrne wrote: > > On Jul 2, 2011 11:55 AM, "Lorenzo Colitti" wrote: > > > > Great, back to square one. > > > > Is the reasoning behind the decision explained somewhere? My reading of > the threads on the subject in v6ops was that the opposition to 6to4-historic > was a small but vocal minority, and I thought that qualified as rough > consensus. But perhaps I missed some discussion. > > > > I saw the same thing. It is a shame that work that directly removes > barriers to REAL ipv6 deployment gets shouted down by a few people not > involved in REAL ipv6 deployment. > > As a member of that "small but vocal minority" I think you are being a little unfair here; some of us are working quite hard in getting IPv6 deployed in a number of different places. > Also, why do the author and the chairs think that the new draft will do > any better than 6to4-historic? I would assume that the same people who spoke > up against 6to4-historic will speak up against the new document, and since > that level of opposition was sufficient to prevent the publication > of 6to4-historic, it may be sufficient to prevent publication of the new > document as well. If so, we will have spent 3-6 months arguing about it for > naught. > And, FWIW, I have no objections to having it off by default. In fact, I welcome that. /TJ --0016e6d6419d93841504a72ec40c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 2, 2011 at 15:21, Cameron Byrne <cb.list6@gmail.com<= /a>> wrote:


On Jul 2, 2011 11:55 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:

=
>
> Great, back to square one.
>
> Is the reasoning behind the decision explained somewhere?=A0My reading= of the threads on the subject in v6ops was that the opposition to 6to4-his= toric was a small but vocal minority, and I thought that qualified as rough= consensus. But perhaps I missed some discussion.
>

I saw the same thing. It is a shame that work that directly removes barr= iers to REAL ipv6 deployment gets shouted down by a few people not involved= in REAL ipv6 deployment.

As a member of that "small but vocal minority= " I think you are being a little unfair here; some of us are working q= uite hard in getting IPv6 deployed in a number of different places.

> Also, why do the aut= hor and the chairs think that the new draft will do any better than 6to4-hi= storic? I would assume that the same people who spoke up against 6to4-histo= ric will speak up against the new document, and since that level of opposit= ion was sufficient to prevent the publication of=A06to4-historic, it may be= sufficient to prevent publication of the new document as well.=A0If so, we= will have spent 3-6 months arguing about it for naught.


And, FWIW, I have no objections to hav= ing it off by default. =A0In fact, I welcome that.


/TJ
--0016e6d6419d93841504a72ec40c-- From arturo.servin@gmail.com Sun Jul 3 12:17:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2DF11E809E; Sun, 3 Jul 2011 12:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5UZgdhCPvg5; Sun, 3 Jul 2011 12:17:47 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1C5611E80A0; Sun, 3 Jul 2011 12:17:46 -0700 (PDT) Received: by vxi40 with SMTP id 40so4093627vxi.31 for ; Sun, 03 Jul 2011 12:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jU0BX6VjJ3FgvtPqqhmZUTC1jFQK9id4ZhEN2kxscls=; b=poinsL1LkMgTaSuH2Ut/11HeWbS58QLDvPqeJ63nhkivelscWBJVOJdHZzxDlgWXgn d0R7cgVE7Y5ZQhbUlptghN35lTdmLuGnGxbwgdqbH5Jf0AApu0ttonzikTsRF8tMLrA3 iprRmkWnG5jchOXnXDK47dTXu1XrclcFnFTSE= Received: by 10.220.213.202 with SMTP id gx10mr2078368vcb.77.1309720662688; Sun, 03 Jul 2011 12:17:42 -0700 (PDT) Received: from [192.168.1.103] (r186-48-230-104.dialup.adsl.anteldata.net.uy [186.48.230.104]) by mx.google.com with ESMTPS id v3sm913271vcg.23.2011.07.03.12.17.40 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jul 2011 12:17:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <746A967B-16AF-4428-8424-298AF8001F87@network-heretics.com> Date: Sun, 3 Jul 2011 16:17:37 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> <100DA5A2-0276-45B8-A8CD-AB7B0D947AC4@network-heretics.com> <746A967B-16AF-4428-8424-298AF8001F87@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 19:17:47 -0000 >>=20 >>=20 >> And b. >>=20 >> And probably it is too much effort for something that will go = away (probably sooner that we expect) with the exhaustion of IPv4 = addresses for each ISP's customer (6to4 does not work with NATs, and = they are here). >=20 > It's clearly inappropriate for operators to be filtering protocol 41. = Not only does this break 6to4, it also breaks other tunneling = mechanisms. More generally, it's inappropriate for operators to be = favoring one kind of traffic over another. Many corporate networks filter them because security concerns (I = am not saying that is right or wrong, it just happens and it breaks = 6to4). They won't change their mind because 6to4. >=20 > The ISPs I've talked to tell me that they see no reason why static, = public IPv4 addresses cannot continue to be given to those that request = them, indefinitely, as long as they're paying for business service.=20 Call one not in the USA. China or India perhaps. -as From moore@network-heretics.com Sun Jul 3 12:31:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4E521F8648; Sun, 3 Jul 2011 12:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9knbBipP9hR; Sun, 3 Jul 2011 12:31:04 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 84A4C21F8647; Sun, 3 Jul 2011 12:31:04 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 1D3BF25E06; Sun, 3 Jul 2011 15:31:04 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 03 Jul 2011 15:31:04 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=3YxmxhrQRiZRs8lT0xDfrR0bVOA=; b=EocOpyoQomoXwqiLeOdUX/h+RATmx5CBaxbdSeXrXNiWbPt539WeEgsfISNhelCHDkJxjkpliBVkCIpgEfaqtJV+EuUvbHI+iMz+yVVPK8qDUpYKE5XSqsEY+tRTuJ6KND7xXtqfZUTI4Oo/4w1calpAGNAB58aaE5Dc8TotZ/U= X-Sasl-enc: r/eqzW5NahkugxwfVFLXDqprNdVO0Jca1NUlhywd3t4K 1309721463 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id A3E36403FC3; Sun, 3 Jul 2011 15:31:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-701763140 From: Keith Moore In-Reply-To: Date: Sun, 3 Jul 2011 15:30:44 -0400 Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> <100DA5A2-0276-45B8-A8CD-AB7B0D947AC4@network-heretics.com> <746A967B-16AF-4428-8424-298AF8001F87@network-heretics.com> To: Arturo Servin X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 19:31:05 -0000 --Apple-Mail-2-701763140 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 3, 2011, at 3:17 PM, Arturo Servin wrote: >>>=20 >>> And b. >>>=20 >>> And probably it is too much effort for something that will go = away (probably sooner that we expect) with the exhaustion of IPv4 = addresses for each ISP's customer (6to4 does not work with NATs, and = they are here). >>=20 >> It's clearly inappropriate for operators to be filtering protocol 41. = Not only does this break 6to4, it also breaks other tunneling = mechanisms. More generally, it's inappropriate for operators to be = favoring one kind of traffic over another. >=20 > Many corporate networks filter them because security concerns (I = am not saying that is right or wrong, it just happens and it breaks = 6to4). They won't change their mind because 6to4. Fair enough. (It bothers me when ISPs filter them, but I consider it = within the rights of an enterprise network to do that. What an = enterprise does with its own traffic should be its own business, and = they can benefit and/or suffer from the consequences of their choices. = Though I do think that there are probably better ways to handle the = (legitimate) security concerns than to merely filter protocol 41. e.g. = ICMP unreachable.) And of course protocol 41 becomes problematic for those behind a NAT of = any kind, including LSN. (I do see LSN as "best effort" delivery; = it's just that the state of the the network has made "best" pretty sad = these days.) So if we were able to omit or finesse considerations (b) and (c) could = we get consensus around the remaining items in that list? >> The ISPs I've talked to tell me that they see no reason why static, = public IPv4 addresses cannot continue to be given to those that request = them, indefinitely, as long as they're paying for business service.=20 >=20 > Call one not in the USA. China or India perhaps. I'll take your word for it. 6to4 is only going to work in corner = cases, and those corners are somewhat defined by geography. Honestly I'd be happy to declare 6to4 Historic if we had a suitable = replacement - one that could be automatically configured by hosts, used = by applications, and worked better than 6to4 in most cases. I don't = think it exists yet. =20 (That oft-touted 80% reliability figure needs to be compared with = similar figures for other methods, along with the realization that = manual configuration, lack of platform support, congestion at = heavily-used tunnel endpoints, are all significant sources of failure. = Note that you can't measure this by looking only at traffic in the = network. And for those who insist that all v6 traffic should be = native, note that from the perspective of an application developer, = there is close to a 0% reliability for this at present. 80% is a huge = improvement over that, though still not good enough.) Keith --Apple-Mail-2-701763140 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

And = b.

And probably it is too much = effort for something that will go away (probably sooner that we expect) = with the exhaustion of IPv4 addresses for each ISP's customer (6to4 does = not work with NATs, and they are = here).

It's clearly = inappropriate for operators to be filtering protocol 41.   Not = only does this break 6to4, it also breaks other tunneling mechanisms. =  More generally, it's inappropriate for operators to be favoring = one kind of traffic over another.

Many = corporate networks filter them because security concerns (I am not = saying that is right or wrong, it just happens and it breaks 6to4). They = won't change their mind because = 6to4.

Fair enough.  (It = bothers me when ISPs filter them, but I consider it within the rights of = an enterprise network to do that.  What an enterprise does with its = own traffic should be its own business, and they can benefit and/or = suffer from the consequences of their choices.  Though I do think = that there are probably better ways to handle the (legitimate) security = concerns than to merely filter protocol 41.  e.g. ICMP = unreachable.)

And of course protocol 41 becomes = problematic for those behind a NAT of any kind, including LSN.   =  (I do see LSN as "best effort" delivery; it's just that the state = of the the network has made "best" pretty sad these = days.)

So if we were able to omit or finesse = considerations (b) and (c) could we get consensus around the remaining = items in that list?

The ISPs I've talked to = tell me that they see no reason why static, public IPv4 addresses cannot = continue to be given to those that request them, indefinitely, as long = as they're paying for business service.

Call one = not in the USA. China or India = perhaps.

I'll take your word for = it.   6to4 is only going to work in corner cases, and those corners = are somewhat defined by geography.

Honestly I'd = be happy to declare 6to4 Historic if we had a suitable replacement - one = that could be automatically configured by hosts, used by applications, = and worked better than 6to4 in most cases.  I don't think it exists = yet.  

(That oft-touted 80% reliability = figure needs to be compared with similar figures for other methods, = along with the realization that manual configuration, lack of platform = support,  congestion at heavily-used tunnel endpoints, are all = significant sources of failure.  Note that you can't measure this = by looking only at traffic in the network.   And for those who = insist that all v6 traffic should be native, note that from the = perspective of an application developer, there is close to a 0% = reliability for this at present.  80% is a huge improvement over = that, though still not good = enough.)

Keith

= --Apple-Mail-2-701763140-- From rogerj@gmail.com Sun Jul 3 12:32:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D337811E807B; Sun, 3 Jul 2011 12:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvJFgx9bu9Zd; Sun, 3 Jul 2011 12:32:47 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B62E121F8670; Sun, 3 Jul 2011 12:32:46 -0700 (PDT) Received: by wwe5 with SMTP id 5so3041147wwe.13 for ; Sun, 03 Jul 2011 12:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JpUYA+FMIu+rQxXeaeNvOCEUe7ZkDm+w1R2ALdpnCs4=; b=wWLi44MfXEYBgHRWT5MnTs9U4oqYfk7d0Ot1pkk9wwmMMc4zk2j4MYlxSu/+DFkk79 0skOrNB8jGztn2gI8XXu+5eoxMyjmsLUmb8ZwAgP3jx40deQvoA0t2TRWEtlrVorp5no s22O9gBfapjGQ+KrlY8Yk+hg/JWle+H9Ab4q0= MIME-Version: 1.0 Received: by 10.227.162.200 with SMTP id w8mr4645594wbx.114.1309721565835; Sun, 03 Jul 2011 12:32:45 -0700 (PDT) Received: by 10.227.142.137 with HTTP; Sun, 3 Jul 2011 12:32:45 -0700 (PDT) Received: by 10.227.142.137 with HTTP; Sun, 3 Jul 2011 12:32:45 -0700 (PDT) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> Date: Sun, 3 Jul 2011 21:32:45 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Ronald Bonica Content-Type: multipart/alternative; boundary=20cf30025e36afb2e804a72f509b Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 19:32:48 -0000 --20cf30025e36afb2e804a72f509b Content-Type: text/plain; charset=ISO-8859-1 A bit late since this threat will be moderated soon. But I strongly object to this delay of needed action. I guess the other way the problem, which will hurt muchmuch more is maybe to considering a filter of 6to4 on isp level? I will suggest it when we start deploying native ipv6. --- Roger J. --- On Jul 2, 2011 6:39 PM, "Ronald Bonica" wrote: > Folks, > > Whereas there has been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have agreed to the following course of action: > > - the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-to-historic > - The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default. > - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus > > If anyone objects to this course of action, please speak up soon. > > Ron > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --20cf30025e36afb2e804a72f509b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

A bit late since this threat will be moderated soon. But I strongly obje= ct to this delay of needed action.

I guess the other way the problem, which will hurt muchmuch more is mayb= e to considering a filter of 6to4 on isp level?
I will suggest it when we start deploying native ipv6.

--- Roger J. ---

On Jul 2, 2011 6:39 PM, "Ronald Bonica"= ; <rbonica@juniper.net> wr= ote:
> Folks,
>
> Whereas there has= been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic,= the v6ops chairs and document author have agreed to the following course o= f action:
>
> - the V6OPS WG will withdraw its request to publish draft-iet= f-v6ops-6to4-to-historic
> - The author will introduce a new draft, i= ntended for standards track publication. The new draft will update RFCs 305= 6 and 3068. It will say that if 6-to-4 is implemented, it must be turned of= f by default.
> - In order for the new draft to be published, it must achieve both V6O= PS WG and IETF consensus
>
> If anyone objects to this course = of action, please speak up soon.
>
> = Ron
> <Speaking as OP= S Area AD>
> _______________________________________________
&g= t; Ietf mailing list
> Ietf@ietf.org=
> https://www.iet= f.org/mailman/listinfo/ietf
--20cf30025e36afb2e804a72f509b-- From rbonica@juniper.net Sun Jul 3 13:58:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B87311E8089; Sun, 3 Jul 2011 13:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.252 X-Spam-Level: X-Spam-Status: No, score=-106.252 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VTdspjpMx+O; Sun, 3 Jul 2011 13:58:06 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 608FB11E807D; Sun, 3 Jul 2011 13:58:06 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKThDX3S6ONtWkIqSQYJyJuphtGm8abK40@postini.com; Sun, 03 Jul 2011 13:58:06 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 3 Jul 2011 13:57:23 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Sun, 3 Jul 2011 16:57:22 -0400 From: Ronald Bonica To: "v6ops@ietf.org" , IETF Discussion Date: Sun, 3 Jul 2011 16:57:21 -0400 Thread-Topic: draft-ietf-v6ops-6to4-to-historic Thread-Index: Acw41iMv6/qWspvgTzCQB463JqIp+AA69FxA Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3507F3A@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 03 Jul 2011 14:07:55 -0700 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 20:58:07 -0000 Folks, I think that I get it. There is no IETF consensus regarding the compromise = proposed below. So, at very least, we will have to abandon the compromise. Right now, the only alternative that I see is to reintroduce draft-ietf-v6o= ps-6to4-to-historic and let the appeal process run its course. I hate to do= this, because the appeals process can be an incredible time sync and distr= action. If anybody sees another alternative, please propose it. Ron P.S. This thread has generated over 100 messages in the last 28 hours. Let'= s all take two days to cool off and spend some time with our families. -----Original Message----- From: Ronald Bonica=20 Sent: Saturday, July 02, 2011 12:36 PM To: v6ops@ietf.org; IETF Discussion Subject: draft-ietf-v6ops-6to4-to-historic Folks, Whereas there has been considerable controversy regarding draft-ietf-v6ops-= 6to4-to-historic, the v6ops chairs and document author have agreed to the f= ollowing course of action: - the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-t= o-historic - The author will introduce a new draft, intended for standards track publi= cation. The new draft will update RFCs 3056 and 3068. It will say that if 6= -to-4 is implemented, it must be turned off by default.=20 - In order for the new draft to be published, it must achieve both V6OPS WG= and IETF consensus If anyone objects to this course of action, please speak up soon. Ron From joelja@bogus.com Sun Jul 3 16:37:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB741F0C3C for ; Sun, 3 Jul 2011 16:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.208 X-Spam-Level: X-Spam-Status: No, score=-102.208 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KPY1qgBmRLv for ; Sun, 3 Jul 2011 16:37:40 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4C71F0C39 for ; Sun, 3 Jul 2011 16:37:39 -0700 (PDT) Received: from [192.168.11.127] (c-76-115-172-69.hsd1.wa.comcast.net [76.115.172.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p63NbaWD045423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 3 Jul 2011 23:37:37 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-45-716569972 From: Joel Jaeggli In-Reply-To: Date: Sun, 3 Jul 2011 16:37:31 -0700 Message-Id: <54E20C35-711A-48ED-9050-DA81C505EBDB@bogus.com> References: <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 03 Jul 2011 23:37:37 +0000 (UTC) X-Mailman-Approved-At: Sun, 03 Jul 2011 16:47:24 -0700 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 23:37:41 -0000 --Apple-Mail-45-716569972 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 1, 2011, at 3:54 PM, Templin, Fred L wrote: > Hi Joel, > =20 > Me again. There have have been others who have also expressed > concerns about DHCPv6 and other "undocumented features" on > ISATAP links, so I decided to split the document into two pieces. > The new piece is now called: "ISATAP Updates" and I guess might > be more appropriate for some other working group. The other piece > retains the original name and is strictly about operational aspects > of widely-deployed implementations: > =20 > http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-12.txt=20= > What should we do next - ask the wg for comments? yeah, I think the question of do isatap implementers or users in v6ops = find this line of work interesting and useful is essentially the open = question thatwould cause us to consider advancing this as a wg document = vs allowing you to pursue it as an indivudal submission. I think that = preaking shcpv6 out of it is a wise idea. > =20 > Thanks - Fred >=20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Templin, Fred L > Sent: Wednesday, June 22, 2011 8:13 AM > To: Joel Jaeggli > Cc: v6ops@ietf.org > Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? >=20 > Hi Joel, > =20 > Thanks for your comments, and see below for responses: >=20 > From: Joel Jaeggli [mailto:joelja@bogus.com]=20 > Sent: Friday, June 17, 2011 12:50 PM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? >=20 > On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote: >=20 >> Hello, >>=20 >> Significant improvements have been made to this document >> (below) based on comments received and new observations. >> IMHO, this is an important document for enabling transition >> to IPv6 within IPv4 sites; hence, I would like to call for >> working group adoption at this time. >>=20 >> Thanks - Fred >> fred.l.templin@boeing.com >>=20 >=20 > Replying to this message as a way to maintain the threading. these = notes are relative to the current version of the draft which I reviewed = last week: >=20 > http://tools.ietf.org/html/draft-templin-v6ops-isops-10 >=20 > So I tried for a while to separate the operational advice that could = be applied to my 2005 era knowledge of isatap and there's quite a few = things that jive with that (tunnel loops for example).=20 > OK. =20 > In other cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, = what implementations are capable of doing that? Are we recommending that = they do it? do they already?=20 > I can't speak for current implementations, but the DHCPv6 approach is > based on the fact that address and prefix assignment on IPv6 = interfaces > are seperable functions. IPv6 prefixes assigned to ISATAP interfaces = can > only be used for autoconfiguration of ISATAP addresses and not = ordinary > IPv6 addresses. However, an ordinary IPv6 address can be assigned to > an ISATAP interface the same as for any other IPv6 interface as long = as > it is not covered by a prefix assigned to the interface. > Regarding aero (section 4.6) that looks pretty much like new work or = an extension to the specification.=20 > AERO is a new but backwards-compatible method of doing redirection > of an on-link neighbor to another on-link neighbor. However, ISATAP > interfaces can still use standards ICMPv6 Redirect messages the same > as for any IPv6 interface. Advertising ISATAP routers should only send > ICMPv6 redirects when they are certain that the redirected ISATAP node > can tunnel packets directly to the target of the redirect, however. = Perhaps > a few more words saying explicitly that standards ICMPv6 redirects are > still supported would help?=20 > Are there participants with extant isatap deployements or host = implementations or knowledge fresher than mine that would care to = comment on this draft.=20 > =20 > There are certainly vendors who are shipping ISATAP in their products > today. Perhaps they can comment.=20 > section 9 alternative approaches, there's some consensus that rfc 3056 = was never really deployed so the reference to 6to4 should probably be to = 3068=20 > =20 > OK - I can fix this. > =20 > Thanks - Fred > fred.l.templin@boeing.com --Apple-Mail-45-716569972 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 1, 2011, at 3:54 PM, Templin, Fred L wrote:

Hi Joel,
 
Me again. There have have been others who have also expressed
concerns about DHCPv6 and other "undocumented features" on
ISATAP links, so I decided to split the document into two pieces.



The new piece is now called: "ISATAP Updates" and I guess might
be more appropriate for some other working group. The other piece
retains the original name and is strictly about operational aspects
of widely-deployed implementations:
 
What should we do next - ask the wg for comments?

yeah, I think the question of do isatap implementers  or users in v6ops find this line of work interesting and useful is essentially the open question thatwould cause us to consider advancing this as a wg document vs allowing you to pursue it as an indivudal submission. I think that preaking shcpv6 out of it is a wise idea.

 
Thanks - Fred

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L
Sent: Wednesday, June 22, 2011 8:13 AM
To: Joel Jaeggli
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?

Hi Joel,
 
Thanks for your comments, and see below for responses:

From: Joel Jaeggli [mailto:joelja@bogus.com]
Sent: Friday, June 17, 2011 12:50 PM
To: Templin, Fred L
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?

On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote:

Hello,

Significant improvements have been made to this document
(below) based on comments received and new observations.
IMHO, this is an important document for enabling transition
to IPv6 within IPv4 sites; hence, I would like to call for
working group adoption at this time.

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


Replying to this message as a way to maintain the threading. these notes are relative to the current version of the draft which I reviewed last week:


So I tried for a while to separate the operational advice that could be applied to my 2005 era knowledge of isatap and there's  quite a few things that jive with that (tunnel loops for example). 
OK.  
In other cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what implementations are capable of doing that? Are we recommending that they do it? do they already? 
I can't speak for current implementations, but the DHCPv6 approach is
based on the fact that address and prefix assignment on IPv6 interfaces
are seperable functions. IPv6 prefixes assigned to ISATAP interfaces can
only be used for autoconfiguration of ISATAP addresses and not ordinary
IPv6 addresses. However, an ordinary IPv6 address can be assigned to
an ISATAP interface the same as for any other IPv6 interface as long as
it is not covered by a prefix assigned to the interface.
Regarding aero (section 4.6) that looks pretty much like new work or an extension to the specification. 
AERO is a new but backwards-compatible method of doing redirection
of an on-link neighbor to another on-link neighbor. However, ISATAP
interfaces can still use standards ICMPv6 Redirect messages the same
as for any IPv6 interface. Advertising ISATAP routers should only send
ICMPv6 redirects when they are certain that the redirected ISATAP node
can tunnel packets directly to the target of the redirect, however. Perhaps
a few more words saying explicitly that standards ICMPv6 redirects are
still supported would help? 
Are there participants with extant isatap deployements or host implementations or knowledge fresher than mine that would care to comment on this draft. 
 
There are certainly vendors who are shipping ISATAP in their products
today. Perhaps they can comment. 
section 9 alternative approaches, there's some consensus that rfc 3056 was never really deployed so the reference to 6to4 should probably be to 3068 
 
OK - I can fix this.
 
Thanks - Fred

--Apple-Mail-45-716569972-- From joelja@bogus.com Sun Jul 3 16:57:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF8C21F85BF; Sun, 3 Jul 2011 16:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mcYdKNxDf3j; Sun, 3 Jul 2011 16:57:20 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9778E21F85D5; Sun, 3 Jul 2011 16:57:19 -0700 (PDT) Received: from [192.168.11.127] (c-76-115-172-69.hsd1.wa.comcast.net [76.115.172.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p63NvGSR045801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 3 Jul 2011 23:57:17 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Sun, 3 Jul 2011 16:57:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5023B51E-7D7D-43EB-B8FC-FF9BE13D5867@bogus.com> References: <282787FA-C418-430C-B473-152B4FFE900C@gmail.com> <20110622210451.60ad8bce@opy.nosense.org> <20110623095548.24d89d7f@opy.nosense.org> <63524B72-6890-48E4-926F-030744B415A2@nominum.com> To: "Manfredi, Albert E" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 03 Jul 2011 23:57:17 +0000 (UTC) X-Mailman-Approved-At: Sun, 03 Jul 2011 17:42:04 -0700 Cc: "v6ops@ietf.org" , "ipv6@ietf.org" Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 23:57:20 -0000 On Jun 23, 2011, at 2:31 PM, Manfredi, Albert E wrote: > Ted Lemon wrote: >=20 >> That's correct. Ultimately the security of the client depends on = the >> client being secure. Trying to secure the client by securing the >> network is a noble cause, but ultimately doomed to failure, because = you >> can't control what networks the client connects to. >=20 > No, I think you have it backwards. >=20 > It is service providers that are interested in protecting their = networks, in this discussion. If they also happen to protect their = clients, that is just a nice byproduct. >=20 > Service providers want to keep malicious clients from degrading their = network. as the former operator of some university residence hall networks, the = goal is to minimize damage in a common l2 broadcast domain. = Misconfigured or malicious users both cause similar sorts of damage, = there's dramatically more of the former than the later. > Bert >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From fred@cisco.com Mon Jul 4 06:55:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9CB1F0C86 for ; Mon, 4 Jul 2011 06:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8zf60T1fOTA for ; Mon, 4 Jul 2011 06:55:01 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 17CF61F0C7E for ; Mon, 4 Jul 2011 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=143; q=dns/txt; s=iport; t=1309787701; x=1310997301; h=date:from:message-id:to:subject:cc; bh=WaUiKikjUuQOdbFZl7ohPgVsq3BU6KGSbpVQlNyhcbE=; b=cMmgPm5YeYMBY9tUXFsrpmbbIK8UwzO+MuYiVozDLYXeqOQesdMZJD3w vkPtMCteXGgPNdbbt6W1lkKKZOc6dKqu713YPcO30QMFhHJmDldPq2zSU ZeSEs25sAGKMyBDTNcg5ElVJD3cMk6pphzrW3NXPloLAI7RDHqMokMLKh g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicIAJTFEU6rRDoH/2dsb2JhbABSmQgBAY5zd6wlnUOGNgSHP5tN X-IronPort-AV: E=Sophos;i="4.65,472,1304294400"; d="scan'208";a="289542806" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-4.cisco.com with ESMTP; 04 Jul 2011 13:55:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p64Dt0q0009202; Mon, 4 Jul 2011 13:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p64Dt0320469; Mon, 4 Jul 2011 06:55:00 -0700 (PDT) Date: Mon, 4 Jul 2011 06:55:00 -0700 (PDT) From: Message-Id: <201107041355.p64Dt0320469@ftpeng-update.cisco.com> To: v6ops@ietf.org X-Mailman-Approved-At: Mon, 04 Jul 2011 08:04:28 -0700 Cc: draft-li-v6ops-load-balancing-requirement@tools.ietf.org Subject: [v6ops] new draft: draft-li-v6ops-load-balancing-requirement-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 13:55:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-li-v6ops-load-balancing-requirement. Please take a look at it and comment. From fred@cisco.com Mon Jul 4 06:55:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8DB1F0C7E for ; Mon, 4 Jul 2011 06:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uN7uUS56ZrnM for ; Mon, 4 Jul 2011 06:55:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 246FA1F0C81 for ; Mon, 4 Jul 2011 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=152; q=dns/txt; s=iport; t=1309787701; x=1310997301; h=date:from:message-id:to:subject:cc; bh=qTiRyDVtYXuX92bDbQzepPwdINhyXb7beDsjDIyebHI=; b=C4yWXsJPYfVXqDQqVpJfNZbcdtF8EI/UHkvYpJrVjd+KioY5hBlP3A9p LbCxL67n95XmXAG1ET3lf2blmgIAfQ2aSogEc9MrtkCG0XAqZD7dP/1Ln n7msmc5kZ1waPorlGrkFMe6TaS+noMd0Qi+hYxUTZddxbjiTI6D/7BW+2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicIAJTFEU6rRDoI/2dsb2JhbABSmQgBAY5zd6wlnUOGNgSHP5tN X-IronPort-AV: E=Sophos;i="4.65,472,1304294400"; d="scan'208";a="360623517" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-5.cisco.com with ESMTP; 04 Jul 2011 13:55:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p64Dt0eA013761; Mon, 4 Jul 2011 13:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p64Dt0a20466; Mon, 4 Jul 2011 06:55:00 -0700 (PDT) Date: Mon, 4 Jul 2011 06:55:00 -0700 (PDT) From: Message-Id: <201107041355.p64Dt0a20466@ftpeng-update.cisco.com> To: v6ops@ietf.org X-Mailman-Approved-At: Mon, 04 Jul 2011 08:04:28 -0700 Cc: draft-gundavelli-v6ops-pmipv6-address-reservations@tools.ietf.org Subject: [v6ops] new draft: draft-gundavelli-v6ops-pmipv6-address-reservations-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 13:55:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-gundavelli-v6ops-pmipv6-address-reservations. Please take a look at it and comment. From fred@cisco.com Mon Jul 4 06:55:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755AC1F0C87 for ; Mon, 4 Jul 2011 06:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NebIULyrZ4qH for ; Mon, 4 Jul 2011 06:55:01 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 218BD1F0C80 for ; Mon, 4 Jul 2011 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=127; q=dns/txt; s=iport; t=1309787701; x=1310997301; h=date:from:message-id:to:subject:cc; bh=KiJKi+g5E5ARMMlHpHOHoWSirltmt1uImipyHEvrEY4=; b=B9P7L+sFeRZC0nOtC2UbOVWZaZuECVlTtSu8bwkdQgo6qe35s9PFq2Yq 7fZxLBc8iDN3jF8UnB9C8IW+HyckzsK4jUnUn1PbUc59cJdfCZd0F6ZOW cKM6Y4c62qBqV5d4KSPcBefJY3Iav2jJ96SfeQAD/RF9Hq3q0N1WZX1tT A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicIAJTFEU6rRDoI/2dsb2JhbABSmQgBAY5zd6wlnUOGNgSHP5tN X-IronPort-AV: E=Sophos;i="4.65,472,1304294400"; d="scan'208";a="289542807" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-4.cisco.com with ESMTP; 04 Jul 2011 13:55:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p64Dt07h013762; Mon, 4 Jul 2011 13:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p64Dt0G20472; Mon, 4 Jul 2011 06:55:00 -0700 (PDT) Date: Mon, 4 Jul 2011 06:55:00 -0700 (PDT) From: Message-Id: <201107041355.p64Dt0G20472@ftpeng-update.cisco.com> To: v6ops@ietf.org X-Mailman-Approved-At: Mon, 04 Jul 2011 08:04:28 -0700 Cc: draft-tan-v6ops-fast6-aaa@tools.ietf.org Subject: [v6ops] new draft: draft-tan-v6ops-fast6-aaa-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 13:55:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-tan-v6ops-fast6-aaa. Please take a look at it and comment. From mohacsi@niif.hu Mon Jul 4 08:52:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9D01F0C38 for ; Mon, 4 Jul 2011 08:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.596 X-Spam-Level: X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1xP-8ZvXkcD for ; Mon, 4 Jul 2011 08:52:33 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 87DBD1F0C34 for ; Mon, 4 Jul 2011 08:52:33 -0700 (PDT) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id C5BFB875CD; Mon, 4 Jul 2011 17:52:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id EV5j5t-Iiv5M; Mon, 4 Jul 2011 17:52:28 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id E0E46875B8; Mon, 4 Jul 2011 17:52:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id DD4638759C; Mon, 4 Jul 2011 17:52:28 +0200 (CEST) Date: Mon, 4 Jul 2011 17:52:28 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: fred@cisco.com In-Reply-To: <201107041355.p64Dt0G20472@ftpeng-update.cisco.com> Message-ID: References: <201107041355.p64Dt0G20472@ftpeng-update.cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 04 Jul 2011 09:10:18 -0700 Cc: v6ops@ietf.org, draft-tan-v6ops-fast6-aaa@tools.ietf.org Subject: Re: [v6ops] new draft: draft-tan-v6ops-fast6-aaa-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 15:52:34 -0000 Hi, 1. This draft should refer as much as possible to: http://tools.ietf.org/html/rfc4779 Duplication of concepts should be avoided in the two drafts. Thus this draft should refer appropriate section of RFC 4779 2. Also http://tools.ietf.org/html/rfc6204 should be refered for CPE side 3. In my view this draft is providing extra to drafts/rfc above specifying the appropariate RADIUS attributes to be used in particular setup. Support for such a RADIUS attibutes can be implementation specific. 4. New elements is the "User-Type" Radius attribute, which is reguire allocation new Radius Types from IANA. I think RADEXT working group is working on a similar draft: http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-04 Maybe this should be discussed there also and probably unify the drafts. 5. Can you elaborate more the FAST6 architeture? Best Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Mon, 4 Jul 2011, fred@cisco.com wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-tan-v6ops-fast6-aaa. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Mon Jul 4 10:00:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5512111E80CF for ; Mon, 4 Jul 2011 10:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKBmSbtoU1Ro for ; Mon, 4 Jul 2011 10:00:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 230BE11E80CD for ; Mon, 4 Jul 2011 10:00:26 -0700 (PDT) Received: from [192.168.11.127] (c-76-115-172-69.hsd1.wa.comcast.net [76.115.172.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p64H0O0c064784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Jul 2011 17:00:25 GMT (envelope-from joelja@bogus.com) Resent-Message-Id: <201107041700.p64H0O0c064784@nagasaki.bogus.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Resent-From: Joel Jaeggli Date: Sun, 3 Jul 2011 16:18:28 -0700 Content-Transfer-Encoding: quoted-printable Resent-Date: Mon, 4 Jul 2011 10:00:19 -0700 Resent-To: 6man-ads@tools.ietf.com, "v6ops@ietf.org WG" References: Message-Id: <4B51E24B-B934-45AB-A72C-03BDDCEFFCCF@bogus.com> To: Andrew Yourtchenko X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 04 Jul 2011 17:00:25 +0000 (UTC) X-Mailman-Approved-At: Mon, 04 Jul 2011 23:31:23 -0700 Cc: v6nd@ne-where.com Subject: Re: [v6ops] new draft: draft-gashinsky-v6nd-enhance-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 17:00:29 -0000 On Jul 1, 2011, at 7:52 PM, Andrew Yourtchenko wrote: > Joel, >=20 > FWIW, a couple of observations about the "6.3. Routing Mitigation" = based on my experiments and various discussions, and a few miscellanea. >=20 > 6.2. Appropriate Subnet Sizing. >=20 > Maybe worth to note here that the folks would still benefit of = allocating the /64, and then using smaller part of it, if they want to = do so. So later if they need to have more hosts in that segment, they = would only renumber that segment. (also to "optimize the allocation for = conservation of braincells" which I remember someone mentioned some = time) fwiw that's essentially what I did in practice, e.g. I assign p-to-p = links as /64s and user them with much shorter. load balancer virtual = ip's are all assigned out of the same /64 but are actually used as = /128s. use of non-default subnet size on the other hand runs afoul of = SLAAC so it has it's limitations. > Also for consistency with 6.1, might be worth noting that this = approach would inhibit the use of RFC4862 altogether ? >=20 > 6.3. Routing Mitigation. >=20 > - the necessity to enable routing will depend on whether the host = implements Strong ES or Weak ES multihoming model as per rfc1122 = terminology - I tested on 2.6.32-24-generic and reaching the global = address configured on the "lo" interface from ethernet side did not = require enabling the forwarding. >=20 > - one semi-related advantage of the routing approach is that it can = and is used in operations to allow the routing-protocol based redundancy = with anycast addresses for transactional services. >=20 > - the overhead on the host will of course depend on the type of the = routing protocol. Also, since it is effectively host->router = communication, one can take an advantage of that. The RIPng seemed like = a good candidate to me in this regard (to be run only on the first hop = router). > The prototype code is 205 lines of vanilla C, of which 113 lines are = the RT_NETLINK boilerplate to retrieve the current address(es) assigned = to loopback interface, such that the host config files were the only = dependency. >=20 > (IMHO this approach is effectively a 7.3, but at network layer at an = expense of some addition to host. Arguably, http server code is also an = addition, though :). >=20 > - one other side effect of this approach is that if it is used in the = NBMA-type ethernet deployment (cf: the RA thread), then the absence of = the on-link global prefix takes care of the inter-host communication - = it will happen via the default gateway. >=20 >=20 > 7.1, item 5: Recommendations for Implementors. >=20 > keeping the state here opens the hole from another end - if a router = "remembers" the "past good" addresses, then a local attacker may easily = exhaust the resources on the router by rapidly changing the source = address and making a single ping, then moving on. yeah I think what exposure a malicious local system might exploit is = worth a thought expierment or two. > 7.2. Queue Tuning. >=20 > How does this interact with the other aspect of the behavior that is = dictated by RFC4861 ? >=20 > "While waiting for address resolution to complete, the sender MUST, > for each neighbor, retain a small queue of packets waiting for > address resolution to complete. " >=20 > Merely rate-limiting the requests from the dataplane would result in = inability for an implementation to comply with this "MUST", I think. yeah > Also, to me this section seems to contradict the 6.4: the 7.2 says = it's applicable if there is a single queue, while 6.4 says it is useful = only if there is more than one queue - while 7.2 reads as the suggestion = to implement the knobs for doing 6.4... If I miss something more subtle = here, might be useful to have it more explicit (and as well to expand on = the relationship between the two chapters). >=20 > 7.3. NDP Protocol Gratuitous NA >=20 > "Hosts MAY be configured to send unsolicited Neighbor = advertisement..." - is it something that exists now somewhere in the OS = or would this require additional code as well ? The implementations I = know of, used ad-hoc appendages to send these NAs. Ergo, I think it is = similar to section 6.3 except it uses the different name for the = protocol ? So NDP, as it exists today assumes that a gratuitious NA message kicks = of a NDP cycle. regarding whether implementations do something along = these links I'm pretty sure that host implmentations for vrrp6 pretty = much do that when transitioning the shared address between instaces. > I wonder if there is a room for "neighbor registration" approach = similar to the one in http://tools.ietf.org/html/draft-ietf-6lowpan-nd. >=20 > 9. >=20 > "... DOS exposure" is the ending of the sentence or there is something = more ? >=20 > s/Explicitely/Explicitly/ > s/maintin/maintain/ > s/amerlorate/ameliorate/ > s/isse/issue/ > s/excissivly/excessively/ > s/lowing/lowering/ > s/investigationg/investigating/ > s/maintaice/maintenance/ > s/recieving/receiving/ > s/correpsonding/corresponding/ thanks > cheers, > andrew >=20 > On Thu, 30 Jun 2011, Joel Jaeggli wrote: >=20 >> I would direct the two working groups' attention if I may to a = recently posted draft: >>=20 >> http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00 >>=20 >> the potential DOS exposure that ipv6 neighbor discovery poses to = routers is generally understood at this point, the document covers = usable work arounds, and includes some rough proposals for addressing = what the authors views as shortcomings in the neighbor disocvery = process. >>=20 >> some inspiration was drawn from: >>=20 >> http://tools.ietf.org/html/draft-nordmark-6man-impatient-nud-00 >>=20 >> thanks >> joel >>=20 >> A new version of I-D, draft-gashinsky-v6nd-enhance-00.txt has been = successfully submitted by joel jaeggli and posted to the IETF = repository. >>=20 >> Filename: draft-gashinsky-v6nd-enhance >> Revision: 00 >> Title: Operational Neighbor Discovery Problems and = Enhancements. >> Creation date: 2011-06-29 >> WG ID: Individual Submission >> Number of pages: 15 >>=20 >> Abstract: >> In IPv4, subnets are generally small, made just large enough to cover >> the actual number of machines on the subnet. In contrast, the >> default IPv6 subnet size is a /64, a number so large it covers >> trillions of addresses, the overwhelming number of which will be >> unassigned. Consequently, simplistic implementations of Neighbor >> Discovery can be vulnerable to denial of service attacks whereby they >> attempt to perform address resolution for large numbers of unassigned >> addresses. Such denial of attacks can be launched intentionally (by >> an attacker), or result from legitimate operational tools that scan >> networks for inventory and other purposes. As a result of these >> vulnerabilities, new devices may not be able to "join" a = network, it >> may be impossible to establish new IPv6 flows, and existing ipv6 >> transported flows may be interrupted. >>=20 >> This document describes the problem in detail and suggests possible >> implementation improvements as well as operational mitigation >> techniques that can in some cases to protect against such attacks. >> It also discusses possible modifications to the traditional [RFC4861] >> neighbor discovery protocol itself. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 From scott.brim@gmail.com Mon Jul 4 15:29:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7D121F87AA for ; Mon, 4 Jul 2011 15:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0403owule+XS for ; Mon, 4 Jul 2011 15:29:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A82721F87A9 for ; Mon, 4 Jul 2011 15:29:05 -0700 (PDT) Received: by iye7 with SMTP id 7so5875749iye.31 for ; Mon, 04 Jul 2011 15:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=yMtL79iHbD3v9qKhsu4qkZZ0dGLEVNym9R13wAMhNjY=; b=A5KfyQTJWyfNxcqTDmGTRzYfPuAdxyyIzTmOWQEQDYcD4P9Z216//M4lMLgbTJCadr MjmpoWrFFvmgOdeIJ+jhKwsRL/PezFYthpG7k6wKKfkOUFrhQvZUJCWraudDiK41Adx1 px8lZt7nO1mkRmNVB04gGBaZ96iVMHpjAFuaI= MIME-Version: 1.0 Received: by 10.231.114.29 with SMTP id c29mr5911027ibq.16.1309818544475; Mon, 04 Jul 2011 15:29:04 -0700 (PDT) Received: by 10.231.31.197 with HTTP; Mon, 4 Jul 2011 15:29:04 -0700 (PDT) Date: Mon, 4 Jul 2011 18:29:04 -0400 Message-ID: From: Scott Brim To: Tim Chown , IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 04 Jul 2011 23:31:23 -0700 Subject: [v6ops] Draft-Chown-v6-address-accountability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 22:29:06 -0000 I'm sure there will be lots of discussion about Tim's draft. I just want to say one thing: be sure you understand endpoint privacy requirements and take them into account. The end user is who you are in business for. Let's use solutions that make them happy to be customers instead of treating them as pesky nuisances. ... Scott From tjc@ecs.soton.ac.uk Mon Jul 4 15:47:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194DF1F0C34 for ; Mon, 4 Jul 2011 15:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exNLr5U0HFSb for ; Mon, 4 Jul 2011 15:47:26 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 24EE621F874D for ; Mon, 4 Jul 2011 15:47:24 -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 p64MlMd6020411 for ; Mon, 4 Jul 2011 23:47:22 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p64MlMd6020411 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1309819642; bh=YDAlvwhquLXPK03Cps7r6JrkrNk=; h=From:Mime-Version:Subject:Date:In-Reply-To:To:References; b=1EUXEzjEqh/+ck8qZW/uz5SC9hG9OMURO1d7BMThpX660XS+530l/Pn7XhFTZJLNh zrsHtTyyp4kEPVngcuzx3ZJWFxkBsVWdmjCZKCfwPFHaKOX82bs4Vp0vAGwEXw40Ab 1T4WvtqIfSvb9KBfAgg71zzp9O8hXMiBrbB2uJzo= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n63NlM0366137623VW ret-id none; Mon, 04 Jul 2011 23:47:22 +0100 Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p64Mk11P010713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 4 Jul 2011 23:46:01 +0100 From: Tim Chown Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3-799879374 Date: Mon, 4 Jul 2011 23:46:01 +0100 In-Reply-To: To: IPv6 Ops WG References: Message-ID: X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n63NlM036613762300; tid=n63NlM0366137623VW; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p64MlMd6020411 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Mailman-Approved-At: Mon, 04 Jul 2011 23:31:23 -0700 Subject: Re: [v6ops] Draft-Chown-v6-address-accountability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 22:47:27 -0000 --Apple-Mail-3-799879374 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 4 Jul 2011, at 23:29, Scott Brim wrote: > I'm sure there will be lots of discussion about Tim's draft. I just > want to say one thing: be sure you understand endpoint privacy > requirements and take them into account. The end user is who you are > in business for. Let's use solutions that make them happy to be > customers instead of treating them as pesky nuisances. Hi Scott, It's a topic that comes up whenever I speak to other university sites = deploying IPv6, or considering doing so, hence the draft, to see what = views and ideas are out there. Two common questions that come up are = whether the existing DHCPv4 accountability model can be applied, and = where it is not (or can not be) how can accountability be best achieved = where clients have multiple autoconfigured or privacy addresses that may = also be changing rapidly over time. What type of user privacy requirements do you have in mind? This topic = isn't included yet as the text is a drafty draft, but I would guess the = general view will be that privacy of addresses within an enterprise is a = somewhat unrealistic expectation because the network administrator will = always have access to the switch or router port-MAC tables or ND tables. = However, for user traffic going outside the enterprise, IPv6 privacy = addresses have a benefit for the user against tracking by 3rd parties. = Obviously comments are welcome on that. For those interested, the draft is here: = http://www.ietf.org/internet-drafts/draft-chown-v6ops-address-accountabili= ty-00.txt Tim --Apple-Mail-3-799879374 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I'm = sure there will be lots of discussion about Tim's draft. I just
want = to say one thing: be sure you understand endpoint = privacy
requirements and take them into account. The end user is who = you are
in business for. Let's use solutions that make them happy to = be
customers instead of treating them as pesky = nuisances.

Hi = Scott,

It's a topic that comes up whenever I = speak to other university sites deploying IPv6, or considering doing so, = hence the draft, to see what views and ideas are out there.  Two = common questions that come up are whether the existing DHCPv4 = accountability model can be applied, and where it is not (or can not be) = how can accountability be best achieved where clients have multiple = autoconfigured or privacy addresses that may also be changing rapidly = over time.

What type of user privacy = requirements do you have in mind?  This topic isn't included = yet as the text is a drafty draft, but I would guess the general view = will be that privacy of addresses within an enterprise is a somewhat = unrealistic expectation because the network administrator will always = have access to the switch or router port-MAC tables or ND tables. =  However, for user traffic going outside the enterprise, IPv6 = privacy addresses have a benefit for the user against tracking by 3rd = parties.  Obviously comments are welcome on = that.

For those interested, the draft is = here:

Tim

= --Apple-Mail-3-799879374-- From randy@psg.com Mon Jul 4 22:32:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C4D11E80A6 for ; Mon, 4 Jul 2011 22:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6JbHo0a5C8t for ; Mon, 4 Jul 2011 22:32:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id F2CBA11E808B for ; Mon, 4 Jul 2011 22:32:44 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QdyFX-000Pv3-7t; Tue, 05 Jul 2011 05:32:43 +0000 Date: Tue, 05 Jul 2011 14:32:42 +0900 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <201107041355.p64Dt0320469@ftpeng-update.cisco.com> References: <201107041355.p64Dt0320469@ftpeng-update.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 04 Jul 2011 23:31:23 -0700 Cc: IPv6 Ops WG Subject: Re: [v6ops] new draft: draft-li-v6ops-load-balancing-requirement-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 05:32:45 -0000 > A new draft has been posted, at > http://tools.ietf.org/html/draft-li-v6ops-load-balancing-requirement. Please > take a look at it and comment. fred, i am confused. almost all the technologies [0] mentioned indeed 'force' a path. and indeed in some cases, these paths could concentrate packets which might otherwise be more diversely forwarded. but that's life in the big city. so that leaves me only seeing that the document is about when services have multiple and diverse servers. so how is this different than ipv4 where, for example, we use load balancers when near servers which need scale and use anycast when we want diversity and resiliency? what should i have learned from this document? clue bat, please. randy -- [0] - note that most of these are non-transition technologies From v6ops@globis.net Tue Jul 5 02:04:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E041221F877E for ; Tue, 5 Jul 2011 02:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huw+fXDsxf9Y for ; Tue, 5 Jul 2011 02:04:57 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id D6DFA21F877F for ; Tue, 5 Jul 2011 02:04:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 597FF8700EF; Tue, 5 Jul 2011 11:04:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNzc+cpaa38e; Tue, 5 Jul 2011 11:04:17 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id F0D568700D7; Tue, 5 Jul 2011 11:04:16 +0200 (CEST) Message-ID: <4E12D390.6020202@globis.net> Date: Tue, 05 Jul 2011 11:04:16 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "v6ops@ietf.org WG" , Joel Jaeggli Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 05 Jul 2011 06:30:06 -0700 Subject: Re: [v6ops] new draft: draft-gashinsky-v6nd-enhance-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 09:04:58 -0000 Thanks for releasing this draft. Following all IMVHO from an operational perspective regarding differences of IPv4 and IPv6 network ingress and egress filtering. I personally believe that the problem description for ND also needs to address the fact that there's a large number of potential source addresses, as well as potential destination addresses: it's a symmetrical problem. p4 section2. "When such probes are directed via a router" talks about scans causing problems for a router. Is there also a local on-wire attack possible on important server hosts? In IPv4, those hosts could also implement tight ingress and egress filters on a local machine-specific firewall. In IPv6, if an attacker compromises one host on the wire, they can use that as a springboard to attack other hosts. By sending many spoofed source addresses from a raw socket, the attacker can exhaust or abuse resources associated with ND or other server processes on the target server machine. OK it's fairly similar to IPv4 ARP flooding, but the attack surface is that much bigger, again because the ingress filters on the target can't be as tight on an IPv6 /64 as say an IPv4/24: that's 12 orders of magnitude difference. PVLAN and disallowing host to host communication might still be an effective mitigation. Is there not also a related case (not directly relevant for ND) whereby an off-wire attacker now has access to far more source addresses than before? SYN flooding prevention and other attack mitigation techniques have led to the implementation of automatic rate-limit filters in firewalls. In the past, a DDOS attack on the Internet required access to a large number of machines, because IPv4 source addresses were in short supply and each attack machine was effectively limited to a single IPv4/32 public IP source address. Now an attacker can easily obtain one or more temporary IPv6/48 today (via any tunnel broker provider and a spoofed email address). Even if the defender filters in firewalls at the IPv6/64 level instead of the IPv4/32 level, that still means that each attacking host can send 2^16 different unique IPv6/64 prefixes to the target for each IPv6/48 prefix it has locally. A change in ratio of 2^16:1 compared to today. Effectively, this could reduce the size of the botnet required to generate a significant attack by 2^16 or nearly 5 orders of magnitude unless defence mechanisms are radically improved compared to just filtering and rate limiting on IPv4/32 and IPv6/64. The attacker could also harvest any replies by setting the local kernel interface into promiscuous mode, whilst also spoofing a large number of source machines (unlike today, where net edge ingress and egress filters would typically limit that to 1 IPv4/32 on the Internet or at most an IPv4 subnet worth of machines in a corporate net = on average say 256 potentially different source addresses). Again a change in ratio of approx 2^16:1. Whilst not specifically ND related, it could also change the odds in favor of the attacker. I'd like to see whether it would be benefical for automated filters and other ingress and egress mitigation filter techniques to not only just filter or rate limit at the IPv6/64 and IPv4/32 level, but also track in parallel the SYN packet/attack rates at IPv6/128 IPv6/48 IPv6/40 IPv6/32 IPv6/16 prefix level simultaneously, with each successively wider filter in turn protecting the narrower filters from resource depletion. [If you only track and filter at the IPv6/64 level, the firewall itself could become a target of a DOS attack for someone with access to multiple /48's] I completely agree such filtering is onerous, but what other tools do we have? Especially for a zero day exploit. I guess the ultimate operational mitigation for ND at the network edge is to configure each critical edge server as a point to point link to a dedicated L3 router port with simple static routing. [not mentioned in your paper, but a variation on 6.3 Routing Mitigation.] High availability may of course be an issue that forces you to use shorter prefixes or dynamic routing. regards, RayH From tanjh.gz@gmail.com Tue Jul 5 02:43:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385D121F8794 for ; Tue, 5 Jul 2011 02:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLFZ-ztxwCGH for ; Tue, 5 Jul 2011 02:43:08 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F87B21F8690 for ; Tue, 5 Jul 2011 02:43:08 -0700 (PDT) Received: by pvh18 with SMTP id 18so7671709pvh.31 for ; Tue, 05 Jul 2011 02:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=83cXWGYDlOmf+5b+N1Cdf5JLRTaTMOWKLdWogPumVDw=; b=W00afnSEPSqjmXZYs4ezuQQxAWu24+fCWeUF7T5VdILRsXHnFuYJ7igxpTcCm2qg4J w9+M/FXemjsqLABltJbOeSwCvW+ucwlzJpF48Mymqci0wr93APlNASf6fCHD1VdgbTBX jNp5rQ3ksVPnB6ySe9fwi9QFnvNLeKZRM37n4= MIME-Version: 1.0 Received: by 10.68.33.8 with SMTP id n8mr958658pbi.207.1309858987495; Tue, 05 Jul 2011 02:43:07 -0700 (PDT) Received: by 10.68.43.168 with HTTP; Tue, 5 Jul 2011 02:43:07 -0700 (PDT) Date: Tue, 5 Jul 2011 17:43:07 +0800 Message-ID: From: =?GB2312?B?zLe+sLuq?= To: mohacsi@niif.hu Content-Type: multipart/alternative; boundary=bcaec51dd0f5a7d04c04a74f4f40 X-Mailman-Approved-At: Tue, 05 Jul 2011 06:30:06 -0700 Cc: v6ops@ietf.org, draft-tan-v6ops-fast6-aaa@tools.ietf.org Subject: Re: [v6ops] new draft: draft-tan-v6ops-fast6-aaa-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 09:47:06 -0000 --bcaec51dd0f5a7d04c04a74f4f40 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, thank for your advice. > -----Original Message----- > From: Mohacsi Janos [mailto:mohacsi@niif.hu] > Sent: Monday, July 04, 2011 11:52 PM > To: fred@cisco.com > Cc: v6ops@ietf.org; draft-tan-v6ops-fast6-aaa@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-tan-v6ops-fast6-aaa-00.txt > > Hi, > > 1. This draft should refer as much as possible to: > http://tools.ietf.org/html/rfc4779 > > Duplication of concepts should be avoided in the two drafts. Thus this > draft should refer appropriate section of RFC 4779 * Description for access scenarios in Chapter 3 could have a little duplication with RFC 4779. But this chapter focus on the process of access and it is not the keypoint of this draft but the base for the following discuss. Maybe the title should modifies to "access process". * > > 2. Also http://tools.ietf.org/html/rfc6204 should be refered for CPE side *Yes,the Routed mode CPE in this draft is similar to the Customer Edge Router in RFC 6204. It refers to =93draft-yang-v6ops-fast6-pppoe-00=94. If Routed mode CPE and Bridged mode CPE is not common, we can change them at subsequent versions. * > > 3. In my view this draft is providing extra to drafts/rfc above specifyin= g > the appropariate RADIUS attributes to be used in particular setup. Suppor= t > for such a RADIUS attibutes can be implementation specific. *Yes, this draft is focus on how to use the "existing" RADIUS attibutes to implement Authentication, Authorization and Accounting, in case of PPP access. It provide one of methods to implement AAA. It clears the access process and how to use attributes in Authorization and Accounting,especilly how to use two groups packets for dual-stack accounting. * > > 4. New elements is the "User-Type" Radius attribute, which is reguire > allocation new Radius Types from IANA. I think RADEXT working group is > working on a similar draft: > > http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-04 > > Maybe this should be discussed there also and probably unify the drafts. *I agree. This draft issue some requirements for RADIUS extensions, and these new attriubes should be defined in one draft. * > > 5. Can you elaborate more the FAST6 architeture? *FAST6 architeture is described in=93draft-yang-v6ops-fast6-pppoe-00=94. In summary,FAST6 is dual stack deploment architeture base on the PPPoE access technology. Maybe we should take the draft as a reference. * > > Best Regards, > > Janos Mohacsi > Head of HBONE+ project > Network Engineer, Deputy Director of Network Planning and Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > On Mon, 4 Jul 2011, fred@cisco.com wrote: > >> >> A new draft has been posted, at http://tools.ietf.org/html/draft-tan-v6ops-fast6-aaa. Please take a look at it and comment. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> --bcaec51dd0f5a7d04c04a74f4f40 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, thank for your advice.

> -----Original Message-----
> F= rom: Mohacsi Janos=20 [mailto:mohacsi@niif.hu]
> Se= nt: Monday, July 04, 2011 11:52 PM
>=20 To: fred@cisco.com
> Cc: v6ops@ietf.org; draft-tan-v6ops-fast6-aaa@tools.ietf.org
>=20 Subject: Re: [v6ops] new draft: draft-tan-v6ops-fast6-aaa-00.txt
>=20
> Hi,
>
> 1. This draft should refer as much as possibl= e=20 to:
> http://tools.iet= f.org/html/rfc4779
>=20
> Duplication of concepts should be avoided in the two drafts. Thus = this=20
> draft should refer appropriate section of RFC 4779

=A0De= scription=20 for access scenarios in Chapter 3 could have a little duplication with RFC = 4779.=20 But this chapter focus on the process of access and it is not the keypoint = of=20 this draft but the base for the following discuss. Maybe the title should= =20 modifies to "access process".

>
> 2. Also http://tools.ietf.org/html/rfc= 6204=20 should be refered for CPE side

Yes,the Routed mode CPE in this dr= aft is=20 similar to the Customer Edge Router in RFC 6204. It=A0 refers to=20 =93draft-yang-v6ops-fast6-pppoe-00=94. If Routed mode CPE and Bridged mode = CPE is=20 not common, we can change them at subsequent versions.

> > 3.=20 In my view this draft is providing extra to drafts/rfc above specifying >=20 the appropariate RADIUS attributes to be used in particular setup. Support= =20
> for such a RADIUS attibutes can be implementation specific.
Yes,=20 this draft is focus on how to use the "existing" RADIUS attibutes= to implement=20 Authentication, Authorization and Accounting, in case of PPP access. It pro= vide=20 one of methods to implement AAA. It clears the access process and how to us= e=20 attributes in Authorization and Accounting,especilly how to use two groups= =20 packets for dual-stack accounting.

>
> 4. New element= s is the=20 "User-Type" Radius attribute, which is reguire
> allocatio= n new Radius=20 Types from IANA. I think RADEXT working group is
> working on a simi= lar=20 draft:
>
> http://tools.ietf.org/html/draft-ietf-radext-ipv6-acce= ss-04
>=20
> Maybe this should be discussed there also and probably unify the= =20 drafts.

I agree. This draft issue some requirements for RADIUS ex= tensions,=20 and these new attriubes should be defined in one draft.

> >=20 5. Can you elaborate more the FAST6 architeture?

FAST6 architetur= e is=20 described in=93draft-yang-v6ops-fast6-pppoe-00=94. In summary,FAST6 is dual= stack=20 deploment architeture base on the PPPoE access technology. Maybe we should = take the draft as a reference.

>
>=20 Best Regards,
>
> Janos Mohacsi
> Head of HBONE+=20 project
> Network Engineer, Deputy Director of Network Planning and= =20 Projects
> NIIF/HUNGARNET, HUNGARY
> Key 70EF9882: DEC2 C685 1E= D4=20 C95A 145F=A0 4300 6F64 7B00 70EF 9882
>
> On Mon, 4 Jul 2011, = fred@cisco.com wrote:
>=20
>>
>> A new draft has been posted, at http://tools.ietf.org/html/d= raft-tan-v6ops-fast6-aaa.=20 Please take a look at it and comment.
>>=20 _______________________________________________
>> v6ops mailing= =20 list
>> v6ops@ietf.org
&g= t;>=20 https://www.ietf.or= g/mailman/listinfo/v6ops
>> --bcaec51dd0f5a7d04c04a74f4f40-- From nick@inex.ie Sun Jul 3 13:35:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777CE11E807D for ; Sun, 3 Jul 2011 13:35:33 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDtu3Hxnp+yJ for ; Sun, 3 Jul 2011 13:35:33 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id E69E022801C for ; Sun, 3 Jul 2011 13:35:31 -0700 (PDT) X-Envelope-To: Received: from crumpet.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p63KZJoA033026 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 3 Jul 2011 21:35:24 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4E10D287.4080104@inex.ie> Date: Sun, 03 Jul 2011 21:35:19 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> <4E10132E.3050902@dougbarton.us> <2DBDB375-BA46-47B5-A170-8B564CD811A7@network-heretics.com> In-Reply-To: <2DBDB375-BA46-47B5-A170-8B564CD811A7@network-heretics.com> X-Enigmail-Version: 1.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 05 Jul 2011 06:39:23 -0700 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 20:35:33 -0000 On 03/07/2011 14:59, Keith Moore wrote: > no, it needs to be fixed. There is no fix. The protocol has no dead broker detection and this cannot be changed without rewriting the protocol from scratch. In the absence of dead broker detection, the only option as an end-user is to hope that things work, and if your connectivity is trashed, to depend on the benevolence of third parties with whom you have no recourse. Speaking as an operator, I do not understand how supporting the continued existence of a protocol of this level of brokenness constitutes good stewardship. >From an operational point of view, the only viable option is to remove the protocol from the Internet, and this document is the first step in that direction. Nick From jnc@mercury.lcs.mit.edu Sun Jul 3 14:29:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A836E21F85CD; Sun, 3 Jul 2011 14:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FRT_FOLLOW1=1.332, FRT_FOLLOW2=0.422, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHxpeS6DEozG; Sun, 3 Jul 2011 14:29:06 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 305BC21F85CC; Sun, 3 Jul 2011 14:29:05 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 34DB218C1C2; Sun, 3 Jul 2011 17:29:05 -0400 (EDT) To: ietf@ietf.org, v6ops@ietf.org Message-Id: <20110703212905.34DB218C1C2@mercury.lcs.mit.edu> Date: Sun, 3 Jul 2011 17:29:05 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailman-Approved-At: Tue, 05 Jul 2011 06:39:23 -0700 Cc: jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 21:29:06 -0000 > From: Ronald Bonica > I think that I get it. There is no IETF consensus regarding the > compromise proposed below. ... > Right now, the only alternative that I see is to reintroduce > draft-ietf-v6ops-6to4-to-historic But there is no rough consensus to do that either. There is simply no IETF-wide agreement on _any_ action with regard to killing off 6to4. So the only possible response is the IETF's normal response when there is no rough consensus on what to do, which is to defer any action. At least, as has been pointed out, we have draft-ietf-v6ops-6to4-advisory, which has already been OKs, and which, _if folllowed_, would alleviate most of the problems. Noel From rbonica@juniper.net Sun Jul 3 16:49:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BC11F0C3F; Sun, 3 Jul 2011 16:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.525 X-Spam-Level: X-Spam-Status: No, score=-106.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x10toxGDkIJS; Sun, 3 Jul 2011 16:49:11 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id CEE871F0C3C; Sun, 3 Jul 2011 16:49:09 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKThD/9eFoLc0qkBSgfnxsDCSg6aKcKNiK@postini.com; Sun, 03 Jul 2011 16:49:11 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 3 Jul 2011 16:49:06 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Sun, 3 Jul 2011 19:49:06 -0400 From: Ronald Bonica To: Noel Chiappa , "ietf@ietf.org" , "v6ops@ietf.org" Date: Sun, 3 Jul 2011 19:49:04 -0400 Thread-Topic: draft-ietf-v6ops-6to4-to-historic Thread-Index: Acw5yD3/2VY+9nwqQ2OF+Gari0e9dwAEsFhA Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3507F50@EMBX01-WF.jnpr.net> References: <20110703212905.34DB218C1C2@mercury.lcs.mit.edu> In-Reply-To: <20110703212905.34DB218C1C2@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 05 Jul 2011 06:39:23 -0700 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 23:49:12 -0000 Comments inline........ -----Original Message----- From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 Sent: Sunday, July 03, 2011 5:29 PM To: ietf@ietf.org; v6ops@ietf.org Cc: jnc@mercury.lcs.mit.edu Subject: RE: draft-ietf-v6ops-6to4-to-historic > From: Ronald Bonica > I think that I get it. There is no IETF consensus regarding the > compromise proposed below. ... > Right now, the only alternative that I see is to reintroduce > draft-ietf-v6ops-6to4-to-historic=20 But there is no rough consensus to do that either. RB> That is the claim of an appeal on the table. Let's run the appeal proce= ss RB> and figure out whether that claim is valid. We certainly aren't having = any RB> success reaching a decision on the mailing list. RB> RB> Ron From marka@isc.org Sun Jul 3 17:55:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5759521F85CC; Sun, 3 Jul 2011 17:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S1iJ8oP9Z+t; Sun, 3 Jul 2011 17:55:03 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id E289F21F85CA; Sun, 3 Jul 2011 17:55:02 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7830E5F98EF; Mon, 4 Jul 2011 00:54:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 25822216C7B; Mon, 4 Jul 2011 00:54:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D2531116B88C; Mon, 4 Jul 2011 10:54:38 +1000 (EST) To: Tim Chown From: Mark Andrews References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703111047.GB2304@Space.Net> <04B2CF82-78EC-4A2B-A681-7710E3EFCDBE@ecs.soton.ac.uk> In-reply-to: Your message of "Sun, 03 Jul 2011 17:09:20 +0100." Date: Mon, 04 Jul 2011 10:54:38 +1000 Message-Id: <20110704005438.D2531116B88C@drugs.dv.isc.org> X-Mailman-Approved-At: Tue, 05 Jul 2011 06:39:23 -0700 Cc: IPv6 Operations , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 00:55:04 -0000 In message , Tim Chown writes: > > On 3 Jul 2011, at 12:10, Gert Doering wrote: > > > On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: > >> There's clearly a lack of consensus to support it. > > > > There's two very vocal persons opposing it and a much larger number of > > people that support it, but have not the time to write a similarily > > large amount of e-mails. For me, this is enough for "rough consensus". > > > > (And I second everything Lorenzo, Randy and Cameron said - there's > > theoretical possibilities, and real world. 6to4 fails the real-world > > test. Get over it, instead of attacking people that run real-world > > networks for the decisions they need to do to keep the networks running > > in a world without enough IPv4 addresses). > > I'm with Gert, Lorenzo, Randy and others here. > > It seemed that both the -advisory and -historic drafts had strong support in > v6ops, which isn't just any WG, it's the WG that anyone with a vested interes > t in IPv6 deployment takes part. Thus its view on IPv6 deployment practices > should be given due regard. The opposition on the IETF list seemed to be a v > ocal minority, and of course one person seemed to post a disproportionate num > ber of replies. > > The problems with 6to4 (20% minimum failure rate, and poor performance when i > t does connect) are well documented and have led to various 'counter measures > ' from the IETF, including: > a) 6to4 off by default, as per 6to4-advisory > b) IPv4 being preferred to 6to4 transport, as per 3484-bis (widely implemente > d already) > c) a fast fallback mechanism from IPv6 to IPv4, as per happy eyeballs (a simp > listic version is already in Chrome) > > Those measures indicate how bad a problem 6to4 creates. No. The 20% connect failure rate shows how bad AUTOMATIC 6to4 is. It show NOTHING about how bad 6to4 itself is. As for longer RTT that is something people accept as part of using 6to4. I know I accept that they are there for the trans Pacific tunnel I use. As for high failure rates. EDNS (RFC 2671) had/has a similar or higher failure rates with any UDP packets that are bigger that 512 bytes or UDP packets that get fragmented or packets that have a OPT record in the additional section or have DO (RFC 3225) set in the OPT record. Firewalls are a pain in the proverbial but we don't stop attempting to use EDNS because they are there. Nameservers tailor their queries to to work around firewalls (happy eyeballs) and log that they needed to use the workarounds. > If we're going to th > e trouble of coming up with all these measures, there seems to be a good case > for 6to4 to Historic, which would be a steer to implementors to no longer in > clude 6to4 support at all. I do agree however that the most important point > is publishing the -advisory text. As for the counter measures, some of them need to be there independently of 6to4. Google Chome was the only brower that could reach www.ietf.org in a timely manner from any dual stack client connecting via Hurricane Electric for half of last week. The noc @HE responded to the issue within 1/2 a hour of it being raised via email by raising a trouble ticket with AT&T. It still took 2-3 days for the problem to be fixed. > As a provider of a (not large) enterprise, I know that a fraction of 1% of co > nnections to our site suffer a 10 second+ delay to a dual-stack web site wher > e they suffer no delay to an IPv4-only one. Which for the most part wouldn't be there if 6to4 required explicit configuration. > There's no way to know for sure > how much of that 'IPv6 brokenness' is 6to4, but measures (a), (b), and (c) sh > ould minimise that figure. Having said that, less than 1% of users who conne > ct to our site over IPv6 use 6to4, so we wouldn't be aggrieved to see it disa > ppear in terms of loss of users, as those users could almost certainly still > reach us over IPv4. Our own users who want IPv6 connectivity when offsite us > e tunnel brokers, which provide a much better (and more predictable) service, > one that also works from behind a NAT, which in the reality of home, hotel, > and other hotspot networks is quite important. > > As for operators 'fixing' 6to4, well, I'd rather see operators invest that ef > fort in deploying IPv6, rather than making 6to4 work better, for some value o > f 'better'. The fixes for 6to4 are deploying suitable sized 6to4 relay boxes and removing protocol 41 filters once the isp has some IPv6 connectivity. The time and effort required to do this is minimal compared to the time and effort required to deploy IPv6 to all of its customers. Remember you don't need to bill for this as the billing is already taken care of with IPv4. You don't need to do address assignments as they are taken care of with IPv4. > Tim > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From geier@geier.ne.tz Sun Jul 3 22:52:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A8221F862F for ; Sun, 3 Jul 2011 22:52:37 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id My19OZB7d0HL for ; Sun, 3 Jul 2011 22:52:36 -0700 (PDT) Received: from tih.co.tz (a.mx.tih.co.tz [217.172.181.156]) by ietfa.amsl.com (Postfix) with ESMTP id 819F321F8630 for ; Sun, 3 Jul 2011 22:52:33 -0700 (PDT) Received: from [127.0.0.1] ([::ffff:41.221.32.130]) (AUTH: LOGIN geier@tih.co.tz, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by tih.co.tz with esmtp; Mon, 04 Jul 2011 07:52:30 +0200 id 002C811B.4E11551E.000041DB Message-ID: <4E11551F.10800@geier.ne.tz> Date: Mon, 04 Jul 2011 08:52:31 +0300 From: Frank Habicht User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: v6ops@ietf.org References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703111047.GB2304@Space.Net> In-Reply-To: <20110703111047.GB2304@Space.Net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 05 Jul 2011 06:39:23 -0700 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 05:52:37 -0000 On 7/3/2011 2:10 PM, Gert Doering wrote: > On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: >> There's clearly a lack of consensus to support it. > > There's two very vocal persons opposing it and a much larger number of > people that support it, but have not the time to write a similarily > large amount of e-mails. For me, this is enough for "rough consensus". > > (And I second everything Lorenzo, Randy and Cameron said - there's > theoretical possibilities, and real world. 6to4 fails the real-world > test. Get over it, instead of attacking people that run real-world > networks for the decisions they need to do to keep the networks running > in a world without enough IPv4 addresses). > > Gert Doering > -- Operator +1 Frank Habicht, Operator. From v6ops@globis.net Tue Jul 5 06:38:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EA721F85F0 for ; Tue, 5 Jul 2011 06:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4Ow21Uba1Ow for ; Tue, 5 Jul 2011 06:38:37 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6F321F86C3 for ; Tue, 5 Jul 2011 06:38:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 98D0F87007D; Tue, 5 Jul 2011 15:38:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmOqJ7c4plJ0; Tue, 5 Jul 2011 15:38:00 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E187C870021; Tue, 5 Jul 2011 15:38:00 +0200 (CEST) Message-ID: <4E1313B8.8060006@globis.net> Date: Tue, 05 Jul 2011 15:38:00 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "v6ops@ietf.org WG" , lizhenqiang@chinamobile.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 05 Jul 2011 06:39:23 -0700 Subject: Re: [v6ops] new draft: draft-li-v6ops-load-balancing-requirement-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 13:38:38 -0000 Thanks for sharing your draft with us. I think you may be missing a whole class of bottleneck that is not receiving too much attention at the moment. Many enterprises transport the majority of their traffic over the boundary between their 'private' internal networks and the Internet via use of a "web proxy." Application Level Gateways (ALG) = RFC2766 Section 2.4 are also considered a valid translation mechanism between IPv4 and IPv6 islands, and can be especially useful for simple outbound HTTP based web traffic. They may also be useful for translating certain inbound requests. Traditionally the WCCP Web Cache Proxy Protocol (non IETF protocol, but described in http://tools.ietf.org/html/draft-wilson-wrec-wccp-v2-01) has been used to balance requests between multiple proxies, or for example between an IPv4 router and a farm of multiple WAN acceleration devices. AFAIK WCCPv2 does not (yet) support IPv6, which IMHO is quite an omission in the options given to enterprises to migrate to IPv6 in a smooth manner. regards, and good luck with your deployment, RayH From moore@network-heretics.com Sun Jul 3 19:36:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966B89E8005; Sun, 3 Jul 2011 19:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOpiePPrjxdJ; Sun, 3 Jul 2011 19:36:53 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id EB8031F0C39; Sun, 3 Jul 2011 19:36:52 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id B1BB82122B; Sun, 3 Jul 2011 22:36:50 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 03 Jul 2011 22:36:50 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=BbYL0HomHjjNRzJd8LZ1Xnaa1hw=; b=UfzH4cWgMSo+NRDHvvoSB5JyGWTG3Vpc/xaIjdwZ8sWTSjPI347dAkwl9MK0atO8/aDrycjiwj0P9E6IQQG6D8fmSDCDkKdmRRZuHYR1aPbsafwX2Hxy8HZg+LK2++2cVKbwRYQb+TnOot0Wf+4dQVvt/Ds9PJ2SkdVQUepBCl0= X-Sasl-enc: MPkGfPJXw1M79Q6Rvrqdbv+KvZUFFtI9dHeYfeMnW5Uo 1309747010 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id BABE8400E38; Sun, 3 Jul 2011 22:36:49 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3507F3A@EMBX01-WF.jnpr.net> Date: Sun, 3 Jul 2011 22:36:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4E80A8E8-7B29-426B-BB43-8FC269330E4B@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507F3A@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 05 Jul 2011 06:39:28 -0700 Cc: "v6ops@ietf.org" , IETF Discussion Subject: [v6ops] 6to4 to Experimental? (was: Re: draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 02:36:53 -0000 On Jul 3, 2011, at 4:57 PM, Ronald Bonica wrote: > Folks, >=20 > I think that I get it. There is no IETF consensus regarding the = compromise proposed below. So, at very least, we will have to abandon = the compromise. >=20 > Right now, the only alternative that I see is to reintroduce = draft-ietf-v6ops-6to4-to-historic and let the appeal process run its = course. I hate to do this, because the appeals process can be an = incredible time sync and distraction. If anybody sees another = alternative, please propose it. >=20 > Ron > The alternative that I proposed to IESG and to the chairs (and never = received any feedback about) was to reclassify 6to4 as Experimental. = Experimental seems completely appropriate for a protocol that is useful, = but only in corner cases. And I think it's also appropriate and useful = to try to learn from the experience with 6to4, even if we realize that = 6to4 will never be a generally applicable IPv6 transition solution = again. And maybe, just maybe, Experimental will be enough of a "slap" at 6to4 = to mollify the "kill it yesterday" crowd. For one thing, it clearly = indicates that 6to4 is no longer a standard. But in order to quieten down the discussion here, I suggest that people = reply to me privately if they can't live with this. If I get lots of = those replies, I'll know that it's not worth pursuing. Keith From fred@cisco.com Tue Jul 5 06:55:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28D821F8730 for ; Tue, 5 Jul 2011 06:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2kOSbFDvIN7 for ; Tue, 5 Jul 2011 06:55:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 3A26421F85FF for ; Tue, 5 Jul 2011 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=145; q=dns/txt; s=iport; t=1309874101; x=1311083701; h=date:from:message-id:to:subject:cc; bh=gglKfE0zipwp5Zca6QVRrhFsEH0iKcT9GjiFHGJbI6Y=; b=gyrVk4F64h8cgi5/x5U8wJoCR7n3hpmJMh4x7Uwx40+CzkW4vA58jCNA iBUiEV78EOx1XVjhlcDQWKfGEVjmqNECLEh0t0JbEqzd13odn6IGThnu6 S9nbfEyHz43ORm4TKixGqeJevmTK/En4NrsIKR4NFAjjEO1wZORUcBaxy 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkKAFMXE06rRDoG/2dsb2JhbABTmQgBAY51d60cnWyGNgSHP5tN X-IronPort-AV: E=Sophos;i="4.65,479,1304294400"; d="scan'208";a="361333616" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2011 13:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p65Dt0f6005271; Tue, 5 Jul 2011 13:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p65Dt0g18666; Tue, 5 Jul 2011 06:55:00 -0700 (PDT) Date: Tue, 5 Jul 2011 06:55:00 -0700 (PDT) From: Message-Id: <201107051355.p65Dt0g18666@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-chen-v6ops-ipv6-bearer-network-trials@tools.ietf.org Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-bearer-network-trials-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 13:55:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-chen-v6ops-ipv6-bearer-network-trials. Please take a look at it and comment. From fred@cisco.com Tue Jul 5 06:55:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C7721F873B for ; Tue, 5 Jul 2011 06:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHEw+DYetsM2 for ; Tue, 5 Jul 2011 06:55:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 275D721F85FE for ; Tue, 5 Jul 2011 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=142; q=dns/txt; s=iport; t=1309874101; x=1311083701; h=date:from:message-id:to:subject:cc; bh=W8roQpxdnEbiFjVLXsi9Z19hHNe6k633C77eEnektp0=; b=MQ8GQ7Ylx37qmaOMPToVHV9tlz9LBI7onKjZOhpWZJtXGv79KKoDtF1u kydvtC/ta9kOArEh1FguTzND45bUb10ioZhrRG9dxXkx8rAW9poPyRILd Lf7qN/vkb9a/1EWtTXXzFL/e4Tt4OjqxXyYwy2il9YRaTh1t2XMHKSfKk 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkKAFMXE06rRDoG/2dsb2JhbABTmQgBAY51d60cnWyGNgSHP5tN X-IronPort-AV: E=Sophos;i="4.65,479,1304294400"; d="scan'208";a="361333614" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2011 13:55:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p65Dt0vV005270; Tue, 5 Jul 2011 13:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p65Dt0V18672; Tue, 5 Jul 2011 06:55:00 -0700 (PDT) Date: Tue, 5 Jul 2011 06:55:00 -0700 (PDT) From: Message-Id: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-hilliard-v6ops-ipv6-discard-prefix@tools.ietf.org Subject: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 13:55:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix. Please take a look at it and comment. From fred@cisco.com Tue Jul 5 06:55:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9F521F85FF for ; Tue, 5 Jul 2011 06:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmIHXxjLX39e for ; Tue, 5 Jul 2011 06:55:01 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id 41A9D21F871F for ; Tue, 5 Jul 2011 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=142; q=dns/txt; s=iport; t=1309874101; x=1311083701; h=date:from:message-id:to:subject:cc; bh=DU2/QUjJAnAapvpqSuJ5nTrtoUnbH1YE/XwWOOaaXnA=; b=mA/+MPaZQ5e7Skcf3+PSlftf88747pYub1lAfHQmURADpCddSXcSGabo +baa8aCuypsRyacFHTzZQmJlPbcF99cMSxtnh6e6kZ6Ck9hnlf0d6XwBJ +ee665lNLODrJWtYvIpZJL0yyptcuu6CfuDF61Vb6sDEB5KTdzxsxGf6J I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkKADAXE06rRDoI/2dsb2JhbABTmQgBAY51d60UnWyGNgSHP5tN X-IronPort-AV: E=Sophos;i="4.65,479,1304294400"; d="scan'208";a="290252607" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-4.cisco.com with ESMTP; 05 Jul 2011 13:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p65Dt08j031495; Tue, 5 Jul 2011 13:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p65Dt0g18669; Tue, 5 Jul 2011 06:55:00 -0700 (PDT) Date: Tue, 5 Jul 2011 06:55:00 -0700 (PDT) From: Message-Id: <201107051355.p65Dt0g18669@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-chown-v6ops-address-accountability@tools.ietf.org Subject: [v6ops] new draft: draft-chown-v6ops-address-accountability-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 13:55:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-chown-v6ops-address-accountability. Please take a look at it and comment. From jnc@mercury.lcs.mit.edu Tue Jul 5 07:44:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46F621F860A; Tue, 5 Jul 2011 07:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDNQ-k9j00Be; Tue, 5 Jul 2011 07:44:31 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id EF3F121F85F5; Tue, 5 Jul 2011 07:44:30 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id DDFE218C10A; Tue, 5 Jul 2011 10:44:29 -0400 (EDT) To: ietf@ietf.org, v6ops@ietf.org Message-Id: <20110705144429.DDFE218C10A@mercury.lcs.mit.edu> Date: Tue, 5 Jul 2011 10:44:29 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 14:44:32 -0000 > From: Ronald Bonica >>> I think that I get it. There is no IETF consensus regarding the >>> compromise proposed below. ... >> But there is no rough consensus to do that either. > That is the claim of an appeal on the table. Let's run the appeal > process and figure out whether that claim is valid. Sorry, this makes no sense. You can't go ahead with draft-ietf-v6ops-6to4-to-historic if there is no basic consensus in the IETF as a whole to do so - and your previous declaration (on Saturday) basically accepted that there was no such basic consensus (otherwise why withdraw the ID). So now there is going to be a reversal, and the document is going to go ahead - i.e. you must now be taking the position that there _is_ basic consensus in the IETF (without which you could not proceed the ID). The effect of this sort of thing on the reputation of I* should be obvious to all. Noel From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jul 5 07:56:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790E511E81F9 for ; Tue, 5 Jul 2011 07:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXqZfqHm3ObB for ; Tue, 5 Jul 2011 07:56:54 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id AA67B11E810F for ; Tue, 5 Jul 2011 07:56:29 -0700 (PDT) Received: from 182-239-205-173.ip.adam.com.au ([182.239.205.173] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qe72y-0002Ub-QI; Wed, 06 Jul 2011 00:26:20 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 07BEF3B341; Wed, 6 Jul 2011 00:26:20 +0930 (CST) Date: Wed, 6 Jul 2011 00:26:19 +0930 From: Mark Smith Message-ID: <20110706002619.39b94073@opy.nosense.org> In-Reply-To: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-hilliard-v6ops-ipv6-discard-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 14:56:55 -0000 Hi, On Tue, 5 Jul 2011 06:55:00 -0700 (PDT) wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix. Please take a look at it and comment. I'm for this. I'm not sure about a /32, as it is very large considering the purpose. Perhaps the /32 could be generally reserved for purposes similar to this, and then the first /48 from with in it used for this specific purpose. Even a /48 seems excessive for this specific purpose, but in IPv6 that's pretty "small" and cheap. Also a bit more explanation of why the following are SHOULD NOT's rather than MUST NOT's might be useful. Is it to allow for the case where the third party AS is performing DoS traffic analysis? That's the only possibility I can think of right now. " The assignment SHOULD NOT be announced to third party autonomous systems and IPv6 traffic with an destination address within this prefix SHOULD NOT be forwarded to third party autonomous systems." Regards, Mark. From rbonica@juniper.net Tue Jul 5 08:07:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F35B11E820E; Tue, 5 Jul 2011 08:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fI4iCOFAtXt; Tue, 5 Jul 2011 08:07:53 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 757DF11E820A; Tue, 5 Jul 2011 08:07:48 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKThMowztdvlvk2XyYYlZxBq+jbMrp+jrv@postini.com; Tue, 05 Jul 2011 08:07:50 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 5 Jul 2011 08:06:28 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 5 Jul 2011 11:06:27 -0400 From: Ronald Bonica To: Noel Chiappa , "ietf@ietf.org" , "v6ops@ietf.org" Date: Tue, 5 Jul 2011 11:06:26 -0400 Thread-Topic: draft-ietf-v6ops-6to4-to-historic Thread-Index: Acw7Ig2WKjysH42vSV2T3QH35x31TQAASRQQ Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3508430@EMBX01-WF.jnpr.net> References: <20110705144429.DDFE218C10A@mercury.lcs.mit.edu> In-Reply-To: <20110705144429.DDFE218C10A@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 15:07:55 -0000 Noel, I didn't say that I was going to push draft-ietf-v6ops-6to4-to-historic thr= ough without running the process. I said that draft-ietf-v6ops-6to4-to-hist= oric has made it all the way past IESG approval. There is an appeal on the = table (at the WG level) questioning whether draft-ietf-v6ops-6to4-to-histor= ic ever had WG consensus. We will run the appeal process. If the WG chairs = cannot justify WG consensus, draft-ietf-v6ops-6to4-to-historic stops dead i= n its tracks. If they can justify WG consensus, the appellant can escalate = the appeal to the IESG (and to the IAB after that). If the appeal succeeds = at any level, draft-ietf-v6ops-6to4-to-historic is not published. Ron -----Original Message----- From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 Sent: Tuesday, July 05, 2011 10:44 AM To: ietf@ietf.org; v6ops@ietf.org Cc: jnc@mercury.lcs.mit.edu Subject: RE: draft-ietf-v6ops-6to4-to-historic > From: Ronald Bonica >>> I think that I get it. There is no IETF consensus regarding the >>> compromise proposed below. ... >> But there is no rough consensus to do that either. > That is the claim of an appeal on the table. Let's run the appeal > process and figure out whether that claim is valid. Sorry, this makes no sense. You can't go ahead with draft-ietf-v6ops-6to4-to-historic if there is no basic consensus in the IETF as a whole to do so - and your previous declaration (on Saturday) basically accepted that there was no such basic consensus (otherwise why withdraw the ID). So now there is going to be a reversal, and the document is going to go ahe= ad - i.e. you must now be taking the position that there _is_ basic consensus = in the IETF (without which you could not proceed the ID). The effect of this sort of thing on the reputation of I* should be obvious to all. Noel From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jul 5 08:08:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF4311E8139; Tue, 5 Jul 2011 08:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.604 X-Spam-Level: X-Spam-Status: No, score=0.604 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgGm6QQanhng; Tue, 5 Jul 2011 08:08:20 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1E511E821B; Tue, 5 Jul 2011 08:08:17 -0700 (PDT) Received: from 182-239-205-173.ip.adam.com.au ([182.239.205.173] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qe7EW-0002hp-N3; Wed, 06 Jul 2011 00:38:16 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 556543B341; Wed, 6 Jul 2011 00:38:16 +0930 (CST) Date: Wed, 6 Jul 2011 00:38:16 +0930 From: Mark Smith Message-ID: <20110706003816.76531ca8@opy.nosense.org> In-Reply-To: <20110705144429.DDFE218C10A@mercury.lcs.mit.edu> References: <20110705144429.DDFE218C10A@mercury.lcs.mit.edu> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 15:08:21 -0000 Just remember kids, disagreeing is not attacking. accusing them of attacking when all they're doing is disagreeing is an attack on them. don't assume people have no real world experience or responsibilities if they choose not to announce to the world their job title or their affiliations in their emails. =E2=90=84 From fred@cisco.com Tue Jul 5 12:38:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265E321F85E1 for ; Tue, 5 Jul 2011 12:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsY5DegzqaaP for ; Tue, 5 Jul 2011 12:38:00 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8CD21F85E0 for ; Tue, 5 Jul 2011 12:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1008; q=dns/txt; s=iport; t=1309894680; x=1311104280; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=G/vgvrEsDib6/xtkk4s6jDgtYZR1y4iYpBMbzYIz5Hk=; b=GMRN9ALiMyWkA1KG1cSXewfgV8ZdRd/piZns/4tt3SbQ7cFM9wLompU2 C+lxLKTNkHJ6Cd4QrXoJOxKbCIa4gBeUAmY24dbnrhxSYBxGmr6ubawnh 2iOCku/YabRYfhk+aOcM7UqR3C0IwInlsedvKBSo8APiohq7Nk5/wL5km U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskHAAdnE06rRDoH/2dsb2JhbABTmRGOd3eIeqR9ngmGNgSHP4p3hHiLXg X-IronPort-AV: E=Sophos;i="4.65,481,1304294400"; d="scan'208";a="361649095" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2011 19:37:59 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p65JbxDA008318; Tue, 5 Jul 2011 19:37:59 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 05 Jul 2011 12:37:59 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 05 Jul 2011 12:37:59 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <20110706002619.39b94073@opy.nosense.org> Date: Tue, 5 Jul 2011 12:37:51 -0700 Message-Id: <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> To: draft-hilliard-v6ops-ipv6-discard-prefix@tools.ietf.org X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 19:38:02 -0000 On Jul 5, 2011, at 7:56 AM, Mark Smith wrote: >> A new draft has been posted, at = http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix. = Please take a look at it and comment. >=20 > I'm for this. >=20 > I'm not sure about a /32, as it is very large considering the purpose. Hmm. Dumb question. We're looking for a way to implement something akin = to ipv6 route
Null0 ipv6 route
with the latter being distributed in a routing protocol. In IPv4, we use 127.0.0.0/8 as a localhost prefix, and specifically = 127.0.0.1/32 as localhost. This was variously implemented; some used the = prefix and some the address. In IPv6, we flipped the coin, and it came = up ::1 as localhost. Is there any substantive reason to not define ::2 as "discard"? It could = be implemented as simply as ipv6 route ::2/128 Null0 ipv6 route ::2 on existing systems, and in future systems could be programmed in the = same way ::1 is.= From jhw@apple.com Tue Jul 5 12:48:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B5B21F88BD for ; Tue, 5 Jul 2011 12:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.599 X-Spam-Level: X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5BZI7a3wNQm for ; Tue, 5 Jul 2011 12:47:59 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id C5F8421F88AA for ; Tue, 5 Jul 2011 12:47:59 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LNV000WILNXYN31@mail-out.apple.com> for v6ops@ietf.org; Tue, 05 Jul 2011 12:47:57 -0700 (PDT) X-AuditID: 11807134-b7c71ae0000014d0-7d-4e1369fb1361 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id A1.05.05328.BF9631E4; Tue, 05 Jul 2011 12:46:03 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNV00490LNXTW40@kencur.apple.com> for v6ops@ietf.org; Tue, 05 Jul 2011 12:47:57 -0700 (PDT) From: james woodyatt In-reply-to: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> Date: Tue, 05 Jul 2011 12:47:57 -0700 Message-id: <4D8CA238-E550-4B4A-81C4-1740CC288878@apple.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUiON1OTfd3prCfwel1Uhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpquX4wFq9gqJh/+wdrA2M3axcjJISFgIjH5ywIWCFtM4sK9 9WxdjFwcQgLtTBLvP/9gA0nwCghK/Jh8D6iIg4NZQF7i4HlZkDCzgJbE90etLBD1U5gknh1f zQSSEBYwk/iy6DRYL5uAisS3y3fB4pwCPhI3N3Qyg9gsAqoS3zasYIQYpCHx+cYvFohdNhIv 3p0DqxcS8JZY3jsdzBYRUJd4vGoaG8Sh8hKLWz4zTmAUmIXkvFkI581Cct4CRuZVjIJFqTmJ lYYmeokFBTmpesn5uZsYQYHXUGiyg/HgT/5DjAIcjEo8vIEGwn5CrIllxZW5hxglOJiVRHgj LYBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEedUzuf2EBNITS1KzU1MLUotgskwcnFINjD0+LHYG qdy8IgvmXzgZ+spD+uZLhrWHXl2dyWultv/x4caZCRcfpMpO7lHNkzzEfdzBc9oPHquVm5ZZ P6zav7fUZSuTpEbyGzf54lJVy0/eISbf+033Smb+V+26lX9czGhRhkaLy+be7HOqP/ltN8xd 19/AbFQ0/2b37H+TmGUc/rypObTumhJLcUaioRZzUXEiAKUTkaY4AgAA Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 19:48:00 -0000 [distribution narrowed] On Jul 2, 2011, at 09:36 , Ronald Bonica wrote: > > - The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default. > > If anyone objects to this course of action, please speak up soon. Assuming the details are specified clearly to set the standard that seems to be the IETF consensus, which is to make this default configuration REQUIRED, i.e. what I-D.ietf-v6ops-6to4-advisory currently only recommends in all lower-case letters, then I can see how this will be a useful document for IETF to publish and I can support its development. -- james woodyatt member of technical staff, core os networking From jhw@apple.com Tue Jul 5 13:06:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02FC21F84EE for ; Tue, 5 Jul 2011 13:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.766 X-Spam-Level: X-Spam-Status: No, score=-106.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI+xvJDYX7Ri for ; Tue, 5 Jul 2011 13:06:15 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1227321F84E3 for ; Tue, 5 Jul 2011 13:06:15 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay12.apple.com ([17.128.113.53]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LNV008OWMCX12E0@mail-out.apple.com> for v6ops@ietf.org; Tue, 05 Jul 2011 13:06:05 -0700 (PDT) X-AuditID: 11807135-b7b76ae000001169-6a-4e136f284274 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay12.apple.com (Apple SCV relay) with SMTP id AB.AA.04457.82F631E4; Tue, 05 Jul 2011 13:08:08 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNV0020XMI4AQ60@cardamom.apple.com> for v6ops@ietf.org; Tue, 05 Jul 2011 13:06:04 -0700 (PDT) From: james woodyatt In-reply-to: <201107051355.p65Dt0g18669@ftpeng-update.cisco.com> Date: Tue, 05 Jul 2011 13:06:04 -0700 Message-id: References: <201107051355.p65Dt0g18669@ftpeng-update.cisco.com> To: draft-chown-v6ops-address-accountability@tools.ietf.org X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OVVcjX9jPYN4RXYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY3/3T5aCj+wVZyffY2tgXMXWxcjJISFgInHl/Q52CFtM4sK9 9UBxLg4hgVYmiVuf+1hAErwCghI/Jt8Dsjk4mAXkJQ6elwUJMwtoSXx/1MoCUT+LSWLftXOM IAlhAX+J2evfM4HYbAIqEt8u3wWzOQUcJB79WMYGModFQFXi+zNDiDkaEp9v/IJaZSPx9vg8 sDFCAvYST7Z1gsVFBKwlnlz5ywhxp7zE4pbPjBMYBWYhuW4WwnWzkFy3gJF5FaNgUWpOYqWh kV5iQUFOql5yfu4mRlDYNRSa7mB8tFD9EKMAB6MSD+9KI2E/IdbEsuLK3EOMEhzMSiK8kRZA Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxVjlx+QgLpiSWp2ampBalFMFkmDk6pBsaDAftOeW32 OX2iIGaTqUe3y27ryeKz976PNOjKLdD47pE3w+uY5DGefS6ZFi7s/fK/DqRvf5mbfLl4y9eV PXcW/V0XmW8cXSWd93dJTsRvx1AX3Tfv5u8vba699Pi8gMwJ52vu0nGuRl85NR9xe4TwMiTO zzL4Lj93Hh/LXcsVi8zez33SsFeJpTgj0VCLuag4EQA1ITolNwIAAA== Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-chown-v6ops-address-accountability-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 20:06:16 -0000 On Jul 5, 2011, at 06:55 , fred@cisco.com wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-chown-v6ops-address-accountability. Please take a look at it and comment. This is a useful draft, and I could support its adoption as a working group item. In section 2.3, the draft says this: While it is possible to craft IPv6 Router Advertisements that give 'hints' to hosts that DHCPv6 should be used ('M' bit set), there is no obligation on the host to honour that hint, or to not use privacy addressing as well. What about leaving the Autonomous flag in the Prefix-Information option unset? Section 5.5.3 of RFC 4862 specifies how hosts are to ignore Prefix-Information options without the Autonomous flag set when creating global addresses with stateless autoconfiguration, and section 3.3 of RFC 4941 explicitly references the relevant passage in RFC 4862. -- james woodyatt member of technical staff, core os networking From msk@cloudmark.com Tue Jul 5 13:39:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBA321F88F3; Tue, 5 Jul 2011 13:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.182 X-Spam-Level: X-Spam-Status: No, score=-103.182 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYfhJ2Rc1UiZ; Tue, 5 Jul 2011 13:39:28 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 77EAB21F88EF; Tue, 5 Jul 2011 13:39:28 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 5 Jul 2011 13:39:28 -0700 From: "Murray S. Kucherawy" To: IPv6 Operations , IETF Discussion Date: Tue, 5 Jul 2011 13:39:26 -0700 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic Thread-Index: Acw5t9BcScQ/ldurRnmLU7pMDnEQ1QBmzmaA Message-ID: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <20110703112048.4a3c7111@opy.nosense.org> <4E0FD788.3000305@dougbarton.us> <20110703131913.28142ec0@opy.nosense.org> <100DA5A2-0276-45B8-A8CD-AB7B0D947AC4@network-heretics.com> <746A967B-16AF-4428-8424-298AF8001F87@network-heretics.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F134EBC4B84EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 20:39:29 -0000 --_000_F5833273385BB34F99288B3648C4F06F134EBC4B84EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I shudder to think that this is a prerequisite for declaring something Hist= oric. If some RFC meant to solve some problem turns out not only to be a bad idea= but also shows that the problem itself is essentially intractable, I don't= think it's practical at all to require a replacement before declaring the = RFC Historic. From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of K= eith Moore Sent: Sunday, July 03, 2011 12:31 PM To: Arturo Servin Cc: IPv6 Operations; IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic Honestly I'd be happy to declare 6to4 Historic if we had a suitable replace= ment - one that could be automatically configured by hosts, used by applica= tions, and worked better than 6to4 in most cases. I don't think it exists = yet. [...] Keith --_000_F5833273385BB34F99288B3648C4F06F134EBC4B84EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I shudder to think that this is a prerequisite for declaring som= ething Historic.

&nbs= p;

If some RFC meant to solve s= ome problem turns out not only to be a bad idea but also shows that the pro= blem itself is essentially intractable, I don’t think it’s prac= tical at all to require a replacement before declaring the RFC Historic.

 

=

From: v6ops-bounces@ietf.org [mailt= o:v6ops-bounces@ietf.org] On Behalf Of Keith Moore
Sent: S= unday, July 03, 2011 12:31 PM
To: Arturo Servin
Cc: IPv= 6 Operations; IETF Discussion
Subject: Re: [v6ops] draft-ietf-v6o= ps-6to4-to-historic

<= o:p> 

Honestly I'd be happy to decl= are 6to4 Historic if we had a suitable replacement - one that could be auto= matically configured by hosts, used by applications, and worked better than= 6to4 in most cases.  I don't think it exists yet.  

 

[…]

<= /div>

 

Keith

 

= --_000_F5833273385BB34F99288B3648C4F06F134EBC4B84EXCHC2corpclo_-- From internet-drafts@ietf.org Tue Jul 5 16:40:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C88521F87D1; Tue, 5 Jul 2011 16:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x1iHdo674bP; Tue, 5 Jul 2011 16:40:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C6E21F87B5; Tue, 5 Jul 2011 16:40:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110705234041.598.36587.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 16:40:41 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 23:40:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : IPv6 in 3GPP Evolved Packet System Author(s) : Jouni Korhonen Jonne Soininen Basavaraj Patil Teemu Savolainen Gabor Bajko Kaisu Iisakkila Filename : draft-ietf-v6ops-3gpp-eps-02.txt Pages : 34 Date : 2011-07-05 Use of data services in smart phones and broadband services via HSPA and HSPA+, in particular Internet services, has increased rapidly and operators that have deployed networks based on 3GPP network architectures are facing IPv4 address shortages at the Internet registries and are feeling a pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-02.txt From jouni.nospam@gmail.com Tue Jul 5 16:44:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D62321F8891 for ; Tue, 5 Jul 2011 16:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OZbHk5Fsckr for ; Tue, 5 Jul 2011 16:44:34 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9F721F888E for ; Tue, 5 Jul 2011 16:44:34 -0700 (PDT) Received: by bwb17 with SMTP id 17so6185531bwb.31 for ; Tue, 05 Jul 2011 16:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=dr8y7Zqsgkragvo3mszybP2Gggeh+Bo0UL0uIPRGG1w=; b=yGXf90jRRaNn8Cm1dvR5gG52lFTp1R7s+SDnuP81sA/5s1XJFurTLsOkzVrRyt8eR9 r8Bwkk1HCRow64qkchkShDsJVoNMUXAtJXvM5+OpixsCQxKfiRirt+QM2Wv0WN8yYQ7C GGmvwE2rfp1sLAWmBCPtMTE7LD/PUE8G8N5uM= Received: by 10.204.26.141 with SMTP id e13mr7586102bkc.64.1309909470333; Tue, 05 Jul 2011 16:44:30 -0700 (PDT) Received: from a88-114-68-210.elisa-laajakaista.fi (a88-114-68-210.elisa-laajakaista.fi [88.114.68.210]) by mx.google.com with ESMTPS id lb15sm814893bkb.13.2011.07.05.16.44.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 16:44:29 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2011 02:44:27 +0300 References: <20110705234041.598.37576.idtracker@ietfa.amsl.com> To: IPv6 Operations Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [v6ops] Fwd: New Version Notification - draft-ietf-v6ops-3gpp-eps-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 23:44:35 -0000 FYI.. the revision -02 should address all the comments we received (and = we thought were useful to address).=20 - Jouni Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 6, 2011 2:40:41 AM GMT+03:00 > To: v6ops-chairs@tools.ietf.org, = draft-ietf-v6ops-3gpp-eps@tools.ietf.org, rbonica@juniper.net > Subject: New Version Notification - draft-ietf-v6ops-3gpp-eps-02.txt >=20 > New version (-02) has been submitted for = draft-ietf-v6ops-3gpp-eps-02.txt. > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-02.txt >=20 >=20 > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-3gpp-eps-02 >=20 > IETF Secretariat. From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jul 5 17:13:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BCD21F862B for ; Tue, 5 Jul 2011 17:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymZLmdk4JMYl for ; Tue, 5 Jul 2011 17:13:14 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id E2EBB21F850A for ; Tue, 5 Jul 2011 17:13:13 -0700 (PDT) Received: from 182-239-205-173.ip.adam.com.au ([182.239.205.173] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QeFjn-0006HD-22; Wed, 06 Jul 2011 09:43:07 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 34F973B33E; Wed, 6 Jul 2011 09:43:06 +0930 (CST) Date: Wed, 6 Jul 2011 09:43:04 +0930 From: Mark Smith To: Fred Baker Message-ID: <20110706094304.7eb9c225@opy.nosense.org> In-Reply-To: <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , draft-hilliard-v6ops-ipv6-discard-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 00:13:15 -0000 Hi Fred, On Tue, 5 Jul 2011 12:37:51 -0700 Fred Baker wrote: > > On Jul 5, 2011, at 7:56 AM, Mark Smith wrote: > > >> A new draft has been posted, at http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix. Please take a look at it and comment. > > > > I'm for this. > > > > I'm not sure about a /32, as it is very large considering the purpose. > > Hmm. Dumb question. We're looking for a way to implement something akin to > > ipv6 route
Null0 > ipv6 route
> > with the latter being distributed in a routing protocol. > > In IPv4, we use 127.0.0.0/8 as a localhost prefix, and specifically 127.0.0.1/32 as localhost. This was variously implemented; some used the prefix and some the address. In IPv6, we flipped the coin, and it came up ::1 as localhost. > > Is there any substantive reason to not define ::2 as "discard"? It could be implemented as simply as > > ipv6 route ::2/128 Null0 > ipv6 route ::2 > > on existing systems, and in future systems could be programmed in the same way ::1 is. I think having a standard preconfigured and generic discard address would be useful, and ::2 would be a pretty good choice. One thought I'd had was that this may not suit people who also would want to implement one or more DoS traffic analysis sink hole routers. I hadn't investigated how that was done too thoroughly (i.e. read RFC3882 properly), I'd thought the routing trick they would be using was to inject the sink hole router's host route into the routing domain as well, taking advantage of recursive route resolution to draw the traffic towards the sink router announcing the discard host route. I've done something similar in the past to cover an interim period where the sink static route wasn't present on all routers. The routers that have the discard host route anycast it into the routing domain, so that DoS traffic was forwarded towards the closest one by the routers that didn't have it, when they received a iBGP route with the NEXT_HOP set to the anycast discard address. So in addition to having ::2 as a well known and preconfigured discard address, I think there still could be some reasons to have a reserved prefix with a number of addresses that can be used as discard host routes. As a side note relating to the 127/8 verses ::1 choice, I've come across an occasion where having a loopback prefix rather than an individual address available was useful. It was so long ago that I can't remember exactly what I was doing, however I do remember that it was inspired by ntpd's trick of having reference clocks listen on addresses within 127/8 e.g. - http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver8.html http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver6.html So if there is enough value in that sort of thing, perhaps ::/64 could be reserved for loopback addresses, and 0:0:0:2::/64 reserved for these discard addresses, with 0:0:0:2::1/128 being a well known and preconfigured one. Regards, Mark. From mrex@sap.com Tue Jul 5 17:54:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6613521F87F9; Tue, 5 Jul 2011 17:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2x6Y165dF1V; Tue, 5 Jul 2011 17:54:38 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A04D821F87CC; Tue, 5 Jul 2011 17:54:37 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p660sT3V020939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jul 2011 02:54:34 +0200 (MEST) From: Martin Rex Message-Id: <201107060054.p660sTMl017973@fs4113.wdf.sap.corp> To: gert@space.net (Gert Doering) Date: Wed, 6 Jul 2011 02:54:29 +0200 (MEST) In-Reply-To: <20110703111047.GB2304@Space.Net> from "Gert Doering" at Jul 3, 11 01:10:47 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: v6ops@ietf.org, moore@network-heretics.com, ietf@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 00:54:38 -0000 Gert Doering wrote: > > On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: > > There's clearly a lack of consensus to support it. > > There's two very vocal persons opposing it There were more than two clearly opposing, and there is no need to further fuel the heated discussion by everyone becoming as vocal as Keith. The pain point is really the unnecessarily aggressive "kill what we don't like" move-to-historic action. This is a procedural issue, not a matter of personal taste. There was an alternative reclassification suggested, that could gather rough consensus. I'm still waiting for a *clean* resolution of the procedural issue (that means serious consideration of suggested alternatives). -Martin From randy@psg.com Tue Jul 5 18:39:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC69421F87F0; Tue, 5 Jul 2011 18:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUog4cb+UM9t; Tue, 5 Jul 2011 18:39:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5524321F87EA; Tue, 5 Jul 2011 18:39:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QeH52-0004Fu-Gf; Wed, 06 Jul 2011 01:39:08 +0000 Date: Wed, 06 Jul 2011 10:39:07 +0900 Message-ID: From: Randy Bush To: Martin Rex In-Reply-To: <201107060054.p660sTMl017973@fs4113.wdf.sap.corp> References: <20110703111047.GB2304@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: v6ops@ietf.org, ietf@ietf.org, moore@network-heretics.com Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 01:39:18 -0000 > The pain point is really the unnecessarily aggressive "kill what we > don't like" move-to-historic action. if we killed everything i do not like, there would be lot fewer rfcs. :) what people are saying is kill it because it is broken, bad, and does a dis-service to ipv6. randy From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Jul 5 18:55:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C54021F886B for ; Tue, 5 Jul 2011 18:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.762 X-Spam-Level: X-Spam-Status: No, score=-0.762 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBg20fatyGKk for ; Tue, 5 Jul 2011 18:55:18 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id A202321F886A for ; Tue, 5 Jul 2011 18:55:18 -0700 (PDT) Received: from 182-239-205-173.ip.adam.com.au ([182.239.205.173] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QeHKa-0002Qd-7E; Wed, 06 Jul 2011 11:25:12 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id ABAF63B33E; Wed, 6 Jul 2011 11:25:11 +0930 (CST) Date: Wed, 6 Jul 2011 11:25:11 +0930 From: Mark Smith To: Mark Smith Message-ID: <20110706112511.7f944129@opy.nosense.org> In-Reply-To: <20110706094304.7eb9c225@opy.nosense.org> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <20110706094304.7eb9c225@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , draft-hilliard-v6ops-ipv6-discard-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 01:55:19 -0000 On Wed, 6 Jul 2011 09:43:04 +0930 Mark Smith wrote: > Hi Fred, > > > So if there is enough value in that sort of thing, perhaps ::/64 could > be reserved for loopback addresses, of course with ::/128 still being the unspecified address. > and 0:0:0:2::/64 reserved for > these discard addresses, with 0:0:0:2::1/128 being a well known and > preconfigured one. > > > Regards, > Mark. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ek@google.com Tue Jul 5 19:08:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C247621F872B for ; Tue, 5 Jul 2011 19:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ+BsOtbrZ65 for ; Tue, 5 Jul 2011 19:08:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C674D21F8725 for ; Tue, 5 Jul 2011 19:08:27 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p6628P41019335 for ; Tue, 5 Jul 2011 19:08:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309918106; bh=xGwM3erP4wxjvEIABytaeGKRYEM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=NsKeHtJ8K3g9/rOuTvAfoT/Vy2XFyeEMaYn2FnLgQzUn6HNw+AdzjwTX1O3SGJTKT KpsnFAnTKJyXrxa4+oqKw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=P818OCMsX/5J8YIX+3riaZ0qMGpr5hYkhO4pccb73+wANTLlUZlDWYhNJ6iS7Tsmu GYoHa90YUdoqy89+q21Kw== Received: from pvg18 (pvg18.prod.google.com [10.241.210.146]) by kpbe19.cbf.corp.google.com with ESMTP id p6628Oqn028292 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 5 Jul 2011 19:08:24 -0700 Received: by pvg18 with SMTP id 18so7878016pvg.10 for ; Tue, 05 Jul 2011 19:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0gJnpELWwqI30HIj7rqiJ8D+ETVPv7A/0E8RJI5cLu4=; b=NY9S3TsnYVgrcmZMDSFcThAj4fFUfK8gv+J6aL7k30rIEQbqCHWNUt08NeU96Scexz rzVjprr7S4b42yHzFhdw== MIME-Version: 1.0 Received: by 10.142.242.6 with SMTP id p6mr3652443wfh.96.1309918102551; Tue, 05 Jul 2011 19:08:22 -0700 (PDT) Received: by 10.142.179.17 with HTTP; Tue, 5 Jul 2011 19:08:22 -0700 (PDT) In-Reply-To: <20110706094304.7eb9c225@opy.nosense.org> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <20110706094304.7eb9c225@opy.nosense.org> Date: Wed, 6 Jul 2011 11:08:22 +0900 Message-ID: From: Erik Kline To: Mark Smith Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: IPv6 Operations , draft-hilliard-v6ops-ipv6-discard-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 02:08:28 -0000 > As a side note relating to the 127/8 verses ::1 choice, I've come > across an occasion where having a loopback prefix rather than an > individual address available was useful. It was so long ago that I > can't remember exactly what I was doing, however I do remember that it > was inspired by ntpd's trick of having reference clocks listen on > addresses within 127/8 e.g. - > > http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver8.html > > http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver6.html I have had similar need at times, and mentioned it once before on v6ops I think. Basically, when writing unittests for systems it's *really* handy to be able to bind each component to its own 127.0.0.x address and pretend you have a locally routed network. And, as you point out, even in regular operational scenarios it can be handy. There's a node-local multicast prefix, iirc, but only a single /128 for unicast. :/ From Dmitry.Anipko@microsoft.com Tue Jul 5 19:28:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1200A21F885F for ; Tue, 5 Jul 2011 19:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLhyPFBZvi53 for ; Tue, 5 Jul 2011 19:28:20 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id C520C21F885E for ; Tue, 5 Jul 2011 19:28:19 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Jul 2011 19:28:19 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 5 Jul 2011 19:28:19 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.201]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Tue, 5 Jul 2011 19:28:16 -0700 From: Dmitry Anipko To: Joel Jaeggli , "Templin, Fred L" Date: Tue, 5 Jul 2011 19:28:12 -0700 Thread-Topic: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? Thread-Index: Acw526CXwWm+1jXSSIWgJ/SR28dQHQBqFbLQ Message-ID: References: <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.com> <54E20C35-711A-48ED-9050-DA81C505EBDB@bogus.com> In-Reply-To: <54E20C35-711A-48ED-9050-DA81C505EBDB@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DD1A73D9E9C89144A927C5080F70285A01A7675A9E5DNAEXMSGS702_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 02:28:21 -0000 --_000_DD1A73D9E9C89144A927C5080F70285A01A7675A9E5DNAEXMSGS702_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joel, >>yeah, I think the question of do isatap implementers or users in v6ops f= ind this line of work interesting and useful is essentially the open questi= on thatwould cause us to consider advancing this as a wg document I think having a document with operational guidance for ISATAP would be use= ful and would support adoption of this document by the WG. Thank you, Dmitry From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of J= oel Jaeggli Sent: Sunday, July 03, 2011 4:38 PM To: Templin, Fred L Cc: v6ops@ietf.org Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? On Jul 1, 2011, at 3:54 PM, Templin, Fred L wrote: Hi Joel, Me again. There have have been others who have also expressed concerns about DHCPv6 and other "undocumented features" on ISATAP links, so I decided to split the document into two pieces. The new piece is now called: "ISATAP Updates" and I guess might be more appropriate for some other working group. The other piece retains the original name and is strictly about operational aspects of widely-deployed implementations: http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-12.txt What should we do next - ask the wg for comments? yeah, I think the question of do isatap implementers or users in v6ops fin= d this line of work interesting and useful is essentially the open question= thatwould cause us to consider advancing this as a wg document vs allowing= you to pursue it as an indivudal submission. I think that preaking shcpv6 = out of it is a wise idea. Thanks - Fred ________________________________ From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Templin, Fred L Sent: Wednesday, June 22, 2011 8:13 AM To: Joel Jaeggli Cc: v6ops@ietf.org Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? Hi Joel, Thanks for your comments, and see below for responses: ________________________________ From: Joel Jaeggli [mailto:joelja@bogus.com] Sent: Friday, June 17, 2011 12:50 PM To: Templin, Fred L Cc: v6ops@ietf.org Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote: Hello, Significant improvements have been made to this document (below) based on comments received and new observations. IMHO, this is an important document for enabling transition to IPv6 within IPv4 sites; hence, I would like to call for working group adoption at this time. Thanks - Fred fred.l.templin@boeing.com Replying to this message as a way to maintain the threading. these notes ar= e relative to the current version of the draft which I reviewed last week: http://tools.ietf.org/html/draft-templin-v6ops-isops-10 So I tried for a while to separate the operational advice that could be app= lied to my 2005 era knowledge of isatap and there's quite a few things tha= t jive with that (tunnel loops for example). OK. In other cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what im= plementations are capable of doing that? Are we recommending that they do i= t? do they already? I can't speak for current implementations, but the DHCPv6 approach is based on the fact that address and prefix assignment on IPv6 interfaces are seperable functions. IPv6 prefixes assigned to ISATAP interfaces can only be used for autoconfiguration of ISATAP addresses and not ordinary IPv6 addresses. However, an ordinary IPv6 address can be assigned to an ISATAP interface the same as for any other IPv6 interface as long as it is not covered by a prefix assigned to the interface. Regarding aero (section 4.6) that looks pretty much like new work or an ext= ension to the specification. AERO is a new but backwards-compatible method of doing redirection of an on-link neighbor to another on-link neighbor. However, ISATAP interfaces can still use standards ICMPv6 Redirect messages the same as for any IPv6 interface. Advertising ISATAP routers should only send ICMPv6 redirects when they are certain that the redirected ISATAP node can tunnel packets directly to the target of the redirect, however. Perhaps a few more words saying explicitly that standards ICMPv6 redirects are still supported would help? Are there participants with extant isatap deployements or host implementati= ons or knowledge fresher than mine that would care to comment on this draft= . There are certainly vendors who are shipping ISATAP in their products today. Perhaps they can comment. section 9 alternative approaches, there's some consensus that rfc 3056 was = never really deployed so the reference to 6to4 should probably be to 3068 OK - I can fix this. Thanks - Fred fred.l.templin@boeing.com --_000_DD1A73D9E9C89144A927C5080F70285A01A7675A9E5DNAEXMSGS702_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Joel,

 

>>yeah, I think the question of do isatap implem= enters  or users in v6ops find this line of work interesting and useful is essentially the open question thatwould cause us to consider advancing this= as a wg document

 

I think having a document with operational guidance fo= r ISATAP would be useful and would support adoption of this document by the W= G.

 

Thank you,

Dmitry

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Joel Jaeggli
Sent: Sunday, July 03, 2011 4:38 PM
To: Templin, Fred L
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?

 

 

On Jul 1, 2011, at 3:54 PM, Templin, Fred L wrote:



Hi Joel,

 

Me again. There have have been others who have also expressed

concerns about DHCPv6 and other "undocumented features" on

ISATAP links, so I decided to split the document into two pieces.

 

 



The new piece is now called: "ISATAP Updates" and I guess might

be more appropriate for some other working group. The other piece<= /o:p>

retains the original name and is strictly about operational aspects

of widely-deployed implementations:

 

http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-12.txt=  

What should we do next - ask the wg for comments?

 

yeah, I think the question of do isatap implementers  or users in v6ops find this line of work interesting and useful is essentially the open question thatwould cause us to consider advancing this= as a wg document vs allowing you to pursue it as an indivudal submission. I th= ink that preaking shcpv6 out of it is a wise idea.



 

Thanks - Fred

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L
Sent: Wednesday, June 22, 2011 8:13 AM
To: Joel Jaeggli
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?

Hi Joel,

 

Thanks for your comments, and see below for responses:

 

From: Joel Jaeggli [mailto:joelja@bogus.com] =
Sent: Friday, June 17, 2011 12:50 PM
To: Templin, Fred L
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?

On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote:



Hello,

Significant improvements have been made to this document
(below) based on comments received and new observations.
IMHO, this is an important document for enabling transition
to IPv6 within IPv4 sites; hence, I would like to call for
working group adoption at this time.

Thanks - Fred
fred.l.templin@boeing.com<= o:p>

 

Replying to this message as a way to maintain the thre= ading. these notes are relative to the current version of the draft which I review= ed last week:

 

 

So I tried for a while to separate the operational advice that could be applie= d to my 2005 era knowledge of isatap and there's  quite a few things that j= ive with that (tunnel loops for example). 

OK. &n= bsp;

In other cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what implementations are capable of doing that? Are we recommending that they do= it? do they already?&nbs= p;

I can't speak for current implementations, but the DHCPv6 approach is=

based on the fact that address and prefix assignment on IPv6 interfaces

are seperable functions. IPv6 prefixes assigned to ISATAP interfaces can

only be used for autoconfiguration of ISA= TAP addresses and not ordinary

IPv6 addresses. However, an ordinary IPv6 address can be assigned to

an ISATAP interface the same as for any o= ther IPv6 interface as long as

it is not covered by a prefix assigned to= the interface.

Regarding aero (section 4.6) that looks pretty much like new work or an extension to = the specification.&nbs= p;

AERO is a new but backwards-compatible me= thod of doing redirection

of an on-link neighbor to another on-link neighbor. However, ISATAP

interfaces can still use standards ICMPv6 Redirect messages the same

as for any IPv6 interface. Advertisi= ng ISATAP routers should only send

ICMPv6 redirects when they are certain th= at the redirected ISATAP node

can tunnel packets directly to the target of the redirect, however. Perhaps

a few more words saying explicitly that standards ICMPv6 redirects are

still supported would help?=  

Are there participants with extant isatap deployements or host implementations = or knowledge fresher than mine that would care to comment on this draft. 

 

There are certainly vendors who are shipp= ing ISATAP in their products

today. Perhaps they can comment. 

section 9 alternative approaches, there's some consensus that rfc 3056 was never re= ally deployed so the reference to 6to4 should probably be to 3068<= span class=3Dapple-style-span> 

 

OK - I can fix this.

 

Thanks - Fred

 

--_000_DD1A73D9E9C89144A927C5080F70285A01A7675A9E5DNAEXMSGS702_-- From marka@isc.org Tue Jul 5 19:28:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF86121F886C for ; Tue, 5 Jul 2011 19:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXxuosFIBjeS for ; Tue, 5 Jul 2011 19:28:36 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6664321F8867 for ; Tue, 5 Jul 2011 19:28:36 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 1FC095F9933; Wed, 6 Jul 2011 02:28:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1139F216C81; Wed, 6 Jul 2011 02:28:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3D011118540E; Wed, 6 Jul 2011 12:28:10 +1000 (EST) To: Erik Kline From: Mark Andrews References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <20110706094304.7eb9c225@opy.nosense.org> In-reply-to: Your message of "Wed, 06 Jul 2011 11:08:22 +0900." Date: Wed, 06 Jul 2011 12:28:10 +1000 Message-Id: <20110706022810.3D011118540E@drugs.dv.isc.org> Cc: IPv6 Operations , draft-hilliard-v6ops-ipv6-discard-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 02:28:39 -0000 In message , Erik Kline writes: > > As a side note relating to the 127/8 verses ::1 choice, I've come > > across an occasion where having a loopback prefix rather than an > > individual address available was useful. It was so long ago that I > > can't remember exactly what I was doing, however I do remember that it > > was inspired by ntpd's trick of having reference clocks listen on > > addresses within 127/8 e.g. - > > > > http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver8.html > > > > http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver6.html > > > I have had similar need at times, and mentioned it once before on > v6ops I think. Basically, when writing unittests for systems it's > *really* handy to be able to bind each component to its own 127.0.0.x > address and pretend you have a locally routed network. And, as you > point out, even in regular operational scenarios it can be handy. > > There's a node-local multicast prefix, iirc, but only a single /128 > for unicast. :/ We ended up using a ULA prefix for our testing. lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 inet 10.53.0.1 netmask 0xff000000 inet6 fd92:7065:b8e:ffff::1 prefixlen 64 inet 10.53.0.2 netmask 0xff000000 inet6 fd92:7065:b8e:ffff::2 prefixlen 64 inet 10.53.0.3 netmask 0xff000000 inet6 fd92:7065:b8e:ffff::3 prefixlen 64 inet 10.53.0.4 netmask 0xff000000 inet6 fd92:7065:b8e:ffff::4 prefixlen 64 inet 10.53.0.5 netmask 0xff000000 inet6 fd92:7065:b8e:ffff::5 prefixlen 64 inet 10.53.0.6 netmask 0xff000000 inet6 fd92:7065:b8e:ffff::6 prefixlen 64 inet 10.53.0.7 netmask 0xff000000 inet6 fd92:7065:b8e:ffff::7 prefixlen 64 > _______________________________________________ > 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 lizhenqiang@chinamobile.com Tue Jul 5 19:38:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85A521F87F9 for ; Tue, 5 Jul 2011 19:38:50 -0700 (PDT) X-Quarantine-ID: <4U6qbvElR+v3> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: 0.118 X-Spam-Level: X-Spam-Status: No, score=0.118 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U6qbvElR+v3 for ; Tue, 5 Jul 2011 19:38:50 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5820C21F876D for ; Tue, 5 Jul 2011 19:38:47 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id B3F28A4C5; Wed, 6 Jul 2011 10:38:41 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id ABDB3A41E; Wed, 6 Jul 2011 10:38:41 +0800 (CST) To: Ray Hunter, v6ops@ietf.org WG MIME-Version: 1.0 From: lizhenqiang@chinamobile.com Date: Wed, 6 Jul 2011 10:38:39 +0800 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.6 March 06, 2007 X-MIMETrack: Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-06 10:38:40 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18242.003 X-TM-AS-Result: No--3.870-7.0-31-10 X-imss-scan-details: No--3.870-7.0-31-10;No--3.870-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: Re: [v6ops] new draft: draft-li-v6ops-load-balancing-requirement-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 02:38:51 -0000 Thanks alot Ray for your comments and interests. The submitted draft is mainly focused on the load balancing requirement of = the network(ISP) side concentrators, i.e., the ARTF of dslite, the BR of 6r= d, the NAT64 and IVI translators. Since web proxy is used at the enterprise= side, it is IMO similar to B4 of dslite, and CE of 6rd. ALG problem should be considered by the translation technology, such as NAT= 64. When designing the loadbalancing solution for NAT64, we will take this = point into account. Best Regards, Zhenqiang Li 2011-07-06=20 ---------------------------------------------------------------------------= ----- From: Ray Hunter=20 Sent: 2011-07-05 21:38:12=20 To: v6ops@ietf.org WG; lizhenqiang@chinamobile.com=20 Subject: re: [v6ops] new draft: draft-li-v6ops-load-balancing-requirement-0= 0.txt=20 =20 Thanks for sharing your draft with us. I think you may be missing a whole class of bottleneck that is not=20 receiving too much attention at the moment. Many enterprises transport the majority of their traffic over the=20 boundary between their 'private' internal networks and the Internet via=20 use of a "web proxy." Application Level Gateways (ALG) =3D RFC2766 Section 2.4 are also=20 considered a valid translation mechanism between IPv4 and IPv6 islands,=20 and can be especially useful for simple outbound HTTP based web traffic.=20 They may also be useful for translating certain inbound requests. Traditionally the WCCP Web Cache Proxy Protocol (non IETF protocol, but=20 described in http://tools.ietf.org/html/draft-wilson-wrec-wccp-v2-01)=20 has been used to balance requests between multiple proxies, or for=20 example between an IPv4 router and a farm of multiple WAN acceleration=20 devices. AFAIK WCCPv2 does not (yet) support IPv6, which IMHO is quite an=20 omission in the options given to enterprises to migrate to IPv6 in a=20 smooth manner. regards, and good luck with your deployment, RayH= From lizhenqiang@chinamobile.com Wed Jul 6 01:15:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339D321F859D for ; Wed, 6 Jul 2011 01:15:05 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: 0.073 X-Spam-Level: X-Spam-Status: No, score=0.073 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDXwp8KdkM0P for ; Wed, 6 Jul 2011 01:15:04 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFA121F859A for ; Wed, 6 Jul 2011 01:15:03 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id C496FA270; Wed, 6 Jul 2011 16:14:57 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id BBC10A24F; Wed, 6 Jul 2011 16:14:57 +0800 (CST) To: Ray Hunter, fred.baker@cisco.com, zhaoqin@bupt.edu.cn, v6ops@ietf.org MIME-Version: 1.0 From: lizhenqiang@chinamobile.com Date: Wed, 6 Jul 2011 16:14:55 +0800 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.6 March 06, 2007 X-MIMETrack: Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-06 16:14:57 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18242.005 X-TM-AS-Result: No--15.879-7.0-31-10 X-imss-scan-details: No--15.879-7.0-31-10;No--15.879-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: Re: [v6ops] new draft: draft-li-v6ops-load-balancing-requirement-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 08:15:05 -0000 Hi Randy and all, Thank you for your question. I do not think the life in a big city with terrible traffic jam is good, al= though this is the fact in lots of big cities. Don't you think it is better= to distribute the traffic among the available roads to mitigate or avoid t= he traffic jam if we can? If you would like to use one huge device to satisfy the requirement of the = increasing traffic during the transition phase from IPv4 to IPv6, you do n= ot need to consider load balance. If you use multiple devices to provide th= e identical function and to achieve the resiliency, it is better to balance= traffic among these devices. The submitted document mainly focuses on the traffic concentration point in= troduced by certain transition technologies such as AFTR in DS-Lite. Loadba= lancing mechanism should be considered to distribute load among multiple de= vices reasonablely at certain scenarios. This document lists the key factor= s that should be considered when designing the load balancing mechanism. Of= course, we should learn the loadbalancing mechanism used in and the experi= ence learned from IPv4 network. Specific suggestion is welcome. Best Regards, Zhenqiang Li 2011-07-06=20 -----Original Message----- From: Randy Bush =20 To: Fred Baker =20 Cc: IPv6 Ops WG =20 Date: Tue, 05 Jul 2011 14:32:42 +0900=20 In-reply-to: <201107041355.p64Dt0320469 at ftpeng-update.cisco.com>=20 References: <201107041355.p64Dt0320469 at ftpeng-update.cisco.com>=20 ---------------------------------------------------------------------------= ----- > A new draft has been posted, at > http://tools.ietf.org/html/draft-li-v6ops-load-balancing-requirement. Ple= ase > take a look at it and comment. fred, i am confused. almost all the technologies [0] mentioned indeed 'force' a path. and indeed in some cases, these paths could concentrate packets which might otherwise be more diversely forwarded. but that's life in the big city. so that leaves me only seeing that the document is about when services have multiple and diverse servers. so how is this different than ipv4 where, for example, we use load balancers when near servers which need scale and use anycast when we want diversity and resiliency? what should i have learned from this document? clue bat, please. randy -- [0] - note that most of these are non-transition technologies= From xiaohong.deng@orange-ftgroup.com Wed Jul 6 02:53:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD0F21F860A; Wed, 6 Jul 2011 02:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djlJ4zN0Dw3Q; Wed, 6 Jul 2011 02:53:38 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 697EF21F86BE; Wed, 6 Jul 2011 02:53:38 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9F80EFC4003; Wed, 6 Jul 2011 11:53:32 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8FFB0FC4001; Wed, 6 Jul 2011 11:53:32 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 11:53:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3BC2.8E7C6ECA" Date: Wed, 6 Jul 2011 17:53:28 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC018698AC@ch-mailsrv.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft: draft-zheng-mif-apps-test-00 Thread-Index: Acw7wo5Sa/zBx7J6SFmBxSnO2ikCAQ== From: To: X-OriginalArrivalTime: 06 Jul 2011 09:53:31.0999 (UTC) FILETIME=[90720EF0:01CC3BC2] Cc: softwires@ietf.org, int-area@ietf.org, v6ops@ietf.org, behave@ietf.org Subject: [v6ops] New draft: draft-zheng-mif-apps-test-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 09:53:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3BC2.8E7C6ECA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, =20 A new draft describing applications behaviors dealing with multiple interface issues in the IPv6 transition context has been submitted. In this draft, DS-Lite, AplusP, NAT64 and their combinations with IPv6 provisioning have been tested and suggestions are therefore stated according to the test results. http://tools.ietf.org/id/draft-zheng-mif-apps-test-00.txt =20 =20 The Abstract of this I-D: =20 With the development of IPv6 and deployment of transition solutions, more and more hosts can access Internet with dual stack by multi-interface and applications behaviors are worth to be concerned under this environment. This memo describes the test results of some well-known applications in different scenarios under MIF environment and provides an analysis and suggestions to develop and deploy under MIF environment. =20 Comments are very much appreciated if it's something of your interest. =20 Cheers, Xiaohong =20 open source PCP Client, open source A+P http://opensourcev6transtechnologies.weebly.com/ =20 =20 ------_=_NextPart_001_01CC3BC2.8E7C6ECA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello=20 all,

 

A new draft describing applications = behaviors=20 dealing with multiple interface issues in the IPv6 transition context = has been=20 submitted. In this draft, DS-Lite, AplusP, NAT64 and their combinations = with=20 IPv6 provisioning have been tested and suggestions are therefore stated=20 according to the test results.

http://tools.ietf.org/id/draft-zheng-mif-apps-test-00.txt=

 

The Abstract of this = I-D:

 

With the development of IPv6 and = deployment of=20 transition solutions, more and more hosts can access Internet with dual = stack by=20 multi-interface and applications behaviors are worth to be concerned = under   this environment. This = memo=20 describes the test results of some well-known applications in different=20 scenarios under MIF environment and provides an analysis and suggestions = to=20 develop and deploy under MIF environment.

 

Comments are very much appreciated if = it's=20 something of your interest.

 

Cheers,

Xiaohong

 
open source PCP = Client,
open source = A+P
http://opensour= cev6transtechnologies.weebly.com/
 
 
------_=_NextPart_001_01CC3BC2.8E7C6ECA-- From geeohgeegeeoh@gmail.com Tue Jul 5 19:12:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F091C21F87A4 for ; Tue, 5 Jul 2011 19:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIgUGDq94cNi for ; Tue, 5 Jul 2011 19:12:58 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0660121F85CC for ; Tue, 5 Jul 2011 19:12:57 -0700 (PDT) Received: by ywp31 with SMTP id 31so3149917ywp.31 for ; Tue, 05 Jul 2011 19:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=SHgI5ltUVvrswFRYJHHCqjFCnYK2ythV/VQLRYCCE54=; b=hsyrWxd7V52tk66KeNeAP7anzIhaXjQtfAc20Zm3LAtN8noEBoZefAbh54EFelx7nO hgkOvXiTm5KdyWa/IEaYSoEorWzdSwa6l6WpCGX35283SO7OsuHFL57OpU25zCqCc4rw VIQmfTTvyLoO0sB1NavHBZfrBK2GUiTBtoIrk= Received: by 10.91.18.4 with SMTP id v4mr6737213agi.22.1309918377374; Tue, 05 Jul 2011 19:12:57 -0700 (PDT) Received: from dynamic157.apnic.net (dynamic157.apnic.net [203.119.42.157]) by mx.google.com with ESMTPS id k3sm7151427ano.11.2011.07.05.19.12.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 19:12:56 -0700 (PDT) Sender: George Michaelson Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: Date: Wed, 6 Jul 2011 12:12:50 +1000 Content-Transfer-Encoding: 7bit Message-Id: <38EA2B58-6E51-46E7-B312-32C295C22127@algebras.org> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <20110706094304.7eb9c225@opy.nosense.org> To: Erik Kline X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 06 Jul 2011 08:06:45 -0700 Cc: IPv6 Operations , draft-hilliard-v6ops-ipv6-discard-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 02:12:59 -0000 On 06/07/2011, at 12:08 PM, Erik Kline wrote: >> As a side note relating to the 127/8 verses ::1 choice, I've come >> across an occasion where having a loopback prefix rather than an >> individual address available was useful. It was so long ago that I >> can't remember exactly what I was doing, however I do remember that it >> was inspired by ntpd's trick of having reference clocks listen on >> addresses within 127/8 e.g. - >> >> http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver8.html >> >> http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver6.html > > > I have had similar need at times, and mentioned it once before on > v6ops I think. Basically, when writing unittests for systems it's > *really* handy to be able to bind each component to its own 127.0.0.x > address and pretend you have a locally routed network. And, as you > point out, even in regular operational scenarios it can be handy. > > There's a node-local multicast prefix, iirc, but only a single /128 > for unicast. :/ > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Wed Jul 6 09:45:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB69521F889A; Wed, 6 Jul 2011 09:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57E-5WzZUABN; Wed, 6 Jul 2011 09:45:30 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 613B321F8896; Wed, 6 Jul 2011 09:45:30 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay12.apple.com ([17.128.113.53]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LNX004GL7TVRT91@mail-out.apple.com>; Wed, 06 Jul 2011 09:45:29 -0700 (PDT) X-AuditID: 11807135-b7b76ae000001169-e2-4e1491a6233f Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay12.apple.com (Apple SCV relay) with SMTP id 39.73.04457.6A1941E4; Wed, 06 Jul 2011 09:47:35 -0700 (PDT) Received: from 67-218-109-100.cust.layer42.net (67-218-109-100.cust.layer42.net [67.218.109.100]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNX006PE7VPWL40@koseret.apple.com>; Wed, 06 Jul 2011 09:45:29 -0700 (PDT) From: james woodyatt In-reply-to: Date: Wed, 06 Jul 2011 09:45:24 -0700 Message-id: <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> References: <20110703111047.GB2304@Space.Net> To: Randy Bush X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUiON1OXXf5RBE/g3+NjBbPNs5nsTh9bC+z A5PHkiU/mQIYo7hsUlJzMstSi/TtErgydvV9ZCloYqs4ccGxgfEGSxcjJ4eEgInEvx1PmSFs MYkL99azdTFycQgJdDJJdM57zA6S4BUQlPgx+R5QAwcHs4C8xMHzsiBhZgEtie+PWlkg6jcx SezvWMsEkhAWMJP4sug0G4jNJqAi8e3yXbA4J1DDyV2rWEFsFgFVieaJ89khBoVKnOg8ywKx y0bizJPzYL1CAt4SLcuawY4TEZCTuHjiHSPEofISi1s+M05gFJiF5LxZCOfNQnLeAkbmVYyC Rak5iZWGRnqJBQU5qXrJ+bmbGEEB2FBouoPx0UL1Q4wCHIxKPLxdvSJ+QqyJZcWVuYcYJTiY lUR4JzkChXhTEiurUovy44tKc1KLDzFKc7AoifNWOXL5CQmkJ5akZqemFqQWwWSZODilGhjD buzY2Zr7U/SFSMytlTPmZU1NZfdvNmPhzPcI6ODQFHphseRsNEfBsbVNx4tXachKMC3nXJE4 r8d61oebzzXdCqJC2NZvUO7k3WCe+FvxaP7Pi/+SD6u1JU35vPrJi4aWgmO/2q76aLuZZ3ke thc9v7GrmalOwzhaiLm6Lezl8vZDlR+r1iqxFGckGmoxFxUnAgAKMV0PPAIAAA== Cc: IPv6 Operations Working Group , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:45:30 -0000 On Jul 5, 2011, at 6:39 PM, Randy Bush wrote: > > what people are saying is kill it because it is broken, bad, and does a dis-service to ipv6. Actually, I seem to have been the only person who proposed killing it-- the rest of you seem to have settled on merely looking at it crossly and hoping it will wither away in shame. By that I mean, I wrote up and circulated an Internet Draft to specify a phase-out plan for RFC 3056 and RFC 3068. I chose not to submit it when it was made clear to me that no such plan could be adopted as a working group item. On a related note, I much prefer Keith Moore's proposal to reclassify RFC 3056 and RFC 3068 as Experimental. -- james woodyatt member of technical staff, core os networking From pch-b2B3A6689@u-1.phicoh.com Wed Jul 6 11:30:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A47421F89AB for ; Wed, 6 Jul 2011 11:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.449 X-Spam-Level: X-Spam-Status: No, score=-8.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avZg5vVCJq-F for ; Wed, 6 Jul 2011 11:30:15 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB0721F899E for ; Wed, 6 Jul 2011 11:30:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QeWrQ-0001hgC; Wed, 6 Jul 2011 20:30:08 +0200 Message-Id: To: james woodyatt From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <20110703111047.GB2304@Space.Net> <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> In-reply-to: Your message of "Wed, 06 Jul 2011 09:45:24 -0700 ." <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> Date: Wed, 06 Jul 2011 20:29:58 +0200 Cc: IPv6 Operations Working Group Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 18:30:16 -0000 In your letter dated Wed, 06 Jul 2011 09:45:24 -0700 you wrote: >On Jul 5, 2011, at 6:39 PM, Randy Bush wrote: >> >> what people are saying is kill it because it is broken, bad, and does a dis- >service to ipv6. > >Actually, I seem to have been the only person who proposed killing it-- the re >st of you seem to have settled on merely looking at it crossly and hoping it w >ill wither away in shame. I'd say that the main attack on 6to4 has already happened: most operating systems now prefer IPv4 over IPv6 when the host has a 6to4 address. >On a related note, I much prefer Keith Moore's proposal to reclassify RFC 3056 > and RFC 3068 as Experimental. In that light, maybe it is good idea to direct hosts to ignore 6to4 prefixes for the purpose of SLAAC (unless explictly configured to accept them) and also to assign the priority low to any default router that also announces a 6to4 prefixes for SLAAC. That should get rid of almost all accidental use of 6to4 while still allowing expert users to use it. (I'm considering switching to 6to4 to get something unreliable enough to actually test happy eyeballs :-) From moore@network-heretics.com Wed Jul 6 11:43:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A2421F88B0 for ; Wed, 6 Jul 2011 11:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lWOZdpOEdwf for ; Wed, 6 Jul 2011 11:43:52 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 7541E21F889E for ; Wed, 6 Jul 2011 11:43:52 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 1AAA220ABB; Wed, 6 Jul 2011 14:43:51 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 06 Jul 2011 14:43:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=qCsUXD2JvXdVLCPqY0+9hrFK+5k=; b=ijnZFMM6j6n7CI9zxnZ9ORHRnyyztOzO0cX3mW6aOt/CWysonvlb41YdI6aTM2mSE3UBmCg4+GDrQ15LkmlTMPXtSXaMbWogIr+g6kBElquXpEIouHGt/gvvDt4Ift9M0pk9zArw6fz02rzamZLzgkZJi2zHtTb/4UemqF0zUP8= X-Sasl-enc: a0GtWSGaW/SIL4/ZFD7dCNM4Ze66MNBA3d9txM0wmUmX 1309977830 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 528894015D3; Wed, 6 Jul 2011 14:43:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 6 Jul 2011 14:43:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0C31BB66-020D-4159-AF34-5F88E4C65567@network-heretics.com> References: <20110703111047.GB2304@Space.Net> <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Working Group Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 18:43:53 -0000 On Jul 6, 2011, at 2:29 PM, Philip Homburg wrote: >> On a related note, I much prefer Keith Moore's proposal to reclassify = RFC 3056 >> and RFC 3068 as Experimental. >=20 > In that light, maybe it is good idea to direct hosts to ignore 6to4 = prefixes > for the purpose of SLAAC (unless explictly configured to accept them) = and also > to assign the priority low to any default router that also announces a = 6to4 > prefixes for SLAAC. No, that makes no sense. The host has no way of knowing whether the = 6to4 prefix is being advertised because the network was deliberately = configured to use it, or because the router enabled it by default. And = relatively few routers ever did that. Make 6to4 off by default at the router, and make host 6to4 off by = default, but don't have hosts second-guess SLAAC. Keith From jhw@apple.com Wed Jul 6 11:46:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF9E21F8A2C for ; Wed, 6 Jul 2011 11:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.724 X-Spam-Level: X-Spam-Status: No, score=-106.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz+EXFK+iusz for ; Wed, 6 Jul 2011 11:46:43 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id B58C921F887C for ; Wed, 6 Jul 2011 11:46:26 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LNX004FCDGPRTG1@mail-out.apple.com> for v6ops@ietf.org; Wed, 06 Jul 2011 11:46:26 -0700 (PDT) X-AuditID: 1180711d-b7c5fae000001427-d3-4e14ad5e0e20 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id A4.14.05159.E5DA41E4; Wed, 06 Jul 2011 11:45:50 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNX006UQDHDWL70@koseret.apple.com> for v6ops@ietf.org; Wed, 06 Jul 2011 11:46:25 -0700 (PDT) From: james woodyatt In-reply-to: Date: Wed, 06 Jul 2011 11:46:25 -0700 Message-id: References: <20110703111047.GB2304@Space.Net> <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> To: Philip Homburg X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUiON1OXTdurYifwam9shanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrtDRgWfmCoe9K9kamBcwtTFyMkhIWAiMe1oDzOELSZx4d56 ti5GLg4hgU4miZ9LrrGCJHgFBCV+TL7H0sXIwcEsIC9x8LwsSJhZQEvi+6NWFoj6GUwSV15s BRskLGAm8WXRaTYQm01AReLb5btgyzgFjCW2zT0DZrMIqErsfHycGWKQkcTaj7fZIHbZSMzd NZsJYuhyRonzH/+ygCREBHQl3tycBnWpvMTils+MExgFZiG5bxbCfbOQ3LeAkXkVo2BRak5i paGxXmJBQU6qXnJ+7iZGUOA1FMruYNz/k/8QowAHoxIPb0eviJ8Qa2JZcWXuIUYJDmYlEd6o 1UAh3pTEyqrUovz4otKc1OJDjNIcLErivDGZ3H5CAumJJanZqakFqUUwWSYOTqkGRtnNs4zt /ranJxWuq16Zvqh2tmrZBMMDUnwy85gvKqVvE7t/0eOrmvFr86W+4kvsRX04tgou9cj77770 0wUFjqpus9mmzVvOXgr5+OjrkoeX/TlFp2mcjzn1+DILj7ydWdEVKfZlBk5pvUZPVwgz2cTJ bSmeqmxTknImcIb4pfMR1y4+Eb44Q4mlOCPRUIu5qDgRACcVAZs4AgAA Cc: IPv6 Operations Working Group Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 18:46:43 -0000 On Jul 6, 2011, at 11:29 , Philip Homburg wrote: > > In that light, maybe it is good idea to direct hosts to ignore 6to4 prefixes > for the purpose of SLAAC... That's what I expect will have to be done if I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel isn't stopped. -- james woodyatt member of technical staff, core os networking From moore@network-heretics.com Wed Jul 6 12:11:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D852221F8AF7 for ; Wed, 6 Jul 2011 12:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vteN5AqBq5eh for ; Wed, 6 Jul 2011 12:11:38 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 53E5A21F8AF1 for ; Wed, 6 Jul 2011 12:11:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id A0C2720907; Wed, 6 Jul 2011 15:11:35 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 06 Jul 2011 15:11:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=sBgsebH7hqrBAx8oBSntWAgcICE=; b=cpt7ZRTCDlPkpLPP/OYvqZkB9KGpMgJ/38T1nTpt4OOXT1Dy9dL+ZPhxNKzz3rCHphe71JWLIfJLnuAIvUIEVG7eBHTRPOrwQ2/ZKFOFnvEm2V1V7oFF96Mlp99QBzeVFdcD1CxnTnMR+6U164FGebq3z9uWtgEets9vkw0YfUQ= X-Sasl-enc: NZYi8fgSIXjeqash2cRY3rcmyLOxUIPvd1ShCMI1JnPR 1309979495 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id DF31D404DF8; Wed, 6 Jul 2011 15:11:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 6 Jul 2011 15:11:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <77479A20-9512-4026-8284-5E1BB23BC086@network-heretics.com> References: <20110703111047.GB2304@Space.Net> <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Working Group Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 19:11:40 -0000 On Jul 6, 2011, at 2:46 PM, james woodyatt wrote: > On Jul 6, 2011, at 11:29 , Philip Homburg wrote: >>=20 >> In that light, maybe it is good idea to direct hosts to ignore 6to4 = prefixes >> for the purpose of SLAAC... >=20 > That's what I expect will have to be done if = I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel isn't stopped. 6to4-provider-managed-tunnel should absolutely be stopped. Anything = that does prefix translation in IPv6 is a very dubious idea.=20 Keith From dougb@dougbarton.us Wed Jul 6 13:08:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368E121F8B4D for ; Wed, 6 Jul 2011 13:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFHZpFyjTO43 for ; Wed, 6 Jul 2011 13:08:21 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id D94B021F8B49 for ; Wed, 6 Jul 2011 13:08:20 -0700 (PDT) Received: (qmail 31371 invoked by uid 399); 6 Jul 2011 20:08:17 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 6 Jul 2011 20:08:17 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E14C0AB.9080105@dougbarton.us> Date: Wed, 06 Jul 2011 13:08:11 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: james woodyatt References: <20110703111047.GB2304@Space.Net> <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> In-Reply-To: <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Working Group , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:08:22 -0000 On 07/06/2011 09:45, james woodyatt wrote: > Actually, I seem to have been the only person who proposed killing it-- the rest of you seem to have settled on merely looking at it crossly and hoping it will wither away in shame. ... as well it should. :) Meanwhile I have stated several times that I'd like it to be gone, completely, yesterday. I was however willing to accept "historic" as a reasonable compromise. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From mrex@sap.com Wed Jul 6 13:14:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B05121F8B85; Wed, 6 Jul 2011 13:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.186 X-Spam-Level: X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP6yOgGXqU6Q; Wed, 6 Jul 2011 13:14:46 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DFA8021F8B82; Wed, 6 Jul 2011 13:14:45 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p66KEcD8015293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jul 2011 22:14:38 +0200 (MEST) From: Martin Rex Message-Id: <201107062014.p66KEc4g024137@fs4113.wdf.sap.corp> To: dougb@dougbarton.us (Doug Barton) Date: Wed, 6 Jul 2011 22:14:38 +0200 (MEST) In-Reply-To: <4E14C0AB.9080105@dougbarton.us> from "Doug Barton" at Jul 6, 11 01:08:11 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:14:49 -0000 Doug Barton wrote: > > Meanwhile I have stated several times that I'd like it to be gone, > completely, yesterday. I was however willing to accept "historic" as a > reasonable compromise. "historic" as a compromise? Between which two positions? -Martin From dougb@dougbarton.us Wed Jul 6 13:18:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB56621F8BA8 for ; Wed, 6 Jul 2011 13:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.564 X-Spam-Level: X-Spam-Status: No, score=-3.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqdAYyydY6OB for ; Wed, 6 Jul 2011 13:18:44 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCC621F8BA4 for ; Wed, 6 Jul 2011 13:18:44 -0700 (PDT) Received: (qmail 12132 invoked by uid 399); 6 Jul 2011 20:18:42 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 6 Jul 2011 20:18:42 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E14C31E.4010603@dougbarton.us> Date: Wed, 06 Jul 2011 13:18:38 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110624 Thunderbird/3.1.11 MIME-Version: 1.0 To: mrex@sap.com References: <201107062014.p66KEc4g024137@fs4113.wdf.sap.corp> In-Reply-To: <201107062014.p66KEc4g024137@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:18:48 -0000 On 07/06/2011 13:14, Martin Rex wrote: > Doug Barton wrote: >> >> Meanwhile I have stated several times that I'd like it to be gone, >> completely, yesterday. I was however willing to accept "historic" as a >> reasonable compromise. > > "historic" as a compromise? Between which two positions? Nuking it from orbit, and erecting a statue in its honor? :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From mrex@sap.com Wed Jul 6 13:49:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D4521F8BBD; Wed, 6 Jul 2011 13:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.189 X-Spam-Level: X-Spam-Status: No, score=-10.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peJ96uyRloII; Wed, 6 Jul 2011 13:49:53 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 927B821F8BB1; Wed, 6 Jul 2011 13:49:53 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p66Knm35017687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Jul 2011 22:49:48 +0200 (MEST) From: Martin Rex Message-Id: <201107062049.p66Knlfi026308@fs4113.wdf.sap.corp> To: dougb@dougbarton.us (Doug Barton) Date: Wed, 6 Jul 2011 22:49:47 +0200 (MEST) In-Reply-To: <4E14C31E.4010603@dougbarton.us> from "Doug Barton" at Jul 6, 11 01:18:38 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: v6ops@ietf.org, mrex@sap.com, ietf@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 20:49:54 -0000 Doug Barton wrote: > > On 07/06/2011 13:14, Martin Rex wrote: > > > > Doug Barton wrote: > > > > > > I was however willing to accept "historic" as a reasonable compromise. > > > > "historic" as a compromise? Between which two positions? > > Nuking it from orbit, and erecting a statue in its honor? Which to options that are actually available to the IESG? I see extremist-A: nuke/kill 6to4 by moving 3056/3068 to historic compromise: move 3056/3068 off Standards Track, i.e. by reclassifying them as Experimental blocked: leave 3056/3068 at Proposed, publish only 6to4-advisory extremist-B: stick fingers in ears, sing la-la-la, pretend 6to4 is perfect -Martin From nick@inex.ie Wed Jul 6 14:17:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC03221F8A75 for ; Wed, 6 Jul 2011 14:17:24 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5yDlJS5geih for ; Wed, 6 Jul 2011 14:17:24 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1314B21F8A74 for ; Wed, 6 Jul 2011 14:17:22 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p66LHAdS072202 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 6 Jul 2011 22:17:16 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4E14D0D6.9010709@inex.ie> Date: Wed, 06 Jul 2011 22:17:10 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Fred Baker References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> In-Reply-To: <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> X-Enigmail-Version: 1.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 21:17:25 -0000 On 05/07/2011 20:37, Fred Baker wrote: > On Jul 5, 2011, at 7:56 AM, Mark Smith wrote: >> I'm not sure about a /32, as it is very large considering the purpose. [...] > Is there any substantive reason to not define ::2 as "discard"? It could be implemented as simply as Stepping back a little, I think we're talking about two slightly different things here. The ID suggests that we reserve a prefix for generic use as something to faciliate traffic discard (i.e. something which you could inject into a routing protocol), whereas defining ::2 as discard is all about creating a local-only discard address, similar in scope to the cisco Null0 interface (i.e. something that you wouldn't necessarily inject into a routing protocol). These are two separate things, and the ID is very specifically talking about one, not the other. In terms of the exact size of prefix that might be useful from the point of view of the ID, the options are either /128 or more than /128. If people feel that a single discard address is all that's required (I don't), then ::2 will suffice, and the functionality of the two separate things noted above will collapse into a single issue. If it's more than /128, then the choice between /32 or /48 is a matter of bikeshed politics. Incidentally, I'm not at all averse to the idea of defining ::2 as a local-only discard address. Nick From nick@inex.ie Wed Jul 6 14:24:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A188921F8AB3 for ; Wed, 6 Jul 2011 14:24:58 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8jxE58qNTUB for ; Wed, 6 Jul 2011 14:24:58 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id D81D121F8AB0 for ; Wed, 6 Jul 2011 14:24:57 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p66LOc16072279 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 6 Jul 2011 22:24:44 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4E14D296.6000203@inex.ie> Date: Wed, 06 Jul 2011 22:24:38 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Smith References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> In-Reply-To: <20110706002619.39b94073@opy.nosense.org> X-Enigmail-Version: 1.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 21:24:58 -0000 On 05/07/2011 15:56, Mark Smith wrote: > Also a bit more explanation of why the following are SHOULD NOT's > rather than MUST NOT's might be useful. Is it to allow for the case > where the third party AS is performing DoS traffic analysis? That's the > only possibility I can think of right now. As far as I'm aware, Informational IDs cannot use "MUST" (I am but an egg, so if someone can correct me here, please do so). More than that, I don't want to proscribe the practice - just to say that it's probably not a good idea, and if you're doing it, you're probably doing something wrong. Nick From wmaton@ryouko.imsb.nrc.ca Wed Jul 6 15:25:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA2E21F8B0E for ; Wed, 6 Jul 2011 15:25:37 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8gEt+W-kqc6 for ; Wed, 6 Jul 2011 15:25:36 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2604:8400:0:127::10]) by ietfa.amsl.com (Postfix) with ESMTP id 029E521F8AF0 for ; Wed, 6 Jul 2011 15:25:35 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.3/8.14.4) with ESMTP id p66MPRNF010301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Jul 2011 18:25:32 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.4/8.14.4/Submit) with ESMTP id p66MPRCk010298 for ; Wed, 6 Jul 2011 18:25:27 -0400 Date: Wed, 6 Jul 2011 18:25:27 -0400 (EDT) From: "William F. Maton Sotomayor" To: v6ops@ietf.org In-Reply-To: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> Message-ID: References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 22:25:37 -0000 On Tue, 5 Jul 2011, fred@cisco.com wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix. Please take a look at it and comment. I support this ducment. I too am concerned about burning an entire /32, but what's a million addresses? In all seriousness, perhaps something shorter could be used, or maybe the /32 might be a boundary better understood over a /48. In any case, the principle counts. As a RTBH operator for AS25689, I have been forced to go off and deploy this as well for IPv6 pest-control reasons (FTP IPv6-enabled client executing dozens of connections per second against the FTP server here. I became ... annoyed). In my implementation I have been using the IPv6 documentation prefix, 2001:0DB8::/32, which I admit may be bad practice and make me out to be a bad boy, e pur si muove. (Or, it works for me.) So on the control router I do: ! Go down Route 66 ipv6 route 2001:DB8::/32 Null0 tag 66 and a route-map: route-map static-to-bgpv6 permit 5 match tag 66 set ipv6 next-hop 2001:DB8::1 set local-preference 2500 set origin igp set community no-export ! The edge routers are then programmed to do the spankings: ipv6 route 2001:DB8::1/128 Null0 (I've left out the usual bits on the BGP peer configuration to prevent accidental leaks, etc.) Thanks, wfms From fred@cisco.com Wed Jul 6 17:30:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0581D21F885C for ; Wed, 6 Jul 2011 17:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=-3.900, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMQGfDFXvU0e for ; Wed, 6 Jul 2011 17:30:37 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 65C4B21F8854 for ; Wed, 6 Jul 2011 17:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3265; q=dns/txt; s=iport; t=1309998637; x=1311208237; h=subject:mime-version:from:date:cc:reply-to:message-id:to: content-transfer-encoding; bh=MmfQiwzeVGZpEF76I2DfQkQJVDkJrCEZSxFJlxdgpMQ=; b=RougpEUk+aS6mkRepMgC1gtDHwNnFtBJz6/v+YYiWfOaaTTIPGau5qSY a+axz15n4rPL9mVViuVSTfifCUrfXE78Mt2Fc0sXmW93WpqKFxYHPSc6m eAY9eWxUERhD0B2ZIdPLHrxrQH5YNQlz/A/5fub+AnxvS8BaDqwZGfTon M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGv9FE6rRDoI/2dsb2JhbABTqAt3rXGeAIY3BIdGinuEeotj X-IronPort-AV: E=Sophos;i="4.65,490,1304294400"; d="scan'208";a="485456" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 07 Jul 2011 00:30:36 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p670USJv020389; Thu, 7 Jul 2011 00:30:31 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 06 Jul 2011 17:30:34 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 06 Jul 2011 17:30:34 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker Date: Wed, 6 Jul 2011 17:30:06 -0700 Message-Id: <900EF936-FD5B-4B2B-B314-396CCD6DE078@cisco.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ron Bonica Subject: [v6ops] Starting to pull together an agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: v6ops-chairs@tools.ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 00:30:38 -0000 The chairs expect updates to draft-ietf-v6ops-ipv6-cpe-router-bis and = draft-jjmb-v6ops-comcast-ipv6-experiences this week. The current drafts = are out of date. We have four sets of drafts to discuss. At IETF-80, we agreed that the = drafts discussed at IETF-81 would be those that gained traction on the = mailing list, so I am in part looking for traction and in part reporting = what appears to us to be traction. We have two agenda slots: 2.5 hours Tuesday morning and two hours = Thursday afternoon. Tuesday morning, I want to start out with a review of the World IPv6 = Day, in terms of what measurably happened, what worked, what didn't, and = what can we learn from it. To that end, we have presentations lined up = related to - draft-jjmb-v6ops-comcast-ipv6-experiences (which is not limied to = IPv6 Day) - draft-keranen-ipv6day-measurements - draft-chown-v6ops-call-to-arms - a presentation from Microsoft - potentially one or two others We have old business the chairs would like to finalize if we can: - draft-ietf-v6ops-ipv6-cpe-router-bis - draft-ietf-v6ops-happy-eyeballs - draft-ietf-v6ops-v6-aaaa-whitelisting-implications - draft-ietf-v6ops-6to4-to-historic The AAAA document was sent to the IESG, and has been effectively = rewritten in that discussion. Meanwhile, further comments have been made = that weren't made on the mailer. I think the working group needs to = decide whether it still agrees with the draft, especially given that it = has been rewritten. 6to4-to-historic has also had a lot of discussion. I would like to have = a brief face to face discussion of it, and specifically a constructive = one. We need to decide on a path forward, whether it is to kill it, = promote it, or do something else. We have some new work that appears to be interesting to folks on the = list:=20 - draft-gont-v6ops-ra-guard-evasion - draft-hilliard-v6ops-ipv6-discard-prefix - draft-sarikaya-v6ops-prefix-delegation We also have some other drafts. Some of these look to the chairs like = there is a fair bit of meat; others look like they need work before they = are ready to discuss, and some have been pretty well rejected on the = list. Here, I'm specifically looking for statements of "traction." If = you're interested in discussion of any of the following, please drop a = note to the chairs. Absent comments, we'll pick a few that seem like = they are ready to discuss.=20 - draft-andrews-v6ops-6to4-router-option - draft-bdgks-arin-shared-transition-space - draft-chen-v6ops-ipv6-bearer-network-trials - draft-chown-v6ops-address-accountability - draft-deng-v6ops-aplusp-experiment-results - draft-denog-v6ops-addresspartnaming - draft-elkins-6man-ipv6-diagnostic-header - draft-fling-v6ops-hybrid-bridged-routed - draft-gundavelli-v6ops-pmipv6-address-reservations - draft-kuarsingh-wireline-incremental-ipv6 - draft-li-v6ops-load-balancing-requirement - draft-matsushima-v6ops-transition-experience - draft-sunq-v6ops-contents-transition - draft-tan-v6ops-fast6-aaa - draft-templin-v6ops-isops - draft-yang-v6ops-fast6-pppoe - draft-yang-v6ops-fast6-tools-selection - draft-yang-v6ops-space6-icp From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Jul 6 18:25:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1E021F89D7 for ; Wed, 6 Jul 2011 18:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYOOe-155Ir9 for ; Wed, 6 Jul 2011 18:25:25 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 5D78921F89D1 for ; Wed, 6 Jul 2011 18:25:25 -0700 (PDT) Received: from 182-239-205-173.ip.adam.com.au ([182.239.205.173] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QedLD-000468-Gl; Thu, 07 Jul 2011 10:55:19 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 79D343B33E; Thu, 7 Jul 2011 10:55:18 +0930 (CST) Date: Thu, 7 Jul 2011 10:55:17 +0930 From: Mark Smith To: Nick Hilliard Message-ID: <20110707105517.0bf3b556@opy.nosense.org> In-Reply-To: <4E14D0D6.9010709@inex.ie> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 01:25:26 -0000 Hi Nick, On Wed, 06 Jul 2011 22:17:10 +0100 Nick Hilliard wrote: > On 05/07/2011 20:37, Fred Baker wrote: > > On Jul 5, 2011, at 7:56 AM, Mark Smith wrote: > >> I'm not sure about a /32, as it is very large considering the purpose. > [...] > > Is there any substantive reason to not define ::2 as "discard"? It could be implemented as simply as > > Stepping back a little, I think we're talking about two slightly different > things here. The ID suggests that we reserve a prefix for generic use as > something to faciliate traffic discard (i.e. something which you could > inject into a routing protocol), whereas defining ::2 as discard is all > about creating a local-only discard address, similar in scope to the cisco > Null0 interface (i.e. something that you wouldn't necessarily inject into a > routing protocol). These are two separate things, and the ID is very > specifically talking about one, not the other. > Sure, although this could be an opportunity to address both similar requirements in the same ID. > In terms of the exact size of prefix that might be useful from the point of > view of the ID, the options are either /128 or more than /128. If people > feel that a single discard address is all that's required (I don't), then > ::2 will suffice, and the functionality of the two separate things noted > above will collapse into a single issue. > > If it's more than /128, then the choice between /32 or /48 is a matter of > bikeshed politics. > Where your thoughts to have it come from within 2000::/3, which is perhaps why you chose /32? I think it probably should come from outside of it similar to ULAs, ::1 etc., because I don't think a discard function is dependent on the Internet's global unicast addressing. Once it's outside of 2000::/3, I'd think the chosen size can chosen based on expected use, rather than trying to reasonably fit in with an existing allocation scheme. > Incidentally, I'm not at all averse to the idea of defining ::2 as a > local-only discard address. > > Nick Regards, Mark. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Thu Jul 7 05:15:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA18C21F87A2 for ; Thu, 7 Jul 2011 05:15:04 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4eRBn9eKyMm for ; Thu, 7 Jul 2011 05:15:04 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2853E21F85B0 for ; Thu, 7 Jul 2011 05:15:03 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.internal.acquirer.com (mail.acquirer.com [87.198.142.10] (may be forged)) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p67CEhA5079337 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 7 Jul 2011 13:14:44 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4E15A333.7080301@inex.ie> Date: Thu, 07 Jul 2011 13:14:43 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110620 Thunderbird/5.0b2 MIME-Version: 1.0 To: Mark Smith References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> In-Reply-To: <20110707105517.0bf3b556@opy.nosense.org> X-Enigmail-Version: 1.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 12:15:04 -0000 On 07/07/2011 02:25, Mark Smith wrote: > Sure, although this could be an opportunity to address both similar > requirements in the same ID. I would see ::2 as more appropriate for standards-track. hilliard-v6ops-ipv6-discard-prefix is very definitely informational. > Where your thoughts to have it come from within 2000::/3, which is > perhaps why you chose /32? I think it probably should come from outside > of it similar to ULAs, ::1 etc., because I don't think a discard > function is dependent on the Internet's global unicast addressing. Once > it's outside of 2000::/3, I'd think the chosen size can chosen based on > expected use, rather than trying to reasonably fit in with an existing > allocation scheme. The exact size is not important at this stage. There is plenty of ipv6 address space out there, and it's just about irrelevant as to whether this prefix would be /64, /48, /32 or anything in-between. Please let's park this issue for the moment, because it's distracting attention away from more substantive issues in the draft. Regarding 2000::/3, as it would be a special purpose prefix, it would probably be better not to take it from Internet unicast space, as it's not general purpose internet unicast address space. Nick From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Jul 7 05:51:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0826C1F0C34 for ; Thu, 7 Jul 2011 05:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqJ1D+r104yZ for ; Thu, 7 Jul 2011 05:51:07 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 1076621F8802 for ; Thu, 7 Jul 2011 05:51:07 -0700 (PDT) Received: from 182-239-205-173.ip.adam.com.au ([182.239.205.173] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qeo2m-0004Lu-VA; Thu, 07 Jul 2011 22:21:01 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 7CAC83B344; Thu, 7 Jul 2011 22:21:00 +0930 (CST) Date: Thu, 7 Jul 2011 22:21:00 +0930 From: Mark Smith To: Nick Hilliard Message-ID: <20110707222100.0d23a5d6@opy.nosense.org> In-Reply-To: <4E15A333.7080301@inex.ie> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> <4E15A333.7080301@inex.ie> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 12:51:08 -0000 On Thu, 07 Jul 2011 13:14:43 +0100 Nick Hilliard wrote: > On 07/07/2011 02:25, Mark Smith wrote: > > The exact size is not important at this stage. There is plenty of ipv6 > address space out there, and it's just about irrelevant as to whether this > prefix would be /64, /48, /32 or anything in-between. Please let's park > this issue for the moment, because it's distracting attention away from > more substantive issues in the draft. > ok. It's not obvious to me what they are though. Once the address space issue was sorted out, I'd see no reason for it not to be published. > Regarding 2000::/3, as it would be a special purpose prefix, it would > probably be better not to take it from Internet unicast space, as it's not > general purpose internet unicast address space. > I think we're agreeing on that, I was just curious where you came up with /32, and though perhaps it was because it is the minimum RIR allocation, which implied it coming out of 2000::/3. Regards, Mark. From dr@cluenet.de Thu Jul 7 07:47:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDA821F8614 for ; Thu, 7 Jul 2011 07:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugawJAiodaVP for ; Thu, 7 Jul 2011 07:47:06 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3C121F85CD for ; Thu, 7 Jul 2011 07:47:05 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id BE1F01080AE; Thu, 7 Jul 2011 16:47:03 +0200 (CEST) Date: Thu, 7 Jul 2011 16:47:03 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110707144703.GA19099@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> <4E15A333.7080301@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E15A333.7080301@inex.ie> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 14:47:07 -0000 On Thu, Jul 07, 2011 at 01:14:43PM +0100, Nick Hilliard wrote: > The exact size is not important at this stage. There is plenty of ipv6 > address space out there, and it's just about irrelevant as to whether this > prefix would be /64, /48, /32 or anything in-between. /64s are far less likely to leak into the DFZ. As such, I'd favor to settle on /64 if size doesn't matter for other reasons. > Regarding 2000::/3, as it would be a special purpose prefix, it would > probably be better not to take it from Internet unicast space, as it's not > general purpose internet unicast address space. ACK. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From ynir@checkpoint.com Thu Jul 7 01:31:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679C521F875F; Thu, 7 Jul 2011 01:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VLDsroJUQVB; Thu, 7 Jul 2011 01:31:45 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D25D521F874E; Thu, 7 Jul 2011 01:31:44 -0700 (PDT) X-CheckPoint: {4E157CB0-9-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p678VX5Z026200; Thu, 7 Jul 2011 11:31:33 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 7 Jul 2011 11:30:08 +0300 From: Yoav Nir To: "'mrex@sap.com'" , Doug Barton Date: Thu, 7 Jul 2011 11:30:06 +0300 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic Thread-Index: Acw8HoFNI9mcKA6JSjSLaIL3Nj9C1wAYXRcA Message-ID: <006FEB08D9C6444AB014105C9AEB133F01714C077305@il-ex01.ad.checkpoint.com> References: <4E14C31E.4010603@dougbarton.us> from "Doug Barton" at Jul 6, 11 01:18:38 pm <201107062049.p66Knlfi026308@fs4113.wdf.sap.corp> In-Reply-To: <201107062049.p66Knlfi026308@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 07 Jul 2011 08:39:21 -0700 Cc: "v6ops@ietf.org" , "ietf@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 08:31:46 -0000 Extremist-A should be to publish a "6to4 considered dangerous" draft with l= ots of MUST NOT language. =20 -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Mar= tin Rex Sent: 06 July 2011 23:50 To: Doug Barton Cc: v6ops@ietf.org; ietf@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic Doug Barton wrote: >=20 > On 07/06/2011 13:14, Martin Rex wrote: > > > > Doug Barton wrote: > > > > > > I was however willing to accept "historic" as a reasonable compromise= . > > > > "historic" as a compromise? Between which two positions? >=20 > Nuking it from orbit, and erecting a statue in its honor? Which to options that are actually available to the IESG? I see extremist-A: nuke/kill 6to4 by moving 3056/3068 to historic compromise: move 3056/3068 off Standards Track, i.e. by reclassifying them as Experimental blocked: leave 3056/3068 at Proposed, publish only 6to4-advisory extremist-B: stick fingers in ears, sing la-la-la, pretend 6to4 is perfect -Martin _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Scanned by Check Point Total Security Gateway. From dougb@dougbarton.us Thu Jul 7 09:25:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CB61F0C42 for ; Thu, 7 Jul 2011 09:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3mc1jZJWR7x for ; Thu, 7 Jul 2011 09:25:12 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD351F0C3D for ; Thu, 7 Jul 2011 09:25:12 -0700 (PDT) Received: (qmail 17055 invoked by uid 399); 7 Jul 2011 16:25:07 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 7 Jul 2011 16:25:07 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E15DDDF.90909@dougbarton.us> Date: Thu, 07 Jul 2011 09:25:03 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Yoav Nir References: <4E14C31E.4010603@dougbarton.us> from "Doug Barton" at Jul 6, 11 01:18:38 pm <201107062049.p66Knlfi026308@fs4113.wdf.sap.corp> <006FEB08D9C6444AB014105C9AEB133F01714C077305@il-ex01.ad.checkpoint.com> In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F01714C077305@il-ex01.ad.checkpoint.com> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "'mrex@sap.com'" , "ietf@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 16:25:13 -0000 ... or to use Randy's language, "6to4 considered caterpillar snot," but yes, that is what I was thinking that end of the spectrum looked like. Doug On 07/07/2011 01:30, Yoav Nir wrote: > Extremist-A should be to publish a "6to4 considered dangerous" draft with lots of MUST NOT language. > > > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Martin Rex > Sent: 06 July 2011 23:50 > To: Doug Barton > Cc: v6ops@ietf.org; ietf@ietf.org > Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic > > Doug Barton wrote: >> >> On 07/06/2011 13:14, Martin Rex wrote: >>> >>> Doug Barton wrote: >>>> >>>> I was however willing to accept "historic" as a reasonable compromise. >>> >>> "historic" as a compromise? Between which two positions? >> >> Nuking it from orbit, and erecting a statue in its honor? > > Which to options that are actually available to the IESG? I see > > extremist-A: nuke/kill 6to4 by moving 3056/3068 to historic > > compromise: move 3056/3068 off Standards Track, > i.e. by reclassifying them as Experimental > > blocked: leave 3056/3068 at Proposed, publish only 6to4-advisory > > extremist-B: stick fingers in ears, sing la-la-la, pretend 6to4 is perfect > > > -Martin > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > Scanned by Check Point Total Security Gateway. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From tpoder@cis.vutbr.cz Thu Jul 7 10:59:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4095B1F0C74 for ; Thu, 7 Jul 2011 10:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkhCLPSMKF8d for ; Thu, 7 Jul 2011 10:59:47 -0700 (PDT) Received: from ferret.cis.vutbr.cz (ferret.cis.vutbr.cz [147.229.3.145]) by ietfa.amsl.com (Postfix) with ESMTP id C25E41F0C64 for ; Thu, 7 Jul 2011 10:59:46 -0700 (PDT) Received: from flamingo.cis.vutbr.cz (flamingo.cis.vutbr.cz [147.229.3.147]) by ferret.cis.vutbr.cz (8.14.4/8.14.4/VUT Brno) with ESMTP id p67HwRAi058450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 Jul 2011 19:58:29 +0200 (CEST) (envelope-from tpoder@cis.vutbr.cz) Received: from Tomas-Podermanskis-MacBook-Pro-2.local (ip-62-245-112-151.net.upcbroadband.cz [62.245.112.151]) (authenticated bits=0) by flamingo.cis.vutbr.cz (8.13.8/8.14.3/VUT v Brne) with ESMTP id p67HwNEW028210 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 7 Jul 2011 19:58:24 +0200 (CEST) (envelope-from tpoder@cis.vutbr.cz) Message-ID: <4E15F3BD.1040902@cis.vutbr.cz> Date: Thu, 07 Jul 2011 19:58:21 +0200 From: Tomas Podermanski User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------050005050001080904070905" X-Scanned-By: MIMEDefang 2.67 on 147.229.3.145 Subject: Re: [v6ops] Draft-Chown-v6-address-accountability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 17:59:48 -0000 This is a multi-part message in MIME format. --------------050005050001080904070905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Tim, there is an document that is very close to the topic you are trying to touch. Some "IPv6 accounting experience" got at a campus network is described there. You may find there some useful ideas for work on your draft. Link is: http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd132.pdf (the second part of the document) Tomas On 7/5/11 12:46 AM, Tim Chown wrote: > > On 4 Jul 2011, at 23:29, Scott Brim wrote: > >> I'm sure there will be lots of discussion about Tim's draft. I just >> want to say one thing: be sure you understand endpoint privacy >> requirements and take them into account. The end user is who you are >> in business for. Let's use solutions that make them happy to be >> customers instead of treating them as pesky nuisances. > > Hi Scott, > > It's a topic that comes up whenever I speak to other university sites > deploying IPv6, or considering doing so, hence the draft, to see what > views and ideas are out there. Two common questions that come up are > whether the existing DHCPv4 accountability model can be applied, and > where it is not (or can not be) how can accountability be best > achieved where clients have multiple autoconfigured or privacy > addresses that may also be changing rapidly over time. > > What type of user privacy requirements do you have in mind? This > topic isn't included yet as the text is a drafty draft, but I would > guess the general view will be that privacy of addresses within an > enterprise is a somewhat unrealistic expectation because the network > administrator will always have access to the switch or router port-MAC > tables or ND tables. However, for user traffic going outside the > enterprise, IPv6 privacy addresses have a benefit for the user against > tracking by 3rd parties. Obviously comments are welcome on that. > > For those interested, the draft is here: > http://www.ietf.org/internet-drafts/draft-chown-v6ops-address-accountability-00.txt > > Tim > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------050005050001080904070905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Tim,
    there is an document that is very close to the topic you are trying to touch. Some "IPv6 accounting experience" got at a campus network is described there. You may find there some useful ideas for work on your draft.

Link is: http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd132.pdf (the second part of the document)

Tomas

On 7/5/11 12:46 AM, Tim Chown wrote:

On 4 Jul 2011, at 23:29, Scott Brim wrote:

I'm sure there will be lots of discussion about Tim's draft. I just
want to say one thing: be sure you understand endpoint privacy
requirements and take them into account. The end user is who you are
in business for. Let's use solutions that make them happy to be
customers instead of treating them as pesky nuisances.

Hi Scott,

It's a topic that comes up whenever I speak to other university sites deploying IPv6, or considering doing so, hence the draft, to see what views and ideas are out there.  Two common questions that come up are whether the existing DHCPv4 accountability model can be applied, and where it is not (or can not be) how can accountability be best achieved where clients have multiple autoconfigured or privacy addresses that may also be changing rapidly over time.

What type of user privacy requirements do you have in mind?  This topic isn't included yet as the text is a drafty draft, but I would guess the general view will be that privacy of addresses within an enterprise is a somewhat unrealistic expectation because the network administrator will always have access to the switch or router port-MAC tables or ND tables.  However, for user traffic going outside the enterprise, IPv6 privacy addresses have a benefit for the user against tracking by 3rd parties.  Obviously comments are welcome on that.

For those interested, the draft is here:

Tim


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

--------------050005050001080904070905-- From fred@cisco.com Thu Jul 7 12:33:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E6B11E80A5 for ; Thu, 7 Jul 2011 12:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=-3.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHozZKlBj-Nw for ; Thu, 7 Jul 2011 12:33:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1F411E80A4 for ; Thu, 7 Jul 2011 12:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1239; q=dns/txt; s=iport; t=1310067229; x=1311276829; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=pZLAhw8SAyfEDqzWy4A0G3hZ9Jnm4mjaIX5+l18CaZo=; b=ComCFKrYmHMyx7WsClUWMvVJ17jfVoSNfffolrY06gZx8MFmv3PreLa/ noQtSf0JMVp8AGkUtGOdX3+uzEi6rC0nlWmb4rZbKgyi2FOGoE2EPkVV0 D93XpOCkIBxn36oEBk8kitzy3ANT2h6VU5kGmUjdicrUBSZbUU8vB6SOp k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANUIFk6rRDoI/2dsb2JhbABUpzZ3iHukYZ1thjgEh0mKfYRYJYtk X-IronPort-AV: E=Sophos;i="4.65,494,1304294400"; d="scan'208";a="788155" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 07 Jul 2011 19:33:48 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p67JXmUD010740; Thu, 7 Jul 2011 19:33:48 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Thu, 07 Jul 2011 12:33:48 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Thu, 07 Jul 2011 12:33:48 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <20110707192002.GA29545@walton.maths.tcd.ie> Date: Thu, 7 Jul 2011 12:33:40 -0700 Message-Id: <85E9ECD6-3B81-4504-81C5-D6249D752484@cisco.com> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110707192002.GA29545@walton.maths.tcd.ie> To: David Malone X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, draft-hilliard-v6ops-ipv6-discard-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 19:33:50 -0000 On Jul 7, 2011, at 12:20 PM, David Malone wrote: > One possible security point arising from making a well-known > allocation for traffic discard, is that there will then be a > well-known traffic sink address available on the network. This means > that attackers that want (say) to fill a link and then have the > traffic vanish as quickly as possible can just generate traffic and > send it to the well-known discard address. >=20 > I'm not sure this is a big deal, but it might be worth discussing? > It might also influence the choice of assigning a single address > vs. a prefix, where network operators can blackhole randomly chosen > addresses, rather than the whole prefix. I agree that we should discuss the solution and its ramifications. We = can obviously continue on the list, but I expect to also do this face to = face. I suspect that the security concern is a minor one; a network with uRPF = or some other form of ingress filtering configured would not accept a = packet sourced from ::2, and the only way I see it getting sent as a = destination address *to* a network involves a pretty obvious mechanism = like direct injection into a tunnel. So if the event occurs, it should = be visible.= From shemant@cisco.com Thu Jul 7 13:19:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E52C21F88D0 for ; Thu, 7 Jul 2011 13:19:41 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH1-qjK3Ztlb for ; Thu, 7 Jul 2011 13:19:40 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 982D821F88CE for ; Thu, 7 Jul 2011 13:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2129; q=dns/txt; s=iport; t=1310069980; x=1311279580; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=GLITiD7J5AT1tx6vMnWEitzt/iBR8hgmoFtYrUhh2sk=; b=ZEN7xypLH/8V2cmTigX5kofqBgzk2ofQ8a5tfZw5Txkh8hi8lbvbC5Zm JFIQydfbcX3dfKRKlnzIKQgqT7kXAWYXLl+Tf4LW1jTNIatEcDXbO2ic4 Gv92Wd6EIqOYh37VGDL9A7oVuz+q29zcFSUt/fXI6wTQlM90aLUOCVKy3 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIBAN4TFk6tJV2c/2dsb2JhbABUmACPNnetXZ1yhjgEh0mQA4RLhw4 X-IronPort-AV: E=Sophos;i="4.65,495,1304294400"; d="scan'208";a="804062" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 07 Jul 2011 20:19:36 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p67KJadB029375; Thu, 7 Jul 2011 20:19:36 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 15:19:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 15:19:33 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30229641C@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-v6ops-ipv6-cpe-router-bis Thread-Index: Acw4BdAMrDcehW0bSUa88cFjEBLoQQAIDSAg References: From: "Hemant Singh (shemant)" To: "John Gammons" , "IPv6 Operations" X-OriginalArrivalTime: 07 Jul 2011 20:19:35.0783 (UTC) FILETIME=[309E5F70:01CC3CE3] Cc: draft-ietf-v6ops-ipv6-cpe-router-bis@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-cpe-router-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 20:19:41 -0000 -----Original Message----- From: John Gammons [mailto:jgammons@gmail.com]=20 Sent: Friday, July 01, 2011 11:44 AM To: IPv6 Operations Cc: draft-ietf-v6ops-ipv6-cpe-router-bis@tools.ietf.org Subject: re: draft-ietf-v6ops-ipv6-cpe-router-bis >First off, overall, this is a great draft and a much needed one at that. =20 Thanks. >A few thoughts that might be considered overly complex, but I thought I'd throw out there for potential talking points by the group. =20 >CGN/LSN(NAT44) environment -=20 >What if the WAN interface was provided an RFC1918 address (or potentially draft-weil-shared-transition-space-request-01/ARIN 2011-5 space), the CPE would accept this address as a management IP only, and >fallback to bridge operation. The thought here being, that rather than downstream CPE operating in a NAT444 environment, they would then be only NAT44. This would obviously require that the provider >no longer deliver only a single v4 address, but an unlimited number for any subscriber routed through a CGN/LSN. There are numerous other potential implications which would need further discussion, but >the thought being, all of those _could_ be more preferred over the NAT444 implications. Essentially it would be "moving" the existing NAT44 to a more advantageous v4 location where overloading can be >performed, rather than adding an additional layer. =20 All of the above text relates to IPv4-only behavior of the CPE router. We are trying to only specify IPv6 related behavior in the bis document and minimal IPv4 behavior when IPv4 impacts dual-stack operation.=20 >No WAN IPv4 address - >If, the CPE is delegated a prefix, but does not receive an IPv4 address (public or private) on its WAN interface, and it does not receive a DS-Lite configuration, then it may be beneficial to fallback >into a NAT46 operation (draft-liu-behave-nat46). =20 My recommendation is to then have the router fail for IPv4. We are actively trying to reduce the number of mandatory transition technologies in the CE Rtr document in hope of facilitating implementation. =20 Hemant From jhw@apple.com Thu Jul 7 13:58:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA1121F8841 for ; Thu, 7 Jul 2011 13:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.71 X-Spam-Level: X-Spam-Status: No, score=-106.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5NRCFfg+NWz for ; Thu, 7 Jul 2011 13:58:07 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6784821F8849 for ; Thu, 7 Jul 2011 13:58:07 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LNZ00KHDE7ZZMT1@mail-out.apple.com> for v6ops@ietf.org; Thu, 07 Jul 2011 13:58:06 -0700 (PDT) X-AuditID: 11807130-b7c45ae000001381-58-4e161db8cf9b Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id A2.37.04993.8BD161E4; Thu, 07 Jul 2011 13:57:28 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNZ0099TE8U0100@cardamom.apple.com> for v6ops@ietf.org; Thu, 07 Jul 2011 13:58:06 -0700 (PDT) From: james woodyatt In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C30229641C@XMB-RCD-109.cisco.com> Date: Thu, 07 Jul 2011 13:58:05 -0700 Message-id: <24F8A4D0-F051-4660-8575-71646E60DFD6@apple.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30229641C@XMB-RCD-109.cisco.com> To: draft-ietf-v6ops-ipv6-cpe-router-bis@tools.ietf.org X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUiON1OVXeHrJifwcUp5hanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpG921kK5nJULJwt3sB4jK2LkZNDQsBEYs2RWawQtpjEhXvr geJcHEICrUwSU7edYAdJ8AoISvyYfI+li5GDg1lAXuLgeVmQMLOAlsT3R60sEPWzmCTm77sG Vi8sYCnx6MYdJhCbTUBF4tvlu2A2p4CvxOHW2WDLWARUJda39DBBzFSR+N/AD7HKRuLCtCUs ILaQQL1E/4JrbCAlIgLmEnNPJkKcKS+xuOUz4wRGgVlIjpuFcNwsJMctYGRexShYlJqTWGlo qJdYUJCTqpecn7uJERRyDYUGOxjX/uQ/xCjAwajEwxt4WdRPiDWxrLgy9xCjBAezkgjv98dA Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryxmdx+QgLpiSWp2ampBalFMFkmDk6pBkbF8wpWYhsK tjktOZIU0KwUbLjd+2dZwYxPK7nvlUQ8TdEV9nMWeZ+qw/PPim+K/GI2Z883e99kZ/qduaH8 OmyrvcfW7LjzL+yvflPruPq+y51dW4hNck+Z0i7lyUsuX53XsNtz+Yv0qLIZWcv2sExZq/by Rh3Tx/6T/cdmJJz99f4Aq9rs1GIlluKMREMt5qLiRAAiDE50NQIAAA== Cc: IPv6 Operations Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-cpe-router-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 20:58:07 -0000 On Jul 7, 2011, at 13:19 , Hemant Singh (shemant) wrote: > On Jul 1, 2011, at 08:44 , John Gammons wrote: >> No WAN IPv4 address - If, the CPE is delegated a prefix, but does not receive an IPv4 address (public or private) on its WAN interface, and it does not receive a DS-Lite configuration, then it may be beneficial to fallback >into a NAT46 operation (draft-liu-behave-nat46). > > My recommendation is to then have the router fail for IPv4. We are > actively trying to reduce the number of mandatory transition > technologies in the CE Rtr document in hope of facilitating > implementation. Exactly so. As a procedural matter, I wouldn't want this draft to be tied down with a dependency on anything that isn't already a working group item, and one that's pretty far along at that. I have technical concerns about PNAT-Lite, but I'll save those for the event that the procedural issues here change. I concur with Mr. Singh on this. -- james woodyatt member of technical staff, core os networking From john.mann@monash.edu Thu Jul 7 20:09:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363A321F8762 for ; Thu, 7 Jul 2011 20:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbywaA4rSTwf for ; Thu, 7 Jul 2011 20:09:27 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id B6CCA21F8605 for ; Thu, 7 Jul 2011 20:09:25 -0700 (PDT) Received: from mail-vx0-f170.google.com ([209.85.220.170]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKThZ04zIPmRuXDWcerWfJapH1j3eKoSQ7@postini.com; Thu, 07 Jul 2011 20:09:26 PDT Received: by mail-vx0-f170.google.com with SMTP id 39so2654210vxi.1 for ; Thu, 07 Jul 2011 20:09:23 -0700 (PDT) Received: by 10.52.74.102 with SMTP id s6mr2163560vdv.125.1310094563090; Thu, 07 Jul 2011 20:09:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.101.226 with HTTP; Thu, 7 Jul 2011 20:09:03 -0700 (PDT) In-Reply-To: <54E20C35-711A-48ED-9050-DA81C505EBDB@bogus.com> References: <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.com> <54E20C35-711A-48ED-9050-DA81C505EBDB@bogus.com> From: "John Mann (ITS)" Date: Fri, 8 Jul 2011 13:09:03 +1000 Message-ID: To: Joel Jaeggli Content-Type: multipart/alternative; boundary=20cf307f34e00e212104a78629a4 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 03:09:28 -0000 --20cf307f34e00e212104a78629a4 Content-Type: text/plain; charset=ISO-8859-1 Joel, On 4 July 2011 09:37, Joel Jaeggli wrote: > ... > yeah, I think the question of do isatap implementers or users in v6ops > find this line of work interesting and useful is essentially the open > question thatwould cause us to consider advancing this as a wg document vs > allowing you to pursue it as an indivudal submission. I think that preaking > shcpv6 out of it is a wise idea. > ... > I am doing an ISATAP deployment, think the document is useful/interesting, and I support advancing this as a WG document. Thanks, John --20cf307f34e00e212104a78629a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joel,

On 4 July 2011 09:37, Joel Jaeggli = <joelja@bogus.com<= /a>> wrote:
...
yeah, I think the question of do isatap implementers =A0or users i= n v6ops find this line of work interesting and useful is essentially the op= en question thatwould cause us to consider advancing this as a wg document = vs allowing you to pursue it as an indivudal submission. I think that preak= ing shcpv6 out of it is a wise idea.
...
<= div>


--20cf307f34e00e212104a78629a4-- From rogerj@gmail.com Fri Jul 8 00:16:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811BA21F88E5; Fri, 8 Jul 2011 00:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWuJU2pUJ8la; Fri, 8 Jul 2011 00:16:26 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C24C321F88E6; Fri, 8 Jul 2011 00:16:25 -0700 (PDT) Received: by wyj26 with SMTP id 26so1290661wyj.31 for ; Fri, 08 Jul 2011 00:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JhDmquOv7EhaxNssIRxk/fmeOwqs1vqPuXJ3WEeYjNs=; b=SXGptf+uYQiOgtYI8nWszBfnbtrikjrevet5QDC3lzLNhhUFjhh5Wo1rd8+pEEZoRG 8EGm0fio0O4yXZVNIr0S9DDZ2RIF02N1Iv7ftGp5JiXNwySHwBOx03kmwQLx3kYrEwoI GlX8Q034sJa1V9nWsVoPHai/DkvbuRm7zLgCQ= MIME-Version: 1.0 Received: by 10.227.160.140 with SMTP id n12mr1440430wbx.69.1310109384557; Fri, 08 Jul 2011 00:16:24 -0700 (PDT) Received: by 10.227.142.137 with HTTP; Fri, 8 Jul 2011 00:16:24 -0700 (PDT) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> Date: Fri, 8 Jul 2011 09:16:24 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Ronald Bonica , IETF Discussion , "v6ops@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 07:16:27 -0000 Guess I should clearify something, the thing I am considering are to drop all 2002::/16 addresses hard, of course preferable return a correct error messages to. wonder how many find 6to4 usable when ISPs start doing that? Nuclear winter or not may follow. --- Roger J --- On Sun, Jul 3, 2011 at 9:32 PM, Roger J=F8rgensen wrote: > A bit late since this threat will be moderated soon. But I strongly objec= t > to this delay of needed action. > > I guess the other way the problem, which will hurt muchmuch more is maybe= to > considering a filter of 6to4 on isp level? > I will suggest it when we start deploying native ipv6. > > --- Roger J. --- > > On Jul 2, 2011 6:39 PM, "Ronald Bonica" wrote: >> Folks, >> >> Whereas there has been considerable controversy regarding >> draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author = have >> agreed to the following course of action: >> >> - the V6OPS WG will withdraw its request to publish >> draft-ietf-v6ops-6to4-to-historic >> - The author will introduce a new draft, intended for standards track >> publication. The new draft will update RFCs 3056 and 3068. It will say t= hat >> if 6-to-4 is implemented, it must be turned off by default. >> - In order for the new draft to be published, it must achieve both V6OPS >> WG and IETF consensus >> >> If anyone objects to this course of action, please speak up soon. >> >> Ron >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From ichiroumakino@gmail.com Fri Jul 8 02:00:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D710A21F884B; Fri, 8 Jul 2011 02:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJAsOtZlAIyE; Fri, 8 Jul 2011 02:00:30 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A43D21F884A; Fri, 8 Jul 2011 02:00:29 -0700 (PDT) Received: by bwb17 with SMTP id 17so1813650bwb.31 for ; Fri, 08 Jul 2011 02:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=VLamD7OQ1HS6dL9n0MIrxBJsb7xL0BhL/0qiYkZxWug=; b=W8Vlm4s8xYRYeDfBz3HCp14/5HU6bMDQdpEOUiKpJmlm0vse86dDsksJNmxF575DJI U1kMCjIHT6o2kqXyZZtUlKHkyuYf6XkST0NODmcp1ZBsAXPjp7kRU9gyn553fNMF41a5 XMbjzqMOh+LXvRpvSYnTKzINEYB1R5S6m9CxU= Received: by 10.204.20.65 with SMTP id e1mr1339593bkb.149.1310115628659; Fri, 08 Jul 2011 02:00:28 -0700 (PDT) Received: from [192.168.2.102] (ip-98-56-72-178.dialup.ice.net [178.72.56.98]) by mx.google.com with ESMTPS id i8sm155580bke.47.2011.07.08.02.00.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jul 2011 02:00:27 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ole Troan In-Reply-To: Date: Fri, 8 Jul 2011 11:00:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> To: =?iso-8859-1?Q?Roger_J=F8rgensen?= X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 09:00:31 -0000 Roger, > Guess I should clearify something, the thing I am considering are to > drop all 2002::/16 addresses hard, of course preferable return a > correct error messages to. >=20 > wonder how many find 6to4 usable when ISPs start doing that? Nuclear > winter or not may follow. took me a while to warm up to PMT, but now I think that's a perfectly = valid solution to rescue the set of innocent victims of 6to4. = http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tun= nel-02 wouldn't be surprised if there already are commercial products that can = do that. cheers, Ole >=20 >=20 >=20 > --- Roger J --- >=20 > On Sun, Jul 3, 2011 at 9:32 PM, Roger J=F8rgensen = wrote: >> A bit late since this threat will be moderated soon. But I strongly = object >> to this delay of needed action. >>=20 >> I guess the other way the problem, which will hurt muchmuch more is = maybe to >> considering a filter of 6to4 on isp level? >> I will suggest it when we start deploying native ipv6. >>=20 >> --- Roger J. --- >>=20 >> On Jul 2, 2011 6:39 PM, "Ronald Bonica" wrote: >>> Folks, >>>=20 >>> Whereas there has been considerable controversy regarding >>> draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document = author have >>> agreed to the following course of action: >>>=20 >>> - the V6OPS WG will withdraw its request to publish >>> draft-ietf-v6ops-6to4-to-historic >>> - The author will introduce a new draft, intended for standards = track >>> publication. The new draft will update RFCs 3056 and 3068. It will = say that >>> if 6-to-4 is implemented, it must be turned off by default. >>> - In order for the new draft to be published, it must achieve both = V6OPS >>> WG and IETF consensus >>>=20 >>> If anyone objects to this course of action, please speak up soon. >>>=20 >>> Ron >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>=20 >=20 >=20 >=20 > --=20 >=20 > Roger Jorgensen | > rogerj@gmail.com | - IPv6 is The Key! > http://www.jorgensen.no | roger@jorgensen.no > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From ichiroumakino@gmail.com Fri Jul 8 02:03:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D03421F876E; Fri, 8 Jul 2011 02:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kKbEW48HXDk; Fri, 8 Jul 2011 02:03:22 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4184521F872E; Fri, 8 Jul 2011 02:03:22 -0700 (PDT) Received: by bwb17 with SMTP id 17so1815748bwb.31 for ; Fri, 08 Jul 2011 02:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tcQqfhDReocyCNB2rIHKjBb5qxNUed7PVnxDtX8CIM4=; b=EENQk+N0owC+X8tF/w6gOonW5s69em9oL1EUGl6/wCWLz9hpBgp5lyIbJQE9nqpjwA J0uG57CRFFqrfUthFxOd0woDeF2r3oXknA3K4ZYTENv08o2rdszVN/e92iGLu1Zupcrx iHQMrGXzCtKCOjtQLjPeZ4zesoxGy2LtcGFDQ= Received: by 10.205.82.133 with SMTP id ac5mr251209bkc.386.1310115801381; Fri, 08 Jul 2011 02:03:21 -0700 (PDT) Received: from [192.168.2.102] (ip-98-56-72-178.dialup.ice.net [178.72.56.98]) by mx.google.com with ESMTPS id u32sm156485bkk.49.2011.07.08.02.03.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jul 2011 02:03:20 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <4E80A8E8-7B29-426B-BB43-8FC269330E4B@network-heretics.com> Date: Fri, 8 Jul 2011 11:03:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0622D8FB-2361-49C9-8E44-D70E7F1C2ADE@employees.org> References: <13205C286662DE4387D9AF3AC30EF456D3F3507F3A@EMBX01-WF.jnpr.net> <4E80A8E8-7B29-426B-BB43-8FC269330E4B@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] 6to4 to Experimental? (was: Re: draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 09:03:23 -0000 Keith, > The alternative that I proposed to IESG and to the chairs (and never = received any feedback about) was to reclassify 6to4 as Experimental. = Experimental seems completely appropriate for a protocol that is useful, = but only in corner cases. And I think it's also appropriate and useful = to try to learn from the experience with 6to4, even if we realize that = 6to4 will never be a generally applicable IPv6 transition solution = again. >=20 > And maybe, just maybe, Experimental will be enough of a "slap" at 6to4 = to mollify the "kill it yesterday" crowd. For one thing, it clearly = indicates that 6to4 is no longer a standard. >=20 > But in order to quieten down the discussion here, I suggest that = people reply to me privately if they can't live with this. If I get = lots of those replies, I'll know that it's not worth pursuing. "Experimental" is certainly better than: - nothing - spending months on hold as appeals are processed. cheers, Ole= From mohacsi@niif.hu Fri Jul 8 02:13:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC5521F88FE; Fri, 8 Jul 2011 02:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yk6zeYIefgWD; Fri, 8 Jul 2011 02:13:07 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 3E60521F88CA; Fri, 8 Jul 2011 02:13:07 -0700 (PDT) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id F100087588; Fri, 8 Jul 2011 11:13:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id DYb-unXn0UwA; Fri, 8 Jul 2011 11:13:03 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id B69B487581; Fri, 8 Jul 2011 11:13:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id B4CFB87548; Fri, 8 Jul 2011 11:13:03 +0200 (CEST) Date: Fri, 8 Jul 2011 11:13:03 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Ole Troan In-Reply-To: <0622D8FB-2361-49C9-8E44-D70E7F1C2ADE@employees.org> Message-ID: References: <13205C286662DE4387D9AF3AC30EF456D3F3507F3A@EMBX01-WF.jnpr.net> <4E80A8E8-7B29-426B-BB43-8FC269330E4B@network-heretics.com> <0622D8FB-2361-49C9-8E44-D70E7F1C2ADE@employees.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" , Keith Moore , IETF Discussion Subject: Re: [v6ops] 6to4 to Experimental? (was: Re: draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 09:13:08 -0000 On Fri, 8 Jul 2011, Ole Troan wrote: > Keith, > >> The alternative that I proposed to IESG and to the chairs (and never received any feedback about) was to reclassify 6to4 as Experimental. Experimental seems completely appropriate for a protocol that is useful, but only in corner cases. And I think it's also appropriate and useful to try to learn from the experience with 6to4, even if we realize that 6to4 will never be a generally applicable IPv6 transition solution again. >> >> And maybe, just maybe, Experimental will be enough of a "slap" at 6to4 to mollify the "kill it yesterday" crowd. For one thing, it clearly indicates that 6to4 is no longer a standard. >> >> But in order to quieten down the discussion here, I suggest that people reply to me privately if they can't live with this. If I get lots of those replies, I'll know that it's not worth pursuing. > > "Experimental" is certainly better than: > - nothing > - spending months on hold as appeals are processed. I proposed experimental also when discussion started about future of 6to4. I support the idea. Best Regards, Janos Mohacsi From tjc@ecs.soton.ac.uk Fri Jul 8 03:11:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D25F21F89A0 for ; Fri, 8 Jul 2011 03:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSjPcfDaQCvJ for ; Fri, 8 Jul 2011 03:11:32 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 8C83C21F86D7 for ; Fri, 8 Jul 2011 03:11:31 -0700 (PDT) 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 p68ABUAU032194 for ; Fri, 8 Jul 2011 11:11:30 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p68ABUAU032194 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1310119890; bh=R+lm017Xl7bhHY4BC1LrFB6lf+E=; h=Subject:References:From:In-Reply-To:Date:To:Mime-Version; b=RsZYegoQTVeZzrJAgPhNAE6yfnTXf8Ds7wF4IAXWdTkFtME7JJNyJ95xfpOpKDvPD 6+3tX730UpOJ7FU8hTdR66K/WejINWIj6H8WJRQrJCcmrbqiMtNdZPWoRnnwrIGw9O yJH/02/qBh8JRkk+1CayhKI9t7JClWxqP75OjH+Q= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n67BBU0366161925Dq ret-id none; Fri, 08 Jul 2011 11:11:30 +0100 Received: from [144.82.91.229] (dhcp-91-229.eduroam.ucl.ac.uk [144.82.91.229]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p68ABMgo003436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Jul 2011 11:11:23 +0100 References: <20110703111047.GB2304@Space.Net> <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> <8FBC436F-4357-4400-8B39-24EBFCBFB85E@ecs.soton.ac.uk> From: Tim Chown Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (8J2) In-Reply-To: Message-ID: Date: Fri, 8 Jul 2011 11:11:21 +0100 To: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 8J2) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n67BBU036616192500; tid=n67BBU0366161925Dq; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p68ABUAU032194 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 10:11:33 -0000 On 6 Jul 2011, at 19:46, james woodyatt wrote: > On Jul 6, 2011, at 11:29 , Philip Homburg wrote: >>=20 >> In that light, maybe it is good idea to direct hosts to ignore 6to4 prefi= xes >> for the purpose of SLAAC... >=20 > That's what I expect will have to be done if I-D.kuarsingh-v6ops-6to4-prov= ider-managed-tunnel isn't stopped. I recall that a hum to adopt the pmt draft as a WG item in Prague failed. Tim= From moore@network-heretics.com Fri Jul 8 06:03:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4542E21F8828; Fri, 8 Jul 2011 06:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+MLeXXUcMmv; Fri, 8 Jul 2011 06:03:01 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id A787021F8800; Fri, 8 Jul 2011 06:03:01 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 8782820BE3; Fri, 8 Jul 2011 09:03:00 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 08 Jul 2011 09:03:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=avnufLw1wkfZ6LBpBn5e8eDaejU=; b=G/7nxB4pLsJgTyhvK05OYtNDTNg2t8bKune2Wo8jpBl8vu0aWkSYqGYWbmKOSEoSghooudevT3LRqBrh8Y4A+EoJM+2WXbd+X0WFSRpPKNpRAb/buTxWSx3an20vQOw1u/ILRkLl/InP/sOX9Tmxacsfe6+08XqGl2uM+rDNRAI= X-Sasl-enc: A/qraeRvgvPQoF83jwcr0r2D+fqRXfnGmcfvL2VbMhe3 1310130180 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 9728B4423CC; Fri, 8 Jul 2011 09:02:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: Date: Fri, 8 Jul 2011 09:02:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> To: =?iso-8859-1?Q?Roger_J=F8rgensen?= X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 13:03:02 -0000 On Jul 8, 2011, at 3:16 AM, Roger J=F8rgensen wrote: > Guess I should clearify something, the thing I am considering are to > drop all 2002::/16 addresses hard, of course preferable return a > correct error messages to. >=20 > wonder how many find 6to4 usable when ISPs start doing that? Nuclear > winter or not may follow. seems like that just exacerbates the problem for your own customers and = for other operators. Keith From turchanyi.geza@gmail.com Fri Jul 8 06:12:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DF121F872E; Fri, 8 Jul 2011 06:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JAdzwmyFw26; Fri, 8 Jul 2011 06:12:52 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C47FA21F8672; Fri, 8 Jul 2011 06:12:51 -0700 (PDT) Received: by vws12 with SMTP id 12so1829842vws.31 for ; Fri, 08 Jul 2011 06:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZLQIyLrEijf4Y/r5jVZaFdkekG4UkxpXnEfQePgVkYQ=; b=ceTsLneUU+i58rJJxnexB1f7TZsKW8FtToJE6tLenGWfOP5+kCttJq3h7dvrv/xnh0 AoXUZulFPtcUUAp/q4/kchyRASwXNj+aRN2zLpA3gYnIGBjWiHmDNF/NtvH88ub/wfpB 7rp5WvPqB2VqHcuMKgLokG8i5JmIfoJUJh9XU= MIME-Version: 1.0 Received: by 10.52.107.33 with SMTP id gz1mr1820920vdb.153.1310130770058; Fri, 08 Jul 2011 06:12:50 -0700 (PDT) Received: by 10.52.101.170 with HTTP; Fri, 8 Jul 2011 06:12:49 -0700 (PDT) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507F3A@EMBX01-WF.jnpr.net> <4E80A8E8-7B29-426B-BB43-8FC269330E4B@network-heretics.com> <0622D8FB-2361-49C9-8E44-D70E7F1C2ADE@employees.org> Date: Fri, 8 Jul 2011 15:12:49 +0200 Message-ID: From: Turchanyi Geza To: Mohacsi Janos Content-Type: multipart/alternative; boundary=bcaec547c629289dbe04a78e97df Cc: IETF Discussion , "v6ops@ietf.org" , Keith Moore Subject: Re: [v6ops] 6to4 to Experimental? (was: Re: draft-ietf-v6ops-6to4-to-historic) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 13:12:52 -0000 --bcaec547c629289dbe04a78e97df Content-Type: text/plain; charset=ISO-8859-1 +1 On Fri, Jul 8, 2011 at 11:13 AM, Mohacsi Janos wrote: > > > > On Fri, 8 Jul 2011, Ole Troan wrote: > > Keith, >> >> The alternative that I proposed to IESG and to the chairs (and never >>> received any feedback about) was to reclassify 6to4 as Experimental. >>> Experimental seems completely appropriate for a protocol that is useful, but >>> only in corner cases. And I think it's also appropriate and useful to try >>> to learn from the experience with 6to4, even if we realize that 6to4 will >>> never be a generally applicable IPv6 transition solution again. >>> >>> And maybe, just maybe, Experimental will be enough of a "slap" at 6to4 to >>> mollify the "kill it yesterday" crowd. For one thing, it clearly indicates >>> that 6to4 is no longer a standard. >>> >>> But in order to quieten down the discussion here, I suggest that people >>> reply to me privately if they can't live with this. If I get lots of those >>> replies, I'll know that it's not worth pursuing. >>> >> >> "Experimental" is certainly better than: >> - nothing >> - spending months on hold as appeals are processed. >> > > I proposed experimental also when discussion started about future of 6to4. > I support the idea. > Best Regards, > Janos Mohacsi > > > ______________________________**_________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/**listinfo/v6ops > --bcaec547c629289dbe04a78e97df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

On Fri, Jul 8, 2011 at 11:13 AM, Mohac= si Janos <mohacsi@n= iif.hu> wrote:



On Fri, 8 Jul 2011, Ole Troan wrote:

Keith,

The alternative that I proposed to IESG and to the chairs (and never receiv= ed any feedback about) was to reclassify 6to4 as Experimental. =A0 Experime= ntal seems completely appropriate for a protocol that is useful, but only i= n corner cases. =A0And I think it's also appropriate and useful to try = to learn from the experience with 6to4, even if we realize that 6to4 will n= ever be a generally applicable IPv6 transition solution again.

And maybe, just maybe, Experimental will be enough of a "slap" at= 6to4 to mollify the "kill it yesterday" crowd. =A0For one thing,= it clearly indicates that 6to4 is no longer a standard.

But in order to quieten down the discussion here, I suggest that people rep= ly to me privately if they can't live with this. =A0 If I get lots of t= hose replies, I'll know that it's not worth pursuing.

"Experimental" is certainly better than:
- nothing
- spending months on hold as appeals are processed.

I proposed experimental also when discussion started about future of 6to4. = I support the idea.
=A0 =A0 =A0 =A0Best Regards,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Janos Mohacsi


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

--bcaec547c629289dbe04a78e97df-- From ek@google.com Fri Jul 8 08:06:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BA121F8ABE for ; Fri, 8 Jul 2011 08:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRAxtoELE4KG for ; Fri, 8 Jul 2011 08:06:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4644E21F8874 for ; Fri, 8 Jul 2011 08:06:36 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p68F6Z5a003080 for ; Fri, 8 Jul 2011 08:06:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310137595; bh=V81UTApkxkdzchrvc2JYmubv2t4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=AL9+QXhC7V65t3cAueay2H4wAUynBSRG5kbsArY3FptEdML+YpNXLneynilZH9g6N 9itKjeVXKA5a7w4YOJkGg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=ZFMMsFRHfdxTJYhuZu5oanS08k/yHik16WRtHcB3gx9C3m6YUoezLOwSZ8qbnViSt VVlaWQIWlWJrltqPwYkbA== Received: from pva4 (pva4.prod.google.com [10.241.209.4]) by hpaq12.eem.corp.google.com with ESMTP id p68F6W4b014938 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 8 Jul 2011 08:06:33 -0700 Received: by pva4 with SMTP id 4so1791571pva.16 for ; Fri, 08 Jul 2011 08:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2UrVTOIgi9wfSs/76+mnJxuu0toLWlJUKhC3uW/F64w=; b=fFvYyPVKgD01dzyF7KhNVjaVlKbRQY2yobTPMrSULf/kCJjHqEbavizZWYXXNWg+yf 60IfE1qWe6NPOy2vQj6Q== MIME-Version: 1.0 Received: by 10.68.25.166 with SMTP id d6mr2935004pbg.136.1310137591880; Fri, 08 Jul 2011 08:06:31 -0700 (PDT) Received: by 10.142.179.17 with HTTP; Fri, 8 Jul 2011 08:06:31 -0700 (PDT) In-Reply-To: References: <20110703111047.GB2304@Space.Net> <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> <8FBC436F-4357-4400-8B39-24EBFCBFB85E@ecs.soton.ac.uk> Date: Sat, 9 Jul 2011 00:06:31 +0900 Message-ID: From: Erik Kline To: Tim Chown Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 15:06:37 -0000 On 8 July 2011 19:11, Tim Chown wrote> On 6 Jul 2011, at 19:46, james woodyatt wrote: > >> On Jul 6, 2011, at 11:29 , Philip Homburg wrote: >>> >>> In that light, maybe it is good idea to direct hosts to ignore 6to4 prefixes >>> for the purpose of SLAAC... >> >> That's what I expect will have to be done if I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel isn't stopped. > > I recall that a hum to adopt the pmt draft as a WG item in Prague failed. Ditto. My own personal feeling is that if someone really wants to do this, so be it, but I see absolutely no reason why it should be standardized or have any more nod of approval from the IETF than an individual submission. From moore@network-heretics.com Fri Jul 8 09:43:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607F921F8BA8 for ; Fri, 8 Jul 2011 09:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrlhxFzAByRi for ; Fri, 8 Jul 2011 09:43:35 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id A7AC821F8BA6 for ; Fri, 8 Jul 2011 09:43:35 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 35A1320C18; Fri, 8 Jul 2011 12:43:35 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 08 Jul 2011 12:43:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=Evo0rNhlUIQynD1OFwuPOP4Wq28=; b=EyGUz9tqejVhyqSxW9fZxKd/epHk/0wqavJKhpsbuD1G4Qw4Aej+/hwWCWERKQYdbNKjpGZniM+jTtGOK3LoAPzwOsqw+jEh67ODlZD1pAevClOZS1fe/Vp/BYn2C5YWwV51OfaIL7ywTYvjfEHqx5tzRcr97Sn8MnwAp7aPCbg= X-Sasl-enc: AVBsRURRuCG4p4dmZXLKXkit5pDcZT36txuD9YaF6KJs 1310143414 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 2E710443614; Fri, 8 Jul 2011 12:43:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Fri, 8 Jul 2011 12:43:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110703111047.GB2304@Space.Net> <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> <8FBC436F-4357-4400-8B39-24EBFCBFB85E@ecs.soton.ac.uk> To: Erik Kline X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:43:36 -0000 On Jul 8, 2011, at 11:06 AM, Erik Kline wrote: > On 8 July 2011 19:11, Tim Chown wrote> On 6 Jul > 2011, at 19:46, james woodyatt wrote: >>=20 >>> On Jul 6, 2011, at 11:29 , Philip Homburg wrote: >>>>=20 >>>> In that light, maybe it is good idea to direct hosts to ignore 6to4 = prefixes >>>> for the purpose of SLAAC... >>>=20 >>> That's what I expect will have to be done if = I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel isn't stopped. >>=20 >> I recall that a hum to adopt the pmt draft as a WG item in Prague = failed. >=20 > Ditto. My own personal feeling is that if someone really wants to do > this, so be it, but I see absolutely no reason why it should be > standardized or have any more nod of approval from the IETF than an > individual submission. I have serious problems with the notion that ISPs should deliberately = break 6to4 (which is what this draft proposes to do, though in a subtle = and I presume unintentional way). One of the primary justifications for developing new applications that = use IPv6, is the ability to run those applications without having to = deal with NAT. Depending on the application, dealing with NAT in IPv4 = can require a huge investment in infrastructure - and this currently = serves as a barrier to deployment of new applications in IPv4. = NATting IPv6 makes IPv6 just as dysfunctional as IPv4. (And yeah, I = know some enterprise networks are going to do it anyway, but hopefully = they'll soon realize that they're only hurting themselves.) Honestly, I'd rather see ISPs set up relay routers that returned ICMP = network unreachable packets, than for them to apply this "fix". (Of = course, such relay routers should only be advertised to that ISP's own = customers.) Keith From ichiroumakino@gmail.com Fri Jul 8 10:33:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5717821F8BE9 for ; Fri, 8 Jul 2011 10:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OkDp+MD1oAN for ; Fri, 8 Jul 2011 10:33:13 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8624B21F85E5 for ; Fri, 8 Jul 2011 10:33:13 -0700 (PDT) Received: by bwb17 with SMTP id 17so2186492bwb.31 for ; Fri, 08 Jul 2011 10:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WJFnhkykFNHYuEQy8H90u2ihmrzmSb5aFH11IDK9+ZY=; b=rESt7Itjc9lYh7k8ZKC9JuMOTV14uJaYZfwU53f3feSS6uvw/9FPE4KDgn9IjY4n97 oBHnw14SG9XZC0Am0yieixbmvbUxDkx3GObayJJBEqAopia+UwG0nqDl2rxD0BI366tS 7tb/u4Zj6Pfpf+paEoMs/oUSU4aC+0KDhbCq0= Received: by 10.204.26.132 with SMTP id e4mr1571555bkc.142.1310146392474; Fri, 08 Jul 2011 10:33:12 -0700 (PDT) Received: from [192.168.2.102] (ip-114-20-179-93.dialup.ice.net [93.179.20.114]) by mx.google.com with ESMTPS id z16sm312652bkd.62.2011.07.08.10.33.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jul 2011 10:33:11 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Fri, 8 Jul 2011 19:33:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110703111047.GB2304@Space.Net> <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> <8FBC436F-4357-4400-8B39-24EBFCBFB85E@ecs.soton.ac.uk> To: Keith Moore X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:33:14 -0000 Keith, >>> I recall that a hum to adopt the pmt draft as a WG item in Prague = failed. >>=20 >> Ditto. My own personal feeling is that if someone really wants to do >> this, so be it, but I see absolutely no reason why it should be >> standardized or have any more nod of approval from the IETF than an >> individual submission. >=20 > I have serious problems with the notion that ISPs should deliberately = break 6to4 (which is what this draft proposes to do, though in a subtle = and I presume unintentional way). >=20 > One of the primary justifications for developing new applications that = use IPv6, is the ability to run those applications without having to = deal with NAT. Depending on the application, dealing with NAT in IPv4 = can require a huge investment in infrastructure - and this currently = serves as a barrier to deployment of new applications in IPv4. = NATting IPv6 makes IPv6 just as dysfunctional as IPv4. (And yeah, I = know some enterprise networks are going to do it anyway, but hopefully = they'll soon realize that they're only hurting themselves.) >=20 > Honestly, I'd rather see ISPs set up relay routers that returned ICMP = network unreachable packets, than for them to apply this "fix". (Of = course, such relay routers should only be advertised to that ISP's own = customers.) assuming that it is true (and I'm speculating) that most users running = 6to4 are unaware of it (consequence of default on in devices). then the pragmatic response by their ISP to help these users, would be = to PMT then. I believe the PMT draft allows for willing users to bypass = the prefix translation. I'm all for it, if we can't get rid of 6to4, then PMT it away from the = global Internet. introducing a relay router doesn't fix the return path. cheers, Ole From moore@network-heretics.com Fri Jul 8 11:19:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBD221F8B5B for ; Fri, 8 Jul 2011 11:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOxsg48aSidS for ; Fri, 8 Jul 2011 11:19:02 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 1006321F8B31 for ; Fri, 8 Jul 2011 11:19:02 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id BA7A520A3F; Fri, 8 Jul 2011 14:19:01 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 08 Jul 2011 14:19:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=00Q+Q5oCOlDwd7a1Wao0EbRik5o=; b=AGjhoJ+5zdyDlGDgheueTKLBR+389dcBFTG6OBT93/fHoW+XSMaG6BbGQhm5WXDDD3TVnGChcHIEyHhamKAScTVKVLupgQqoWbTizRO02AfiXjpubv1IBaGrG0iCfVD/NNvhjnL/kt/moNqEwJy1R4HqWD326RLMpurE7AXyi/Q= X-Sasl-enc: eTkH2jxwuVv09c3tZLJJ0kyYOs1OkiIHOsFrsvxxKHjy 1310149141 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id A7CF64436DA; Fri, 8 Jul 2011 14:19:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Fri, 8 Jul 2011 14:18:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110703111047.GB2304@Space.Net> <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> <8FBC436F-4357-4400-8B39-24EBFCBFB85E@ecs.soton.ac.uk> To: Ole Troan X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:19:03 -0000 >=20 > Keith, >=20 >>>> I recall that a hum to adopt the pmt draft as a WG item in Prague = failed. >>>=20 >>> Ditto. My own personal feeling is that if someone really wants to = do >>> this, so be it, but I see absolutely no reason why it should be >>> standardized or have any more nod of approval from the IETF than an >>> individual submission. >>=20 >> I have serious problems with the notion that ISPs should deliberately = break 6to4 (which is what this draft proposes to do, though in a subtle = and I presume unintentional way). >>=20 >> One of the primary justifications for developing new applications = that use IPv6, is the ability to run those applications without having = to deal with NAT. Depending on the application, dealing with NAT in = IPv4 can require a huge investment in infrastructure - and this = currently serves as a barrier to deployment of new applications in IPv4. = NATting IPv6 makes IPv6 just as dysfunctional as IPv4. (And yeah, = I know some enterprise networks are going to do it anyway, but hopefully = they'll soon realize that they're only hurting themselves.) >>=20 >> Honestly, I'd rather see ISPs set up relay routers that returned ICMP = network unreachable packets, than for them to apply this "fix". (Of = course, such relay routers should only be advertised to that ISP's own = customers.) >=20 > assuming that it is true (and I'm speculating) that most users running = 6to4 are unaware of it (consequence of default on in devices). > then the pragmatic response by their ISP to help these users, would be = to PMT then. I believe the PMT draft allows for willing users to bypass = the prefix translation. It's simply not acceptable for operators to NAT IPv6. =20 > introducing a relay router doesn't fix the return path. No, but a "relay router" that returned ICMP network unreachables would = (a) give applications a chance to realize that the address that they = chose did not work, and allow them to fail over to a different address = if one were available, and (b) provide a quick indication of failure to = the host (and hopefully the application) rather than waiting for a TCP = connection timeout. (I actually think there are other ways to fix the return path problem, = but they need more work.) Keith From rbonica@juniper.net Fri Jul 8 11:59:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04D521F8A04 for ; Fri, 8 Jul 2011 11:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd9uwdS3pu74 for ; Fri, 8 Jul 2011 11:59:31 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 25DB321F893E for ; Fri, 8 Jul 2011 11:59:31 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKThdTkrH1pMtNAB3bV3eSRYoAgW8rUQGs@postini.com; Fri, 08 Jul 2011 11:59:31 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 8 Jul 2011 11:56:07 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 8 Jul 2011 14:56:07 -0400 From: Ronald Bonica To: "v6ops@ietf.org" Date: Fri, 8 Jul 2011 14:56:05 -0400 Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic Thread-Index: Acw9m4kD4mWyC2GlRWWAmah59CQMJAABKVRg Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3915460@EMBX01-WF.jnpr.net> References: <20110703111047.GB2304@Space.Net> <159599EA-8812-400C-A6CA-506996DB1EBF@apple.com> <8FBC436F-4357-4400-8B39-24EBFCBFB85E@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:59:31 -0000 Chairs, What is the status of this email thread? At least one participant thinks th= at it has been ended or paused. Others think that it is still active. Are the floodgates open or closed? Also, it might be good to put time on the agenda in Quebec for this topic. Ron From Ted.Lemon@nominum.com Fri Jul 8 14:02:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1BC21F8903 for ; Fri, 8 Jul 2011 14:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsyfshEOjX3h for ; Fri, 8 Jul 2011 14:02:10 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id D5A4721F88E5 for ; Fri, 8 Jul 2011 14:02:09 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKThdwUALGMShDzFquV5Eh4ehq/a7EQf7s@postini.com; Fri, 08 Jul 2011 14:02:09 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 922011B834C for ; Fri, 8 Jul 2011 14:02:08 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 738FD190060 for ; Fri, 8 Jul 2011 14:02:08 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 8 Jul 2011 14:02:08 -0700 Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 8 Jul 2011 14:02:08 -0700 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jul 2011 17:02:04 -0400 Message-ID: <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> To: "v6ops@ietf.org Operations" MIME-Version: 1.0 (Apple Message framework v1242) X-Mailer: Apple Mail (2.1242) Subject: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 21:02:10 -0000 Maybe this is a dumb question, but it occurred to me today to check to = see if it's possible to receive mail from IPv6-enabled servers if your = MX record points to a name with a valid AAAA but no A record. Although = I had no trouble delivering the mail to my mail server using a telnet = session over IPv6, when I tried to send mail the usual way it bounced. = One MTA gave me this: : host other.example.com[10.20.30.40] said: 550 = MX record points to an invalid IP for domain:my.example.com - usmtp (in = reply to RCPT TO command) When I tried to send the mail from gmail, I got no bounce, but the mail = hasn't arrived after several hours, so I think it's safe to assume it's = not going to. I'd never thought to look into this issue before, so I suppose it's = possible that I'm missing some RFC that says SMTP is only supported for = now on dual-stack and v4-only devices, not on v6-only devices, but it = seems unlikely to me. So what's going on here? Are people disabling delivery over IPv6 for = operational reasons, or are the implementations broken? Is this = something we ought to be talking about? From dwmalone@maths.tcd.ie Thu Jul 7 12:20:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AE511E8091 for ; Thu, 7 Jul 2011 12:20:07 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHQBu8UmpiNN for ; Thu, 7 Jul 2011 12:20:06 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by ietfa.amsl.com (Postfix) with SMTP id D35D711E809C for ; Thu, 7 Jul 2011 12:20:05 -0700 (PDT) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 7 Jul 2011 20:20:04 +0100 (BST) Date: Thu, 7 Jul 2011 20:20:02 +0100 From: David Malone To: fred@cisco.com Message-ID: <20110707192002.GA29545@walton.maths.tcd.ie> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie X-Mailman-Approved-At: Fri, 08 Jul 2011 14:44:50 -0700 Cc: v6ops@ietf.org, draft-hilliard-v6ops-ipv6-discard-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 19:20:07 -0000 One possible security point arising from making a well-known allocation for traffic discard, is that there will then be a well-known traffic sink address available on the network. This means that attackers that want (say) to fill a link and then have the traffic vanish as quickly as possible can just generate traffic and send it to the well-known discard address. I'm not sure this is a big deal, but it might be worth discussing? It might also influence the choice of assigning a single address vs. a prefix, where network operators can blackhole randomly chosen addresses, rather than the whole prefix. David. From sander@steffann.nl Fri Jul 8 15:08:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F8321F8C09 for ; Fri, 8 Jul 2011 15:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiEOcJfzU315 for ; Fri, 8 Jul 2011 15:08:42 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9DA21F8C00 for ; Fri, 8 Jul 2011 15:08:42 -0700 (PDT) Received: from macpro.10ww.steffann.nl (unknown [IPv6:2001:610:6ce:1:224:36ff:feef:1d89]) by mail.sintact.nl (Postfix) with ESMTP id D699B2021; Sat, 9 Jul 2011 00:03:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <20110707192002.GA29545@walton.maths.tcd.ie> Date: Sat, 9 Jul 2011 00:03:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5B1574FB-CC39-414A-9A4F-D1DC131E8949@steffann.nl> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110707192002.GA29545@walton.maths.tcd.ie> To: David Malone X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , draft-hilliard-v6ops-ipv6-discard-prefix@tools.ietf.org Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 22:08:42 -0000 Hi, > One possible security point arising from making a well-known > allocation for traffic discard, is that there will then be a > well-known traffic sink address available on the network. This means > that attackers that want (say) to fill a link and then have the > traffic vanish as quickly as possible can just generate traffic and > send it to the well-known discard address. On the other hand: if there is a well-known discard address that is in = wide-spread use then the traffic will disappear at the first router that = supports it. If usage is wide-spread enough this might be before it even = goes onto the link :-) - Sander From moore@network-heretics.com Fri Jul 8 16:15:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4520421F8C6B for ; Fri, 8 Jul 2011 16:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1sFnK4b6p2J for ; Fri, 8 Jul 2011 16:15:16 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 861D021F8C27 for ; Fri, 8 Jul 2011 16:15:16 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 286E420C1A; Fri, 8 Jul 2011 19:15:16 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute5.internal (MEProxy); Fri, 08 Jul 2011 19:15:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=e+EsMY7vMPnenWKr4hcv3eaP1N0=; b=LVwUu2q8XQyAWBxMh3VHuOjw7RVvfQpS6rzhFmy5+RT5EwBHUT2h7Ize3MYz4uTm9K+gQR4jQMoCjiY0/evvp9NvU5FYfstrzzM6U9Ejzv3eIaTsv/eilXL89m5A9i+uXvwn43mbzWeQSIfE79xIXb2dz1icNqjC7sWkrh80FZA= X-Sasl-enc: ytzdfN/Np2Tt04GqcHfKQyHi6Fj/iQlemYtPaZjKYxqG 1310166915 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 54423443BE0; Fri, 8 Jul 2011 19:15:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> Date: Fri, 8 Jul 2011 19:15:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 23:15:17 -0000 On Jul 8, 2011, at 5:02 PM, Ted Lemon wrote: > Maybe this is a dumb question, but it occurred to me today to check to = see if it's possible to receive mail from IPv6-enabled servers if your = MX record points to a name with a valid AAAA but no A record. Although = I had no trouble delivering the mail to my mail server using a telnet = session over IPv6, when I tried to send mail the usual way it bounced. = One MTA gave me this: >=20 > : host other.example.com[10.20.30.40] said: 550 = MX > record points to an invalid IP for domain:my.example.com - usmtp (in = reply to > RCPT TO command) >=20 > When I tried to send the mail from gmail, I got no bounce, but the = mail hasn't arrived after several hours, so I think it's safe to assume = it's not going to. >=20 > I'd never thought to look into this issue before, so I suppose it's = possible that I'm missing some RFC that says SMTP is only supported for = now on dual-stack and v4-only devices, not on v6-only devices, but it = seems unlikely to me. >=20 > So what's going on here? Are people disabling delivery over IPv6 for = operational reasons, or are the implementations broken? Is this = something we ought to be talking about? There's no assurance that any MTA that is handling your outbound mail = has IPv6 capability, and no requirement that they provide such = capability. Practically speaking, you're going to need at least one IPv4-capable MX = for your domain for the foreseeable future. Keith From brian.e.carpenter@gmail.com Fri Jul 8 16:35:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC441F0C38; Fri, 8 Jul 2011 16:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xig4CWbMqaQ7; Fri, 8 Jul 2011 16:35:50 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3811A1F0C39; Fri, 8 Jul 2011 16:35:50 -0700 (PDT) Received: by fxe4 with SMTP id 4so3170341fxe.27 for ; Fri, 08 Jul 2011 16:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4UZCi/q3qCKTNw7ieuFfJl0zMF0M+vrx73553QoYQDA=; b=VkmISAwUWw5ICNVtffxHgpU55gdWnPoTjyn1UPsNDJ01gzxVViCfryhOWSq5GMXMrO uRpAd+Eqx3y8silaB2GbUusmOdjOcy5owCtehufegKhjNUuUEXqPTfmwl4Btat1PW4gg 7Z9byDibhwcA539/pYXwoxSZYMdNVwRbZ90bM= Received: by 10.223.59.17 with SMTP id j17mr767105fah.120.1310168149294; Fri, 08 Jul 2011 16:35:49 -0700 (PDT) Received: from ?IPv6:2001:388:f000::35? ([2001:388:f000::35]) by mx.google.com with ESMTPS id u20sm5522220fac.18.2011.07.08.16.35.44 (version=SSLv3 cipher=OTHER); Fri, 08 Jul 2011 16:35:48 -0700 (PDT) Message-ID: <4E179442.3050405@gmail.com> Date: Sat, 09 Jul 2011 11:35:30 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?Um9nZXIgSsO4cmdlbnNlbg==?= References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , IETF Discussion Subject: [v6ops] Dropping 2002::/16 considered very harmful X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 23:35:51 -0000 On 2011-07-08 19:16, Roger J=C3=B8rgensen wrote: > Guess I should clearify something, the thing I am considering are to > drop all 2002::/16 addresses hard, of course preferable return a > correct error messages to. This is an awesomely bad idea. As explained in the approved advisory document, it makes things worse for everybody (the user, the content provider, and the unfortunate person answering calls from either of them at the help desk). On the contrary - it's in everyone's interests to have the return path working. Once a user manages to get a packet to the content provider, everybody suffers if the return path fails. (However, if you are announcing a route to 2002::/16, it must lead to a relay that will relay all 6to4 packets, with no form of ACL). Brian From cb.list6@gmail.com Fri Jul 8 16:48:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9512321F871A; Fri, 8 Jul 2011 16:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXLfD+rcf6Cc; Fri, 8 Jul 2011 16:48:01 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D46121F86E2; Fri, 8 Jul 2011 16:48:01 -0700 (PDT) Received: by wyj26 with SMTP id 26so1869957wyj.31 for ; Fri, 08 Jul 2011 16:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mj/fDV+H6wjpnvRMQTeJIv7L04T8pIHAFIunlCdenbw=; b=czF5m3L0aETsZj/lCjHf4sHBFhY9jFvw+Ebu+UTSX7jS2dm+orXThIWhKW/j04YWVu rbQJBJ0GoePeyUkESoVuuLNxe01fAjPABQHaN+e19NDRY7gVeq2CM7rle90mWmjchQO8 MOlXSoYwAmfXGqlo3nRnprzX856MANBmJxN4s= MIME-Version: 1.0 Received: by 10.216.78.144 with SMTP id g16mr2139608wee.64.1310168878894; Fri, 08 Jul 2011 16:47:58 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Fri, 8 Jul 2011 16:47:58 -0700 (PDT) Received: by 10.216.39.83 with HTTP; Fri, 8 Jul 2011 16:47:58 -0700 (PDT) In-Reply-To: <4E179442.3050405@gmail.com> References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <4E179442.3050405@gmail.com> Date: Fri, 8 Jul 2011 16:47:58 -0700 Message-ID: From: Cameron Byrne To: Brian E Carpenter Content-Type: multipart/alternative; boundary=000e0ce0ce089f507504a797767d Cc: IETF Discussion , "v6ops@ietf.org" Subject: Re: [v6ops] Dropping 2002::/16 considered very harmful X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 23:48:02 -0000 --000e0ce0ce089f507504a797767d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I, for one, am not interested talking about 6to4 anymore. On Jul 8, 2011 4:36 PM, "Brian E Carpenter" wrote: > On 2011-07-08 19:16, Roger J=F8rgensen wrote: >> Guess I should clearify something, the thing I am considering are to >> drop all 2002::/16 addresses hard, of course preferable return a >> correct error messages to. > > This is an awesomely bad idea. As explained in the approved advisory > document, it makes things worse for everybody (the user, the content > provider, and the unfortunate person answering calls from either of > them at the help desk). > > On the contrary - it's in everyone's interests to have the return > path working. Once a user manages to get a packet to the content > provider, everybody suffers if the return path fails. > > (However, if you are announcing a route to 2002::/16, it must lead > to a relay that will relay all 6to4 packets, with no form of ACL). > > Brian > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --000e0ce0ce089f507504a797767d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I, for one, am not interested talking about 6to4 anymore.

On Jul 8, 2011 4:36 PM, "Brian E Carpenter&= quot; <brian.e.carpenter@= gmail.com> wrote:
> On 2011-07-08 19:16, = Roger J=F8rgensen wrote:
>> Guess I should clearify something, the thing I am considering are = to
>> drop all 2002::/16 addresses hard, of course preferable retu= rn a
>> correct error messages to.
>
> This is an awe= somely bad idea. As explained in the approved advisory
> document, it makes things worse for everybody (the user, the content> provider, and the unfortunate person answering calls from either of<= br>> them at the help desk).
>
> On the contrary - it's= in everyone's interests to have the return
> path working. Once a user manages to get a packet to the content
&g= t; provider, everybody suffers if the return path fails.
>
> (= However, if you are announcing a route to 2002::/16, it must lead
> t= o a relay that will relay all 6to4 packets, with no form of ACL).
>
> Brian
>
> ___________________________________= ____________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
--000e0ce0ce089f507504a797767d-- From ek@google.com Fri Jul 8 17:11:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BF921F8C0E for ; Fri, 8 Jul 2011 17:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.877 X-Spam-Level: X-Spam-Status: No, score=-105.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brdeGwas2tM0 for ; Fri, 8 Jul 2011 17:11:12 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id BBC8A21F8C0D for ; Fri, 8 Jul 2011 17:11:11 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p690BAPv007045 for ; Fri, 8 Jul 2011 17:11:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310170270; bh=RfnLDWql/UBH57MdXs2r73PeO2w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=EvsPuUczLN3ahhJNHhRUPnraOnEgsiP2BOo9ckIzllH47AjWkzaiH+7L7HDUKSqdw cOHhPgSH0RMOwoxtEiplw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=xqUvTGIdU3GrvElFBOKH8hmRhlsXAy2mxU7o+LxHPBel2GsXlHSyNP8a8wh4HsYej VPC1xgQzeM66nVVVWPwOA== Received: from pzk9 (pzk9.prod.google.com [10.243.19.137]) by hpaq1.eem.corp.google.com with ESMTP id p690B705016470 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 8 Jul 2011 17:11:08 -0700 Received: by pzk9 with SMTP id 9so2585539pzk.33 for ; Fri, 08 Jul 2011 17:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wZq+1D2lq+4dHHoNE5/84j3eJxGLwHZSxbFXgaXFBdI=; b=KfJJmEx9r/C3AhtFu9092F7WKJ7Fdf2XEP4o/VkxgozEzz7K4olX28LjsilUFxwiZi s3Z/DtxKq8lxkQG2x/sQ== MIME-Version: 1.0 Received: by 10.142.242.6 with SMTP id p6mr563143wfh.96.1310170267154; Fri, 08 Jul 2011 17:11:07 -0700 (PDT) Received: by 10.142.179.17 with HTTP; Fri, 8 Jul 2011 17:11:07 -0700 (PDT) In-Reply-To: <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> References: <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> Date: Sat, 9 Jul 2011 09:11:07 +0900 Message-ID: From: Erik Kline To: Ted Lemon Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 00:11:12 -0000 > When I tried to send the mail from gmail, I got no bounce, but the mail hasn't arrived after several hours, so I think it's safe to assume it's not going to. Gmail does not yet have IPv6-capable SMTP in nor out. It only has AAAAs for the web frontend as well as POP and IMAP. From victor.kuarsingh@gmail.com Fri Jul 8 17:19:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F6C21F8C6C for ; Fri, 8 Jul 2011 17:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R28iKZC2nBlc for ; Fri, 8 Jul 2011 17:19:58 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 596B321F8840 for ; Fri, 8 Jul 2011 17:19:58 -0700 (PDT) Received: by iwn39 with SMTP id 39so2666388iwn.31 for ; Fri, 08 Jul 2011 17:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=2sta6akb+/7yuW4jmRExiWqHv1+KGlhYJOXmPDGHOwA=; b=jv7JkM14iT6vr57jK5SEJYLG0IIEZ4UmQ7OEkkRRGc/j05UjCfmyJLqIuR/gLkFq0D CMw4p30FyThyaMkbQUTYB3Zk5Iysbzbu+dpWGUz+QpopIWPQFGjwPZPkr1EVOzsC4CQU OCu3Am+/MhzNvjrEBihYZXRqXGRuCMJ6Yic3E= Received: by 10.231.83.213 with SMTP id g21mr2279613ibl.100.1310170797890; Fri, 08 Jul 2011 17:19:57 -0700 (PDT) Received: from [192.168.100.89] ([67.224.83.163]) by mx.google.com with ESMTPS id x4sm5516919ibm.25.2011.07.08.17.19.55 (version=SSLv3 cipher=OTHER); Fri, 08 Jul 2011 17:19:57 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Fri, 08 Jul 2011 20:19:52 -0400 From: Victor Kuarsingh To: Ole Troan , Keith Moore Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 00:19:59 -0000 Ole On 11-07-08 1:33 PM, "Ole Troan" wrote: >Keith, > >>>> I recall that a hum to adopt the pmt draft as a WG item in Prague >>>>failed. >>> >>> Ditto. My own personal feeling is that if someone really wants to do >>> this, so be it, but I see absolutely no reason why it should be >>> standardized or have any more nod of approval from the IETF than an >>> individual submission. >> >> I have serious problems with the notion that ISPs should deliberately >>break 6to4 (which is what this draft proposes to do, though in a subtle >>and I presume unintentional way). >> >> One of the primary justifications for developing new applications that >>use IPv6, is the ability to run those applications without having to >>deal with NAT. Depending on the application, dealing with NAT in IPv4 >>can require a huge investment in infrastructure - and this currently >>serves as a barrier to deployment of new applications in IPv4. >>NATting IPv6 makes IPv6 just as dysfunctional as IPv4. (And yeah, I >>know some enterprise networks are going to do it anyway, but hopefully >>they'll soon realize that they're only hurting themselves.) >> >> Honestly, I'd rather see ISPs set up relay routers that returned ICMP >>network unreachable packets, than for them to apply this "fix". (Of >>course, such relay routers should only be advertised to that ISP's own >>customers.) > >assuming that it is true (and I'm speculating) that most users running >6to4 are unaware of it (consequence of default on in devices). >then the pragmatic response by their ISP to help these users, would be to >PMT then. I believe the PMT draft allows for willing users to bypass the >prefix translation. Yes, you can by-pass if you are are an "aware" 6to4 user. Have fun with the global system. > >I'm all for it, if we can't get rid of 6to4, then PMT it away from the >global Internet. Our experience from WIPv6 (also before and after) was that PMT worked well. We have users in both camps, some were PMTed and others were not. Both can work in parallel. Default deployments (Policy is b Subnet-ID) using subnet-ID 0 were translated and appeared with native IPv6 address to the Internet (I.e. When going to some content). >From a performance perspective, similar as 6RD based on our tests. Most users did not notice other then much improved RTTs and removal of dependancy on remote relays. > >introducing a relay router doesn't fix the return path. Correct. There are some improvements as we saw in our network, and others like Comcast saw in their network (per draft-jjmb-v6ops-comcast-ipv6-experiences-01). > >cheers, >Ole > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From moore@network-heretics.com Fri Jul 8 17:28:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E871111E8072 for ; Fri, 8 Jul 2011 17:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yoaq6VBAgKN for ; Fri, 8 Jul 2011 17:28:58 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 4761611E8071 for ; Fri, 8 Jul 2011 17:28:58 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id EB22120940; Fri, 8 Jul 2011 20:28:57 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 08 Jul 2011 20:28:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=DRkpeotS+Ep0S//CiJKsSmZvy8E=; b=qFTP/28TwOb+0905//E3RLBhyKL5WDNLSdfrlSAKUkVB43+XeOM4zJYpVmNfdl01furZYnWiVtgP+L1CNIXgeou1GdiHddGxNBMKsac+i2ncYfIZTm2DEsGAymSf3GvrmVD5tJJgzNAVhkWtAp2Oyv2Y3QAb8devETIUPXfMA5o= X-Sasl-enc: V7mOClwPRHKzY4vM+k9+PmOuN34vbJR32qJkmk3A+Nd2 1310171337 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 21D784438B6; Fri, 8 Jul 2011 20:28:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Fri, 8 Jul 2011 20:28:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <21EC2CBB-4766-4157-B5B3-3CF74B1CBED4@network-heretics.com> References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 00:28:59 -0000 On Jul 8, 2011, at 8:19 PM, Victor Kuarsingh wrote: > Our experience from WIPv6 (also before and after) was that PMT worked > well. =20 A lot of people think IPv4 NAT works well too. Then when an application = doesn't work, they blame the application. Or when an application fails = to succeed because the IPv4 network is dysfunctional, and there's not a = big enough market to support the infrastructure required to work well = thorough NAT, users never realize that they lost the ability to run = something useful because of NAT. NAT is completely unacceptable for IPv6. Keith From yiu_lee@cable.comcast.com Fri Jul 8 17:35:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F2111E809B for ; Fri, 8 Jul 2011 17:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.731 X-Spam-Level: X-Spam-Status: No, score=-106.731 tagged_above=-999 required=5 tests=[AWL=1.732, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBfq9vO-BHiZ for ; Fri, 8 Jul 2011 17:35:56 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 40CBB11E8099 for ; Fri, 8 Jul 2011 17:35:56 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.133562326; Fri, 08 Jul 2011 20:35:54 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Fri, 8 Jul 2011 20:35:54 -0400 From: "Lee, Yiu" To: Keith Moore , Victor Kuarsingh Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic Thread-Index: AQHMPdAcmEXRYv+ZFUK6veCh3bERww== Date: Sat, 9 Jul 2011 00:35:53 +0000 Message-ID: In-Reply-To: <21EC2CBB-4766-4157-B5B3-3CF74B1CBED4@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <13650083E12D104B989C990C39F4D895@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 00:35:57 -0000 I don't think Victor implies he promotes NAT for IPv6. I believe he is very much promoting native IPv6. All he said was trying to improve the RTT for 6to4 users. He also provides a way to opt-out if NAT is a concern. On 7/8/11 8:28 PM, "Keith Moore" wrote: >On Jul 8, 2011, at 8:19 PM, Victor Kuarsingh wrote: > >> Our experience from WIPv6 (also before and after) was that PMT worked >> well. =20 > >A lot of people think IPv4 NAT works well too. Then when an application >doesn't work, they blame the application. Or when an application fails >to succeed because the IPv4 network is dysfunctional, and there's not a >big enough market to support the infrastructure required to work well >thorough NAT, users never realize that they lost the ability to run >something useful because of NAT. > >NAT is completely unacceptable for IPv6. > >Keith > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Fri Jul 8 17:46:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A862921F877D for ; Fri, 8 Jul 2011 17:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.087 X-Spam-Level: X-Spam-Status: No, score=-102.087 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk8VV+MHQu5u for ; Fri, 8 Jul 2011 17:46:39 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EEF0221F8782 for ; Fri, 8 Jul 2011 17:46:38 -0700 (PDT) Received: from [192.168.11.127] (c-76-115-172-69.hsd1.wa.comcast.net [76.115.172.69]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p690kafl079474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 9 Jul 2011 00:46:37 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-84--994774049 From: Joel Jaeggli In-Reply-To: Date: Fri, 8 Jul 2011 17:46:31 -0700 Message-Id: <449FDB7D-B28A-400E-8B88-7A1DC2E67ECF@bogus.com> References: <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.com> <54E20C35-711A-48ED-9050-DA81C505EBDB@bogus.com> To: John Mann (ITS) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 09 Jul 2011 00:46:37 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 00:46:39 -0000 --Apple-Mail-84--994774049 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii cool, could we potentially pigeonhole you for a review of the doc from the = vantage point of someone using it? joel On Jul 7, 2011, at 8:09 PM, John Mann (ITS) wrote: > Joel, >=20 > On 4 July 2011 09:37, Joel Jaeggli wrote: > ... > yeah, I think the question of do isatap implementers or users in = v6ops find this line of work interesting and useful is essentially the = open question thatwould cause us to consider advancing this as a wg = document vs allowing you to pursue it as an indivudal submission. I = think that preaking shcpv6 out of it is a wise idea. > ... >=20 > I am doing an ISATAP deployment, think the document is = useful/interesting, and I support advancing this as a WG document. >=20 > Thanks, > John > =20 >=20 --Apple-Mail-84--994774049 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii cool,

could we potentially pigeonhole you for a review of the doc from the vantage point of someone using it?

joel

On Jul 7, 2011, at 8:09 PM, John Mann (ITS) wrote:

Joel,

On 4 July 2011 09:37, Joel Jaeggli <joelja@bogus.com> wrote:
...
yeah, I think the question of do isatap implementers  or users in v6ops find this line of work interesting and useful is essentially the open question thatwould cause us to consider advancing this as a wg document vs allowing you to pursue it as an indivudal submission. I think that preaking shcpv6 out of it is a wise idea.
...

I am doing an ISATAP deployment, think the document is useful/interesting, and I support advancing this as a WG document.

Thanks,
    John
 


--Apple-Mail-84--994774049-- From moore@network-heretics.com Fri Jul 8 17:49:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE801F0C3B for ; Fri, 8 Jul 2011 17:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpnRtm+q5Jsp for ; Fri, 8 Jul 2011 17:49:30 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id B25A31F0C39 for ; Fri, 8 Jul 2011 17:49:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 6C16E20AE4; Fri, 8 Jul 2011 20:49:30 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 08 Jul 2011 20:49:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=FYFDK3kv1wa+8uE3bLAibNu1wGQ=; b=ulCx19JealhvpllzDoK7RFMu9w5wG2NZlBTqkPdXwujmZWqqPNn0ZsRqZVeekR18/ntTrLqfVsn2az/YX/CKtdWCZnocyuU7BfM2UAEY0M5XlPOhiBZC37DKe6le7hjkqJOxHvLKz6eC8AQh76FXoGOcWXkhZjDgD/JjpcAN+4M= X-Sasl-enc: Ap56Em+uld4hdulkwV1idZ7/3Xj+Wb6Md7Fw7axqE+7v 1310172569 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 7B5904413F6; Fri, 8 Jul 2011 20:49:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Fri, 8 Jul 2011 20:49:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 00:49:31 -0000 It's still imposing NAT by default. That's a lot worse than, say, using = 6to4 by default in preference to IPv4. I believe there's widespread agreement on a number of measures which = should reduce accidental/casual use of 6to4. As for the return-path = problem for the remaining users of 6to4, there are better ways to = improve that situation than with NAT. Keith On Jul 8, 2011, at 8:35 PM, Lee, Yiu wrote: > I don't think Victor implies he promotes NAT for IPv6. I believe he is > very much promoting native IPv6. All he said was trying to improve the = RTT > for 6to4 users. He also provides a way to opt-out if NAT is a concern. >=20 >=20 > On 7/8/11 8:28 PM, "Keith Moore" wrote: >=20 >> On Jul 8, 2011, at 8:19 PM, Victor Kuarsingh wrote: >>=20 >>> Our experience from WIPv6 (also before and after) was that PMT = worked >>> well. =20 >>=20 >> A lot of people think IPv4 NAT works well too. Then when an = application >> doesn't work, they blame the application. Or when an application = fails >> to succeed because the IPv4 network is dysfunctional, and there's not = a >> big enough market to support the infrastructure required to work well >> thorough NAT, users never realize that they lost the ability to run >> something useful because of NAT. >>=20 >> NAT is completely unacceptable for IPv6. >>=20 >> Keith >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From john_brzozowski@cable.comcast.com Fri Jul 8 18:20:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59B89E8009 for ; Fri, 8 Jul 2011 18:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.463 X-Spam-Level: X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CbR9pUoXJZe for ; Fri, 8 Jul 2011 18:20:04 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id C0DAC9E8004 for ; Fri, 8 Jul 2011 18:20:03 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.133563808; Fri, 08 Jul 2011 21:19:59 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Fri, 8 Jul 2011 21:19:59 -0400 From: "Brzozowski, John" To: Ted Lemon , "v6ops@ietf.org Operations" Thread-Topic: [v6ops] IPv6-only SMTP delivery? Thread-Index: AQHMPbJcaPjCIP9QU0iKxxFZ18J86ZTjMTsA Date: Sat, 9 Jul 2011 01:19:57 +0000 Message-ID: In-Reply-To: <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [98.225.180.189] Content-Type: text/plain; charset="us-ascii" Content-ID: <43C32B8D83383C4CA006A7A5E1FF5C36@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 01:20:04 -0000 Ted, I think there is an assumption here that mail sent to an SMTP server for delivery could be IPv6 only, however, the transmission to the destination will likely be dual stack for some time and more than likely default to IPv4 only. We have recently enabled as part of our trials SMTP servers for Comcast trial users to send mail through, however when delivering the same there is an assumption that the server is dual stack. We do not yet have inbound mail receipt enabled over IPv6. Spam mitigation for IPv6 does not appear to ready just yet. To answer your question, the choice at this time appears to be operational. FWIW - when mail is sent via mail servers over IPv6 the message header on the receiving end will in fact report the source IPv6 address. This is at least what we have observed. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 7/8/11 5:02 PM, "Ted Lemon" wrote: >Maybe this is a dumb question, but it occurred to me today to check to >see if it's possible to receive mail from IPv6-enabled servers if your MX >record points to a name with a valid AAAA but no A record. Although I >had no trouble delivering the mail to my mail server using a telnet >session over IPv6, when I tried to send mail the usual way it bounced. >One MTA gave me this: > >: host other.example.com[10.20.30.40] said: 550 MX > record points to an invalid IP for domain:my.example.com - usmtp (in >reply to > RCPT TO command) > >When I tried to send the mail from gmail, I got no bounce, but the mail >hasn't arrived after several hours, so I think it's safe to assume it's >not going to. > >I'd never thought to look into this issue before, so I suppose it's >possible that I'm missing some RFC that says SMTP is only supported for >now on dual-stack and v4-only devices, not on v6-only devices, but it >seems unlikely to me. > >So what's going on here? Are people disabling delivery over IPv6 for >operational reasons, or are the implementations broken? Is this something >we ought to be talking about? >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From victor.kuarsingh@gmail.com Fri Jul 8 18:38:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD1321F8C53 for ; Fri, 8 Jul 2011 18:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKWoduY8eyQ9 for ; Fri, 8 Jul 2011 18:38:44 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99F7021F8C57 for ; Fri, 8 Jul 2011 18:38:44 -0700 (PDT) Received: by iwn39 with SMTP id 39so2703084iwn.31 for ; Fri, 08 Jul 2011 18:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=EueQojJik6a4HLzy5Tng3HNjSKUGjPVclOGFZjSfck8=; b=HS3/jbUgzR3SOANRnh8xbxzFHuzC3Ypc8I3h7woXrV8IBG4WMNODloZTFRPB+Lv26G Mq7eCmTWOeBGnNr/496TR3tg/IoDm4t9KAZlep0tNrLJcK8h4NQZ71sAvox0ob7O6+bv iTL7G57sWVaAQLeGlHQoa9c71f8ABBi4poOY4= Received: by 10.42.132.72 with SMTP id c8mr2502571ict.505.1310175524007; Fri, 08 Jul 2011 18:38:44 -0700 (PDT) Received: from [192.168.100.89] ([67.224.83.163]) by mx.google.com with ESMTPS id hw7sm11403234icc.15.2011.07.08.18.38.36 (version=SSLv3 cipher=OTHER); Fri, 08 Jul 2011 18:38:43 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Fri, 08 Jul 2011 21:38:13 -0400 From: Victor Kuarsingh To: Keith Moore , "Lee, Yiu" Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6to4-to-historic In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 01:38:45 -0000 Keith, >It's still imposing NAT by default. That's a lot worse than, say, using >6to4 by default in preference to IPv4. Agreed. NAT is less then desirable. Although the imposition of NAT is to deal with a problematic connection where the default behaviour may cause problems. So the choice being made is not NAT vs. Good IPv6, but NAT vs. Problematic IPv6. The goal is to make the user experience better. Users (the average user) tend to look for the cosmetics in the Internet experience. "I" click on some content, it shows up on "my" screen - I am happy (the ugly mechanics of the connection doesn't seem to keep them up at night). I am not suggesting for moment that 6to4 with PMT will make all things beautiful. It's to fix/manage a challenge during this period of initial transition (as content states to become available on IPv6 but native deployments lag). This is temporary until Native is deployed (as I assume we all agree that 6to4 - even if all major Operators had relays etc - is not the strategic answer for IPv6 deployments). > >I believe there's widespread agreement on a number of measures which >should reduce accidental/casual use of 6to4. As for the return-path >problem for the remaining users of 6to4, there are better ways to improve >that situation than with NAT. Sure, and if the measures make it out to the deployed hosts/hardware then great. My concern is we are talking about it; and by the time the group decides on how best to guide the protocol; vendors/developers implement it; and it's pushed out - it may be too late. 6to4 is a problem now not later. If these measures are implemented later, then back to normal 6to4 we go. Victor K > >Keith > >On Jul 8, 2011, at 8:35 PM, Lee, Yiu wrote: > >> I don't think Victor implies he promotes NAT for IPv6. I believe he is >> very much promoting native IPv6. All he said was trying to improve the >>RTT >> for 6to4 users. He also provides a way to opt-out if NAT is a concern. >> >> >> On 7/8/11 8:28 PM, "Keith Moore" wrote: >> >>> On Jul 8, 2011, at 8:19 PM, Victor Kuarsingh wrote: >>> >>>> Our experience from WIPv6 (also before and after) was that PMT worked >>>> well. >>> >>> A lot of people think IPv4 NAT works well too. Then when an >>>application >>> doesn't work, they blame the application. Or when an application fails >>> to succeed because the IPv4 network is dysfunctional, and there's not a >>> big enough market to support the infrastructure required to work well >>> thorough NAT, users never realize that they lost the ability to run >>> something useful because of NAT. >>> >>> NAT is completely unacceptable for IPv6. >>> >>> Keith >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> > From moore@network-heretics.com Fri Jul 8 19:02:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D9521F8B88 for ; Fri, 8 Jul 2011 19:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdOcB0J7ZbzB for ; Fri, 8 Jul 2011 19:02:28 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id BFCCE21F8B80 for ; Fri, 8 Jul 2011 19:02:23 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 2D8E6207B7; Fri, 8 Jul 2011 22:02:23 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 08 Jul 2011 22:02:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=SWR9AMXIm3xxfKMl1WxSLPlpdsY=; b=ON+vOjRR1P1b1pckGxVLDxibvITm7mcsVN/HJJmSOCUXgzSGmP443mpbvsCuQJpOKzYCAXTyCh0NxEqyA/j3xR2WRcJr/JFl+yuKW21rHVOiw6aYhA6f3vk9H3LNXDqdoDJXEovMy23dzPIpO2u0Vuyfa+4YjGYIx+kHhnYyvx8= X-Sasl-enc: WFSA2xfc/6dtsp71bgfDbv/XpOg7ANAbqpWsCp0ysib4 1310176942 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 1BD8C443CA0; Fri, 8 Jul 2011 22:02:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Fri, 8 Jul 2011 22:02:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 02:02:30 -0000 On Jul 8, 2011, at 9:38 PM, Victor Kuarsingh wrote: > Keith, >=20 >> It's still imposing NAT by default. That's a lot worse than, say, = using >> 6to4 by default in preference to IPv4. >=20 > Agreed. NAT is less then desirable. Although the imposition of NAT = is to > deal with a problematic connection where the default behaviour may = cause > problems. So the choice being made is not NAT vs. Good IPv6, but NAT = vs. > Problematic IPv6. No, that's a mischaracterization. In many cases the IPv6 service = provided by 6to4 is good. And it's not the case that 6to4 with PMT is = better than bad 6to4. Even in those cases, PMT just replaces one kind = of brokenness with another, and the brokenness imposed by PMT is even = more subtle and harder to diagnose. Again, it would be far better to = impose a relay router that always returned ICMP network unreachable = messages than to impose PMT. > The goal is to make the user experience better. Users (the average = user) > tend to look for the cosmetics in the Internet experience. "I" click = on > some content, it shows up on "my" screen - I am happy (the ugly = mechanics > of the connection doesn't seem to keep them up at night). It's a mistake to judge 6to4 by how well it works with HTTP. It's also = a mistake to use 6to4 (or any other v6-over-v4 tunnel) in preference to = IPv4 for HTTP (or any other common client-server protocol that works = fine through NAT). 6to4 and other v6-over-v4 tunneling technologies = should be used for apps that need v6. The default behavior for hosts = should be to prefer native v6 > native v4 > tunneled v6 over v4. = There's no disagreement about that, and the default is being fixed. = Once the default is fixed, it's a good bet that any application that = explicitly chooses to use IPv6 actually wants IPv6, and there's a good = chance that the reason that the app wants v6 is to avoid NAT. > I am not suggesting for moment that 6to4 with PMT will make all things > beautiful. It's to fix/manage a challenge during this period of = initial > transition (as content states to become available on IPv6 but native > deployments lag). This is temporary until Native is deployed (as I = assume > we all agree that 6to4 - even if all major Operators had relays etc - = is > not the strategic answer for IPv6 deployments). It's not acceptable to harm applications that use 6to4 just because = native v6 isn't here yet. You might not believe that PMT will harm = 6to4, but it will. >> I believe there's widespread agreement on a number of measures which >> should reduce accidental/casual use of 6to4. As for the return-path >> problem for the remaining users of 6to4, there are better ways to = improve >> that situation than with NAT. >=20 > Sure, and if the measures make it out to the deployed hosts/hardware = then > great. My concern is we are talking about it; and by the time the = group > decides on how best to guide the protocol; vendors/developers = implement > it; and it's pushed out - it may be too late. > 6to4 is a problem now not later. If these measures are implemented = later, > then back to normal 6to4 we go. 6to4 is not a problem; rather, poor operational practices are causing = problems with 6to4. You're proposing yet another poor operational = practice. And fixes for at least some of the problems associated with 6to4 are = already in the pipeline. Implementations will be updated to disable = 6to4 by default, and to choose v4 in preference to 6to4.=20 Keith From bigbadbob0@gmail.com Fri Jul 8 19:16:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A869321F8BF9 for ; Fri, 8 Jul 2011 19:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx7gqVs9EhyU for ; Fri, 8 Jul 2011 19:16:47 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C615821F8BF8 for ; Fri, 8 Jul 2011 19:16:47 -0700 (PDT) Received: by qyk9 with SMTP id 9so677598qyk.10 for ; Fri, 08 Jul 2011 19:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=p80FLsoJrk+Kq0TceoxXrg8spc7Bi8lF8GouZ7s3GMU=; b=dII5+g8TlV0JKEdBDw5mjkYgxta5DwlstsnUB83mT9oNgNRrHBxe6Op1+KVU7QBhfL aEqW1Uq8T0v7EWrW1fRE9ajKLnGTkOzHxYoj6lnnHMwCxvRlM4e/Jwn3W98drUsUwMsu BAaYRb+ClBFnQ3X9L6FUlHZWe/ErBIp2hVXZo= MIME-Version: 1.0 Received: by 10.229.217.3 with SMTP id hk3mr380092qcb.38.1310177806633; Fri, 08 Jul 2011 19:16:46 -0700 (PDT) Sender: bigbadbob0@gmail.com Received: by 10.229.192.16 with HTTP; Fri, 8 Jul 2011 19:16:46 -0700 (PDT) In-Reply-To: References: <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> Date: Fri, 8 Jul 2011 19:16:46 -0700 X-Google-Sender-Auth: NcmDQQzp9qCB3ubnbgCalqVdhc0 Message-ID: From: Bob Van Zant To: "Brzozowski, John" , Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 02:18:01 -0000 I have an IPv6 email reflector setup here for anyone that wants to goof around and see what at least one other MX on the Internet sees. ipv6@test-ipv6.veznat.com I've had my email domains accepting email over v6 for about a year now. Spam filtering with only content filtering (no IP reputation) has been working out well. IPv6 email as a percentage of total email is paltry and spam as a percentage of that is way below what I see on IPv4. I say flip a AAAA on one of your less important MX records and start experimenting. -Bob On Fri, Jul 8, 2011 at 6:19 PM, Brzozowski, John wrote: > Ted, > > I think there is an assumption here that mail sent to an SMTP server for > delivery could be IPv6 only, however, the transmission to the destination > will likely be dual stack for some time and more than likely default to > IPv4 only. =A0We have recently enabled as part of our trials SMTP servers > for Comcast trial users to send mail through, however when delivering the > same there is an assumption that the server is dual stack. > > We do not yet have inbound mail receipt enabled over IPv6. =A0Spam > mitigation for IPv6 does not appear to ready just yet. > > To answer your question, the choice at this time appears to be operationa= l. > > FWIW - when mail is sent via mail servers over IPv6 the message header on > the receiving end will in fact report the source IPv6 address. =A0This is= at > least what we have observed. > > John > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski@cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > On 7/8/11 5:02 PM, "Ted Lemon" wrote: > >>Maybe this is a dumb question, but it occurred to me today to check to >>see if it's possible to receive mail from IPv6-enabled servers if your MX >>record points to a name with a valid AAAA but no A record. =A0 Although I >>had no trouble delivering the mail to my mail server using a telnet >>session over IPv6, when I tried to send mail the usual way it bounced. >>One MTA gave me this: >> >>: host other.example.com[10.20.30.40] said: 550 MX >> record points to an invalid IP for domain:my.example.com - usmtp (in >>reply to >> RCPT TO command) >> >>When I tried to send the mail from gmail, I got no bounce, but the mail >>hasn't arrived after several hours, so I think it's safe to assume it's >>not going to. >> >>I'd never thought to look into this issue before, so I suppose it's >>possible that I'm missing some RFC that says SMTP is only supported for >>now on dual-stack and v4-only devices, not on v6-only devices, but it >>seems unlikely to me. >> >>So what's going on here? =A0 Are people disabling delivery over IPv6 for >>operational reasons, or are the implementations broken? Is this something >>we ought to be talking about? >>_______________________________________________ >>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 Ted.Lemon@nominum.com Fri Jul 8 19:51:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1C821F88EF for ; Fri, 8 Jul 2011 19:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+58yZAS4KO7 for ; Fri, 8 Jul 2011 19:51:25 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2026721F88D5 for ; Fri, 8 Jul 2011 19:51:25 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKThfCLKeiu2XE21BKDwcGlr5XNGpj7MK0@postini.com; Fri, 08 Jul 2011 19:51:25 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 379C31B833A for ; Fri, 8 Jul 2011 19:51:24 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 22A2E190064; Fri, 8 Jul 2011 19:51:24 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 8 Jul 2011 19:51:24 -0700 Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 8 Jul 2011 19:51:23 -0700 MIME-Version: 1.0 (Apple Message framework v1242) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Fri, 8 Jul 2011 22:51:19 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <897F24ED-743C-4236-8351-A5C5B3D73BC5@nominum.com> References: <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> To: Keith Moore X-Mailer: Apple Mail (2.1242) Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 02:51:25 -0000 On Jul 8, 2011, at 7:15 PM, Keith Moore wrote: > There's no assurance that any MTA that is handling your outbound mail = has IPv6 capability, and no requirement that they provide such = capability. >=20 > Practically speaking, you're going to need at least one IPv4-capable = MX for your domain for the foreseeable future. That's not the question I was asking. Erik's response is more on = point, because he's speaking to his own company's operations. The real = question I'm asking is, is this something we ought to be talking about? From Ted.Lemon@nominum.com Fri Jul 8 19:57:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF8721F8B2B for ; Fri, 8 Jul 2011 19:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJgYY9kmQcGP for ; Fri, 8 Jul 2011 19:57:28 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 111BB21F8B1B for ; Fri, 8 Jul 2011 19:57:28 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKThfDl5B53aEFeIxv/Vh1y6GPgfgEiTT/@postini.com; Fri, 08 Jul 2011 19:57:28 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 48B771B833A for ; Fri, 8 Jul 2011 19:57:27 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3DD63190064; Fri, 8 Jul 2011 19:57:27 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-02.WIN.NOMINUM.COM (64.89.228.132) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 8 Jul 2011 19:57:27 -0700 Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 8 Jul 2011 19:57:26 -0700 MIME-Version: 1.0 (Apple Message framework v1242) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Fri, 8 Jul 2011 22:57:20 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <74FC4DBC-0678-4EA3-AFF0-4B06A63C00D3@nominum.com> References: To: "Brzozowski, John" X-Mailer: Apple Mail (2.1242) Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 02:57:28 -0000 On Jul 8, 2011, at 9:19 PM, Brzozowski, John wrote: > I think there is an assumption here that mail sent to an SMTP server = for > delivery could be IPv6 only, however, the transmission to the = destination > will likely be dual stack for some time and more than likely default = to > IPv4 only. We have recently enabled as part of our trials SMTP = servers > for Comcast trial users to send mail through, however when delivering = the > same there is an assumption that the server is dual stack. >=20 > We do not yet have inbound mail receipt enabled over IPv6. Spam > mitigation for IPv6 does not appear to ready just yet. This is exactly what I'm interested in. It makes sense that you = wouldn't enable inbound SMTP for precisely this reason. But why not = enable it for outbound? I think Erik's answer makes sense, although = it's a bit unfortunate, but if you have the operational capability to = make an outbound IPv6 SMTP connection, is there any reason why you'd = deliberately disable it? From john_brzozowski@cable.comcast.com Fri Jul 8 20:06:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDF51F0C3E for ; Fri, 8 Jul 2011 20:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6PSiGNawjW1 for ; Fri, 8 Jul 2011 20:06:05 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6AC1F0C3C for ; Fri, 8 Jul 2011 20:06:05 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.43939798; Fri, 08 Jul 2011 21:10:14 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Fri, 8 Jul 2011 23:06:02 -0400 From: "Brzozowski, John" To: Ted Lemon Thread-Topic: [v6ops] IPv6-only SMTP delivery? Thread-Index: AQHMPbJcaPjCIP9QU0iKxxFZ18J86ZTjMTsAgABeRAD//79dgA== Date: Sat, 9 Jul 2011 03:06:01 +0000 Message-ID: In-Reply-To: <74FC4DBC-0678-4EA3-AFF0-4B06A63C00D3@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 03:06:08 -0000 We are looking at outbound, the work right now is to ensure the mail platform is stable and scales, etc. Once all of this is ready one could simply add AAAAs for the SMTP servers. The issue of connectivity may come into play specifically if mail clients think they have some form of IPv6 but truly do not or the same is poor. I suspect SMTP would be more forgiving unlike end users visiting web sites (HTTP). John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 7/8/11 10:57 PM, "Ted Lemon" wrote: >On Jul 8, 2011, at 9:19 PM, Brzozowski, John wrote: >> I think there is an assumption here that mail sent to an SMTP server for >> delivery could be IPv6 only, however, the transmission to the >>destination >> will likely be dual stack for some time and more than likely default to >> IPv4 only. We have recently enabled as part of our trials SMTP servers >> for Comcast trial users to send mail through, however when delivering >>the >> same there is an assumption that the server is dual stack. >>=20 >> We do not yet have inbound mail receipt enabled over IPv6. Spam >> mitigation for IPv6 does not appear to ready just yet. > >This is exactly what I'm interested in. It makes sense that you >wouldn't enable inbound SMTP for precisely this reason. But why not >enable it for outbound? I think Erik's answer makes sense, although >it's a bit unfortunate, but if you have the operational capability to >make an outbound IPv6 SMTP connection, is there any reason why you'd >deliberately disable it? > From Ted.Lemon@nominum.com Fri Jul 8 20:33:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E68F1F0C3C for ; Fri, 8 Jul 2011 20:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aRWc-cW7ALk for ; Fri, 8 Jul 2011 20:33:28 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id EE6331F0C34 for ; Fri, 8 Jul 2011 20:33:27 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKThfMBytHEPqk7ncki7EBKRAQKdS0S7Fz@postini.com; Fri, 08 Jul 2011 20:33:28 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DEC501B834D for ; Fri, 8 Jul 2011 20:33:26 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CA0A8190064; Fri, 8 Jul 2011 20:33:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 8 Jul 2011 20:33:15 -0700 Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 8 Jul 2011 20:33:15 -0700 MIME-Version: 1.0 (Apple Message framework v1242) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Fri, 8 Jul 2011 23:33:11 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: "Brzozowski, John" X-Mailer: Apple Mail (2.1242) Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 03:33:28 -0000 On Jul 8, 2011, at 11:06 PM, Brzozowski, John wrote: > The issue of connectivity may come > into play specifically if mail clients think they have some form of = IPv6 > but truly do not or the same is poor. I suspect SMTP would be more > forgiving unlike end users visiting web sites (HTTP). Certainly *submitting* mail over SMTP when you have a non-working IPv6 = prefix would introduce a delivery delay, but as long as the MUA tries v4 = as well as v6, the end-user isn't likely to notice it. But for = outbound SMTP, it's really not a problem. Any MTA worth its salt = already understands how to try alternatives, and SMTP is a = store-and-forward protocol, so instant delivery isn't particularly = expected. From v6ops@globis.net Fri Jul 8 23:41:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76C921F86E9 for ; Fri, 8 Jul 2011 23:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCGiMamLbKlK for ; Fri, 8 Jul 2011 23:41:46 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3657921F86E6 for ; Fri, 8 Jul 2011 23:41:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 812578700B7; Sat, 9 Jul 2011 08:41:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA7z8j57kqhy; Sat, 9 Jul 2011 08:41:38 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 27F7A87005C; Sat, 9 Jul 2011 08:41:38 +0200 (CEST) Message-ID: <4E17F822.7010403@globis.net> Date: Sat, 09 Jul 2011 08:41:38 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="------------020803090406040800080007" Subject: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 06:41:48 -0000 This is a multi-part message in MIME format. --------------020803090406040800080007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes IPv6-only SMTP delivery should be discussed. One current potential showstopper for enabling IPv6 SMTP is the lack of many operational IPv6 DNSxLs. Only one I know of is http://virbl.bit.nl/index.php#ipv6 If you know of others, please yell. Another problem in my view is that current DNSxLs generally rely on the scarcity of IPv4 addresses to encode return values including an implicit IPv4 /32 prefix length. Section 2.4 of RFC5782 suggests encoding results for IPv6 queries in the same way as IPv4 results. However, quoting RFC5782: "If a DNSxL is represented using traditional zone files and wildcards, there is no way to specify the length of the name that a wildcard matches, so wildcard names would indeed be ambiguous for DNSxLs served in that fashion." Can anyone clarify how you'd encode a response for indicating use of a filter for an IPv6 /48 or larger, as opposed to a fixed IPv6 /64 prefix length filter assumed in the Virbl implementation? If not, I think the current RFC 5782 mechanism perhaps needs expanding to include an explicit prefix length for encoding IPv6 related responses. IMHO an implicit IPv6 /128 or IPv6 /64 prefix length in IPv6 response encoding is inadequate for long-term smooth operation of an IPv6 DNSxL, as many spamming machines will probably gain access to very large numbers of potential source addresses way beyond a single /64. regards, RayH > Subject: > [v6ops] IPv6-only SMTP delivery? > From: > Ted Lemon > Date: > Fri, 8 Jul 2011 17:02:04 -0400 > > To: > "v6ops@ietf.org Operations" > > Content-Transfer-Encoding: > quoted-printable > Precedence: > list > MIME-Version: > 1.0 (Apple Message framework v1242) > Message-ID: > <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> > Content-Type: > text/plain; charset="us-ascii" > Message: > 1 > > > Maybe this is a dumb question, but it occurred to me today to check to see if it's possible to receive mail from IPv6-enabled servers if your MX record points to a name with a valid AAAA but no A record. Although I had no trouble delivering the mail to my mail server using a telnet session over IPv6, when I tried to send mail the usual way it bounced. One MTA gave me this: > > : host other.example.com[10.20.30.40] said: 550 MX > record points to an invalid IP for domain:my.example.com - usmtp (in reply to > RCPT TO command) > > When I tried to send the mail from gmail, I got no bounce, but the mail hasn't arrived after several hours, so I think it's safe to assume it's not going to. > > I'd never thought to look into this issue before, so I suppose it's possible that I'm missing some RFC that says SMTP is only supported for now on dual-stack and v4-only devices, not on v6-only devices, but it seems unlikely to me. > > So what's going on here? Are people disabling delivery over IPv6 for operational reasons, or are the implementations broken? Is this something we ought to be talking about? > > --------------020803090406040800080007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes IPv6-only SMTP delivery should be discussed.

One current potential showstopper for enabling IPv6 SMTP is the lack of many operational IPv6 DNSxLs.
Only one I know of is http://virbl.bit.nl/index.php#ipv6 If you know of others, please yell.

Another problem in my view is that current DNSxLs generally rely on the scarcity of IPv4 addresses to encode return values including an implicit IPv4 /32 prefix length.

Section 2.4 of RFC5782 suggests encoding results for IPv6 queries in the same way as IPv4 results.

However, quoting RFC5782: "If a DNSxL is represented using traditional zone files and wildcards, there is no way to specify the length of the name that a wildcard matches, so wildcard names would indeed be ambiguous for DNSxLs served in that fashion."

Can anyone clarify how you'd encode a response for indicating use of a filter for an IPv6 /48 or larger, as opposed to a fixed IPv6 /64 prefix length filter assumed in the Virbl implementation?

If not, I think the current RFC 5782 mechanism perhaps needs expanding to include an explicit prefix length for encoding IPv6 related responses. IMHO an implicit IPv6 /128 or IPv6 /64 prefix length in IPv6 response encoding is inadequate for long-term smooth operation of an IPv6 DNSxL, as many spamming machines will probably gain access to very large numbers of potential source addresses way beyond a single /64.

regards,
RayH

Subject:
[v6ops] IPv6-only SMTP delivery?
From:
Ted Lemon <Ted.Lemon@nominum.com>
Date:
Fri, 8 Jul 2011 17:02:04 -0400
To:
"v6ops@ietf.org Operations" <v6ops@ietf.org>
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1242)
Message-ID:
<3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com>
Content-Type:
text/plain; charset="us-ascii"
Message:
1		 

Maybe this is a dumb question, but it occurred to me today to check to see if it's possible to receive mail from IPv6-enabled servers if your MX record points to a name with a valid AAAA but no A record.   Although I had no trouble delivering the mail to my mail server using a telnet session over IPv6, when I tried to send mail the usual way it bounced.   One MTA gave me this:

<mellon@my.example.com>: host other.example.com[10.20.30.40] said: 550 MX
 record points to an invalid IP for domain:my.example.com - usmtp (in reply to
 RCPT TO command)

When I tried to send the mail from gmail, I got no bounce, but the mail hasn't arrived after several hours, so I think it's safe to assume it's not going to.

I'd never thought to look into this issue before, so I suppose it's possible that I'm missing some RFC that says SMTP is only supported for now on dual-stack and v4-only devices, not on v6-only devices, but it seems unlikely to me.

So what's going on here?   Are people disabling delivery over IPv6 for operational reasons, or are the implementations broken? Is this something we ought to be talking about?
--------------020803090406040800080007-- From turchanyi.geza@gmail.com Sat Jul 9 00:12:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC2021F8685 for ; Sat, 9 Jul 2011 00:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=1.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUw2gn+2znLQ for ; Sat, 9 Jul 2011 00:12:41 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7400321F8684 for ; Sat, 9 Jul 2011 00:12:38 -0700 (PDT) Received: by vxi40 with SMTP id 40so2475643vxi.31 for ; Sat, 09 Jul 2011 00:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=llDni9RUvTwiwnvMTL5FFNdencTHZ28cSZpE39z4ghw=; b=XAB/KoSqorB9DJQo+c6nETwy4DUl2isWt5blVLrrWRYeIOp23RRrbwJ+5AeIfZ1znn PuqmfHmqcGNAPlH4uRifxH1wDr4dQ3jCKJdek3V2AoWPF500+jiTBZFC6I2kscc/rtHK eq9zwgVuxhVDtYDZ3KmXJ41Vi/JfjKKh06lbs= MIME-Version: 1.0 Received: by 10.52.99.67 with SMTP id eo3mr3845555vdb.89.1310195557670; Sat, 09 Jul 2011 00:12:37 -0700 (PDT) Received: by 10.52.115.99 with HTTP; Sat, 9 Jul 2011 00:12:37 -0700 (PDT) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F3507EDA@EMBX01-WF.jnpr.net> <4E179442.3050405@gmail.com> Date: Sat, 9 Jul 2011 09:12:37 +0200 Message-ID: From: Turchanyi Geza To: Cameron Byrne Content-Type: multipart/alternative; boundary=20cf307f377acd1f0004a79dac9e Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Dropping 2002::/16 considered very harmful X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 07:12:43 -0000 --20cf307f377acd1f0004a79dac9e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian's comments were usefull, I think. Best, G=E9za On Sat, Jul 9, 2011 at 1:47 AM, Cameron Byrne wrote: > I, for one, am not interested talking about 6to4 anymore. > On Jul 8, 2011 4:36 PM, "Brian E Carpenter" > wrote: > > On 2011-07-08 19:16, Roger J=F8rgensen wrote: > >> Guess I should clearify something, the thing I am considering are to > >> drop all 2002::/16 addresses hard, of course preferable return a > >> correct error messages to. > > > > This is an awesomely bad idea. As explained in the approved advisory > > document, it makes things worse for everybody (the user, the content > > provider, and the unfortunate person answering calls from either of > > them at the help desk). > > > > On the contrary - it's in everyone's interests to have the return > > path working. Once a user manages to get a packet to the content > > provider, everybody suffers if the return path fails. > > > > (However, if you are announcing a route to 2002::/16, it must lead > > to a relay that will relay all 6to4 packets, with no form of ACL). > > > > Brian > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > --20cf307f377acd1f0004a79dac9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian's comments were usefull, I think.

Best,

G=E9za
<= br>
On Sat, Jul 9, 2011 at 1:47 AM, Cameron Byrne= <cb.list6@gmail= .com> wrote:

I, for one, am not interested talking ab= out 6to4 anymore.

On Jul 8, 2011 4:36 PM, "Brian E Carpenter&= quot; <= brian.e.carpenter@gmail.com> wrote:
> On = 2011-07-08 19:16, Roger J=F8rgensen wrote:
>> Guess I should clearify something, the thing I am considering are = to
>> drop all 2002::/16 addresses hard, of course preferable retu= rn a
>> correct error messages to.
>
> This is an awe= somely bad idea. As explained in the approved advisory
> document, it makes things worse for everybody (the user, the content> provider, and the unfortunate person answering calls from either of<= br>> them at the help desk).
>
> On the contrary - it's= in everyone's interests to have the return
> path working. Once a user manages to get a packet to the content
&g= t; provider, everybody suffers if the return path fails.
>
> (= However, if you are announcing a route to 2002::/16, it must lead
> t= o a relay that will relay all 6to4 packets, with no form of ACL).
>
> Brian
>
> ___________________________________= ____________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman= /listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ietf


--20cf307f377acd1f0004a79dac9e-- From marka@isc.org Sat Jul 9 00:21:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F9C21F86D8 for ; Sat, 9 Jul 2011 00:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLQ-DEUN7q+K for ; Sat, 9 Jul 2011 00:21:28 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 891C521F86D7 for ; Sat, 9 Jul 2011 00:21:28 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 9A7A6C94E1; Sat, 9 Jul 2011 07:21:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 31B99216C7B; Sat, 9 Jul 2011 07:21:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 291E511A7C37; Sat, 9 Jul 2011 17:21:12 +1000 (EST) To: Ray Hunter From: Mark Andrews References: <4E17F822.7010403@globis.net> In-reply-to: Your message of "Sat, 09 Jul 2011 08:41:38 +0200." <4E17F822.7010403@globis.net> Date: Sat, 09 Jul 2011 17:21:12 +1000 Message-Id: <20110709072112.291E511A7C37@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 07:21:29 -0000 In message <4E17F822.7010403@globis.net>, Ray Hunter writes: > > Yes IPv6-only SMTP delivery should be discussed. > > One current potential showstopper for enabling IPv6 SMTP is the lack of > many operational IPv6 DNSxLs. > Only one I know of is http://virbl.bit.nl/index.php#ipv6 If you know of > others, please yell. > > Another problem in my view is that current DNSxLs generally rely on the > scarcity of IPv4 addresses to encode return values including an implicit > IPv4 /32 prefix length. > > Section 2.4 of RFC5782 suggests encoding results for IPv6 queries in the > same way as IPv4 results. > > However, quoting RFC5782: "If a DNSxL is represented using traditional > zone files and wildcards, there is no way to specify the length of the > name that a wildcard matches, so wildcard names would indeed be > ambiguous for DNSxLs served in that fashion." > > Can anyone clarify how you'd encode a response for indicating use of a > filter for an IPv6 /48 or larger, as opposed to a fixed IPv6 /64 prefix > length filter assumed in the Virbl implementation? > > If not, I think the current RFC 5782 mechanism perhaps needs expanding > to include an explicit prefix length for encoding IPv6 related > responses. IMHO an implicit IPv6 /128 or IPv6 /64 prefix length in IPv6 > response encoding is inadequate for long-term smooth operation of an > IPv6 DNSxL, as many spamming machines will probably gain access to very > large numbers of potential source addresses way beyond a single /64. > > regards, > RayH Well the simple way is to take advantage of the structure and that NXDOMAIN does indicate that there are no children then start at the /32 reverse and expand out a nibble at a time until you get data or NXDOMAIN. x.x.x.x.x.x.x.x.bl.example.com TXT "this isp is a spam haven" x.x.x.x.x.x.x.x.bl.example.com A 127.0.0.2 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ek@google.com Sat Jul 9 00:35:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E30E21F8712 for ; Sat, 9 Jul 2011 00:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMUz4GOqPYw8 for ; Sat, 9 Jul 2011 00:35:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id BC55221F870F for ; Sat, 9 Jul 2011 00:35:44 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p697ZhDF014079 for ; Sat, 9 Jul 2011 00:35:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310196943; bh=yeOMUcRFQ83zTZU9J4ER1WmN/bc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=dhT3OIjxfdZwd15/J3AsOUdSHD3LaSO4eltDLVdWfvgzSmg1wydr9z7dYZuVFz33B ECDKw6G5HwbP/moZUjFWg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=a1+TwQnj8dA/ntQHDFXWwDmvJOQN9K+cQ0PrP6ADTyOnxG8qeJLpZa+0jvSffPk2y GVBIVBjspd8N3z/VA7RJw== Received: from pzd13 (pzd13.prod.google.com [10.243.17.205]) by wpaz24.hot.corp.google.com with ESMTP id p697ZgYj005045 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 9 Jul 2011 00:35:42 -0700 Received: by pzd13 with SMTP id 13so3171205pzd.11 for ; Sat, 09 Jul 2011 00:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qBVUrtRDCzJEyWanGEjBnGy64n0NyNcIRjmDfjwS3v8=; b=Vlutxb6Xld679IpnyixzlKt531cceokkrJDpxjzTC6e3a3Np41qzGFTXM9Zd0WrGkL 81XjmgA+SXUt5Mdpalbw== MIME-Version: 1.0 Received: by 10.142.164.17 with SMTP id m17mr793505wfe.153.1310196941773; Sat, 09 Jul 2011 00:35:41 -0700 (PDT) Received: by 10.142.179.17 with HTTP; Sat, 9 Jul 2011 00:35:41 -0700 (PDT) In-Reply-To: <20110709072112.291E511A7C37@drugs.dv.isc.org> References: <4E17F822.7010403@globis.net> <20110709072112.291E511A7C37@drugs.dv.isc.org> Date: Sat, 9 Jul 2011 16:35:41 +0900 Message-ID: From: Erik Kline To: Mark Andrews Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 07:35:45 -0000 Maybe an APL RR could be included in the response (with a sanity check that the IP address looked up must be within the APL RR). The A record could still hold the "return value", while the APL would indicate how broadly it applies, as far as that DNSxL is concerned. http://tools.ietf.org/html/rfc3123 But I am not well versed in counter-spam techniques nor theories of operation even. From v6ops@globis.net Sat Jul 9 00:41:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BB921F8654 for ; Sat, 9 Jul 2011 00:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKyax3Ca2Nlp for ; Sat, 9 Jul 2011 00:41:00 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id F017321F8706 for ; Sat, 9 Jul 2011 00:40:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 91FD48700B7; Sat, 9 Jul 2011 09:40:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnQGdOrQurlt; Sat, 9 Jul 2011 09:40:49 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id A4A9E87008A; Sat, 9 Jul 2011 09:40:49 +0200 (CEST) Message-ID: <4E180601.40203@globis.net> Date: Sat, 09 Jul 2011 09:40:49 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Mark Andrews References: <4E17F822.7010403@globis.net> <20110709072112.291E511A7C37@drugs.dv.isc.org> In-Reply-To: <20110709072112.291E511A7C37@drugs.dv.isc.org> Content-Type: multipart/alternative; boundary="------------050309090304050405020701" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 07:41:01 -0000 This is a multi-part message in MIME format. --------------050309090304050405020701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit OK, AFAIK Section 2.4 of RFC 5782 suggests encoding IPv6 as RFC3596 ip6.arpa, so each nibble in an IPv6 would be one octet. So assuming your use case for DNSxL was you wanted to start at /128 as a max length prefix (deny one host) and /32 as a shortest length prefix (deny corporation), in the worst case that'd generate look ups for /128 /120 /112 /104 /96 /88 /72 /64 /56 /48 /40 /32 /24 at which point you'd get no response => 13 lookups. If you assume something more reasonable like /64 as a max length and /32 as a minimum (although that could be debatable depending on your use case) that'd still be 6 DNS lookups for one source. Seems like a candidate for creating some sort of packet amplification attack to me. Isn't there a better way of somehow including the prefix length into the encoding of the first reply, or sending two replies, one with old format and one new? At first read I like Eric's suggestion based on RFC3123 better, although I certainly admit this is not my core competence area. regards, RayH Mark Andrews wrote: > In message<4E17F822.7010403@globis.net>, Ray Hunter writes: > >> Yes IPv6-only SMTP delivery should be discussed. >> >> One current potential showstopper for enabling IPv6 SMTP is the lack of >> many operational IPv6 DNSxLs. >> Only one I know of is http://virbl.bit.nl/index.php#ipv6 If you know of >> others, please yell. >> >> Another problem in my view is that current DNSxLs generally rely on the >> scarcity of IPv4 addresses to encode return values including an implicit >> IPv4 /32 prefix length. >> >> Section 2.4 of RFC5782 suggests encoding results for IPv6 queries in the >> same way as IPv4 results. >> >> However, quoting RFC5782: "If a DNSxL is represented using traditional >> zone files and wildcards, there is no way to specify the length of the >> name that a wildcard matches, so wildcard names would indeed be >> ambiguous for DNSxLs served in that fashion." >> >> Can anyone clarify how you'd encode a response for indicating use of a >> filter for an IPv6 /48 or larger, as opposed to a fixed IPv6 /64 prefix >> length filter assumed in the Virbl implementation? >> >> If not, I think the current RFC 5782 mechanism perhaps needs expanding >> to include an explicit prefix length for encoding IPv6 related >> responses. IMHO an implicit IPv6 /128 or IPv6 /64 prefix length in IPv6 >> response encoding is inadequate for long-term smooth operation of an >> IPv6 DNSxL, as many spamming machines will probably gain access to very >> large numbers of potential source addresses way beyond a single /64. >> >> regards, >> RayH >> > > Well the simple way is to take advantage of the structure and that > NXDOMAIN does indicate that there are no children then start at the > /32 reverse and expand out a nibble at a time until you get data > or NXDOMAIN. > > x.x.x.x.x.x.x.x.bl.example.com TXT "this isp is a spam haven" > x.x.x.x.x.x.x.x.bl.example.com A 127.0.0.2 > > Mark > --------------050309090304050405020701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit OK, AFAIK Section 2.4 of RFC 5782 suggests encoding IPv6 as RFC3596 ip6.arpa, so each nibble in an IPv6 would be one octet.

So assuming your use case for DNSxL was you wanted to start at /128 as a max length prefix (deny one host) and /32 as a shortest length prefix (deny corporation), in the worst case that'd generate look ups for  /128 /120 /112 /104 /96 /88 /72 /64 /56 /48 /40 /32 /24 at which point you'd get no response => 13 lookups.

If you assume something more reasonable like /64 as a max length and /32 as a minimum (although that could be debatable depending on your use case) that'd still be 6 DNS lookups for one source.

Seems like a candidate for creating some sort of packet amplification attack to me.

Isn't there a better way of somehow including the prefix length into the encoding of the first reply, or sending two replies, one with old format and one new? At first read I like Eric's suggestion based on RFC3123 better, although I certainly admit this is not my core competence area.

regards,
RayH


Mark Andrews wrote: 
In message <4E17F822.7010403@globis.net>, Ray Hunter writes:
  
Yes IPv6-only SMTP delivery should be discussed.

One current potential showstopper for enabling IPv6 SMTP is the lack of 
many operational IPv6 DNSxLs.
Only one I know of is http://virbl.bit.nl/index.php#ipv6 If you know of 
others, please yell.

Another problem in my view is that current DNSxLs generally rely on the 
scarcity of IPv4 addresses to encode return values including an implicit 
IPv4 /32 prefix length.

Section 2.4 of RFC5782 suggests encoding results for IPv6 queries in the 
same way as IPv4 results.

However, quoting RFC5782: "If a DNSxL is represented using traditional 
zone files and wildcards, there is no way to specify the length of the 
name that a wildcard matches, so wildcard names would indeed be 
ambiguous for DNSxLs served in that fashion."

Can anyone clarify how you'd encode a response for indicating use of a 
filter for an IPv6 /48 or larger, as opposed to a fixed IPv6 /64 prefix 
length filter assumed in the Virbl implementation?

If not, I think the current RFC 5782 mechanism perhaps needs expanding 
to include an explicit prefix length for encoding IPv6 related 
responses. IMHO an implicit IPv6 /128 or IPv6 /64 prefix length in IPv6 
response encoding is inadequate for long-term smooth operation of an 
IPv6 DNSxL, as many spamming machines will probably gain access to very 
large numbers of potential source addresses way beyond a single /64.

regards,
RayH
    

Well the simple way is to take advantage of the structure and that
NXDOMAIN does indicate that there are no children then start at the
/32 reverse and expand out a nibble at a time until you get data
or NXDOMAIN.

	x.x.x.x.x.x.x.x.bl.example.com  TXT "this isp is a spam haven"
	x.x.x.x.x.x.x.x.bl.example.com  A 127.0.0.2

Mark

--------------050309090304050405020701-- From gert@space.net Sat Jul 9 02:00:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5215421F869A for ; Sat, 9 Jul 2011 02:00:27 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqIxqaIEZECd for ; Sat, 9 Jul 2011 02:00:26 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id F0F5121F8698 for ; Sat, 9 Jul 2011 02:00:24 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 3C2C6F8549 for ; Sat, 9 Jul 2011 11:00:23 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 05C85F8531 for ; Sat, 9 Jul 2011 11:00:23 +0200 (CEST) Received: (qmail 40984 invoked by uid 1007); 9 Jul 2011 11:00:22 +0200 Date: Sat, 9 Jul 2011 11:00:22 +0200 From: Gert Doering To: Ted Lemon Message-ID: <20110709090022.GZ2304@Space.Net> References: <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org Operations" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 09:00:27 -0000 Hi, On Fri, Jul 08, 2011 at 05:02:04PM -0400, Ted Lemon wrote: > Maybe this is a dumb question, but it occurred to me today to > check to see if it's possible to receive mail from IPv6-enabled > servers if your MX record points to a name with a valid AAAA but > no A record. No problem, *if* the client side software supports it. For demonstration purpose, I've used "gert@v6only.greenie.net" before, and that resolves to: $ host v6only.greenie.net v6only.greenie.net has IPv6 address 2001:608:0:1007:a00:20ff:fefe:4bd2 v6only.greenie.net mail is handled by 5 v6only.greenie.net. > Although I had no trouble delivering the mail to my > mail server using a telnet session over IPv6, when I tried to send > mail the usual way it bounced. One MTA gave me this: > > : host other.example.com[10.20.30.40] said: 550 MX > record points to an invalid IP for domain:my.example.com - usmtp (in reply to > RCPT TO command) Sounds like a client MTA that has no IPv6 support compiled in... > When I tried to send the mail from gmail, I got no bounce, but > the mail hasn't arrived after several hours, so I think it's safe > to assume it's not going to. As far as I understand, gmail has no v6 yet on the "mail side of things". > I'd never thought to look into this issue before, so I suppose > it's possible that I'm missing some RFC that says SMTP is only > supported for now on dual-stack and v4-only devices, not on v6-only > devices, but it seems unlikely to me. If you have a single-stack v4 client trying to deliever to a single-stack v6-only server, it will fail. Nothing new here. Which is why I run my production mail server dual-stacked, and I receive quite a lot of e-mail over v6 transport (so it works) - and all the legacy hosts can still send it over v4. > So what's going on here? Are people disabling delivery over > IPv6 for operational reasons, or are the implementations broken? > Is this something we ought to be talking about? I've been told that IPv6 is not available everywhere yet... Gert Doering -- NetMaster -- did you enable 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 (89) 32356-444 USt-IdNr.: DE813185279 From rogerj@gmail.com Sat Jul 9 02:03:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D3A21F869D for ; Sat, 9 Jul 2011 02:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izH+hNJ2l75J for ; Sat, 9 Jul 2011 02:03:17 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7198521F8683 for ; Sat, 9 Jul 2011 02:03:17 -0700 (PDT) Received: by wwe5 with SMTP id 5so1740698wwe.13 for ; Sat, 09 Jul 2011 02:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MLyni8rLGmHtbhDrVVbWcIVDQOmFGmAaLanvJbhXoV0=; b=g7swgEQTpVQnCPPCFKFHpJm55HfoM1fimDfGNgOR25JivqjF89pSmNul7ySienJbe9 f4fqsXiyHO0z9c/vg+gkcO+ZRIW/XiIieoc1De+YAe0EXu+ohF34wykUWn6nwctj7uHn h61788NzlPKik018ZsctTfkoBxX6vwXHDayQ0= MIME-Version: 1.0 Received: by 10.227.24.146 with SMTP id v18mr2543958wbb.84.1310202195315; Sat, 09 Jul 2011 02:03:15 -0700 (PDT) Received: by 10.227.142.137 with HTTP; Sat, 9 Jul 2011 02:03:15 -0700 (PDT) In-Reply-To: <20110707105517.0bf3b556@opy.nosense.org> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> Date: Sat, 9 Jul 2011 11:03:15 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Mark Smith , IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 09:03:18 -0000 On Thu, Jul 7, 2011 at 3:25 AM, Mark Smith wrote: > Hi Nick, > > On Wed, 06 Jul 2011 22:17:10 +0100 > Nick Hilliard wrote: >> In terms of the exact size of prefix that might be useful from the point= of >> view of the ID, the options are either /128 or more than /128. If people >> feel that a single discard address is all that's required (I don't), the= n >> ::2 will suffice, and the functionality of the two separate things noted >> above will collapse into a single issue. >> >> If it's more than /128, then the choice between /32 or /48 is a matter o= f >> bikeshed politics. >> > > Where your thoughts to have it come from within 2000::/3, which is > perhaps why you chose /32? I think it probably should come from outside > of it similar to ULAs, ::1 etc., because I don't think a discard > function is dependent on the Internet's global unicast addressing. Once > it's outside of 2000::/3, I'd think the chosen size can chosen based on > expected use, rather than trying to reasonably fit in with an existing > allocation scheme. I see two problem with what have been suggested so far. ::2 may not a good choice, it is alike ::1 and everything else. Why not use ::f instead? It's clearly on a edge sort of very different from ::1 It should be a ::/32 and should be taken from the very end of the same 2000::/3 we are currently using. To pick it from outside the current used address may sound like a good idea, and may be tempting to make it stand out from current addresses. But I'm more afraid that will polute our next go on IPv6. I suggest we use ::f and we use a /32 from the very end of our current 2000::/3 range. That make both stand very out from all of our current addresses. And if we use something else than /32 on our next go (not from 2000::/3) we can very easy change the prefix. --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From sm@resistor.net Sat Jul 9 03:56:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7C121F8774 for ; Sat, 9 Jul 2011 03:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRPo8TAerMUe for ; Sat, 9 Jul 2011 03:56:24 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8664F21F8770 for ; Sat, 9 Jul 2011 03:56:24 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p69AuHSY028068; Sat, 9 Jul 2011 03:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1310208983; bh=SRn2Md642OYM7uejcYg70v3wkcS+rvhmIuYKave0QwQ=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=erFhtkId6DoQ9/G2NAG3pkxM5cKNWCc5QsUGpiN90NXn0NG9PcJRZvbyka47FxQa3 HO+3pweAscObN+tNjXxuwJZLT0POvVnZwXO6Yqk7x9RdFcIA5rGKtec3iT8zqoew5M pkz/SpzI/8KuS/9v6GkMyAx+OB2OhlMjwJyPIkzs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1310208983; bh=SRn2Md642OYM7uejcYg70v3wkcS+rvhmIuYKave0QwQ=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=0MccuTNdNLlfz/9Q4ThMqUOhOm6LaZ3EPYZoIcQzVVjbR0y/X1bVYi8fEtOWx70rX WM0J5Dm2Jv0brOjEsKvdn24PDwn/Fr4C/NdYG2MqqIPO0s1aEW1xrRj6ye4ofOcard tbjuW0VIzczNcysJZ/g4KewjK1w9wg0METyX3n4A= Message-Id: <6.2.5.6.2.20110709031116.037d0ab8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 09 Jul 2011 03:36:49 -0700 To: Ted Lemon From: SM In-Reply-To: <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> References: <3121957D-3086-4BE5-8A77-A82A20B441CD@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 10:56:29 -0000 Hi Ted, At 14:02 08-07-2011, Ted Lemon wrote: >Maybe this is a dumb question, but it occurred to me today to check >to see if it's possible to receive mail from IPv6-enabled servers if >your MX record points to a name with a valid AAAA but no A >record. Although I had no trouble delivering the mail to my mail >server using a telnet session over IPv6, when I tried to send mail >the usual way it bounced. One MTA gave me this: > >: host other.example.com[10.20.30.40] said: 550 MX > record points to an invalid IP for domain:my.example.com - usmtp > (in reply to > RCPT TO command) Some mail filters test for invalid A records. The test may fail if there is a (valid) AAAA record. >I'd never thought to look into this issue before, so I suppose it's >possible that I'm missing some RFC that says SMTP is only supported >for now on dual-stack and v4-only devices, not on v6-only devices, >but it seems unlikely to me. Mail relaying over SMTP will fail if there isn't any path between the IPv6 and IPv4 islands. >So what's going on here? Are people disabling delivery over IPv6 >for operational reasons, or are the implementations broken? Is this >something we ought to be talking about? The well-known SMTP implementations support IPv6. Regards, -sm From moore@network-heretics.com Sat Jul 9 05:05:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338AD21F87A3 for ; Sat, 9 Jul 2011 05:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x+B8s1CDg+V for ; Sat, 9 Jul 2011 05:05:23 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8B03821F879C for ; Sat, 9 Jul 2011 05:05:23 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 68F7020AC9; Sat, 9 Jul 2011 08:05:22 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Sat, 09 Jul 2011 08:05:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=Rh7X/lMkhUP1AaMhBTMKSp203Ms=; b=qUYYpBNsLjgoVv3hey+NKwOH76F7wWbaTqnbzPJRNlKQXgCW2ljKnPXibawhhT64r8j3ySkixRYEwcEpry4tEnoZ2BEnl9ePE2RfKS2qoIg4iYCqhVK15c7uSDNJRyCYhXa8qV0ORQHU6m7nMSRnO2VlA7x+125STpc9m9R2xbM= X-Sasl-enc: yNzCnoekAJqXF9v9xVc0q69U3rkHJY7SJUtPS9lUTkHI 1310213122 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id C5BD140771E; Sat, 9 Jul 2011 08:05:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E17F822.7010403@globis.net> Date: Sat, 9 Jul 2011 08:05:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <474D99D9-B53E-4DFB-9617-90F78972EC58@network-heretics.com> References: <4E17F822.7010403@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 12:05:24 -0000 On Jul 9, 2011, at 2:41 AM, Ray Hunter wrote: > Another problem in my view is that current DNSxLs generally rely on = the scarcity of IPv4 addresses to encode return values including an = implicit IPv4 /32 prefix length. More broadly, the ease with which a v6 host can be address agile means = that a reputation based on an IPv6 address is of dubious value. = Spammers can be expected to change source addresses frequently. =20 You could associate reputation with an address prefix of /64 or less = length. But that would no longer isolate a bad reputation to individual = hosts. Keith From v6ops@globis.net Sat Jul 9 06:37:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FA421F85FF for ; Sat, 9 Jul 2011 06:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id megZvt1CJ4gZ for ; Sat, 9 Jul 2011 06:37:07 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id A596621F85A8 for ; Sat, 9 Jul 2011 06:37:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B70018700F0; Sat, 9 Jul 2011 15:37:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnywEQVPja6J; Sat, 9 Jul 2011 15:37:00 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 27A9D87005C; Sat, 9 Jul 2011 15:37:00 +0200 (CEST) Message-ID: <4E18597C.70002@globis.net> Date: Sat, 09 Jul 2011 15:37:00 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Keith Moore References: <4E17F822.7010403@globis.net> <474D99D9-B53E-4DFB-9617-90F78972EC58@network-heretics.com> In-Reply-To: <474D99D9-B53E-4DFB-9617-90F78972EC58@network-heretics.com> Content-Type: multipart/alternative; boundary="------------080208050503020603020804" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 13:37:07 -0000 This is a multi-part message in MIME format. --------------080208050503020603020804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks. I entirely agree with you that address based mechanisms could be of dubious value. Same same for existing IPv4 based DNSxl mechanisms, due to extensive use of NAT and with CGN on its way. But putting that discussion aside for a moment, simple DNSxl tools save me processing well over 90%+ of incoming spam today as early as possible in the transfer (even before the DATA command), whilst applying other more resource-intensive techniques on the remainder. So what other mechanisms exist to share/key information on reputation today? And being pragmatic, if it turns out not to be dubious to filter based on IPv6 address block information (because ISPs do deploy decent ingress filtering in their IPv6 operations), what's the harm in ensuring that the existing reputation sharing mechanism is already updated and tested and able to efficiently handle variable length IPv6 prefixes long before that's really needed in production? regards, RayH Keith Moore wrote: > On Jul 9, 2011, at 2:41 AM, Ray Hunter wrote: > > >> Another problem in my view is that current DNSxLs generally rely on the scarcity of IPv4 addresses to encode return values including an implicit IPv4 /32 prefix length. >> > > More broadly, the ease with which a v6 host can be address agile means that a reputation based on an IPv6 address is of dubious value. Spammers can be expected to change source addresses frequently. > > You could associate reputation with an address prefix of /64 or less length. But that would no longer isolate a bad reputation to individual hosts. > > Keith > > --------------080208050503020603020804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks. I entirely agree with you that address based mechanisms could be of dubious value. Same same for existing IPv4 based DNSxl mechanisms, due to extensive use of NAT and with CGN on its way.

But putting that discussion aside for a moment, simple DNSxl tools save me processing well over 90%+ of incoming spam today as early as possible in the transfer (even before the DATA command), whilst applying other more resource-intensive techniques on the remainder.

So what other mechanisms exist to share/key information on reputation today?

And being pragmatic, if it turns out not to be dubious to filter based on IPv6 address block information (because ISPs do deploy decent ingress filtering in their IPv6 operations), what's the harm in ensuring that the existing reputation sharing mechanism is already updated and tested and able to efficiently handle variable length IPv6 prefixes long before that's really needed in production?

regards,
RayH

Keith Moore wrote: 
On Jul 9, 2011, at 2:41 AM, Ray Hunter wrote:

  
Another problem in my view is that current DNSxLs generally rely on the scarcity of IPv4 addresses to encode return values including an implicit IPv4 /32 prefix length.
    

More broadly, the ease with which a v6 host can be address agile means that a reputation based on an IPv6 address is of dubious value.  Spammers can be expected to change source addresses frequently.  

You could associate reputation with an address prefix of /64 or less length.  But that would no longer isolate a bad reputation to individual hosts.

Keith

--------------080208050503020603020804-- From moore@network-heretics.com Sat Jul 9 06:59:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9796121F85EA for ; Sat, 9 Jul 2011 06:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-Mzr1EihZQK for ; Sat, 9 Jul 2011 06:59:14 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id CD88921F85E3 for ; Sat, 9 Jul 2011 06:59:13 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 6FCDB201B4; Sat, 9 Jul 2011 09:59:13 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Sat, 09 Jul 2011 09:59:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=Sn1OdXkwBjJvvKD+pnB3NO1xf0I=; b=oBlhFuTnqlYC/72Ic07GXjYvDR0DpnZuMdl4yB2TPzknfjaf1bavInF5CtUB4qSLWH9h10WDd6PU9RF0Um4hgb+N1e9kVvx+YQep7PITBLzf8U7E0LnMB+2MJbbMen8WTMQhDCYR5ZRS0BBcGAcOswt5ichvIRqriJMZ2Q3/0hc= X-Sasl-enc: GNL+BHkwcqk0PtTebn9gbe2+Wcqn73zGaSaOnF/7kjOj 1310219952 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 54C65405937; Sat, 9 Jul 2011 09:59:12 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E18597C.70002@globis.net> Date: Sat, 9 Jul 2011 09:59:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <76566470-4034-461A-8851-075BDB932CAD@network-heretics.com> References: <4E17F822.7010403@globis.net> <474D99D9-B53E-4DFB-9617-90F78972EC58@network-heretics.com> <4E18597C.70002@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 13:59:14 -0000 On Jul 9, 2011, at 9:37 AM, Ray Hunter wrote: > Thanks. I entirely agree with you that address based mechanisms could = be of dubious value. Same same for existing IPv4 based DNSxl mechanisms, = due to extensive use of NAT and with CGN on its way. >=20 > But putting that discussion aside for a moment, simple DNSxl tools = save me processing well over 90%+ of incoming spam today as early as = possible in the transfer (even before the DATA command), whilst applying = other more resource-intensive techniques on the remainder. Saving 90% of CPU-intensive processing sounds impressive, though as you = hint, that begs the question of how many of the messages blocked in that = way were really spam. I suggest that v6ops not go there. There has = been plenty of discussion already on spam-related groups and it's been = going on, quite intensively, for many years, without any significant = contribution to the problem IMO. > So what other mechanisms exist to share/key information on reputation = today? Honestly I'm not sure that there is such a mechanism today. Of all of = the tokens that could be associated with a reputation, IP address = (though quite dubious already and increasingly moreso) is by far the = best - where "best" means "most reliably associated with a host or user = and most difficult to forge or obtain an ephemeral token". Of course, = there isn't much IPv6 mail traffic today, so maybe it's not a problem = yet. I'm thinking that maybe what is needed is some sort of reputation = identifier that's difficult to forge - maybe something based on a = difficult computation. Maybe there could be an SMTP extension to = support it. Again, it's not a topic for v6ops, but maybe the smtpext = list. Maybe IPv6 will be enough of an incentive to get people to want = to do something new in this space. > And being pragmatic, if it turns out not to be dubious to filter based = on IPv6 address block information (because ISPs do deploy decent ingress = filtering in their IPv6 operations), what's the harm in ensuring that = the existing reputation sharing mechanism is already updated and tested = and able to efficiently handle variable length IPv6 prefixes long before = that's really needed in production? The problem is collateral damage. If you associate reputation with an = address block, and a single host in that address block gets compromised, = all of the mail from that address block falls on the floor at any MTA = that trusts that DNSBL. Keith From pch-b2B3A6689@u-1.phicoh.com Sat Jul 9 14:26:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D68821F8A57 for ; Sat, 9 Jul 2011 14:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYrPhPwAq5HT for ; Sat, 9 Jul 2011 14:26:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id BD1C921F8A52 for ; Sat, 9 Jul 2011 14:26:12 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1Qff2Q-0001gwC; Sat, 9 Jul 2011 23:26:10 +0200 Message-Id: To: Keith Moore From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <4E17F822.7010403@globis.net> <474D99D9-B53E-4DFB-9617-90F78972EC58@network-heretics.com> In-reply-to: Your message of "Sat, 9 Jul 2011 08:05:20 -0400 ." <474D99D9-B53E-4DFB-9617-90F78972EC58@network-heretics.com> Date: Sat, 09 Jul 2011 23:25:46 +0200 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 21:26:14 -0000 In your letter dated Sat, 9 Jul 2011 08:05:20 -0400 you wrote: >More broadly, the ease with which a v6 host can be address agile means that a >reputation based on an IPv6 address is of dubious value. Spammers can be expe >cted to change source addresses frequently. > >You could associate reputation with an address prefix of /64 or less length. >But that would no longer isolate a bad reputation to individual hosts. What could be done (but I requires experimenting to see if it works in practice) is to query first for a /64 and then for the /128. By default put addresses in the /128 list. If the spammer is trying to evade that list then add an entry to the /64 list. There is also a proposal out somewhere to encode DNSBLs as some sort of B-tree. Sounds a bit too complex to me, but maybe that is what will be required eventually. From ek@google.com Sat Jul 9 17:31:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D3721F86A3 for ; Sat, 9 Jul 2011 17:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.902 X-Spam-Level: X-Spam-Status: No, score=-105.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKnqrygU2fFB for ; Sat, 9 Jul 2011 17:31:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id CEE2721F866B for ; Sat, 9 Jul 2011 17:31:19 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p6A0VGEi015644 for ; Sat, 9 Jul 2011 17:31:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310257878; bh=PCqKNdb8f4vkBsEJ8RI42YkKPos=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=mPGg5uOzQEmbq69iVUPRqM22wY5p1QvzWoNqgAnQSga4sGm6aA4ely3c+G7GdePRH 6Fbl+7x8ZN70zSqW9r4Qw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=Wsfk8PHlD8gQZTc/5u0dOjA0fJHexx+JNXPj1eEcjT15ZuDBgO7Vg6v9WfVF1vFoO pT+lfv+AtKPLuJFVE25Xw== Received: from pwi3 (pwi3.prod.google.com [10.241.219.3]) by wpaz1.hot.corp.google.com with ESMTP id p6A0VEAl018975 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 9 Jul 2011 17:31:15 -0700 Received: by pwi3 with SMTP id 3so2295838pwi.36 for ; Sat, 09 Jul 2011 17:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mPBT32ejP1YeO1B5pmG5AFMDvKtDfgN+x45TXEp4V18=; b=JplsUK1cYCVbGvxVgE4GGZrBCOVI0faM7lJ5JQmsKvRMwE8zJ6oyjRkDxoRf2PyTgQ c4i/yJaRXn7Ay+JyJlVQ== MIME-Version: 1.0 Received: by 10.143.97.37 with SMTP id z37mr1159340wfl.210.1310257874688; Sat, 09 Jul 2011 17:31:14 -0700 (PDT) Received: by 10.142.179.17 with HTTP; Sat, 9 Jul 2011 17:31:14 -0700 (PDT) In-Reply-To: References: <4E17F822.7010403@globis.net> <474D99D9-B53E-4DFB-9617-90F78972EC58@network-heretics.com> Date: Sun, 10 Jul 2011 09:31:14 +0900 Message-ID: From: Erik Kline To: Philip Homburg Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 00:31:23 -0000 > There is also a proposal out somewhere to encode DNSBLs as some sort of > B-tree. Sounds a bit too complex to me, but maybe that is what will be > required eventually. http://tools.ietf.org/html/draft-levine-iprangepub From moore@network-heretics.com Sat Jul 9 19:03:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56E421F8A21 for ; Sat, 9 Jul 2011 19:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.513 X-Spam-Level: X-Spam-Status: No, score=-4.513 tagged_above=-999 required=5 tests=[AWL=1.086, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctpGznoMfrN8 for ; Sat, 9 Jul 2011 19:03:05 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 2614121F8A1D for ; Sat, 9 Jul 2011 19:03:05 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id BEF7B20A5B; Sat, 9 Jul 2011 22:03:04 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Sat, 09 Jul 2011 22:03:04 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=xDl2pHelwKIF94ovTZZwWpdY10A=; b=Yo+svyPf2hOmnG+sPB7eT3tnczcuu/MCdhxTLoAMFlzuU4KR/HSyWPc8DqRYOUvrccrsQYZ+luT8gPr/vrG3Gr0kyjxbVWsRvbvRHmosY1qcRTEIqd9nnqVv7izEVpVlNKS2HmrbLYzuU73SwLxljoxJ1vw+GxnUcJqzWP3qIHU= X-Sasl-enc: xZuDoT/S94BchEO6IoLnG0hq4lBdaM3kh0ixXTV9WcZt 1310263384 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id E343E4067EF; Sat, 9 Jul 2011 22:03:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Sat, 9 Jul 2011 22:03:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3D73F215-4008-427A-8C56-5C2C80A0A1DF@network-heretics.com> References: <4E17F822.7010403@globis.net> <474D99D9-B53E-4DFB-9617-90F78972EC58@network-heretics.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 02:03:05 -0000 On Jul 9, 2011, at 5:25 PM, Philip Homburg wrote: > In your letter dated Sat, 9 Jul 2011 08:05:20 -0400 you wrote: >> More broadly, the ease with which a v6 host can be address agile = means that a=20 >> reputation based on an IPv6 address is of dubious value. Spammers = can be expe >> cted to change source addresses frequently. =20 >>=20 >> You could associate reputation with an address prefix of /64 or less = length. =20 >> But that would no longer isolate a bad reputation to individual = hosts. >=20 > What could be done (but I requires experimenting to see if it works in > practice) is to query first for a /64 and then for the /128.=20 >=20 > By default put addresses in the /128 list. If the spammer is trying to > evade that list then add an entry to the /64 list. Interesting idea. I'm wondering if each contribution to the /128 list = within a /64 should count slightly against the reputation of the /64. = So if there's a spammer or a compromised host using lots of addresses = within a /64, the reputation of that /64 will quickly degrade. But if = there are only a small number of hosts within a /64 with a bad = reputation, it won't affect the others. Figuring out what the threshold should be would be an interesting = exercise. Problem is, some /64s will be denser than others. Keith From vishwas.ietf@gmail.com Sat Jul 9 19:30:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56D221F8A6E for ; Sat, 9 Jul 2011 19:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[AWL=2.475, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBJEjO+59Zjb for ; Sat, 9 Jul 2011 19:30:43 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1436721F8A21 for ; Sat, 9 Jul 2011 19:30:42 -0700 (PDT) Received: by vws12 with SMTP id 12so3003721vws.31 for ; Sat, 09 Jul 2011 19:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ek3X4po/OaWUXZp6czVGTTSyYGkiDXHe1ZnTfCOIyLQ=; b=GZbqeSL11YqJYO/akOj+1XamOJvhYFWVK4Iv7LVYvcAS4/msN6SH48Mu3EPsvhXwqW taTy2n4mgC49cxf5v+vnlPNnbzWGCxnvIa8Idw2Ek//6Z7gLXxUJtFcp+i0DQVboCrFZ 0wzT+yuIFgi2iFKJ9DSTKT91MjzK3jejKyNCc= MIME-Version: 1.0 Received: by 10.52.161.230 with SMTP id xv6mr4485487vdb.123.1310265042451; Sat, 09 Jul 2011 19:30:42 -0700 (PDT) Received: by 10.52.157.37 with HTTP; Sat, 9 Jul 2011 19:30:42 -0700 (PDT) In-Reply-To: <3D73F215-4008-427A-8C56-5C2C80A0A1DF@network-heretics.com> References: <4E17F822.7010403@globis.net> <474D99D9-B53E-4DFB-9617-90F78972EC58@network-heretics.com> <3D73F215-4008-427A-8C56-5C2C80A0A1DF@network-heretics.com> Date: Sat, 9 Jul 2011 19:30:42 -0700 Message-ID: From: Vishwas Manral To: Keith Moore Content-Type: multipart/alternative; boundary=bcaec53f91f56abd9e04a7adda12 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 02:30:43 -0000 --bcaec53f91f56abd9e04a7adda12 Content-Type: text/plain; charset=ISO-8859-1 Hi Kieth, > Interesting idea. I'm wondering if each contribution to the /128 list within > a /64 should count slightly against the reputation of the /64. So if there's > a spammer or a compromised host using lots of addresses within a /64, > the reputation of that /64 will quickly degrade. But if there are only a > small number of hosts within a /64 with a bad reputation, it won't affect > the others. > > Figuring out what the threshold should be would be an interesting > exercise. Problem is, some /64s will be denser than others. This is exactly what the virbl project does. If it finds more then 5 in the same /64, the entire /64 is blacklisted. -Vishwas --bcaec53f91f56abd9e04a7adda12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kieth,
=A0
> Interesting idea. =A0I'm wondering if each contribution to th= e /128 list within
>=A0a /64 should count slightly against the reputation of the /64. = =A0So if there's
>=A0a spammer or a compromised host using lots of addresses within = a /64,
>=A0the reputation of that /64 will quickly degrade. =A0But if ther= e are only a
>=A0small number of hosts within a /64 with a bad reputation, it wo= n't affect
>=A0the others.
>
> Figuring out what the threshold sho= uld be would be an interesting
> exercise. =A0Problem is, some /64s will be denser than others.This is exactly what the virbl project does. If it finds more then 5 in th= e same /64, the entire /64 is blacklisted.
=A0
-Vishwas
--bcaec53f91f56abd9e04a7adda12-- From john.mann@monash.edu Sat Jul 9 19:39:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4299B21F8A21 for ; Sat, 9 Jul 2011 19:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGYZZZ0GukaZ for ; Sat, 9 Jul 2011 19:39:30 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id 19B6421F8A0F for ; Sat, 9 Jul 2011 19:39:30 -0700 (PDT) Received: from mail-vx0-f174.google.com ([209.85.220.174]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKThkQ4eGkn3P1Eo7PWu0+jOwN54pjyu9d@postini.com; Sat, 09 Jul 2011 19:39:30 PDT Received: by mail-vx0-f174.google.com with SMTP id 39so2085240vxb.19 for ; Sat, 09 Jul 2011 19:39:29 -0700 (PDT) Received: by 10.52.74.74 with SMTP id r10mr4230800vdv.212.1310265569230; Sat, 09 Jul 2011 19:39:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.108.193 with HTTP; Sat, 9 Jul 2011 19:39:09 -0700 (PDT) In-Reply-To: <449FDB7D-B28A-400E-8B88-7A1DC2E67ECF@bogus.com> References: <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.com> <54E20C35-711A-48ED-9050-DA81C505EBDB@bogus.com> <449FDB7D-B28A-400E-8B88-7A1DC2E67ECF@bogus.com> From: "John Mann (ITS)" Date: Sun, 10 Jul 2011 12:39:09 +1000 Message-ID: To: Joel Jaeggli Content-Type: multipart/alternative; boundary=20cf307cff20d0bd8f04a7adf935 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 02:39:31 -0000 --20cf307cff20d0bd8f04a7adf935 Content-Type: text/plain; charset=ISO-8859-1 Joel, Sure, John On 9 July 2011 10:46, Joel Jaeggli wrote: > cool, > > could we potentially pigeonhole you for a review of the doc from the > vantage point of someone using it? > > joel > > On Jul 7, 2011, at 8:09 PM, John Mann (ITS) wrote: > > Joel, > > On 4 July 2011 09:37, Joel Jaeggli wrote: > >> ... >> yeah, I think the question of do isatap implementers or users in v6ops >> find this line of work interesting and useful is essentially the open >> question thatwould cause us to consider advancing this as a wg document vs >> allowing you to pursue it as an indivudal submission. I think that preaking >> shcpv6 out of it is a wise idea. >> ... >> > > I am doing an ISATAP deployment, think the document is useful/interesting, > and I support advancing this as a WG document. > > Thanks, > John > > > > --20cf307cff20d0bd8f04a7adf935 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joel,

Sure,
=A0 =A0John

On 9 July 2011 10:46, Joel Jaeggli <joelja@bogus.com> wrote:
cool,

could we poten= tially pigeonhole you for a review of the doc from the vantage point of som= eone using it?

joel

On Jul 7, 2011, at 8:09 PM,= John Mann (ITS) wrote:

Joel,

On 4 July 2011 09:37, Joel Jaeggli <joelja@bogus.co= m> wrote:
...
yeah= , I think the question of do isatap implementers =A0or users in v6ops find = this line of work interesting and useful is essentially the open question t= hatwould cause us to consider advancing this as a wg document vs allowing y= ou to pursue it as an indivudal submission. I think that preaking shcpv6 ou= t of it is a wise idea.
...

I am doing an ISATAP deployment, think the document is useful/interes= ting, and I support advancing this as a WG document.

Thanks,
=A0 =A0 John
=A0



--20cf307cff20d0bd8f04a7adf935-- From rogerj@gmail.com Sun Jul 10 02:24:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B170921F86A0 for ; Sun, 10 Jul 2011 02:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Be+7aLFpfHCT for ; Sun, 10 Jul 2011 02:24:07 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F15A21F8587 for ; Sun, 10 Jul 2011 02:24:07 -0700 (PDT) Received: by wwe5 with SMTP id 5so2053993wwe.13 for ; Sun, 10 Jul 2011 02:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ufoZXm86V3IFgsZW6jIbBoDclKmyqn9BpU1hIDBGImA=; b=tXFYA5AftJiDv7g7qO4UxCYQ8c0d38UVlvNXDIENs0TEud3qCnOt21Xy8cK4wlSofO ZFZplCgcPu5rMPu+BhdzcDpdowBbsWbjwDv/mvodsI1wR2nYkO3irDobKb8OwSCPJkm+ dEvotQCNW5FFbVSm15sXG4dzgO4sBk21XvYak= MIME-Version: 1.0 Received: by 10.227.142.141 with SMTP id q13mr3288237wbu.114.1310289844986; Sun, 10 Jul 2011 02:24:04 -0700 (PDT) Received: by 10.227.142.137 with HTTP; Sun, 10 Jul 2011 02:24:04 -0700 (PDT) In-Reply-To: <3D73F215-4008-427A-8C56-5C2C80A0A1DF@network-heretics.com> References: <4E17F822.7010403@globis.net> <474D99D9-B53E-4DFB-9617-90F78972EC58@network-heretics.com> <3D73F215-4008-427A-8C56-5C2C80A0A1DF@network-heretics.com> Date: Sun, 10 Jul 2011 11:24:04 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 09:24:08 -0000 On Sun, Jul 10, 2011 at 4:03 AM, Keith Moore w= rote: > Interesting idea. =A0I'm wondering if each contribution to the /128 list = within a /64 should count slightly against the reputation of the /64. =A0So= if there's a spammer or a compromised host using lots of addresses within = a /64, the reputation of that /64 will quickly degrade. =A0But if there are= only a small number of hosts within a /64 with a bad reputation, it won't = affect the others. > > Figuring out what the threshold should be would be an interesting exercis= e. =A0Problem is, some /64s will be denser than others. Blocking an entire /64 is probably not that harmful, what are the chance that a real SMTP server will be in a /64 with a lot of other clients/servers? What I'm trying to say, we can assume a /64 is a LAN (most of the time) and if you block it you will either a.) block all SMTP server for an ISP, if they are sending out spam then they have issues anyway. b.) block a client LAN, this will hurt some real SMTP traffic but in 99,9% (my wild guess) this is not real traffic anyway. And the next thing to block after a /64 should maybe be a /48 :] --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From moore@network-heretics.com Sun Jul 10 05:51:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408B821F86AF for ; Sun, 10 Jul 2011 05:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M3BfuOrzaAh for ; Sun, 10 Jul 2011 05:51:25 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id B732121F85BB for ; Sun, 10 Jul 2011 05:51:25 -0700 (PDT) Received: from [65.16.145.177] (helo=host65-16-145-177.birch.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QftTp-0001S5-0Q; Sun, 10 Jul 2011 08:51:25 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: Date: Sun, 10 Jul 2011 08:51:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <79FEC325-3053-467E-A707-6C10BC0169D5@network-heretics.com> References: <4E17F822.7010403@globis.net> <474D99D9-B53E-4DFB-9617-90F78972EC58@network-heretics.com> <3D73F215-4008-427A-8C56-5C2C80A0A1DF@network-heretics.com> To: =?iso-8859-1?Q?Roger_J=F8rgensen?= X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da9401c9a33865d847d4db868ddfe5dfbeefe350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.16.145.177 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] IPv6-only SMTP delivery? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 12:51:26 -0000 On Jul 10, 2011, at 5:24 AM, Roger J=F8rgensen wrote: > On Sun, Jul 10, 2011 at 4:03 AM, Keith Moore = wrote: > >> Interesting idea. I'm wondering if each contribution to the /128 = list within a /64 should count slightly against the reputation of the = /64. So if there's a spammer or a compromised host using lots of = addresses within a /64, the reputation of that /64 will quickly degrade. = But if there are only a small number of hosts within a /64 with a bad = reputation, it won't affect the others. >>=20 >> Figuring out what the threshold should be would be an interesting = exercise. Problem is, some /64s will be denser than others. >=20 >=20 > Blocking an entire /64 is probably not that harmful, what are the > chance that a real SMTP server will be in a /64 with a lot of other > clients/servers? To a large degree it depends on how hostile major MSPs and blacklists = are to receiving mail that's originated by MTAs maintained by = individuals and small businesses. RIght now, if you want your mail to = be delivered reliably, you pretty much have to use a professional mail = service provider to originate your mail. Individuals and small = businesses typically don't have the resources needed to monitor = blacklists and to appease them when they block mail (often for no good = reason). =20 I have this bizarre idea that the appropriate role for network operators = is to be content-neutral. I realize that's probably heresy here, and I = also realize that operators have pragmatic needs to keep their customers = happy when their customers blame the operators for spam that they = receive. But when people start assuming that users will (or should) use = the IPv6 network in a certain way, and configure their networks to = interfere with others' traffic based on those assumptions, I think = that's crossing a line. Keith From moore@network-heretics.com Sun Jul 10 13:34:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F09221F86EE for ; Sun, 10 Jul 2011 13:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXv2Yp5LfAIN for ; Sun, 10 Jul 2011 13:34:13 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC7621F86EA for ; Sun, 10 Jul 2011 13:34:13 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 86F1620E40 for ; Sun, 10 Jul 2011 16:34:12 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 10 Jul 2011 16:34:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=from:content-type:date:subject:to:message-id:mime-version; s=smtpout; bh=8xmJkbwuY+ltlFCSD5ZFGN4B5ZA=; b=mwA3jtrkke6yo4TZZAj05yavkkX8zO1HnoGGlSUsMaPH5t4hjRpfWdCBaElMgIXDdiWMKWqIvF5LL4NSuYl29vBPj+Mtkc6cYKe9UZOg4s/nda/ewb51wBh/mQ0nkeVpO6IT1EyVR4Yhp+/VnX0ojC0P2NNrcIP08cVYu3rm6Fs= X-Sasl-enc: 7+xarn5JINp9zC7er9ALVAiKs7D/32XFnpjrW8H3oZ/z 1310330052 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id CA91D402980; Sun, 10 Jul 2011 16:34:11 -0400 (EDT) From: Keith Moore Content-Type: multipart/alternative; boundary=Apple-Mail-40--837114892 Date: Sun, 10 Jul 2011 16:34:10 -0400 To: "v6ops@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [v6ops] draft-moore-6to4-experimental-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 20:34:14 -0000 --Apple-Mail-40--837114892 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Apparently, the draft got hung up in the submission process. The = secretariat said they'd post it if I emailed them a copy with the = correct boilerplate, which I believe I did, but they may still be = backlogged. Anyway, it can be downloaded here: = http://home.earthlink.net/~heretic/data/draft-moore-6to4-experimental-00.t= xt I'm not asking that v6ops take this on, but I'd appreciate any comments = from v6ops participants in private mail. After I get some feedback, = I'll revise the draft and circulate it more widely. Keith --Apple-Mail-40--837114892 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Apparently, the draft got hung up in the submission process.  The secretariat said they'd post it if I emailed them a copy with the correct boilerplate, which I believe I did, but they may still be backlogged.  Anyway, it can be downloaded here:

http://home.earthlink.net/~heretic/data/draft-moore-6to4-experimental-00.txt

I'm not asking that v6ops take this on, but I'd appreciate any comments from v6ops participants in private mail.    After I get some feedback, I'll revise the draft and circulate it more widely.

Keith

--Apple-Mail-40--837114892-- From internet-drafts@ietf.org Sun Jul 10 19:13:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00D821F8877; Sun, 10 Jul 2011 19:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.233 X-Spam-Level: X-Spam-Status: No, score=-102.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhuvv9UuZhmE; Sun, 10 Jul 2011 19:13:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4622E21F877A; Sun, 10 Jul 2011 19:13:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711021348.27480.63578.idtracker@ietfa.amsl.com> Date: Sun, 10 Jul 2011 19:13:48 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-cpe-router-bis-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 02:13:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Advanced Requirements for IPv6 Customer Edge Routers Author(s) : Hemant Singh Wes Beebee Chris Donley Barbara Stark Ole Troan Filename : draft-ietf-v6ops-ipv6-cpe-router-bis-01.txt Pages : 15 Date : 2011-07-10 This document continues the work undertaken by the IPv6 CE Router Phase I work in the IETF v6ops Working Group. Advanced requirements or Phase II work is covered in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-bis-01= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-cpe-router-bis-01.= txt From phdgang@gmail.com Sun Jul 10 21:06:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D221F8556 for ; Sun, 10 Jul 2011 21:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLDp+R6mHS2Z for ; Sun, 10 Jul 2011 21:06:57 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA35921F8554 for ; Sun, 10 Jul 2011 21:06:56 -0700 (PDT) Received: by vws12 with SMTP id 12so3654179vws.31 for ; Sun, 10 Jul 2011 21:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=XZZd/tIkEZXKm9qBT2Lecq5KD/mY/CVCOrRXK3CQj/Y=; b=xIsS4nmZXpgaO/W9Qbqbt20gaQX41TMn2+xxDHPofIqWcRbeUlJBy2GyGDRC8DvUrK wzLUz7Xd8C/gw5+ePmEeBSjakcNQ9PCE7kgKoyqoPqDZjEOAdihREaocj7FDHQUnGJp4 PsRdtiDKaUFGxvqlIhoONUU8gxOXXjn/T+YNs= MIME-Version: 1.0 Received: by 10.52.31.1 with SMTP id w1mr1859513vdh.371.1310357216293; Sun, 10 Jul 2011 21:06:56 -0700 (PDT) Received: by 10.52.166.130 with HTTP; Sun, 10 Jul 2011 21:06:56 -0700 (PDT) Date: Mon, 11 Jul 2011 12:06:56 +0800 Message-ID: From: GangChen To: v6ops Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] draft-chen-v6ops-nat64-cpe-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 04:06:57 -0000 Dear all, We have submitted a draft for updating NAT64 operational requirements. Compared to the last version, requirements for NAT64-CGN have been added according to received comments. Please kindly to check it. Many thanks Gang Filename: draft-chen-v6ops-nat64-cpe Revision: 02 Title: NAT64-CPE Mode Operation for Opening Residential Service Creation date: 2011-07-11 WG ID: Individual Submission Number of pages: 9 Abstract: The document has summarized NAT64 usages on different modes, in which NAT64-CGN would serve for a large-scale network and NAT64-CPE would give residential service opportunities to be accessed by IPv6 remote subscribers. The document has described different operations for each usage and proposed operational considerations for each particular NAT64-mode. From nick@inex.ie Mon Jul 11 08:39:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A11F21F8DAD for ; Mon, 11 Jul 2011 08:39:48 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVP8XpNfm5u9 for ; Mon, 11 Jul 2011 08:39:47 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6FD21F8DAE for ; Mon, 11 Jul 2011 08:39:46 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.internal.acquirer.com (mail.acquirer.com [87.198.142.10] (may be forged)) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p6BFdaxF024854 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 11 Jul 2011 16:39:37 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4E1B1938.5050906@inex.ie> Date: Mon, 11 Jul 2011 16:39:36 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: David Malone References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110707192002.GA29545@walton.maths.tcd.ie> In-Reply-To: <20110707192002.GA29545@walton.maths.tcd.ie> X-Enigmail-Version: 1.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:39:48 -0000 On 07/07/2011 20:20, David Malone wrote: > One possible security point arising from making a well-known > allocation for traffic discard, is that there will then be a > well-known traffic sink address available on the network. This means > that attackers that want (say) to fill a link and then have the > traffic vanish as quickly as possible can just generate traffic and > send it to the well-known discard address. It's certainly possible that this could happen, which is why the draft says: "IPv6 traffic with an destination address within this prefix SHOULD NOT be forwarded to third party autonomous systems", which deals with inter-AS traffic forwarding. As for local traffic forwarding, this is generally much easier to deal with, because as a service provider you will usually have a contractual relationship with your downstreams, and if they start doing silly stuff like this, they just end up trashing their own connectivity or ending themselves up with large bills. Of course, the traffic flow could be malicious in nature, in which case you wouldn't want either of these, but billing issues are an order of magnitude up the protocol stack from this ID. In any case, netflow is usually implemented to detect large bursts of traffic like this, so it's probably not that much different from other DoS attacks in this respect. You has your DoS, you takes out your netflow stats, then you figures out what's going on. Nick From Internet-Drafts@ietf.org Mon Jul 11 09:15:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316D311E8085; Mon, 11 Jul 2011 09:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLoxL7FOhzKi; Mon, 11 Jul 2011 09:15:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D5911E808A; Mon, 11 Jul 2011 09:15:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711161503.10931.6058.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 09:15:03 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:15:11 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Happy Eyeballs: Success with Dual-Stack Hosts Author(s) : D. Wing, et al Filename : draft-ietf-v6ops-happy-eyeballs-03.txt Pages : 13 Date : 2011-07-11 When the IPv4 server and path is working but the IPv6 server or IPv6 path is down, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual-stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this delay, and provides an example algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-happy-eyeballs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-happy-eyeballs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-07-11091251.I-D@ietf.org> --NextPart-- From internet-drafts@ietf.org Mon Jul 11 11:45:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B8F11E815F; Mon, 11 Jul 2011 11:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQIgROjZNwcM; Mon, 11 Jul 2011 11:45:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959FF11E80A8; Mon, 11 Jul 2011 11:45:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711184518.2747.63831.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 11:45:18 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-3gpp-eps-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 18:45:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : IPv6 in 3GPP Evolved Packet System Author(s) : Jouni Korhonen Jonne Soininen Basavaraj Patil Teemu Savolainen Gabor Bajko Kaisu Iisakkila Filename : draft-ietf-v6ops-3gpp-eps-03.txt Pages : 34 Date : 2011-07-11 Use of data services in smart phones and broadband services via HSPA and HSPA+, in particular Internet services, has increased rapidly and operators that have deployed networks based on 3GPP network architectures are facing IPv4 address shortages at the Internet registries and are feeling a pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-eps-03.txt From pch-b2B3A6689@u-1.phicoh.com Mon Jul 11 12:06:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F25311E8147 for ; Mon, 11 Jul 2011 12:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.524 X-Spam-Level: X-Spam-Status: No, score=-7.524 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp6UxSnBXU7k for ; Mon, 11 Jul 2011 12:06:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0A40621F8E53 for ; Mon, 11 Jul 2011 12:06:30 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QgLoJ-0001hpC; Mon, 11 Jul 2011 21:06:27 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Mon, 11 Jul 2011 09:15:03 -0700 ." <20110711161503.10931.6058.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 21:06:20 +0200 Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 19:06:37 -0000 I like this approach. By now, my own HE algorithm is quite complex and it would probably take a long time to get any kind of consensus about what algorithm to use. Maybe later we could have a separate BCP that outlines how to construct a HE implementation. I'll start with some comments on specific parts of the draft and add some suggestions for other issues that could/should be addressed. Section 4.1 In my opinion the MUST is too strong. I think a SHOULD is more than enough. But more importantly, Section 4.2 qualifies that MUST. I think that either 4.1 should contain a description of when MUST can be violated or it should explicitly forward reference 4.2. In my opinion it is important that requirements are as self-contained as possible. Section 4.2 In think that Section 4.2 should explain what 'failed' means. Obviously, if a protocol doesn't work at all, it should be considered failed. But I think that in many cases, a tunnel that always adds 200 ms latency can be considered as failing as well. (my own algorithm just connects to whatever works best, without trying to declare something as failed). Section 5.5 I quickly read the (by now expired) draft on Same Origin Policy and I didn't find anything that directly deal with IP addresses. If it were, then any setup that use a proxy would be in deep trouble. I think that 'origin' in this context is a domain, not a specific address. But I could be wrong. Suggestions 1) Playing with my own HE implementation I arrived a the following prototype for the library function that provides it: int tcp_connect_to_name(char *hostname, char *portname, int *gai_errp, struct timeval *tv); I think application portability will be enhanced if HE implementations provide similar features. There is also no need for OS implementors to all reinvent the wheel. 2) In practice, a DNS RR set may contain more than just one IPv4 and one IPv6 address. It may be a good idea to add some discussion about this. 3) In practice, local IPv6 connections may still work while the link to the outside world is broken. What does 'failed' mean in this context? 4) What happens if I take the same algorithm as Google used in Chrome but I set the timer to 30 ms instead of 300? Is that considered an acceptable HE implementation according to this draft? 5) This draft sometimes talks about an entire address family (for example Section 4.2) but in other places (Section 4) it's about addresses for an individual host. I think this should be make more clear in Sections 4.1 and 4.2. From marka@isc.org Mon Jul 11 18:30:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D4811E83FA for ; Mon, 11 Jul 2011 18:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROyeQj1MoZ8S for ; Mon, 11 Jul 2011 18:30:06 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A43D611E8213 for ; Mon, 11 Jul 2011 18:30:05 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 7CBC8C94F8; Tue, 12 Jul 2011 01:29:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 11D15216C7B; Tue, 12 Jul 2011 01:29:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B96B511B383C; Tue, 12 Jul 2011 11:29:49 +1000 (EST) To: Philip Homburg From: Mark Andrews References: In-reply-to: Your message of "Mon, 11 Jul 2011 21:06:20 +0200." Date: Tue, 12 Jul 2011 11:29:49 +1000 Message-Id: <20110712012949.B96B511B383C@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 01:30:06 -0000 In message , Philip Homburg writes: > I like this approach. By now, my own HE algorithm is quite complex and it > would probably take a long time to get any kind of consensus about what > algorithm to use. Maybe later we could have a separate BCP that outlines > how to construct a HE implementation. > > I'll start with some comments on specific parts of the draft and add some > suggestions for other issues that could/should be addressed. > > Section 4.1 > > In my opinion the MUST is too strong. I think a SHOULD is more than enough. > But more importantly, Section 4.2 qualifies that MUST. I think that either > 4.1 should contain a description of when MUST can be violated or it should > explicitly forward reference 4.2. In my opinion it is important that > requirements are as self-contained as possible. > > Section 4.2 > > In think that Section 4.2 should explain what 'failed' means. Obviously, > if a protocol doesn't work at all, it should be considered failed. But I thin > k > that in many cases, a tunnel that always adds 200 ms latency can be considere > d > as failing as well. > > (my own algorithm just connects to whatever works best, without trying to > declare something as failed). > > Section 5.5 > > I quickly read the (by now expired) draft on Same Origin Policy and I didn't > find anything that directly deal with IP addresses. > > If it were, then any setup that use a proxy would be in deep trouble. > > I think that 'origin' in this context is a domain, not a specific address. > But I could be wrong. > > Suggestions > > 1) > > Playing with my own HE implementation I arrived a the following prototype for > the library function that provides it: > > int tcp_connect_to_name(char *hostname, char *portname, int *gai_errp, > struct timeval *tv); > > I think application portability will be enhanced if HE implementations provid > e > similar features. There is also no need for OS implementors to all reinvent > the wheel. Whereas mine is: int connect_to_host(struct addrinfo *res0); > 2) > > In practice, a DNS RR set may contain more than just one IPv4 and one IPv6 > address. It may be a good idea to add some discussion about this. Which is one of the reasons I keep saying that this isn't a IPv4/IPv6 issue but a multi-homed server issue. > 3) > > In practice, local IPv6 connections may still work while the link to the > outside world is broken. What does 'failed' mean in this context? Again this is one of the reasons I keep saying that this isn't a IPv4/IPv6 issue but a multi-homed server issue. > 4) > > What happens if I take the same algorithm as Google used in Chrome but I > set the timer to 30 ms instead of 300? Is that considered an acceptable HE > implementation according to this draft? I can't see why not. > 5) > > This draft sometimes talks about an entire address family (for example > Section 4.2) but in other places (Section 4) it's about addresses for an > individual host. I think this should be make more clear in Sections 4.1 and > 4.2. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwmalone@maths.tcd.ie Mon Jul 11 08:47:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A81121F8D7D for ; Mon, 11 Jul 2011 08:47:12 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx4zdIwjeiqW for ; Mon, 11 Jul 2011 08:47:11 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by ietfa.amsl.com (Postfix) with SMTP id 023EF21F8D71 for ; Mon, 11 Jul 2011 08:47:10 -0700 (PDT) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 11 Jul 2011 16:47:08 +0100 (BST) Date: Mon, 11 Jul 2011 16:47:08 +0100 From: David Malone To: Nick Hilliard Message-ID: <20110711154708.GA76347@walton.maths.tcd.ie> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110707192002.GA29545@walton.maths.tcd.ie> <4E1B1938.5050906@inex.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E1B1938.5050906@inex.ie> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie X-Mailman-Approved-At: Tue, 12 Jul 2011 08:02:49 -0700 Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:47:12 -0000 On Mon, Jul 11, 2011 at 04:39:36PM +0100, Nick Hilliard wrote: > In any case, netflow is usually implemented to detect large bursts of > traffic like this, so it's probably not that much different from other DoS > attacks in this respect. You has your DoS, you takes out your netflow > stats, then you figures out what's going on. Sounds reasonable. I think you have your security considerations section right there. David. From cx.cernet@gmail.com Tue Jul 12 18:21:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9311E80D9 for ; Tue, 12 Jul 2011 18:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly3FHnhEunz1 for ; Tue, 12 Jul 2011 18:21:37 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D36A11E80E3 for ; Tue, 12 Jul 2011 18:21:37 -0700 (PDT) Received: by pzk5 with SMTP id 5so6172168pzk.31 for ; Tue, 12 Jul 2011 18:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5cKG1KB1m9ccEUpSV3mmDTk7AHdrLw4b/ynrCFTWGpU=; b=Cn6bNTjA6H+GMd0aiKkkmxlcONcJmrHLev8OnxLztEyKR3y4xv4hFn7sJLQh4T23yZ 6JrR0Wk/2hTuH0CNRHuyrbMpKyJAE8XfG5LHadrvDXvOld+QJTcPsNWwSi8cWIqtGQvy pVFj6MENmAgjQCoSEX5GN0SylY8+aKwC0pwc0= MIME-Version: 1.0 Received: by 10.142.250.38 with SMTP id x38mr243585wfh.30.1310520095745; Tue, 12 Jul 2011 18:21:35 -0700 (PDT) Received: by 10.142.164.14 with HTTP; Tue, 12 Jul 2011 18:21:35 -0700 (PDT) Date: Wed, 13 Jul 2011 09:21:35 +0800 Message-ID: From: Congxiao Bao To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=001636ed62f9c7299b04a7e93c7d Cc: congxiao@cernet.edu.cn Subject: [v6ops] request for a presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 01:28:16 -0000 --001636ed62f9c7299b04a7e93c7d Content-Type: text/plain; charset=ISO-8859-1 Hi Fred, We would like to request a timeslot to present our draft in v6ops in the coming ietf meeting. Presenter : Wojciech Dec Title of the draft:Stateless 4Via6 Address Sharing Url: https://datatracker.ietf.org/doc/draft-dec-stateless-4v6/?include_text=1 Thank you very much! Congxiao --001636ed62f9c7299b04a7e93c7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Fred,

We would like to reque= st a timeslot to present our draft in v6= ops in the coming ietf meeting.

Presenter : Wojciech Dec
Ti= tle of the draft:Stateless 4Via6 = Address Sharing
Url: https://datatracker.ietf.org/doc/draft-dec-stateless-4v6/?inclu= de_text=3D1

Thank you very much!

Congxi= ao --001636ed62f9c7299b04a7e93c7d-- From congxiao@cernet.edu.cn Tue Jul 12 17:58:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E11C11E80DA for ; Tue, 12 Jul 2011 17:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.004 X-Spam-Level: X-Spam-Status: No, score=-96.004 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_HAS_XAIMC=2.696, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGEyOl4UXywu for ; Tue, 12 Jul 2011 17:58:57 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 3A19011E80D6 for ; Tue, 12 Jul 2011 17:58:57 -0700 (PDT) Received: from [127.0.0.1]([59.66.24.198]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm364e1d651d; Wed, 13 Jul 2011 08:58:55 +0800 Message-ID: <4E1CEDD9.5040107@cernet.edu.cn> Date: Wed, 13 Jul 2011 08:59:05 +0800 From: Congxiao Bao User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: "Fred Baker (fred)" , "Wojciech Dec (wdec)" , "Rajiv Asati (rajiva)" , Xing Li , v6ops@ietf.org Content-Type: multipart/alternative; boundary="------------040907000008040205090402" X-AIMC-AUTH: congxiao X-AIMC-MAILFROM: congxiao@cernet.edu.cn X-AIMC-Msg-ID: coxmng0B X-Mailman-Approved-At: Wed, 13 Jul 2011 08:01:57 -0700 Subject: [v6ops] request for presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 00:58:58 -0000 This is a multi-part message in MIME format. --------------040907000008040205090402 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Hi Fred, We would like to request a timeslot to present our draft in v6ops in the coming ietf meeting. Presenter : Wojciech Dec Title of the draft:Stateless 4Via6 Address Sharing Url: https://datatracker.ietf.org/doc/draft-dec-stateless-4v6/?include_text=1 Thank you very much! Congxiao --------------040907000008040205090402 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 7bit Hi Fred,

We would like to request a timeslot to present our draft in v6ops in the coming ietf meeting.

Presenter : Wojciech Dec
Title of the draft:Stateless 4Via6 Address Sharing
Url: https://datatracker.ietf.org/doc/draft-dec-stateless-4v6/?include_text=1


Thank you very much!


Congxiao --------------040907000008040205090402-- From fred@cisco.com Wed Jul 13 13:06:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4798B21F853A for ; Wed, 13 Jul 2011 13:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.445 X-Spam-Level: X-Spam-Status: No, score=-104.445 tagged_above=-999 required=5 tests=[AWL=-2.446, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfaOGsvt7qFa for ; Wed, 13 Jul 2011 13:06:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8F86C21F8534 for ; Wed, 13 Jul 2011 13:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=544; q=dns/txt; s=iport; t=1310587582; x=1311797182; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=QLln6tyuskXPyp+Lx7S2/tclEO6jk5U3/ZaAEEaLan8=; b=HAX5XKj/P50NhsxmwI2MbUqQJnZnSuTFWzRqNyaInnFdc2zwg9U7c6yc 23Pqm0IxEcKe/1ZLcp475r2O07HweRrRoZ8H84nJpvx35PHE2tPEK3Hjw KESGCJ6ZUohA0Dm6CvP3RLwXpJcCLJGzB2zKNEbBZOTqk3kUo5/pfyB/A E=; X-IronPort-AV: E=Sophos;i="4.65,526,1304294400"; d="scan'208";a="2673483" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-1.cisco.com with ESMTP; 13 Jul 2011 20:06:20 +0000 Received: from Freds-Computer.local (sjc-vpn4-887.cisco.com [10.21.83.118]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6DK6Jsm011584; Wed, 13 Jul 2011 20:06:19 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Wed, 13 Jul 2011 16:06:20 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Wed, 13 Jul 2011 16:06:20 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E1CEDD9.5040107@cernet.edu.cn> Date: Wed, 13 Jul 2011 16:06:05 -0400 Message-Id: References: <4E1CEDD9.5040107@cernet.edu.cn> To: Congxiao Bao X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, "Wojciech Dec \(wdec\)" , "Rajiv Asati \(rajiva\)" Subject: Re: [v6ops] request for presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 20:06:23 -0000 On Jul 12, 2011, at 8:59 PM, Congxiao Bao wrote: > Hi Fred, >=20 > We would like to request a timeslot to present our draft in v6ops in = the coming ietf meeting. >=20 > Presenter : Wojciech Dec=20 > Title of the draft:Stateless 4Via6 Address Sharing > Url: = https://datatracker.ietf.org/doc/draft-dec-stateless-4v6/?include_text=3D1= >=20 > Thank you very much! >=20 > Congxiao Dumb question: Given that all drafts related to tunneling IPv4 over IPv6 = are being handled in softwire, why is this not a softwire draft? From john.mann@monash.edu Wed Jul 13 17:29:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6D911E808D for ; Wed, 13 Jul 2011 17:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.775 X-Spam-Level: X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ctfc-juCaC7Y for ; Wed, 13 Jul 2011 17:28:57 -0700 (PDT) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with ESMTP id F358F21F893C for ; Wed, 13 Jul 2011 17:28:56 -0700 (PDT) Received: from mail-gw0-f44.google.com ([74.125.83.44]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKTh44SCZnu1aTg8A1QPfSHNG7NwfAmNGt@postini.com; Wed, 13 Jul 2011 17:28:57 PDT Received: by gwb20 with SMTP id 20so3119538gwb.31 for ; Wed, 13 Jul 2011 17:28:55 -0700 (PDT) Received: by 10.90.76.1 with SMTP id y1mr1869150aga.136.1310603334284; Wed, 13 Jul 2011 17:28:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.118.6 with HTTP; Wed, 13 Jul 2011 17:28:34 -0700 (PDT) In-Reply-To: References: <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.com> From: "John Mann (ITS)" Date: Thu, 14 Jul 2011 10:28:34 +1000 Message-ID: To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=00163630edcd2e751304a7fc9ee6 Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 00:29:03 -0000 --00163630edcd2e751304a7fc9ee6 Content-Type: text/plain; charset=ISO-8859-1 v6ops people, Fred and I have done round of review off-list. This is my reply to that .. On 14 July 2011 02:53, Templin, Fred L wrote: > ** > Hi John, > > Thanks again for the comments, and see below for proposed > resolutions: > > ------------------------------ > *From:* John Mann (ITS) [mailto:john.mann@monash.edu] > *Sent:* Tuesday, July 05, 2011 11:24 PM > *To:* Templin, Fred L > > *Subject:* Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? > > Fred, > > The per-page heading is "Routing Loop Attack". > > Good catch. I will change this to "ISATAP Operational Guidance". > > > 1. Introduction > > s/RANGERS/RANGER/ > > > There are actually two documents - RANGER is [RFC5720] and RANGERS > is [RFC6139]. I was meaning to cite the latter. > > > 2. Enabling IPv6 Services using ISATAP > > "Many existing sites within the Internet predominantly use IPv4-based > services for their internal networking needs, but there is a growing > requirement for enabling IPv6 services to support communications with > IPv6-only correspondents." > > This sentence is a a re-hash of the last paragraph of section 1. > Perhaps it can be removed ?? > > > Good point, but I'd still like a lead-in sentence to that paragraph so > how would it be if I simply replaced that sentence with the following: > > "Existing IPv4 sites within the Internet will soon need to enable > IPv6 services." > Fine. > > "Smaller sites that wish to enable IPv6 > typically arrange to obtain public IPv6 prefixes from an Internet > Service Provider (ISP), where the prefixes may be either purely > native, the near-native prefixes offered by 6rd [RFC5969] or the > transitional prefixes offered by 6to4 [RFC3056][RFC3068]. " > > I would split this into > Smaller sites that wish to enable IPv6 > can arrange to obtain public IPv6 prefixes from an Internet > Service Provider (ISP), where the prefixes may be either purely > native, or the near-native prefixes offered by 6rd [RFC5969]. > Or use an ISP-independant method like > transitional prefixes offered by 6to4 [RFC3056][RFC3068], > or prefixes from a tunnel-broker [ref?]. > > > Good point, although I think perhaps a bit more should be said about > 6to4. Rephrasing slightly, see if this sounds OK: > > "Smaller sites that wish to enable IPv6 can arrange to obtain public IPv6 > prefixes from an Internet Service Provider (ISP), where the prefixes may > be either purely native or the near-native prefixes offered by 6rd > [RFC5969]. > Alternatively, the site can obtain prefixes independently of an ISP e.g., > via > a tunnel broker [RFC3053], by using one of its public IPv4 addresses to > form a 6to4 prefix [RFC3056][RFC3068], etc." > Please add something like Note that 6to4 is not recommended for new implementations [draft-ietf-v6ops-6to4-to-historic or draft-moore-6to4-experimental ], and should be implemented with care [ draft-ietf-v6ops-6to4-advisory or RFC-new ]. > "Advertising ISATAP > routers configure their site-facing ISATAP interfaces as advertising > router interfaces " > > "site-facing" isn't defined. How many interfaces each router has is not > defined. > > => Each advertising ISATAP router configures an site-internal interface > as an ISATAP advertising router interface. > > "ISATAP hosts > configure their site-facing ISATAP interfaces as simple host > interfaces and ..." > > "site-facing"? how many interfaces? > > => Each ISATAP host configures an interface as a simple ISATAP host > interface and ... > > > I get your point, and I think perhaps a bit more work is needed here. > Any node (host or router) can have any number of ISATAP interfaces > connected to any number of sites. The host may be an advertising > ISATAP router on some sites, a non-advertising ISATAP router on > other sites, and a simple ISATAP host on other sites. Each such > "personality" of the node would be represented by a distinct ISATAP > interface. With that in mind, here is a proposed rewrite of the paragraph: > > "The ISATAP service is based on two node types known as > advertising ISATAP routers and simple ISATAP hosts. (A third node > type known as non-advertising ISATAP routers is defined in > [draft-templin-isupdate] but out of scope for this document.) Each node > may further have multiple ISATAP interfaces (i.e., one interface for > each > site), and may act as an advertising ISATAP router on some of those > interfaces and a simple ISATAP host on others. Hence, the node type > is considered on a per-interface basis. > > Advertising ISATAP routers configure their ISATAP interfaces as > advertising router interfaces (see: [RFC4861], Section 6.2.2). ISATAP > hosts configure their ISATAP interfaces as simple host interfaces and > also coordinate their autoconfiguration operations with advertising > ISATAP > routers. In this sense, advertising ISATAP routers are "servers" while > ISATAP hosts are "clients" in the service model." > I am a little bit confused here about the possibility that a host may be connected to a number of sites. For the purposes of this document, is it useful to simplify the model a little: | *IPv4 view* | *ISATAP view* | *Connectivity* | *Multi-site* | | host | ISATAP host | connected to one ISATAP subnet | No | | gateway | advertising ISATAP router | can connect to multiple ISATAP subnets | Possible | [ I know, I have introduced a new term "gateway" ] > 3.3. Reference Operational Scenario - Shared Prefix Model > > I think this could be _slightly_ improved by being a bit more explicit when > packets are encapsulated, > and whether they are sent to a host/routers IPv4 or IPv6 address. > > > I like the idea of being more explicit. In your proposed text below, > however, would you mind if I omitted the "IPv6-in-IPv4" and just > used the word "encapsulated". Reason being is that, since we > are talking about ISATAP, IPv6-in-IPv4 is already assumed. > > > "Assuming 'A' is closest, 'C' receives an > _IPv6-in-IPv4 encapsulated_ > RA from 'A' then configures a default > IPv6 route with next-hop address fe80::5efe:192.0.2.1 via the ISATAP > interface and processes the IPv6 prefix 2001:db8::/64 advertised in > the PIO. " > > " 'D' next performs an > _IPv6-in-IPv4 encapsulated_ > anycast RS/RA exchange that is serviced by 'B', " > > "If the site is not partitioned internally, the > router that receives the packet can use ISATAP to statelessly forward > the packet directly to 'C' _using IPv6-in-IPv4 encapsulation_. > > Yes, IPv6-in-IPv4 should be clear in context. > === > Otherwise, excellent stuff. > > > Thanks, and I hope this work may be useful to you and others. > > > I have installed, but not gone live with a slightly different model. > I don't know if it is interesting enough to be included in the draft ... > > Large enterprise network, mostly IPv6 dual-stack, but not on wireless. > Staff wireless --> one /64 ISATAP subnet > Student wireless --> different ISATAP subnet > Staff and student wireless aren't geographically separate, so I can't split > PRL by site. > One pair of ISATAP gateways for staff advertise anycast 130.194.29.255/32 > One pair of ISATAP gateways for students advertise anycast > 130.194.29.254/32 > PRL contains 130.194.29.255 and 130.194.29.254 > > Separation managed by ACL inbound on ISATAP interface including > ... > permit ipv6 FE80::200:5EFE:317F:0/112 any > deny ipv6 FE80::200:5EFE:0:0/96 any > deny ipv6 FE80::5EFE:0:0/96 any > ... > i.e. permit encapsulated RS's from ISATAP-mapped 49.127/16 but not from > other IPv4 address ranges > > > I like this method for logically partitioning an ISATAP link that is not > physically partitioned. A similar method is covered in the third > paragraph of Section 3.5, but your description augments what is > already there. Please check the following to see if this looks like > a worthwhile augmentation of that paragraph: > > "When individual prefixes are used, site administrators can configure > advertising ISATAP routers to advertise different individual prefixes > to > different sets of clients, e.g., based on the client's IPv4 subnet > prefix. > (For example, administrators can configure each advertising ISATAP > router to provide services to some sets of ISATAP clients but not > others through inbound IPv6 Access Control List (ACL) entries that > discard encapsulated messages with certain ISATAP source addresses > based on the embedded IPv4 subnet prefix). When a shared prefix is > used, the site administrator could instead configure the ISATAP routers > to advertise the shared prefix to all clients." > Fine, except for the last sentence. s/could/would/ ?? If a shared prefix is used, when would that shared prefix _not_ be advertised to all clients. > > John > > > Thanks again for all of your great suggestions. Please let me know > if this adequately addresses everything. > > Fred > fred.l.templin@boeing.com > === New I see that loop avoidance gets mentioned in sections 3.6 and 10. How about more-generic address checking? An ISATAP router SHOULD check all incoming encapsulated addresses to make sure that the embedded IPv6 source address is valid -- link-local or global within the range of IPv4-mapped addresses for that subnet. An ISATAP router SHOULD check all IPv6 packets to be encapsulated to make sure that the IPv6 destination address is valid -- link-local or global within the range of IPv4-mapped addresses for that subnet, or multicast. For SLAAC-assigned addresses in the shared prefix model above providing services to 192.0.2.0/24, the valid addresses would be fe80::5efe: 192.0.2.0/120 and 2001:db8::5efe:192.0.2.0/120 . However, if Global IPv4 addresses are used, the ISATAP prefix is 0200:5efe:: rather than 0000:5efe:: see http://tools.ietf.org/html/rfc5214#section-6.1 Is 192.0.2.0/24 an example "global" or "private" address? http://tools.ietf.org/html/rfc3330 doesn't say. This question impacts the examples in this Draft, and elsewhere such as http://tools.ietf.org/html/draft-ietf-v6ops-tunnel-loops-07#section-3.2.4.5 The "wisdom of crowds" is divided on this: Google search for "isatap fe80::200:5efe:C000" == 243 hits Google search for "isatap fe80::5ef5:C000" == 571 hits My Cisco router seems to do the local/global bit wrong [ "????" and "####" == address obfuscation. ] --- Interface Tunnel9 ipv6 address 2001:388:608C:????::/64 eui-64 tunnel mode ipv6ip isatap ... Tunnel9 is up, line protocol is up Global unicast address(es): 2001:388:608C:????:0:5EFE:82C2:####, subnet is 2001:388:608C:????::/64 [EUI] --- The 82C2:#### mapped IPv4 address is 130.194.0.0/16 which is definitely globally valid. John > > On 2 July 2011 08:54, Templin, Fred L wrote: > >> ** >> Hi Joel, >> >> Me again. There have have been others who have also expressed >> concerns about DHCPv6 and other "undocumented features" on >> ISATAP links, so I decided to split the document into two pieces. >> >> The new piece is now called: "ISATAP Updates" and I guess might >> be more appropriate for some other working group. The other piece >> retains the original name and is strictly about operational >> aspects >> of widely-deployed implementations: >> >> http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-12.txt >> What should we do next - ask the wg for comments? >> >> Thanks - Fred >> >> ------------------------------ >> *From:* v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] *On >> Behalf Of *Templin, Fred L >> *Sent:* Wednesday, June 22, 2011 8:13 AM >> *To:* Joel Jaeggli >> *Cc:* v6ops@ietf.org >> *Subject:* Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? >> >> Hi Joel, >> >> Thanks for your comments, and see below for responses: >> >> ------------------------------ >> *From:* Joel Jaeggli [mailto:joelja@bogus.com] >> *Sent:* Friday, June 17, 2011 12:50 PM >> *To:* Templin, Fred L >> *Cc:* v6ops@ietf.org >> *Subject:* Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? >> >> On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote: >> >> Hello, >> >> Significant improvements have been made to this document >> (below) based on comments received and new observations. >> IMHO, this is an important document for enabling transition >> to IPv6 within IPv4 sites; hence, I would like to call for >> working group adoption at this time. >> >> Thanks - Fred >> fred.l.templin@boeing.com >> >> >> Replying to this message as a way to maintain the threading. these notes >> are relative to the current version of the draft which I reviewed last week: >> >> http://tools.ietf.org/html/draft-templin-v6ops-isops-10 >> >> So I tried for a while to separate the operational advice that could be >> applied to my 2005 era knowledge of isatap and there's quite a few things >> that jive with that (tunnel loops for example). >> >> OK. >> >> In other cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what >> implementations are capable of doing that? Are we recommending that they do >> it? do they already? >> >> I can't speak for current implementations, but the DHCPv6 approach is >> based on the fact that address and prefix assignment on IPv6 interfaces >> are seperable functions. IPv6 prefixes assigned to ISATAP interfaces can >> only be used for autoconfiguration of ISATAP addresses and not ordinary >> IPv6 addresses. However, an ordinary IPv6 address can be assigned to >> an ISATAP interface the same as for any other IPv6 interface as long as >> it is not covered by a prefix assigned to the interface. >> >> Regarding aero (section 4.6) that looks pretty much like new work or an >> extension to the specification. >> >> AERO is a new but backwards-compatible method of doing redirection >> of an on-link neighbor to another on-link neighbor. However, ISATAP >> interfaces can still use standards ICMPv6 Redirect messages the same >> as for any IPv6 interface. Advertising ISATAP routers should only send >> ICMPv6 redirects when they are certain that the redirected ISATAP node >> can tunnel packets directly to the target of the redirect, however. >> Perhaps >> a few more words saying explicitly that standards ICMPv6 redirects are >> still supported would help? >> >> Are there participants with extant isatap deployements or host >> implementations or knowledge fresher than mine that would care to comment on >> this draft. >> >> >> There are certainly vendors who are shipping ISATAP in their products >> today. Perhaps they can comment. >> >> section 9 alternative approaches, there's some consensus that rfc 3056 was >> never really deployed so the reference to 6to4 should probably be to 3068 >> >> >> >> OK - I can fix this. >> >> Thanks - Fred >> fred.l.templin@boeing.com >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > --00163630edcd2e751304a7fc9ee6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable v6ops people,

Fred and I have done round of review off-l= ist.
This is my reply to that ..

On 14 July 2011 02:53, Templin, Fred L <Fred.L.Templin@bo= eing.com> wrote:
Hi Jo= hn,
=A0
Thank= s again for the comments, and see below for=20 proposed
resol= utions:

From: John Mann (ITS)=20 [mailto:john.ma= nn@monash.edu]
Sent: Tuesday, July 05, 2011 11:24=20 PM
To: Templin, Fred L

Subject: Re: [v6ops]=20 'draft-templin-v6ops-isops' as v6ops wg item?
Fred,

The per-page heading is "Routing Loop Attack".=A0
Good catch.=20 I will change this to "ISATAP=A0Operational=20 Guidance".=A0

1. =A0Introduction

s/RANGERS/RANGER/=A0
=A0
There are=20 actually two documents - RANGER is [RFC5720] and RANGERS
is=20 [RFC6139].=A0I was meaning to cite the latter.=A0

2. =A0Enabling IPv6 Services using ISATAP

=A0 =A0"Many existing sites within the Internet predominantly u= se=20 IPv4-based
=A0 =A0services for their internal networking needs, but there is a= =20 growing
=A0 =A0requirement for enabling IPv6 services to support=20 communications with
=A0 =A0IPv6-only correspondents."

This sentence is a a re-hash of the last paragraph of section 1.
Perhaps it can be removed ??=A0
=A0
Good point,=20 but I'd still like=A0 a lead-in sentence=A0to that paragraph=20 so
how would it=20 be if I=20 simply replaced that sentence with the following:
=A0
=A0=20 "Existing IPv4 sites within the Internet will soon need to=20 enable
=A0=A0 = IPv6=20 services."

Fine.
=A0

=A0 =A0"Smaller sites that wish to enable IPv6
=A0 =A0typically arrange to obtain public IPv6 prefixes from an=20 Internet
=A0 =A0Service Provider (ISP), where the prefixes may be either=20 purely
=A0 =A0native, the near-native prefixes offered by 6rd [RFC5969] or= =20 the
=A0 =A0transitional prefixes offered by 6to4 [RFC3056][RFC3068].=20 "

I would split this into
=A0 =A0Smaller sites that wish to enable IPv6
=A0 =A0can arrange to obtain public IPv6 prefixes from an=20 Internet
=A0 =A0Service Provider (ISP), where the prefixes may be either=20 purely
=A0 =A0native, or the near-native prefixes offered by 6rd=20 [RFC5969].
=A0 =A0Or use an ISP-independant method like
=A0 =A0transitional prefixes offered by 6to4=20 [RFC3056][RFC3068],
=A0 =A0or prefixes from a tunnel-broker [ref?].=A0
=A0
Good point,=20 although I think perhaps a bit more should be said about
6to4.=20 Rephrasing=A0slightly, = see if this sounds OK:
=A0
=A0=20 "Smaller sites that wish to enable IPv6 can arrange to=A0obtain public= =20 IPv6
=A0=A0=A0prefixes fr= om an Internet Service Provider (ISP), where=20 the prefixes may
=A0=A0=20 be either purely native or the=A0near-native=A0prefixes offered by 6rd=20 [RFC5969].
=A0=A0=20 Alternatively, the site can obtain prefixes independently of an ISP=20 e.g.,=20 via
=A0=A0=20 a tunnel=A0broker [RFC3053], by using one of its public IPv4 addresses=20 to
=A0=A0=20 form a 6to4=20 prefix=20 [RFC3056][RFC3068], etc= ."=A0=A0

<= /div>
Please add something like
=A0 =A0Note that 6to4 is not = recommended for new implementations [draft-ietf-v6ops-6to4-to-historic or= =A0draft-moore-6to4-experimental ],
and should be implemented with care [=A0draft-ietf-v6ops-6to4-advisory= or RFC-new ].


=A0 =A0"Advertising ISATAP
=A0 =A0routers configure their site-facing ISATAP interfaces as=20 advertising
=A0 =A0router interfaces "

"site-facing" isn't defined. =A0How many interfaces ea= ch router has is=20 not defined.

=A0=3D> =A0Each advertising ISATAP router configures an=20 site-internal interface as an ISATAP advertising router interface.

=A0 =A0"ISATAP hosts
=A0 =A0configure their site-facing ISATAP interfaces=A0as simple=20 host
=A0 =A0interfaces and ..."

"site-facing"? =A0how many interfaces?

=3D> Each ISATAP host configures an interface as a simple ISATAP = host=20 interface and ...= =A0
=A0
I get your=20 point, and I think perhaps a bit=A0more work is needed=20 here.
Any node=20 (host or router) can have any number of ISATAP interfaces
connected to=20 any number of sites. The host may be an advertising
ISATAP=20 router on some sites, a non-advertising ISATAP router on
other sites,=20 and a simple ISATAP host on other sites. Each such
"personality&qu= ot; of the node would be represented by a distinct=20 ISATAP
interface.=20 With that in mind, here is a proposed rewrite of the=20 paragraph:
=A0
=A0 "The=20 ISATAP service is based on two=A0node types known as
=A0=A0 adverti= sing ISATAP routers=A0and simple=20 ISATAP hosts. (A third=20 node
=A0=A0 type kn= own as non-advertising ISATAP routers is defined in
=A0=A0 = [draft-templin-isupdate] but out of scope for this=20 document.) Each=20 node
=A0=A0 may further have multiple ISATAP interfaces (i.e., one i= nterface for each
=A0=A0 = site), and may act as an advertising ISATAP router on so= me of those
=A0=A0 = interfaces and a simple ISATAP host on others. Hence,=20 the node type
=A0=A0 is cons= idered on a per-interface=20 basis.
=A0
=A0=A0=20 Advertising ISATAP routers configure their ISATAP interfaces=20 as
=A0=A0=20 advertising router interfaces (see: [RFC4861], Section 6.2.2).=20 ISATAP
=A0=A0=20 hosts configure their ISATAP interfaces as simple host interfaces=20 and
=A0=A0=20 also coordinate their autoconfiguration operations with advertising=20 ISATAP
=A0=A0=20 routers. In this sense, advertising ISATAP routers are "servers"= =20 while
=A0=A0 ISATAP = hosts are "clients" in the service=20 model."

I am a little bit confused here about the possibility that a host may be= connected to a number of sites.
For the purposes of this documen= t, is it useful to simplify the model a little:

| *IPv4 view* | *ISATAP view* | *Connectivity* | *Multi= -site* |
| host | ISATAP host | connected to one ISATAP subnet | = No |
| gateway | advertising ISATAP router | can connect to multi= ple ISATAP subnets | Possible |

[ I know, I have introduced a new term "gateway&qu= ot; ]
=A0
3.3. =A0Reference Operational Scenario - Shared Prefix=20 Model

I think this could be _slightly_ improved by being a bit more explic= it=20 when packets are encapsulated,
and whether they are sent to a host/routers IPv4 or IPv6 address.=A0
=A0
I like the=20 idea of being more explicit. In your proposed text below,
however,=20 would you mind=A0if I omitted the "IPv6-in-IPv4" and just<= /span>
used the=20 word "encapsulated". Reason being is that, since we=
are talking=20 about ISATAP, IPv6-in-IPv4 is already assumed.

"Assuming=A0'A' is closest, 'C' receives an
=A0 =A0 _IPv6-in-IPv4=A0encapsulated_
=A0 =A0RA from 'A' then configures a default
=A0 =A0IPv6 route with next-hop address fe80::5efe:192.0.2.1 via=20 the ISATAP
=A0 =A0interface and processes the IPv6 prefix 2001:db8::/64=20 advertised in
=A0 =A0the PIO. "

"=A0'D' next performs an
=A0 =A0 _IPv6-in-IPv4 encapsulated_
=A0 =A0anycast RS/RA exchange that is serviced by 'B', "= ;

"If the site is not partitioned internally, the
=A0 =A0router that receives the packet can use ISATAP to=20 statelessly forward
=A0 =A0the packet directly to 'C' _using=A0IPv6-in-IPv4=20 encapsulation_.

Yes, IPv6-in-IPv4 should be clear in context.
=A0
=3D=3D=3D
Otherwise, excellent stuff.=A0
=A0
Thanks, and=20 I hope this work may be useful to you and others.=A0

I have installed, but not gone live with a slightly different=20 model.
I don't know if it is interesting enough to be included in the d= raft=20 ...

Large enterprise network, mostly IPv6 dual-stack, but not on=20 wireless.
Staff wireless --> one /64 ISATAP subnet
Student wireless --> different ISATAP subnet
Staff and student wireless aren't geographically separate, so I = can't=20 split PRL by site.
One pair of ISATAP gateways for staff advertise anycast 130.194.29.255/32
One pair of ISATAP gateways for students advertise anycast 130.194.29.254/32
PRL contains=A0130.194.29.255 and=A0130.194.29.254

Separation managed by ACL inbound on ISATAP interface including
=A0 =A0 ... =A0=A0
=A0 =A0=A0permit ipv6 FE80::200:5EFE:317F:0/112 any
=A0 =A0 deny ipv6 FE80::200:5EFE:0:0/96 any
=A0 =A0 deny ipv6 FE80::5EFE:0:0/96 any
=A0 =A0 ...
i.e. permit encapsulated RS's from ISATAP-mapped 49.127/16 but n= ot from=20 other IPv4 address ranges=A0
=A0
I like this=20 method for=A0logically partitioning an ISATAP=A0link that is=20 not
physically=A0= partitioned. A similar=20 method is covered in the third
paragraph of=20 Section 3.5, but your description augments what is
already=20 there. Please check the following to see if this looks like
a worthwhile=20 augmentation of that paragraph:
=A0
=A0 "When=20 individual prefixes are used, site administrators can=20 configure
=A0=A0=20 advertising ISATAP routers to advertise different individual = prefixes to
=A0=A0=20 different sets of clients, e.g., based on the client's IPv4 subnet=20 prefix.
=A0=A0=20 (For example, administrators can configure=A0each advertising=20 ISATAP
=A0=A0=A0router to=20 provide services= to some sets of ISATAP clients but not
=A0=A0=20 others through <= /span>inbound IPv6 Access Control Lis= t (ACL) entries that
=A0=A0=A0discard enc= apsulated messages=20 with=A0certain=A0ISATAP source addresses
=A0=A0=20 based on the embedded I= Pv4 subnet prefix). When a shared prefix is
=A0=A0=20 used, the site administrator could instead configure=A0the ISATAP=20 routers
=A0=A0=20 to advertise the shared prefix to all clients."

Fine, except for the last sentence.
s/could/would/ ??
If a shared prefix is used, when would t= hat shared prefix _not_ be advertised to all clients.

=A0 =A0 John= =A0
=A0
Thanks again=20 for all of your great suggestions. Please let me know
if this=20 adequately addresses everything.


=
=3D=3D=3D New
=

I see that loop avoidance gets mentioned in sections 3.= 6 and 10.
How about more-generic address checking?

=
An ISATAP router SHOULD check all incoming encapsulated addresses to m= ake sure that the embedded IPv6 source address is valid --
link-local = or global within the range of IPv4-mapped addresses for that subnet.
An ISATAP router SHOULD check all IPv6 packets t= o be encapsulated to make sure that the IPv6 destination address is valid -= -=A0
link-local or global within the range = of IPv4-mapped addresses for that subnet, or multicast.
For SLAAC-assigned addresses in the shared prefi= x model above providing services to 192.0.2= .0/24, the valid addresses would be =A0fe80::5efe:192.0.2.0/120 and 2001:db8::5efe:192.0.2.0/120 .

However, if Global IPv4 addresses are used, the ISATAP prefi= x is 0200:5efe:: rather than 0000:5efe:: see=A0http://tools.ietf.org/html/rfc5214#section-6= .1
Is 192.0.2.0/24 an example "g= lobal" or "private" address?=A0http://tools.ietf.org/html/rfc3330 doesn't say.

This question impacts the examples in this Draft, and e= lsewhere such as
The "wisdom of crowds" is divided on this:
=A0 Goo= gle search for "isatap fe80::200:5efe:C000" =3D=3D 243 hits
=
=A0 Google search for "isatap fe80::5ef5:C000" =3D=3D 571 hi= ts

My Cisco router seems to do the local/global bit wrong = [ "????" and "####" =3D=3D address obfuscation. ]
=
---
Interface Tunnel9
=A0ipv6 address 2001:38= 8:608C:????::/64 eui-64
=A0tunnel mode ipv6ip isatap
=A0...

Tunnel9 is up, line protocol is up
Global unicast add= ress(es):
=A0 =A0 2001:388:608C:????:0:5EFE:82C2:####, subnet is = 2001:388:608C:????::/64 [EUI]
---
The 82C2:#### mapped IPv4 address is 130.194.0.0/16 which is definitely globally valid.=

=A0 =A0 John
=A0

On 2 July 2011 08:54, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
H= i=20 Joel,
<= /span>=A0
M= e again. There have=20 have been others who have also expressed
c= oncerns about DHCPv6=20 and other "und= ocumented=20 features" on
I= SATAP links, so I=20 decided to split the document into two pieces.
<= /span>=A0
<= span>The new piece=20 is now called: "ISATAP Updates" and I guess=20 might
<= span>be more=20 appropriate for some other working group. The= =20 other piece
retains=20 the original name and is strictly about operational=20
aspects
o= f widely-deployed=20 implementations:
<= /span>=A0
<= font face=3D"Times New Roman" size=3D"3">http://www= .ietf.org/internet-drafts/draft-templin-v6ops-isops-12.txt=A0
W= hat should we do next - ask the wg for comment= s?
<= /span>=A0
T= hanks -=20 Fred

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin,=20 Fred L
Sent: Wednesday, June 22, 2011 8:13 AM
To:= Joel=20 Jaeggli
Cc: v= 6ops@ietf.org
Subject: Re: [v6ops]=20 'draft-templin-v6ops-isops' as v6ops wg=20 item?

Hi=20 Joel,
=A0
Thanks for your=20 comments, and see below for responses:

From: Joel Jaeggli [mailto:= joelja@bogus.com]= =20
Sent: Friday, June 17, 2011 12:50 PM
To: Templ= in,=20 Fred L
Cc: v6ops@ietf.org
Subject: Re: [v6ops]=20 'draft-templin-v6ops-isops' as v6ops wg item?
On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote:

Hello,

Significant improvements have been made to thi= s=20 document
(below) based on comments received and new=20 observations.
IMHO, this is an important document for enabling= =20 transition
to IPv6 within IPv4 sites; hence, I would like to c= all=20 for
working group adoption at this time.

Thanks - Fred<= br>fred.l.te= mplin@boeing.com


Replying=20 to this message as a way to maintain the threading. these notes are= =20 relative to the current version of the draft which I reviewed last= =20 week:


So I tried for a while t= o=20 separate the operational advice that could be applied to my 2005 er= a=20 knowledge of isatap and there's =A0quite a few things that jive= with=20 that (tunnel loops for example).=A0
OK.=A0=A0
In other cases such isat= ap=20 dhcpv6 (4.5) I'm a bit-off in the weeds, what implementations a= re=20 capable of doing that? Are we recommending that they do it? do they= =20 already?=A0=
I can't speak for current=A0implementations, bu= t the DHCPv6=20 approach is
based on the fact that address and prefix assignmen= t on IPv6=20 interfaces
are seperable functions. IPv6 prefixes assigned to = ISATAP=20 interfaces can
only be used for autoconfiguration of ISATAP addres= ses=20 and not ordinary
IPv6 addresses. However, an ordinary IPv6 address c= an=20 be assigned to
an ISATAP interface the same as for any other IPv6= =20 interface as long as
it is not covered by a prefix assigned to the=20 interface.=
Regarding aero (section = 4.6)=20 that looks pretty much like new work or an extension to the=20 specification.=A0
AERO is a new but backwards-compatible method of do= ing=20 redirection
of an on-link neighbor to another on-link neighbor.= =20 However,=A0ISATAP
interfaces can still use standards ICMPv6 Redirect = messages the=20 same
as for any IPv6 interface.=A0Advertising ISATAP=20 routers=A0should only send
ICMPv6 redirects when they are certain that the red= irected ISATAP=20 node
can=A0tunnel packets directly to the target of the = redirect,=20 however. Perhaps
a few more words saying explicitly that standards I= CMPv6 redirects=20 are
still supported would help?=A0=
Are there participants w= ith=20 extant isatap deployements or host implementations or knowledge fre= sher=20 than mine that would care to comment on this draft.=A0
=A0<= /div>
There are certainly vendors who are shipping ISATAP= in their=20 products
today. Perhaps they can comment.=A0
section 9 alternative=20 approaches, there's some consensus that rfc 3056 was never real= ly=20 deployed so the reference to 6to4 should probably be to 3068<= font face=3D"Arial" color=3D"#0000ff" size=3D"2">=A0
=A0<= /div>
OK - I can fix this.
=A0
Thanks - Fred
<= /div>

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



--00163630edcd2e751304a7fc9ee6-- From cx.cernet@gmail.com Thu Jul 14 02:24:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE34B21F86BA for ; Thu, 14 Jul 2011 02:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erHChRNFdArq for ; Thu, 14 Jul 2011 02:24:29 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 465A021F8560 for ; Thu, 14 Jul 2011 02:24:29 -0700 (PDT) Received: by pvh18 with SMTP id 18so87989pvh.31 for ; Thu, 14 Jul 2011 02:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sco6y21cVa/p0Fcdim4a5ba4RNXpQI40CIgCM2c1CGk=; b=PbXidOW91lkTOg2PR6y4nrRchbbP3tMpZWjkyO3e1imJN0DoUtBwHnNrFbUR8/AkJn GaBZiZVvHHLJtxW0q/KcM0VWyGKxbw1jv73/7Q8ozqr59pV66KMJGiHDdNmn0m+bK6I2 5M2Bq5qaUzdSoEgXQFAq8AJqPgX+/V8TRLGQ0= MIME-Version: 1.0 Received: by 10.142.65.42 with SMTP id n42mr978497wfa.144.1310635468900; Thu, 14 Jul 2011 02:24:28 -0700 (PDT) Received: by 10.142.164.14 with HTTP; Thu, 14 Jul 2011 02:24:28 -0700 (PDT) In-Reply-To: References: <4E1CEDD9.5040107@cernet.edu.cn> Date: Thu, 14 Jul 2011 17:24:28 +0800 Message-ID: From: Congxiao Bao To: Fred Baker Content-Type: multipart/alternative; boundary=001636e0b9548dc96c04a80419ba Cc: Congxiao Bao , "Wojciech Dec \(wdec\)" , v6ops@ietf.org, "Rajiv Asati \(rajiva\)" Subject: Re: [v6ops] request for presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 09:24:29 -0000 --001636e0b9548dc96c04a80419ba Content-Type: text/plain; charset=ISO-8859-1 Hi Fred, This draft, "Stateless 4Via6 Address Sharing" draft is trying to address a detailed comparison of stateless dual translation and tunneling from the operational perspective. It is not proposing any solution, neither a translation solution nor a tunneling solution. The original dIVI (and dIVI-PD) drafts for dual stateless tranlation technologies will be presented at BEHAVE group and the 4rd draft for stateless tunneling technologies will be presented in Softwire group. Best, Congxiao 2011/7/14 Fred Baker > > On Jul 12, 2011, at 8:59 PM, Congxiao Bao wrote: > > > Hi Fred, > > > > We would like to request a timeslot to present our draft in v6ops in the > coming ietf meeting. > > > > Presenter : Wojciech Dec > > Title of the draft:Stateless 4Via6 Address Sharing > > Url: > https://datatracker.ietf.org/doc/draft-dec-stateless-4v6/?include_text=1 > > > > Thank you very much! > > > > Congxiao > > Dumb question: Given that all drafts related to tunneling IPv4 over IPv6 > are being handled in softwire, why is this not a softwire draft? > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001636e0b9548dc96c04a80419ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Fred,

This draft, "Stateless 4Via6 Add= ress Sharing" draft is trying to address a detailed comparison of stat= eless dual translation and tunneling from the operational perspective. It i= s not proposing any solution, neither a translation solution nor a tunnelin= g solution.

The original dIVI (and dIVI-PD) drafts for dual stateless tranlation te= chnologies will be presented at BEHAVE group and the 4rd draft for stateles= s tunneling technologies will be presented in Softwire group.

Best,=

Congxiao

2011/7/14 Fred Baker <fred@cisco.com>

On Jul 12, 2011, at 8:59 PM, Congxiao Bao wrote:
<= br>> Hi Fred,
>
> We would like to request a timeslot to pre= sent our draft in v6ops in the coming ietf meeting.
>
> Present= er : Wojciech Dec
> Title of the draft:Stateless 4Via6 Address Sharing
> Url: https://datatracker.ietf.org/doc/draft-dec-stateles= s-4v6/?include_text=3D1
>
> Thank you very much!
>
> Congxiao

Dumb question: Given that all drafts related to tunneling IPv4 over IPv6= are being handled in softwire, why is this not a softwire draft?


_______________________________________________
v6ops mailing listv6ops@ietf.org
https://www.ietf.o= rg/mailman/listinfo/v6ops

--001636e0b9548dc96c04a80419ba-- From wdec.ietf@gmail.com Thu Jul 14 06:29:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D4021F87AF for ; Thu, 14 Jul 2011 06:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uadk0GSt3CwG for ; Thu, 14 Jul 2011 06:29:37 -0700 (PDT) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 25F3821F86EC for ; Thu, 14 Jul 2011 06:29:37 -0700 (PDT) Received: by pzd13 with SMTP id 13so361512pzd.39 for ; Thu, 14 Jul 2011 06:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NbN6gr7d3e4Tja4MbsCsYNJdR0L2VrPaRNiMCTimThc=; b=f5CoaOmgtvoF+wrAwRGYochVn6d6Rj+z2u+ZQTzUfbGXQZVzgB6szuSrv2ABcoNxqu Y/PtGmQQOwSOFi0FfRjLfkjbzr73fza9BorDjg+Wc5e6qmxvGxz1kAz68kGdBZUbDoJE D4bpfy/aNIyo78yi7SY/WKKQD73pO4Du9BlUU= MIME-Version: 1.0 Received: by 10.143.98.14 with SMTP id a14mr990708wfm.198.1310650176490; Thu, 14 Jul 2011 06:29:36 -0700 (PDT) Received: by 10.142.136.8 with HTTP; Thu, 14 Jul 2011 06:29:36 -0700 (PDT) In-Reply-To: <4E1CEDD9.5040107@cernet.edu.cn> References: <4E1CEDD9.5040107@cernet.edu.cn> Date: Thu, 14 Jul 2011 15:29:36 +0200 Message-ID: From: Wojciech Dec To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Congxiao Bao , "Wojciech Dec \(wdec\)" , "Rajiv Asati \(rajiva\)" Subject: Re: [v6ops] request for presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 13:29:37 -0000 And alongside we solicit and welcome feedback from the WG on this draft: http://tools.ietf.org/html/draft-dec-stateless-4v6 Abstract This document presents an overview of the characteristics of stateless 4V6 solutions, alongside a assessment of the issues attributes. The impact of translated or mapped tunnel transport modes is also presented in the broader context of other industry standard reference architectures and existing deployments. Thanks, Woj. 2011/7/13 Congxiao Bao : > Hi Fred, > > We would like to request a timeslot to present our draft in v6ops in the > coming ietf meeting. > > Presenter : Wojciech Dec > Title of the draft:Stateless 4Via6 Address Sharing > Url: > https://datatracker.ietf.org/doc/draft-dec-stateless-4v6/?include_text=1 > > > Thank you very much! > > > Congxiao > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From fred@cisco.com Thu Jul 14 10:54:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF9511E80BC for ; Thu, 14 Jul 2011 10:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.536 X-Spam-Level: X-Spam-Status: No, score=-104.536 tagged_above=-999 required=5 tests=[AWL=-1.937, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id risWJGb8NvXG for ; Thu, 14 Jul 2011 10:54:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6682311E80BB for ; Thu, 14 Jul 2011 10:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2608; q=dns/txt; s=iport; t=1310666069; x=1311875669; h=subject:mime-version:from:date:cc:reply-to:message-id:to: content-transfer-encoding; bh=LR0odOu/YQgMs9c8vCYgaJGMG9hJc0Cu85P/JvyRAqA=; b=ZVkYMgh4BwTLY/VdxD+WDD7kZDyuYMeDnz7YdqN0X4kHRQVkFHH+1HST OIYmvYosk05GpFKMcXRIWgNvX9zG//wYN/Vy7VajQfINESKQ3zrcyIgn9 vsrKJUGGzW1bcnKCEMF92H7T1mLUREzL8cDS8QDe/1CewFYkNH6jJbSk8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGUsH06rRDoH/2dsb2JhbABTp1d3rGqDFQ8Bmn2FW18EkmSFAItt X-IronPort-AV: E=Sophos;i="4.65,530,1304294400"; d="scan'208";a="3014547" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 14 Jul 2011 17:54:28 +0000 Received: from Freds-Computer.local (sjc-vpn4-654.cisco.com [10.21.82.142]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6EHsRDQ009990; Thu, 14 Jul 2011 17:54:27 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 14 Jul 2011 13:54:28 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 14 Jul 2011 13:54:28 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker Date: Thu, 14 Jul 2011 13:54:17 -0400 Message-Id: To: IPv6 Operations X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Preliminary agenda posted X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ron Bonica , Joel Jaeggli , Fred Baker List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 17:54:31 -0000 A first-cut agenda has been posted at http://www.ietf.org/proceedings/81/agenda/v6ops.html I need to apologize to the people behind ten drafts. We currently have = posted draft-matsushima-v6ops-transition-experience-02.txt draft-denog-v6ops-addresspartnaming-04.txt draft-fling-v6ops-hybrid-bridged-routed-00.txt draft-andrews-v6ops-6to4-router-option-02.txt draft-chown-v6ops-call-to-arms-03.txt draft-gont-v6ops-ra-guard-evasion-01.txt draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06.txt draft-yang-v6ops-space6-icp-00.txt draft-sarikaya-v6ops-prefix-delegation-07.txt draft-ietf-v6ops-6to4-to-historic-05.txt draft-gashinsky-v6nd-enhance-00.txt draft-templin-v6ops-isops-12.txt draft-gundavelli-v6ops-pmipv6-address-reservations-00.txt draft-chen-v6ops-ipv6-bearer-network-trials-00.txt draft-elkins-6man-ipv6-diagnostic-header-00.txt draft-hilliard-v6ops-ipv6-discard-prefix-00.txt draft-kuarsingh-wireline-incremental-ipv6-00.txt draft-tan-v6ops-fast6-aaa-01.txt draft-deng-v6ops-aplusp-experiment-results-01.txt draft-jjmb-v6ops-comcast-ipv6-experiences-01.txt draft-ietf-v6ops-ipv6-cpe-router-bis-01.txt draft-chen-v6ops-nat64-cpe-02.txt draft-yang-v6ops-fast6-pppoe-01.txt draft-yang-v6ops-fast6-tools-selection-01.txt draft-li-v6ops-load-balancing-requirement-01.txt draft-ietf-v6ops-happy-eyeballs-03.txt draft-keranen-ipv6day-measurements-01.txt draft-sunq-v6ops-contents-transition-01.txt draft-dec-stateless-4v6-02.txt draft-chown-v6ops-address-accountability-01.txt which is to say "30 drafts". We have 270 minutes, 150 on Tuesday and 120 = on Thursday. In the agenda, I have given slots to 20 discussions, three = of which are reports on IPv6 Day that don't have drafts behind them; = that pretty much means 13 minutes each, including switchover time. The = other thirteen drafts didn't make the cut. "Making the cut", as we discussed in IETF-80, involves traction on the = list or the chairs deciding it's important. Joel and I think the World = IPv6 Day is timely and important, and solicited talks from various = quarters. The other drafts on the agenda are drafts that have had = discussion on the list, got high marks in the survey I ran in early = June, or by some other argument seem operationally valuable. The ones = that didn't make the cut had negative traction on the list or no list = discussion at all, or is targeted to a different working group such as = opsawg. If someone thinks we have misjudged something, please comment to the = chairs. We'll finalize the agenda next week.= From joelja@bogus.com Thu Jul 14 11:07:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686FD11E80BB for ; Thu, 14 Jul 2011 11:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.005 X-Spam-Level: X-Spam-Status: No, score=-103.005 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovmgBrt5Hgi5 for ; Thu, 14 Jul 2011 11:07:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id BAF5011E80B3 for ; Thu, 14 Jul 2011 11:07:13 -0700 (PDT) Received: from [172.16.24.53] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6EI7AlW036774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jul 2011 18:07:10 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Thu, 14 Jul 2011 11:07:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <162A9C99-870F-412C-8F3E-16CE3977247F@bogus.com> References: To: Ron Bonica , Joel Jaeggli , Fred Baker X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 14 Jul 2011 18:07:10 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] Preliminary agenda posted X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 18:07:14 -0000 On Jul 14, 2011, at 10:54 AM, Fred Baker wrote: >=20 > "Making the cut", as we discussed in IETF-80, involves traction on the = list or the chairs deciding it's important. Joel and I think the World = IPv6 Day is timely and important, and solicited talks from various = quarters. The other drafts on the agenda are drafts that have had = discussion on the list, got high marks in the survey I ran in early = June, or by some other argument seem operationally valuable. The ones = that didn't make the cut had negative traction on the list or no list = discussion at all, or is targeted to a different working group such as = opsawg. When we survey sentiment again, drafts for which we do not have space in = the agenda will be represented. > If someone thinks we have misjudged something, please comment to the = chairs. > We'll finalize the agenda next week. Thanks joel From Fred.L.Templin@boeing.com Thu Jul 14 11:34:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F76521F8589 for ; Thu, 14 Jul 2011 11:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x6FTQ1PueTk for ; Thu, 14 Jul 2011 11:33:55 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3E19621F858E for ; Thu, 14 Jul 2011 11:33:54 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p6EIXp9A013063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Jul 2011 11:33:51 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p6EIXoko001321; Thu, 14 Jul 2011 11:33:50 -0700 (PDT) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p6EIXnS9001276 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 14 Jul 2011 11:33:50 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Thu, 14 Jul 2011 11:33:49 -0700 From: "Templin, Fred L" To: "John Mann (ITS)" , "v6ops@ietf.org" Date: Thu, 14 Jul 2011 11:33:48 -0700 Thread-Topic: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? Thread-Index: AcxBvQWtQWZ7hrh3T4215ads+OUiBwAjSQxw Message-ID: References: <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C6B37F4BDXCHNW01Vnwnos_" MIME-Version: 1.0 Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 18:34:00 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C6B37F4BDXCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, Thanks for this, and see below for follow-up: ________________________________ From: John Mann (ITS) [mailto:john.mann@monash.edu] Sent: Wednesday, July 13, 2011 5:29 PM To: v6ops@ietf.org Cc: Templin, Fred L Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? v6ops people, Fred and I have done round of review off-list. This is my reply to that .. On 14 July 2011 02:53, Templin, Fred L > wrote: Hi John, Thanks again for the comments, and see below for proposed resolutions: ________________________________ From: John Mann (ITS) [mailto:john.mann@monash.edu] Sent: Tuesday, July 05, 2011 11:24 PM To: Templin, Fred L Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? Fred, The per-page heading is "Routing Loop Attack". Good catch. I will change this to "ISATAP Operational Guidance". 1. Introduction s/RANGERS/RANGER/ There are actually two documents - RANGER is [RFC5720] and RANGERS is [RFC6139]. I was meaning to cite the latter. 2. Enabling IPv6 Services using ISATAP "Many existing sites within the Internet predominantly use IPv4-based services for their internal networking needs, but there is a growing requirement for enabling IPv6 services to support communications with IPv6-only correspondents." This sentence is a a re-hash of the last paragraph of section 1. Perhaps it can be removed ?? Good point, but I'd still like a lead-in sentence to that paragraph so how would it be if I simply replaced that sentence with the following: "Existing IPv4 sites within the Internet will soon need to enable IPv6 services." Fine. "Smaller sites that wish to enable IPv6 typically arrange to obtain public IPv6 prefixes from an Internet Service Provider (ISP), where the prefixes may be either purely native, the near-native prefixes offered by 6rd [RFC5969] or the transitional prefixes offered by 6to4 [RFC3056][RFC3068]. " I would split this into Smaller sites that wish to enable IPv6 can arrange to obtain public IPv6 prefixes from an Internet Service Provider (ISP), where the prefixes may be either purely native, or the near-native prefixes offered by 6rd [RFC5969]. Or use an ISP-independant method like transitional prefixes offered by 6to4 [RFC3056][RFC3068], or prefixes from a tunnel-broker [ref?]. Good point, although I think perhaps a bit more should be said about 6to4. Rephrasing slightly, see if this sounds OK: "Smaller sites that wish to enable IPv6 can arrange to obtain public IPv6 prefixes from an Internet Service Provider (ISP), where the prefixes may be either purely native or the near-native prefixes offered by 6rd [RFC5= 969]. Alternatively, the site can obtain prefixes independently of an ISP e.g.= , via a tunnel broker [RFC3053], by using one of its public IPv4 addresses to form a 6to4 prefix [RFC3056][RFC3068], etc." Please add something like Note that 6to4 is not recommended for new implementations [draft-ietf-v6= ops-6to4-to-historic or draft-moore-6to4-experimental ], and should be implemented with care [ draft-ietf-v6ops-6to4-advisory or RFC= -new ]. I would really rather not fan the flames of the recent list discussions on this subject, so would you be OK the following: "Note that experience shows that the 6to4 method has some problems in cur= rent deployments that can lead to connectivity failures [ draft-ietf-v6ops-6t= o4-advisory ]." (Also, the advisory document already cites the historic document, so there should be no need for citing it again in this document.) "Advertising ISATAP routers configure their site-facing ISATAP interfaces as advertising router interfaces " "site-facing" isn't defined. How many interfaces each router has is not de= fined. =3D> Each advertising ISATAP router configures an site-internal interface= as an ISATAP advertising router interface. "ISATAP hosts configure their site-facing ISATAP interfaces as simple host interfaces and ..." "site-facing"? how many interfaces? =3D> Each ISATAP host configures an interface as a simple ISATAP host inter= face and ... I get your point, and I think perhaps a bit more work is needed here. Any node (host or router) can have any number of ISATAP interfaces connected to any number of sites. The host may be an advertising ISATAP router on some sites, a non-advertising ISATAP router on other sites, and a simple ISATAP host on other sites. Each such "personality" of the node would be represented by a distinct ISATAP interface. With that in mind, here is a proposed rewrite of the paragraph: "The ISATAP service is based on two node types known as advertising ISATAP routers and simple ISATAP hosts. (A third node type known as non-advertising ISATAP routers is defined in [draft-templin-isupdate] but out of scope for this document.) Each node may further have multiple ISATAP interfaces (i.e., one interface for eac= h site), and may act as an advertising ISATAP router on some of those interfaces and a simple ISATAP host on others. Hence, the node type is considered on a per-interface basis. Advertising ISATAP routers configure their ISATAP interfaces as advertising router interfaces (see: [RFC4861], Section 6.2.2). ISATAP hosts configure their ISATAP interfaces as simple host interfaces and also coordinate their autoconfiguration operations with advertising ISAT= AP routers. In this sense, advertising ISATAP routers are "servers" while ISATAP hosts are "clients" in the service model." I am a little bit confused here about the possibility that a host may be co= nnected to a number of sites. Take for example a host that connects to an IPv4 network where the ISATAP service is deployed, and also VPNs into an IPv4 enterprise network where a separate ISATAP service is also deployed. The host should be able to configure a first ISATAP interface ("is0") over the locally-connected IPv4 network interface and a second ISATAP interface ("is1") over the VPN interface. That would be two different ISATAP interfaces; each with its own associated set of PRL routers, IPv6 prefixes, etc. It is up to the host as to how it would keep the two different domains separate, but multiple ISATAP host interfaces are indeed possible. For the purposes of this document, is it useful to simplify the model a lit= tle: | *IPv4 view* | *ISATAP view* | *Connectivity* | *Multi-site* | | host | ISATAP host | connected to one ISATAP subnet | No | | gateway | advertising ISATAP router | can connect to multiple ISATAP subn= ets | Possible | [ I know, I have introduced a new term "gateway" ] Are you meaning to suggest any changes to the document? 3.3. Reference Operational Scenario - Shared Prefix Model I think this could be _slightly_ improved by being a bit more explicit when= packets are encapsulated, and whether they are sent to a host/routers IPv4 or IPv6 address. I like the idea of being more explicit. In your proposed text below, however, would you mind if I omitted the "IPv6-in-IPv4" and just used the word "encapsulated". Reason being is that, since we are talking about ISATAP, IPv6-in-IPv4 is already assumed. "Assuming 'A' is closest, 'C' receives an _IPv6-in-IPv4 encapsulated_ RA from 'A' then configures a default IPv6 route with next-hop address fe80::5efe:192.0.2.1 via the ISATAP interface and processes the IPv6 prefix 2001:db8::/64 advertised in the PIO. " " 'D' next performs an _IPv6-in-IPv4 encapsulated_ anycast RS/RA exchange that is serviced by 'B', " "If the site is not partitioned internally, the router that receives the packet can use ISATAP to statelessly forward the packet directly to 'C' _using IPv6-in-IPv4 encapsulation_. Yes, IPv6-in-IPv4 should be clear in context. I came up with a slightly different fix which I hope you will find satisfactory. Rather than saying "using encapsulation" in multiple places, I added the following new paragraph to Section 2: "After the PRL is published, ISATAP clients within the site can automatic= ally perform unicast IPv6 Neighbor Discovery Router Solicitation (RS) / Route= r Advertisement (RA) exchanges with advertising ISATAP routers using IPv6-in-IPv4 encapsulation [RFC4861][RFC5214]. In the exchange, the IPv4 source address of the RS and the destination address of the RA are an IPv4 address of the client, while the IPv4 destination address of the= RS and the source address of the RA are an IPv4 address of the server found= in the PRL. Similarly, the IPv6 source address of the RS and the destinatio= n address of the RA are a link-local ISATAP address that embeds the client= 's IPv4 address, while the IPv6 destination address of the RS and the sourc= e address of the RA are a link-local ISATAP address that embeds the server= 's IPv4 address." Then, everywhere else throughout the document, I simply say "RS/RA exchange" rather than "IPv6-in-IPv4 encapsulated RS/RA exchange". Is that OK with you? =3D=3D=3D Otherwise, excellent stuff. Thanks, and I hope this work may be useful to you and others. I have installed, but not gone live with a slightly different model. I don't know if it is interesting enough to be included in the draft ... Large enterprise network, mostly IPv6 dual-stack, but not on wireless. Staff wireless --> one /64 ISATAP subnet Student wireless --> different ISATAP subnet Staff and student wireless aren't geographically separate, so I can't split= PRL by site. One pair of ISATAP gateways for staff advertise anycast 130.194.29.255/32 One pair of ISATAP gateways for students advertise anycast 130.194.29.254/3= 2 PRL contains 130.194.29.255 and 130.194.29.254 Separation managed by ACL inbound on ISATAP interface including ... permit ipv6 FE80::200:5EFE:317F:0/112 any deny ipv6 FE80::200:5EFE:0:0/96 any deny ipv6 FE80::5EFE:0:0/96 any ... i.e. permit encapsulated RS's from ISATAP-mapped 49.127/16 but not from oth= er IPv4 address ranges I like this method for logically partitioning an ISATAP link that is not physically partitioned. A similar method is covered in the third paragraph of Section 3.5, but your description augments what is already there. Please check the following to see if this looks like a worthwhile augmentation of that paragraph: "When individual prefixes are used, site administrators can configure advertising ISATAP routers to advertise different individual prefixes to different sets of clients, e.g., based on the client's IPv4 subnet prefi= x. (For example, administrators can configure each advertising ISATAP router to provide services to some sets of ISATAP clients but not others through inbound IPv6 Access Control List (ACL) entries that discard encapsulated messages with certain ISATAP source addresses based on the embedded IPv4 subnet prefix). When a shared prefix is used, the site administrator could instead configure the ISATAP routers to advertise the shared prefix to all clients." Fine, except for the last sentence. s/could/would/ ?? If a shared prefix is used, when would that shared prefix _not_ be advertis= ed to all clients. Will "s/could/would". John Thanks again for all of your great suggestions. Please let me know if this adequately addresses everything. Fred fred.l.templin@boeing.com =3D=3D=3D New I see that loop avoidance gets mentioned in sections 3.6 and 10. How about more-generic address checking? An ISATAP router SHOULD check all incoming encapsulated addresses to make s= ure that the embedded IPv6 source address is valid -- link-local or global within the range of IPv4-mapped addresses for that sub= net. An ISATAP router SHOULD check all IPv6 packets to be encapsulated to make s= ure that the IPv6 destination address is valid -- link-local or global within the range of IPv4-mapped addresses for that sub= net, or multicast. For SLAAC-assigned addresses in the shared prefix model above providing ser= vices to 192.0.2.0/24, the valid addresses would be f= e80::5efe:192.0.2.0/120 and 2001:db8::5efe:192.0.2.0/= 120 . This looks like potential new material for the tunnel-loops document, however any intentional or unintentional abuse of the embedded IPv4 address field would already be nullified by the RFC5214, Section 10 recommendation that site border rotuers implement ip-protocol-41 filtering. In other words, any packets with addresses with an IPv6 prefix specific to the local site but an embedded IPv4 address prefix specific to some other site would be dropped by a site border router (and possibly logged). However, if Global IPv4 addresses are used, the ISATAP prefix is 0200:5efe:= : rather than 0000:5efe:: see http://tools.ietf.org/html/rfc5214#section-6.= 1 That's not *exactly* what the spec says. The spec says "When the IPv4 address is known to be globally unque ...". But, no implementation can ever know for sure that the IPv4 address is globally unique without some global form of duplicate address detection. Indeed, the spec goes on to say that: "...ISATAP nodes are not required to validate the interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique". Is 192.0.2.0/24 an example "global" or "private" addre= ss? http://tools.ietf.org/html/rfc3330 doesn't say. This question impacts the examples in this Draft, and elsewhere such as http://tools.ietf.org/html/draft-ietf-v6ops-tunnel-loops-07#section-3.2.4.5 The "wisdom of crowds" is divided on this: Google search for "isatap fe80::200:5efe:C000" =3D=3D 243 hits Google search for "isatap fe80::5ef5:C000" =3D=3D 571 hits My Cisco router seems to do the local/global bit wrong [ "????" and "####" = =3D=3D address obfuscation. ] --- Interface Tunnel9 ipv6 address 2001:388:608C:????::/64 eui-64 tunnel mode ipv6ip isatap ... Tunnel9 is up, line protocol is up Global unicast address(es): 2001:388:608C:????:0:5EFE:82C2:####, subnet is 2001:388:608C:????::/64 = [EUI] --- The 82C2:#### mapped IPv4 address is 130.194.0.0/16 = which is definitely globally valid. I suspect the cisco router simply sets u/l to 0 always when it configures its ISATAP link-local address and ignores the u/l bit on receipt - which seems like a reasonable interpretation of the spec. Hindsight being 20/20, it probably would have been better had the spec said to simply set the u/l bit to 0 in all cases. Do any implementors have anything to add wrt this? Fred John On 2 July 2011 08:54, Templin, Fred L > wrote: Hi Joel, Me again. There have have been others who have also expressed concerns about DHCPv6 and other "undocumented features" on ISATAP links, so I decided to split the document into two pieces. The new piece is now called: "ISATAP Updates" and I guess might be more appropriate for some other working group. The other piece retains the original name and is strictly about operational aspects of widely-deployed implementations: http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-12.txt What should we do next - ask the wg for comments? Thanks - Fred ________________________________ From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Templin, Fred = L Sent: Wednesday, June 22, 2011 8:13 AM To: Joel Jaeggli Cc: v6ops@ietf.org Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? Hi Joel, Thanks for your comments, and see below for responses: ________________________________ From: Joel Jaeggli [mailto:joelja@bogus.com] Sent: Friday, June 17, 2011 12:50 PM To: Templin, Fred L Cc: v6ops@ietf.org Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote: Hello, Significant improvements have been made to this document (below) based on comments received and new observations. IMHO, this is an important document for enabling transition to IPv6 within IPv4 sites; hence, I would like to call for working group adoption at this time. Thanks - Fred fred.l.templin@boeing.com Replying to this message as a way to maintain the threading. these notes ar= e relative to the current version of the draft which I reviewed last week: http://tools.ietf.org/html/draft-templin-v6ops-isops-10 So I tried for a while to separate the operational advice that could be app= lied to my 2005 era knowledge of isatap and there's quite a few things tha= t jive with that (tunnel loops for example). OK. In other cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what im= plementations are capable of doing that? Are we recommending that they do i= t? do they already? I can't speak for current implementations, but the DHCPv6 approach is based on the fact that address and prefix assignment on IPv6 interfaces are seperable functions. IPv6 prefixes assigned to ISATAP interfaces can only be used for autoconfiguration of ISATAP addresses and not ordinary IPv6 addresses. However, an ordinary IPv6 address can be assigned to an ISATAP interface the same as for any other IPv6 interface as long as it is not covered by a prefix assigned to the interface. Regarding aero (section 4.6) that looks pretty much like new work or an ext= ension to the specification. AERO is a new but backwards-compatible method of doing redirection of an on-link neighbor to another on-link neighbor. However, ISATAP interfaces can still use standards ICMPv6 Redirect messages the same as for any IPv6 interface. Advertising ISATAP routers should only send ICMPv6 redirects when they are certain that the redirected ISATAP node can tunnel packets directly to the target of the redirect, however. Perhaps a few more words saying explicitly that standards ICMPv6 redirects are still supported would help? Are there participants with extant isatap deployements or host implementati= ons or knowledge fresher than mine that would care to comment on this draft= . There are certainly vendors who are shipping ISATAP in their products today. Perhaps they can comment. section 9 alternative approaches, there's some consensus that rfc 3056 was = never really deployed so the reference to 6to4 should probably be to 3068 OK - I can fix this. Thanks - Fred fred.l.templin@boeing.com _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_E1829B60731D1740BB7A0626B4FAF0A65C6B37F4BDXCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi John,
 
Thanks for this, and see below for=20 follow-up:

From: John Mann (ITS)=20 [mailto:john.mann@monash.edu]
Sent: Wednesday, July 13, 2011 5= :29=20 PM
To: v6ops@ietf.org
Cc: Templin, Fred=20 L
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg= =20 item?

v6ops people,

Fred and I have done round of review off-list.
This is my reply to that ..

On 14 July 2011 02:53, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
Hi=20 John,
 
Thanks ag= ain for the=20 comments, and see below for proposed
resolutions:

From: John Mann (ITS) [mailto:john.mann@monash= .edu]=20
Sent: Tuesday, July 05, 2011 11:24 PM
To:= =20 Templin, Fred L

Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v= 6ops=20 wg item?

Fred,=20

The per-page heading is "Routing Loop Attack". 
Good catch. I will cha= nge this to=20 "ISATAP Operational Guidance". 

1.  Introduction

s/RANGERS/RANGER/ 
 
There are actually two= documents=20 - RANGER is [RFC5720] and RANGERS
is [RFC6139]. I w= as meaning=20 to cite the latter. 

2.  Enabling IPv6 Services using ISATAP

   "Many existing sites within the Internet predominan= tly=20 use IPv4-based
   services for their internal networking needs, but t= here=20 is a growing
   requirement for enabling IPv6 services to support=20 communications with
   IPv6-only correspondents."

This sentence is a a re-hash of the last paragraph of section=20 1.
Perhaps it can be removed ?? 
 
Good point, but I'd st= ill=20 like  a lead-in sentence to that paragraph so
how would it=20 be if I simply replaced= that=20 sentence with the following:
 
  "Existing IPv4 = sites=20 within the Internet will soon need to enable
  =20 IPv6 services."

Fine.
 

   "Smaller sites that wish to enable IPv6
   typically arrange to obtain public IPv6 prefixes fr= om an=20 Internet
   Service Provider (ISP), where the prefixes may be e= ither=20 purely
   native, the near-native prefixes offered by 6rd=20 [RFC5969] or the
   transitional prefixes offered by 6to4=20 [RFC3056][RFC3068]. "

I would split this into
   Smaller sites that wish to enable IPv6
   can arrange to obtain public IPv6 prefixes from an= =20 Internet
   Service Provider (ISP), where the prefixes may be e= ither=20 purely
   native, or the near-native prefixes offered by 6rd= =20 [RFC5969].
   Or use an ISP-independant method like
   transitional prefixes offered by 6to4=20 [RFC3056][RFC3068],
   or prefixes from a tunnel-broker [ref?]. 
 
Good point, although I= think=20 perhaps a bit more should be said about
6to4. Rephrasing slightly, see if this sounds=20 OK:
 
  "Smaller sites = that wish=20 to enable IPv6 can arrange to obtain public IPv6
   pref= ixes from=20 an Internet Service Provider (ISP), where the prefixes=20 may
   be either= purely=20 native or the near-native prefixes offered by 6rd=20 [RFC5969].
   Alternati= vely, the=20 site can obtain prefixes independently of an ISP e.g., via
   a tunnel&= nbsp;broker=20 [RFC3053], by using one of its public IPv4 addresses to
   form a=20 6to4 prefix [RFC3056][RFC3068], etc."  

Please add something like
   Note that 6to4 is not recommended for new implementatio= ns=20 [draft-ietf-v6ops-6to4-to-historic or draft-moore-6to4-experimental= =20 ],
and should be implemented with care [ draft-ietf-v6ops-6to4-adv= isory=20 or RFC-new ]. 
 
I would really rather not fan the flames of the recent list=20 discussions
on this subject, so would you be OK the=20 following:
 
  "Note that experience shows that the 6to4 method has some p= roblems=20 in current
   deployments that can lead to connectivity failures [= =20 draft-ietf-v6ops-6to4-advisory ]."
 
(Also, the advisory document already cites the historic document, = so=20 there
should be no need for citing it again in this=20 document.)


   "Advertising ISATAP
   routers configure their site-facing ISATAP interfac= es as=20 advertising
   router interfaces "

"site-facing" isn't defined.  How many interfaces each rout= er=20 has is not defined.

 =3D>  Each advertising ISATAP router configures an= =20 site-internal interface as an ISATAP advertising router interface.

   "ISATAP hosts
   configure their site-facing ISATAP interfaces = as=20 simple host
   interfaces and ..."

"site-facing"?  how many interfaces?

=3D> Each ISATAP host configures an interface as a simple ISA= TAP=20 host interface and ... 
 
I get your point, and = I think=20 perhaps a bit more work is needed here.
Any node (host or rout= er) can=20 have any number of ISATAP interfaces
connected to any numbe= r of sites.=20 The host may be an advertising
ISATAP router on some = sites, a=20 non-advertising ISATAP router on
other sites, and a sim= ple ISATAP=20 host on other sites. Each such
"personality" of the n= ode would=20 be represented by a distinct ISATAP
interface. With that i= n mind,=20 here is a proposed rewrite of the paragraph:
 
  "The ISATAP ser= vice is=20 based on two node types known as
   adv= ertising=20 ISATAP routers and simple ISATAP hosts. (A third=20 node
   typ= e known as=20 non-advertising ISATAP routers is defined=20 in
  =20 [draft-templin-isupdate] but out of scope for this documen= t.)=20 Each node
   may= =20 further have multiple ISATAP interfaces (i.e.= , one=20 interface for each
  =20 site), and may act as an advertising ISATAP r= outer=20 on some of those
  =20 interfaces and a simple ISATAP host on=20 others. Hence, the node type
   is = considered=20 on a per-interface basis.
 
   Advertisi= ng ISATAP=20 routers configure their ISATAP interfaces as
   advertisi= ng router=20 interfaces (see: [RFC4861], Section 6.2.2). ISATAP
   hosts con= figure=20 their ISATAP interfaces as simple host interfaces and
   also coor= dinate=20 their autoconfiguration operations with advertising=20 ISATAP
   routers. = In this=20 sense, advertising ISATAP routers are "servers" while
   ISA= TAP hosts=20 are "clients" in the service=20 model."

I am a little bit confused here about the possib= ility=20 that a host may be connected to a number of sites. 
Take for example a host that connects to an IPv4 n= etwork=20 where
the ISATAP service is deployed, and also VPNs into= an=20 IPv4
enterprise network where a separate ISAT= AP=20 service is also deployed.
The host should be able to configure a first ISATA= P=20 interface
("is0") over the locally-connected IPv4 network in= terface=20 and a
second ISATAP interface ("is1") over the VPN inter= face.=20 That would
be two different ISATAP interfaces; each= =20 with its own associated set
of PRL routers, IPv6 prefixes, etc. It is up to th= e host as=20 to how it
would keep the two different domains separate, but= multiple=20 ISATAP
host interfaces are indeed possible.=
For the purposes of this document, is it useful = to=20 simplify the model a little:

| *IPv4 view* | *ISATAP view* | *Connectivity* |= =20 *Multi-site* |
| host | ISATAP host | connected to one ISATAP s= ubnet |=20 No |
| gateway | advertising ISATAP router | can conn= ect to=20 multiple ISATAP subnets | Possible |

[ I know, I have introduced a new term "gateway"= ] 
 
Are you meaning to suggest any changes to the=20 document? 
3.3.  Reference Operational Scenario - Shared Prefix=20 Model

I think this could be _slightly_ improved by being a bit more=20 explicit when packets are encapsulated,
and whether they are sent to a host/routers IPv4 or IPv6=20 address. 
 
I like the idea of bei= ng more=20 explicit. In your proposed text below,
however, would you min= d if I=20 omitted the "IPv6-in-IPv4" and just
used the word "encapsu= lated".=20 Reason being is that, since we
are talking about ISAT= AP,=20 IPv6-in-IPv4 is already assumed.

"Assuming 'A' is closest, 'C' receives an
    _IPv6-in-IPv4 encapsulated_
   RA from 'A' then configures a default
   IPv6 route with next-hop address fe80::5efe:192.0.2= .1=20 via the ISATAP
   interface and processes the IPv6 prefix 2001:db8::/= 64=20 advertised in
   the PIO. "

" 'D' next performs an
    _IPv6-in-IPv4 encapsulated_
   anycast RS/RA exchange that is serviced by 'B', "

"If the site is not partitioned internally, the
   router that receives the packet can use ISATAP to=20 statelessly forward
   the packet directly to 'C' _using IPv6-in-IPv4= =20 encapsulation_.

Yes, IPv6-in-IPv4 should be clear in context. 
 
I came up with a slightly different fix which I ho= pe you=20 will find
satisfactory. Rather than saying "using encapsulat= ion" in=20 multiple
places, I added the following new paragraph t= o Section=20 2:
 
  "After the PRL is published, ISATAP clients= within=20 the site can automatically
   perform unicast IPv6 Neighbor Di= scovery=20 Router Solicitation (RS) / Router
   Advertisement (RA) exchanges wit= h=20 advertising ISATAP routers using
   IPv6-in-IPv4 encapsulation [RFC4861][= RFC5214].=20 In the exchange, the
   IPv4 source address of the RS and the= =20 destination address of the RA are
   an IPv4 address of the client, while = the IPv4=20 destination address of the RS
   and the source address of the RA are = an IPv4=20 address of the server found in
   the PRL. Similarly, the IPv6 source a= ddress of=20 the RS and the destination
   address of the RA are a link-local IS= ATAP=20 address that embeds the client's
   IPv4 address, while the IPv6 destinat= ion=20 address of the RS and the source
   address of the RA are a link-local IS= ATAP=20 address that embeds the server's
   IPv4 address."
 
Then,=20 everywhere else throughout the document, I simply say "RS/RA<= /DIV>
exchange" rather than "IPv6-in-IPv4 encapsulated RS/RA exchange".= =20 Is
that=20 OK with you?
=3D=3D=3D
Otherwise, excellent stuff. 
 
Thanks, and I hope thi= s work may=20 be useful to you and others. 

I have installed, but not gone live with a slightly different=20 model.
I don't know if it is interesting enough to be included in the d= raft=20 ...

Large enterprise network, mostly IPv6 dual-stack, but not on=20 wireless.
Staff wireless --> one /64 ISATAP subnet
Student wireless --> different ISATAP subnet
Staff and student wireless aren't geographically separate, so I = can't=20 split PRL by site.
One pair of ISATAP gateways for staff advertise anycast 130.194.29.255/32
One pair of ISATAP gateways for students advertise anycast 130.194.29.254/32
PRL contains 130.194.29.255 and 130.194.29.254

Separation managed by ACL inbound on ISATAP interface including<= /DIV>
    ...   
    permit ipv6 FE80::200:5EFE:317F:0/112 any
    deny ipv6 FE80::200:5EFE:0:0/96 any
    deny ipv6 FE80::5EFE:0:0/96 any
    ...
i.e. permit encapsulated RS's from ISATAP-mapped 49.127/16 but n= ot=20 from other IPv4 address ranges 
 
I like this method=20 for logically partitioning an ISATAP link that is=20 not
physically = ;partitioned. A similar method is covered in the=20 third
paragraph of Section 3= .5, but=20 your description augments what is
already there. Please = check the=20 following to see if this looks like
a worthwhile augmentat= ion of that=20 paragraph:
 
  "When individua= l prefixes=20 are used, site administrators can configure
   advertisi= ng ISATAP=20 routers to advertise different individual prefixes to
   different= sets of=20 clients, e.g., based on the client's IPv4 subnet prefix.
   (For exam= ple,=20 administrators can configure each advertising ISATAP
   rout= er=20 to p= rovide=20 services to some= sets of=20 ISATAP clients but not
   others=20 through=20 inbound IPv6 Access Con= trol List=20 (ACL) entries that
   disc= ard=20 encapsulated messages=20 with certain ISATAP source addresses
   based on= =20 the embedded IPv4 subne= t=20 prefix). When a shared= =20 prefix is=
   used, the= site=20 administrator could instead configure the ISATAP routers
   to advert= ise the=20 shared prefix to all clients."

Fine, except for the last sentence.
s/could/would/ ??
If a shared prefix is used, when would that shar= ed=20 prefix _not_ be advertised to all clients. 
 
Will "s/could/would".

    John 
 
Thanks again for all o= f your=20 great suggestions. Please let me know
if this adequately add= resses=20 everything.
 
Fred
fred.l.templin@boeing.com 
=


=3D=3D=3D New

I see that loop avoidance gets mentioned in sections 3.6 and 10.
How about more-generic address checking?

An ISATAP router SHOULD check all incoming encapsulated addresses to= make=20 sure that the embedded IPv6 source address is valid --
link-local or= =20 global within the range of IPv4-mapped addresses for that subnet.
An ISATAP router SHOULD check all IPv6 packets t= o be=20 encapsulated to make sure that the IPv6 destination address is valid=20 -- 
link-local or global within the range of IPv4-ma= pped=20 addresses for that subnet, or multicast.
For SLAAC-assigned addresses in the shared prefi= x model=20 above providing services to 192.0.2.0/24<= /A>,=20 the valid addresses would be  fe80::5efe:192.0.2.0/120 and 2001:db8::5efe:192.0.2.0/120 . 
 
This looks like potential new material for the tun= nel-loops=20 document,
however any intentional or unintentional= abuse of=20 the embedded IPv4
address field would already be nullified by the RF= C5214,=20 Section 10
recommendation that site border rotuers implement= =20 ip-protocol-41
filtering. In other words, any packets with addres= ses with=20 an IPv6 prefix
specific to the = local site=20 but an embedded IPv4 address prefix specific
to = some other site= would be=20 dropped by a site border router (and
possibly logged).
However, if Global IPv4 addresses are used, the = ISATAP=20 prefix is 0200:5efe:: rather than 0000:5efe:: see http://tools.ietf= .org/html/rfc5214#section-6.1 
 
That's not *exactly* what the spec says. The=20 spec says "When the IPv4
address is known to be globally unque ...". But, n= o=20 implementation can
ever know for sure that the IPv4 address is global= ly unique=20 without some
global form of duplicate address detection. Indeed= , the=20 spec goes on to
say that: "...ISATAP nodes are not required to val= idate the=20 interface
identifiers created with modified EUI-64 tokens wi= th the=20 "u" bit set to
universal are unique". 
Is 192.0.2.0/24<= /A> an=20 example "global" or "private" address? http://tools.ietf.org/html/rf= c3330=20 doesn't say.

This question impacts the examples in this Draft= , and=20 elsewhere such as
http://tools.ietf.org/html/draft-ietf-v6ops-tunnel-loops-07#sec= tion-3.2.4.5
The "wisdom of crowds" is divided on this:
  Google search for "isatap fe80::200:5efe:= C000"=20 =3D=3D 243 hits
  Google search for "isatap fe80::5ef5:C000= " =3D=3D=20 571 hits

My Cisco router seems to do the local/global bit= wrong=20 [ "????" and "####" =3D=3D address obfuscation. ]
---
Interface Tunnel9
 ipv6 address 2001:388:608C:????::/64 eui-64
 tunnel mode ipv6ip isatap
 ...

Tunnel9 is up, line protocol is up
Global unicast address(es):
    2001:388:608C:????:0:5EFE:82C2:####, subnet is=20 2001:388:608C:????::/64 [EUI]
---
The 82C2:#### mapped IPv4 address is 130.194.0.0/16 which is definitely glo= bally=20 valid. 
I suspect the cisco router simply sets u/l to 0 al= ways when=20 it
configures its ISATAP link-local address and ignor= es=20 the u/l bit
on receipt - which seems like a reasonable interpr= etation=20 of the
spec. Hindsight being 20/20, it probably wo= uld=20 have been better
had the spec= said to=20 simply set the u/l bit to 0 in all cases.

Do any=20 implementors have anything to add wrt this?
 
= Fred

    John
 

On 2 July 2011 08:54, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
Hi=20 Joel,
 
Me ag= ain. There=20 have have been others who have also expressed
conce= rns about=20 DHCPv6 and other "undocumented features" on
ISATA= P links, so I=20 decided to split the document into two pieces.
 
The new=20 piece is now called: "ISATAP Updates" and I guess=20 might
be more=20 appropriate for some other working group. The=20 other piece
retains the original name and is strictly about operationa= l=20
aspects
of wi= dely-deployed=20 implementations:
 
http://www.ietf.org/internet-drafts/draft-templin-v= 6ops-isops-12.txt 
What= =20 should we do next -= ask the=20 wg for comments?
 
Thank= s -=20 Fred

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= emplin,=20 Fred L
Sent: Wednesday, June 22, 2011 8:13 AM
To:= =20 Joel Jaeggli
Cc: v6ops@ietf.org
Subject: Re: [v6ops]= =20 'draft-templin-v6ops-isops' as v6ops wg=20 item?

Hi= =20 Joel,
 
Tha= nks for your=20 comments, and see below for responses:

From: Joel Jaeggli [mailto:= joelja@bogus.c= om]=20
Sent: Friday, June 17, 2011 12:50 PM
To:=20 Templin, Fred L
Cc: v6ops@ietf.org
Subject: Re: [v6op= s]=20 'draft-templin-v6ops-isops' as v6ops wg item?

On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote:

Hello,

Significant improvements have been made to= this=20 document
(below) based on comments received and new=20 observations.
IMHO, this is an important document for enab= ling=20 transition
to IPv6 within IPv4 sites; hence, I would like = to=20 call for
working group adoption at this time.

Thank= s -=20 Fred
fred.l.templin@boeing.com


Replying=20 to this message as a way to maintain the threading. these notes= are=20 relative to the current version of the draft which I reviewed l= ast=20 week:

http://tools.ietf.org/html/draft-templin-v6ops-= isops-10

So I tried for a wh= ile to=20 separate the operational advice that could be applied to my 200= 5 era=20 knowledge of isatap and there's  quite a few things that j= ive=20 with that (tunnel loops for example). 
OK.  
In other cases such= isatap=20 dhcpv6 (4.5) I'm a bit-off in the weeds, what implementations a= re=20 capable of doing that? Are we recommending that they do it? do = they=20 already? 
I can't speak for current implementati= ons, but=20 the DHCPv6 approach is
based on the fact that address and prefix a= ssignment=20 on IPv6 interfaces
are seperable functions. IPv6 prefixes assi= gned to=20 ISATAP interfaces can
only be used for autoconfiguration of ISATA= P=20 addresses and not=20 ordinary
IPv6 addresses. However, an ordinary IPv6 a= ddress=20 can be=20 assigned to
an ISATAP interface the same as for any oth= er IPv6=20 interface as long as
it is not covered by a prefix assigned to t= he=20 interface.
Regarding aero (sec= tion=20 4.6) that looks pretty much like new work or an extension to th= e=20 specification. 
AERO is a new but backwards-compatible meth= od of=20 doing redirection
of an on-link neighbor to another on-link n= eighbor.=20 However, ISATAP
interfaces can still use standards ICMPv6 R= edirect=20 messages the same
as for any IPv6 interface. Advertising= ISATAP=20 routers should only send
ICMPv6 redirects when they are certain that= the=20 redirected ISATAP node
can tunnel packets directly to the tar= get of=20 the redirect, however. Perhaps
a few more words saying explicitly that sta= ndards=20 ICMPv6 redirects are
still supported would=20 help? 
Are there participa= nts=20 with extant isatap deployements or host implementations or know= ledge=20 fresher than mine that would care to comment on this=20 draft. 
 
There are certainly vendors who are shippin= g ISATAP=20 in their products
today. Perhaps they can=20 comment. 
section 9 alternati= ve=20 approaches, there's some consensus that rfc 3056 was never real= ly=20 deployed so the reference to 6to4 should probably be to=20 3068 
 
OK - I can fix this.
 
Thanks - Fred

_______________________________________= ________
v6ops=20 mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
=


--_000_E1829B60731D1740BB7A0626B4FAF0A65C6B37F4BDXCHNW01Vnwnos_-- From dougb@dougbarton.us Thu Jul 14 20:12:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4536F21F8520 for ; Thu, 14 Jul 2011 20:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc-ZvTXlcFps for ; Thu, 14 Jul 2011 20:12:08 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4D86621F8515 for ; Thu, 14 Jul 2011 20:12:08 -0700 (PDT) Received: (qmail 21532 invoked by uid 399); 15 Jul 2011 03:12:02 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 15 Jul 2011 03:12:02 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E1FAFFF.7050506@dougbarton.us> Date: Thu, 14 Jul 2011 20:11:59 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> In-Reply-To: X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 03:12:14 -0000 On 07/09/2011 02:03, Roger Jrgensen wrote: > I suggest we use ::f I like the idea of using an alpha, but how about ::d (for discard)? > and we use a /32 from the very end of our current > 2000::/3 range. That make both stand very out from all of our current > addresses. I agree that 3fff:ffff::/32 is a good idea for this purpose. 3ff* is more or less useless for general purposes anyway given the historical Teredo usage. I don't like the idea of using a prefix from a block outside 2000::/3, since we have been operating under the assumption that if we screw something up in this /3 that we can start over in one of the others. I'd hate to cripple that premise. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From ek@google.com Thu Jul 14 23:41:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD08C9E800F for ; Thu, 14 Jul 2011 23:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.917 X-Spam-Level: X-Spam-Status: No, score=-105.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvPa24u5AmIV for ; Thu, 14 Jul 2011 23:41:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 827E39E800A for ; Thu, 14 Jul 2011 23:41:34 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p6F6fW26003476 for ; Thu, 14 Jul 2011 23:41:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310712093; bh=6NmHH3NJ+LV060kju5UocHQZN98=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Atlf4vDo6YrDvH0oaC2SHPG77a4DBg6nLHErFzkBJl7QV7XuQY6d1rHDjFbSd9mhq ZnxqT/wUxgmcIgTH55foA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=NsHUrE1r4Vj05DfwoZ6nRbjuuhJlKRHBECEyike6XGHc/S95uH9oeh4gkLRACFFkW AjfkdefPpbgTiJS/w/rUQ== Received: from pvh18 (pvh18.prod.google.com [10.241.210.210]) by kpbe19.cbf.corp.google.com with ESMTP id p6F6f9N3008622 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 14 Jul 2011 23:41:31 -0700 Received: by pvh18 with SMTP id 18so1260193pvh.31 for ; Thu, 14 Jul 2011 23:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pV4Wn/NvzFGr5kPxZxJA7O/go6eHQgXRmjleE+FabLo=; b=uRFfOEMNW9pxhxYmcK7tXBxVguVst74SOIsdx1rIbxpCfKx+6IR/mOYSAtJcolDXqF 8zl4M8cNVceKsX6yf/LA== MIME-Version: 1.0 Received: by 10.142.6.1 with SMTP id 1mr1403047wff.267.1310712091059; Thu, 14 Jul 2011 23:41:31 -0700 (PDT) Received: by 10.142.179.17 with HTTP; Thu, 14 Jul 2011 23:41:30 -0700 (PDT) In-Reply-To: <4E1FAFFF.7050506@dougbarton.us> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> <4E1FAFFF.7050506@dougbarton.us> Date: Fri, 15 Jul 2011 15:41:30 +0900 Message-ID: From: Erik Kline To: Doug Barton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 06:41:35 -0000 On 15 July 2011 12:11, Doug Barton wrote: > On 07/09/2011 02:03, Roger J=C3=B8rgensen wrote: >> I suggest we use ::f > > I like the idea of using an alpha, but how about ::d (for discard)? > >> and we use a /32 from the very end of our current >> 2000::/3 range. That make both stand very out from all of our current >> addresses. > > I agree that 3fff:ffff::/32 is a good idea for this purpose. 3ff* is > more or less useless for general purposes anyway given the historical > Teredo usage. > > I don't like the idea of using a prefix from a block outside 2000::/3, > since we have been operating under the assumption that if we screw > something up in this /3 that we can start over in one of the others. I'd > hate to cripple that premise. What about something from up near the ULA space? From rogerj@gmail.com Fri Jul 15 01:46:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3781E21F8794 for ; Fri, 15 Jul 2011 01:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIaiqMtWQwnO for ; Fri, 15 Jul 2011 01:46:20 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC5AC21F86BB for ; Fri, 15 Jul 2011 01:46:19 -0700 (PDT) Received: by wyj26 with SMTP id 26so754844wyj.31 for ; Fri, 15 Jul 2011 01:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wi8o1tzSuHFQNqzoJrjpQtvvdQgIpc8m0rCZQtitNTA=; b=gyjac6LLx8Uy8SagP23xZU3piuxh/FBx5Awi2Ncf/JzrNKFAX/HpN7Y33pslhBT4o9 GoPzOigq9d40fSdmoPsFYJCxFrWaV9f2+Z2gzIhSNFDKhnraDEY304v96IT+GN6zms0o ZAAcysB9oLq+tW5oN09V5JqUNBmDtEXGZlzvA= MIME-Version: 1.0 Received: by 10.227.24.146 with SMTP id v18mr2864566wbb.84.1310719578685; Fri, 15 Jul 2011 01:46:18 -0700 (PDT) Received: by 10.227.142.137 with HTTP; Fri, 15 Jul 2011 01:46:18 -0700 (PDT) In-Reply-To: References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> <4E1FAFFF.7050506@dougbarton.us> Date: Fri, 15 Jul 2011 10:46:18 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Erik Kline , Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 08:46:24 -0000 On Fri, Jul 15, 2011 at 8:41 AM, Erik Kline wrote: > On 15 July 2011 12:11, Doug Barton wrote: >> On 07/09/2011 02:03, Roger J=F8rgensen wrote: >>> I suggest we use ::f >> >> I like the idea of using an alpha, but how about ::d (for discard)? >> >>> and we use a /32 from the very end of our current >>> 2000::/3 range. That make both stand very out from all of our current >>> addresses. >> >> I agree that 3fff:ffff::/32 is a good idea for this purpose. 3ff* is >> more or less useless for general purposes anyway given the historical >> Teredo usage. >> >> I don't like the idea of using a prefix from a block outside 2000::/3, >> since we have been operating under the assumption that if we screw >> something up in this /3 that we can start over in one of the others. I'd >> hate to cripple that premise. > > What about something from up near the ULA space? as long as it's not from the un-used IPv6 space (outside currently used space) anything is fine really. And 3fff:ffff:: might be a good choice, combined with ::d for discard :) --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From moore@network-heretics.com Fri Jul 15 06:01:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C23721F8572 for ; Fri, 15 Jul 2011 06:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwOj6cnJ-VSW for ; Fri, 15 Jul 2011 06:01:50 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 21CC621F856D for ; Fri, 15 Jul 2011 06:01:40 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id D05A8207EC; Fri, 15 Jul 2011 09:01:38 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 15 Jul 2011 09:01:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=pWTbAowtxyzhNS0lgsrUk51UmSw=; b=jD/rQY/IVuIkG08wWoXUXwVU62tYDU3tJURcZzA6jLVUbVebAR6Zz56bNjAzfik9tJzZ8AP2/NGeVJBzr3IJcPHWQiOyP5iYpuUd5fFXugzWKeo+j1hwBNq6SdnqFug8gOgTrh6Hyq+P6scew2ig90uJCdxBL+GcC0sAyLKdQ0A= X-Sasl-enc: xxm41VsVozynOdt3FhgvcgNj+UFqs5MhovzH7tHVfY+X 1310734898 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id C3D1540214A; Fri, 15 Jul 2011 09:01:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: Date: Fri, 15 Jul 2011 09:01:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <761B5F52-A3E2-4444-AA9B-02F28A983F8B@network-heretics.com> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> <4E1FAFFF.7050506@dougbarton.us> To: =?iso-8859-1?Q?Roger_J=F8rgensen?= X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 13:01:54 -0000 On Jul 15, 2011, at 4:46 AM, Roger J=F8rgensen wrote: > On Fri, Jul 15, 2011 at 8:41 AM, Erik Kline wrote: >> On 15 July 2011 12:11, Doug Barton wrote: >>> On 07/09/2011 02:03, Roger J=F8rgensen wrote: >>>> I suggest we use ::f >>>=20 >>> I like the idea of using an alpha, but how about ::d (for discard)? >>>=20 >>>> and we use a /32 from the very end of our current >>>> 2000::/3 range. That make both stand very out from all of our = current >>>> addresses. >>>=20 >>> I agree that 3fff:ffff::/32 is a good idea for this purpose. 3ff* is >>> more or less useless for general purposes anyway given the = historical >>> Teredo usage. >>>=20 >>> I don't like the idea of using a prefix from a block outside = 2000::/3, >>> since we have been operating under the assumption that if we screw >>> something up in this /3 that we can start over in one of the others. = I'd >>> hate to cripple that premise. >>=20 >> What about something from up near the ULA space? >=20 > as long as it's not from the un-used IPv6 space (outside currently > used space) anything is fine really. > And 3fff:ffff:: might be a good choice, combined with ::d for discard = :) There's always {prefix}::dead:beef Keith From rja.lists@gmail.com Fri Jul 15 06:31:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671F821F864F; Fri, 15 Jul 2011 06:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lAqWR184T62; Fri, 15 Jul 2011 06:31:15 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9A92C21F85C0; Fri, 15 Jul 2011 06:31:15 -0700 (PDT) Received: by qyk29 with SMTP id 29so892891qyk.10 for ; Fri, 15 Jul 2011 06:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=nqry6kXWiIjCHSL/FBU3elfHlJXGUXZnBB/aEBA1xBg=; b=FNbckt44itmTL5Q9OYVMJUfG4f43n4m8I7vd+PuyCHth6aj38stX5Fp8GCp/WHhh+j XUIr6MpWxOX/X+9bSnDDDhUzcFPhGiTV7n4K7GLRwTHBYyxgLNZL5zwVn7DQmeTjA827 Emsg3hBMhraJuq+Hr0ILvAQbkS26ln2/Azgxg= Received: by 10.224.208.196 with SMTP id gd4mr3207142qab.101.1310736674884; Fri, 15 Jul 2011 06:31:14 -0700 (PDT) Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id p4sm886052qct.24.2011.07.15.06.31.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jul 2011 06:31:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: RJ Atkinson In-Reply-To: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> Date: Fri, 15 Jul 2011 09:31:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> To: ipv6@ietf.org, v6ops@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 13:31:16 -0000 On 14 Jul 2011, at 23:00 , Joel Jaeggli wrote: > On Jul 13, 2011, at 9:51 AM, RJ Atkinson wrote: >=20 >> On Weds 13 July 2011 at 11:54:08 -0400, Joel Halpern wrote: >>> There appear to be several different cases, which can be addressed=20= >>> by different reasonable mechanisms (not firewalls, and not = lengthening >>> the subnet prefix.) >>>=20 >>> For ISPs, I would assume the primary concern is routers connecting=20= >>> to subnets used to provide services. A non-dynamic approach to ND >>> can address that. >>>=20 >>> For ISPs providing bridged residential services, the ISP normally=20 >>> operates on the basis that it gets registration information=20 >>> from all the devices in the home. Thus, it does not need >>> to generate ND solicitations. >>=20 >> Agreed. >>=20 >> I do think it would be useful to have an informational document >> that describes the issue, describes the several cases, and outlines=20= >> some reasonable mechanisms (possibly separate mechanisms for each = case), >> both for the benefit of network operations folks and also for >> the benefit of equipment suppliers. >=20 > we discussed some possible (but certainly incomplete) mitigations in: >=20 > http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00 >=20 > but we also proposed changes to v6nd so that's why we brought it to = 6man >=20 >> Perhaps I am confused, but such a document sounds more like an IPv6 = Ops WG=20 >> item than an IPv6 WG item. So I'm wondering whether this thread = belongs=20 >> over there rather than here. >=20 > possibly, probably it straddles both groups. (First, a broad apology for cross-posting this note, which is in a thread that originated on the IPv6 WG mailing list. I encourage authors of follow-up notes to consider whether their follow-up=20 might belong only on 1 of these 2 lists. WG Chair guidance=20 about proper place for follow-up discussion would also be welcome. :-) I apologise for being unclear. The document I was trying to propose in the quoted text above was NOT about protocol changes, but instead would focus on extant mitigations -- so the document I was proposing would more obviously seem to fit in IPv6 Ops WG. To some extent, I would prefer an approach where IPv6 Ops would work on that informational document (threats/concerns, operational use cases, existing mitigations that could be deployed) first. Then, if there were use cases not adequately covered by the material in that (proposed) IPv6 Ops WG document, the IPv6 WG could use that IPv6 Ops WG document to examine potential protocol specification changes on a much more=20 informed basis. I am concerned that the current document is inadvertently=20 "putting the cart in front of the horse" by going straight=20 to the IPv6 WG, without starting with an informational=20 "issues and existing-mitigations" type document over in the=20 IPv6 Ops WG. Operator input on this topic would be strongly=20 beneficial since this is fundamentally an operations issue. I'm also concerned that most of the operational folks are active=20 in the IPv6 Ops WG , while only some of those folks are active=20 in IPv6 WG. So it would seem better to start working these concerns over there and later, after the IPv6 Ops WG has reached some conclusions about the issues/existing mitigations, possibly bring that output to the IPv6 WG to drive discussion of potential protocol specification changes in a more informed way than we seem to be achieving just now. Perhaps I am=20 more nearly an outlier in my concern that we not start with protocol modification discussions and instead start with a separate document covering the concerns/issues, use cases, and existing/known mitigations (possibly organised by use case). Yours, Ran Atkinson From joelja@bogus.com Fri Jul 15 09:41:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E123721F8B4C; Fri, 15 Jul 2011 09:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uouSgDY02OTc; Fri, 15 Jul 2011 09:41:03 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AE4F821F8B4B; Fri, 15 Jul 2011 09:40:59 -0700 (PDT) Received: from [10.179.81.29] (254.sub-166-250-32.myvzw.com [166.250.32.254]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6FGer8w066061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2011 16:40:55 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Fri, 15 Jul 2011 09:40:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: John C Klensin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 15 Jul 2011 16:40:58 +0000 (UTC) Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 16:41:04 -0000 So the rational for the advice document not being combined with the = standards action in it is that the later has some polarizing impact, the = advice document does not. the advice document is through and done, = historic is not. On Jul 15, 2011, at 8:55 AM, John C Klensin wrote: > Hi. >=20 > I've been thinking about this and having a few off-list > conversations and want to make a suggestion that draws together > a few others. Since many people don't like my long notes with > the conclusion at the end, this one is suggestion-first. If the > suggestion offends you sufficiently, you can just stop reading > there. >=20 > Recommendation: >=20 > (1) Abandon the effort to classify the specifications as > Historic. It is at best a symbolic act that few people outside > the IETF community will even notice, much less act differently > because we have done it. Instead, let's try to focus on what is > actually important, not classification and name-called ("curse > you, you Historic protocol" :-( ). >=20 > (2) Pull the "-advice" document back from the RFC Editor queue > and fold the actual substantive content of the "-historic" > document into it, preferably as a very clear and very prominent > Applicability Statement. If this is what v6ops believes, the > statement might reasonably say something like: >=20 > (2a) This protocol, if not used very carefully, leads to > bad operational situations in which things get lost and > the problems are hard to diagnose. We strongly > recommend that it not ever be a default and that it not > be used except under special circumstances and with > great care. > =09 > (2b) Even then, we recommend that it not be used unless > all of those configuring routing information and all the > systems along the routing path are run by experts who > both understanding the issues and are willing to accept > responsibility. > =09 > (2c) If you do decide to use the thing, the "advice" > recommendations in the rest of this document are > mandatory and MUST be followed to avoid serious > operational problems. >=20 > I haven't included either Randy's colorful language or mine in > the example above, but the intent should be clear. Depending on > how much detail the community thinks is useful, there is a good > deal of potentially-useful text in draft-moore-6to4-experimental > as well as in the "-historic" draft. >=20 > The resulting document should explicitly update RFC3056 and > RFC3068. Taking that action will send a much stronger "you need > to read that document before doing anything with this one" > message to most of the people who are familiar with how things > work than a reclassification of the base documents. For those > who aren't familiar with how things work, all of these > approaches, including moving 6to4 to Historic, are pointless. >=20 > That is all. This can and should be made to sound like mature > engineering advice, which it presumably is, and not like small > children throwing mud at each other. >=20 >=20 > Explanation and Rants: >=20 > (ii) I think moving _this_ protocol to Experimental is just > silly. We use Experimental for things that are > pre-standardization or not sufficiently mature to be > standardized. Although the bar is higher, there are elements of > "experiment" in every Proposed Standard --that is why we have a > multiple-step standardization process. If there is really > something to be learned from 6to4 operated in a different way, > then the right action to take would be to propose a 6to4bis that > outlines the characteristics of the protocol, eliminates > anything we have concluded should not be done, and outlines the > desired experiment. That document might reasonably be listed as > updating RFC3056 and RFC3068 as well. =20 >=20 > (i) Presumably our goal is to get IPv6 deployed and > provide advice useful to its deployment, independent of any > particular piece of protocol or transition arrangement. At > least one of the many reasons we haven't seen more deployment is > that we keep sending messages to the broader community that, > however unintentionally, discourage that deployment. In the > early days of IPv6, we did that by advertising (or letting > others who were presumed to be speaking for us advertise) that > IPv6 was completely ready and that transition was going to be > easy, cheap, and seamless. For those who had to make decisions > as to when to deploy IPv6, sufficient investigation tp discover > that some of that story was untrue became sufficient motivation > to back away from IPv6 entirely until we got our acts together. > In more recent years, we have continued to deliver the message > that the IETF (and, to a lesser extent the RIRs) are simply > confused about what advice to give and therefore that IPv6 isn't > ready for someone to deploy who suffers from limited resources > and a strong desire to do it only when all of the ducks are > lined up. Every time we propose a new transition model or > denounce an old one without what seems to be an > externally-convincing analysis of the complete picture, we make > things worse by distributing yet another chapter of "even the > IETF has no real idea how to transition to IPv6". >=20 > If we are serious about encouraging deployment of IPv6 -- and I > hope we are -- then it is time to stop the apparent war among > transition strategies. It seems to me that the document that is > needed is a vastly strengthened (and probably standards-track) > version of RFC 6180 (a rather nice document that I would > encourage those who are engaged in the 6to4 debate on the IETF > list to read), but one that goes beyond such statements as=20 >=20 > There are several types of tunneling mechanisms, > including manually configured IPv6-over-IPv4 tunnels > [RFC4213], 6to4 [RFC3056], automatic host-based tunnels > [RFC4380], tunnel brokers [RFC3053], running IPv6 over > MPLS with IPv6 Provider Edge Routers (6PE) [RFC4798], > the use of Virtual Private Networks (VPNs) or mobility > tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454] > [RFC5555] [RFC5844], and many others. >=20 > (from Section 4.2) and into a serious discussion of the > scenarios that are the best match to different of these > strategies (and others). If we don't know, then let's say, > explicitly, that we haven't had quite enough experience to > provide a differential chart of when particular techniques can > be used but that they are out their, with their strengths and > weaknesses, for situations to which they seem well-adapted. It > is almost possible to infer from 6180's conclusions that almost > all transition mechanisms are equivalent, at least within > groups, and those that aren't are best dealt with by public > burning. Clearly we don't believe the first part of that; we > should get away from the appearance of believing the second. >=20 > And, again and most important, if we want to see IPv6 deployed, > we need a clear message that we actually understand what we are > doing, that we have a coherent picture, and that our process is > not one of lurching among solutions, hoping that each one will > be the magic bullet, and then denouncing any that turn out to > not have sufficient magical properties. The marketplace knows > how to deal with the message we are sending with debates about > recategorization and we have already seen the answer: it isn't > the universal deployment of IPv6 before now or any time soon. > >=20 > john >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From rogerj@gmail.com Fri Jul 15 10:26:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7FE21F8B8D for ; Fri, 15 Jul 2011 10:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kADXj+r121-9 for ; Fri, 15 Jul 2011 10:26:43 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14EA021F8B8C for ; Fri, 15 Jul 2011 10:26:42 -0700 (PDT) Received: by wyj26 with SMTP id 26so58603wyj.31 for ; Fri, 15 Jul 2011 10:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=A+M4ZGyoq2QbxMpbQJnv932PmF/7OjASNnS82Tghdo4=; b=FdRFYTmlrBzyc+Oba7aXvF2kLKVyxe/oj2TcqNHC7yHkURo3dCckhIgBbI99t9030d XHvAG7eo4gTUdd5G1tisFgGCbEhVI865aTETfi1S9s3JPoYR/p2eBDu17A2h0frZ4QEh z5o55HRQ4mmlwkkecXdy9w2yjToxp3+WPJR2E= MIME-Version: 1.0 Received: by 10.227.24.146 with SMTP id v18mr3309309wbb.84.1310750801999; Fri, 15 Jul 2011 10:26:41 -0700 (PDT) Received: by 10.227.142.137 with HTTP; Fri, 15 Jul 2011 10:26:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Jul 2011 19:26:41 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: IPv6 Operations , John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fwd: Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:26:47 -0000 no point in removing v6ops@ for the to: list ---------- Forwarded message ---------- From: Roger J=F8rgensen Date: Fri, Jul 15, 2011 at 7:25 PM Subject: Re: Another look at 6to4 (and other IPv6 transition issues) To: John C Klensin , Brian E Carpenter Cc: rogerj@gmail.com +1 (as in G+) from me. Get on with the work of rewriting/combining it into one document. It is for me a much more sound strategy. I've read the -experimental draft and I don't think it is the sort of document we should publish. And with some hindsight, we should have combined -historic and -advisory into one and not attempted to run them side-by-side through the system :( ps: thanks for, probably the first grown-up mail on this subject for quite a while! --- Roger J --- On Fri, Jul 15, 2011 at 5:55 PM, John C Klensin wrote: > Hi. > > I've been thinking about this and having a few off-list > conversations and want to make a suggestion that draws together > a few others. =A0Since many people don't like my long notes with > the conclusion at the end, this one is suggestion-first. =A0If the > suggestion offends you sufficiently, you can just stop reading > there. > > Recommendation: > > (1) Abandon the effort to classify the specifications as > Historic. =A0It is at best a symbolic act that few people outside > the IETF community will even notice, much less act differently > because we have done it. =A0Instead, let's try to focus on what is > actually important, not classification and name-called ("curse > you, you Historic protocol" :-( =A0). > > (2) Pull the "-advice" document back from the RFC Editor queue > and fold the actual substantive content of the "-historic" > document into it, preferably as a very clear and very prominent > Applicability Statement. =A0If this is what v6ops believes, the > statement might reasonably say something like: > > =A0 =A0 =A0 =A0(2a) This protocol, if not used very carefully, leads to > =A0 =A0 =A0 =A0bad operational situations in which things get lost and > =A0 =A0 =A0 =A0the problems are hard to diagnose. =A0 We strongly > =A0 =A0 =A0 =A0recommend that it not ever be a default and that it not > =A0 =A0 =A0 =A0be used except under special circumstances and with > =A0 =A0 =A0 =A0great care. > > =A0 =A0 =A0 =A0(2b) Even then, we recommend that it not be used unless > =A0 =A0 =A0 =A0all of those configuring routing information and all the > =A0 =A0 =A0 =A0systems along the routing path are run by experts who > =A0 =A0 =A0 =A0both understanding the issues and are willing to accept > =A0 =A0 =A0 =A0responsibility. > > =A0 =A0 =A0 =A0(2c) If you do decide to use the thing, the "advice" > =A0 =A0 =A0 =A0recommendations in the rest of this document are > =A0 =A0 =A0 =A0mandatory and MUST be followed to avoid serious > =A0 =A0 =A0 =A0operational problems. > > I haven't included either Randy's colorful language or mine in > the example above, but the intent should be clear. =A0Depending on > how much detail the community thinks is useful, there is a good > deal of potentially-useful text in draft-moore-6to4-experimental > as well as in the "-historic" draft. > > The resulting document should explicitly update RFC3056 and > RFC3068. =A0Taking that action will send a much stronger "you need > to read that document before doing anything with this one" > message to most of the people who are familiar with how things > work than a reclassification of the base documents. =A0For those > who aren't familiar with how things work, all of these > approaches, including moving 6to4 to Historic, are pointless. > > That is all. =A0This can and should be made to sound like mature > engineering advice, which it presumably is, and not like small > children throwing mud at each other. > > > Explanation and Rants: > > (ii) I think moving _this_ protocol to Experimental is just > silly. =A0We use Experimental for things that are > pre-standardization or not sufficiently mature to be > standardized. =A0Although the bar is higher, there are elements of > "experiment" in every Proposed Standard --that is why we have a > multiple-step standardization process. =A0 If there is really > something to be learned from 6to4 operated in a different way, > then the right action to take would be to propose a 6to4bis that > outlines the characteristics of the protocol, eliminates > anything we have concluded should not be done, and outlines the > desired experiment. =A0That document might reasonably be listed as > updating RFC3056 and RFC3068 as well. > > (i) Presumably our goal is to get IPv6 deployed and > provide advice useful to its deployment, independent of any > particular piece of protocol or transition arrangement. =A0At > least one of the many reasons we haven't seen more deployment is > that we keep sending messages to the broader community that, > however unintentionally, discourage that deployment. =A0In the > early days of IPv6, we did that by advertising (or letting > others who were presumed to be speaking for us advertise) that > IPv6 was completely ready and that transition was going to be > easy, cheap, and seamless. =A0For those who had to make decisions > as to when to deploy IPv6, sufficient investigation tp discover > that some of that story was untrue became sufficient motivation > to back away from IPv6 entirely until we got our acts together. > In more recent years, we have continued to deliver the message > that the IETF (and, to a lesser extent the RIRs) are simply > confused about what advice to give and therefore that IPv6 isn't > ready for someone to deploy who suffers from limited resources > and a strong desire to do it only when all of the ducks are > lined up. =A0Every time we propose a new transition model or > denounce an old one without what seems to be an > externally-convincing analysis of the complete picture, we make > things worse by distributing yet another chapter of "even the > IETF has no real idea how to transition to IPv6". > > If we are serious about encouraging deployment of IPv6 -- and I > hope we are -- then it is time to stop the apparent war among > transition strategies. =A0It seems to me that the document that is > needed is a vastly strengthened (and probably standards-track) > version of RFC 6180 (a rather nice document that I would > encourage those who are engaged in the 6to4 debate on the IETF > list to read), but one that goes beyond such statements as > > =A0 =A0 =A0 =A0There are several types of tunneling mechanisms, > =A0 =A0 =A0 =A0including manually configured IPv6-over-IPv4 tunnels > =A0 =A0 =A0 =A0[RFC4213], 6to4 [RFC3056], automatic host-based tunnels > =A0 =A0 =A0 =A0[RFC4380], tunnel brokers [RFC3053], running IPv6 over > =A0 =A0 =A0 =A0MPLS with IPv6 Provider Edge Routers (6PE) [RFC4798], > =A0 =A0 =A0 =A0the use of Virtual Private Networks (VPNs) or mobility > =A0 =A0 =A0 =A0tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454] > =A0 =A0 =A0 =A0[RFC5555] [RFC5844], and many others. > > (from Section 4.2) and into a serious discussion of the > scenarios that are the best match to different of these > strategies (and others). =A0If we don't know, then let's say, > explicitly, that we haven't had quite enough experience to > provide a differential chart of when particular techniques can > be used but that they are out their, with their strengths and > weaknesses, for situations to which they seem well-adapted. =A0It > is almost possible to infer from 6180's conclusions that almost > all transition mechanisms are equivalent, at least within > groups, and those that aren't are best dealt with by public > burning. =A0Clearly we don't believe the first part of that; we > should get away from the appearance of believing the second. > > And, again and most important, if we want to see IPv6 deployed, > we need a clear message that we actually understand what we are > doing, that we have a coherent picture, and that our process is > not one of lurching among solutions, hoping that each one will > be the magic bullet, and then denouncing any that turn out to > not have sufficient magical properties. =A0The marketplace knows > how to deal with the message we are sending with debates about > recategorization and we have already seen the answer: it isn't > the universal deployment of IPv6 before now or any time soon. > > > =A0 =A0john > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From moore@network-heretics.com Fri Jul 15 10:53:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E521821F8BF5 for ; Fri, 15 Jul 2011 10:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cz84UZQvIkp7 for ; Fri, 15 Jul 2011 10:53:20 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id AAC0621F8BFB for ; Fri, 15 Jul 2011 10:53:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 5FED0212FB; Fri, 15 Jul 2011 13:53:20 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 15 Jul 2011 13:53:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=T0qgzMdgII4BZ9wFJAtBd8FNXfo=; b=Eb/hn0Am8lSU6cGL4h4KSOXGflVcnA3u8rWcnKd2awawusTgC4mZwJb9penlkcKHwJm6kgU/dZnvRDnOw1xx4loP/DKYUc6oHd5WlhYhWUNlIQJgU7P6n5myW5wmAB+Ylp28VBuzCO87rPPKgWAnKlL0DlEtulNwEo0wuRQlRNQ= X-Sasl-enc: OcCCKPlWjzrWhOJxpPSXgcwnLkcaihdAKaUP640btlzE 1310752399 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 59B77400310; Fri, 15 Jul 2011 13:53:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: Date: Fri, 15 Jul 2011 13:53:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <53889EA2-8CC7-4ACF-8D81-060D3B587291@network-heretics.com> References: To: =?iso-8859-1?Q?Roger_J=F8rgensen?= X-Mailer: Apple Mail (2.1084) Cc: John C Klensin , IPv6 Operations Subject: Re: [v6ops] Fwd: Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:53:25 -0000 On Jul 15, 2011, at 1:26 PM, Roger J=F8rgensen wrote: > no point in removing v6ops@ for the to: list >=20 >=20 > ---------- Forwarded message ---------- > From: Roger J=F8rgensen > Date: Fri, Jul 15, 2011 at 7:25 PM > Subject: Re: Another look at 6to4 (and other IPv6 transition issues) > To: John C Klensin , Brian E Carpenter > > Cc: rogerj@gmail.com >=20 >=20 > +1 (as in G+) from me. >=20 > Get on with the work of rewriting/combining it into one document. It > is for me a much more sound strategy. I've read the -experimental > draft and I don't think it is the sort of document we should publish. One of my goals in writing -experimental was to produce a set of = statements which are reasonably objective, and thus, which could win = community consensus. If there are incorrect statements in there, or if = there are obviously correct statements of relevance which are omitted, = please let me know. Of course, that's a separate question from whether = Experimental status is appropriate for 6to4. Trashing 6to4 was not a goal of -experimental. Nor IMO is it an = appropriate goal, especially when other available transition mechanisms = in that space are as bad or worse in their own ways. =20 Keith From ipng@69706e6720323030352d30312d31340a.nosense.org Fri Jul 15 10:53:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412DB21F8BB5 for ; Fri, 15 Jul 2011 10:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.452 X-Spam-Level: X-Spam-Status: No, score=-1.452 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N94bFo3Jl+mN for ; Fri, 15 Jul 2011 10:53:45 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id B624521F8BFB for ; Fri, 15 Jul 2011 10:53:44 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qhma0-0000tE-PF; Sat, 16 Jul 2011 03:23:36 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 40B5D3B346; Sat, 16 Jul 2011 03:23:36 +0930 (CST) Date: Sat, 16 Jul 2011 03:23:35 +0930 From: Mark Smith To: Doug Barton Message-ID: <20110716032335.102b0503@opy.nosense.org> In-Reply-To: <4E1FAFFF.7050506@dougbarton.us> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> <4E1FAFFF.7050506@dougbarton.us> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:53:46 -0000 On Thu, 14 Jul 2011 20:11:59 -0700 Doug Barton wrote: > On 07/09/2011 02:03, Roger J=C3=B8rgensen wrote: > > I suggest we use ::f >=20 > I like the idea of using an alpha, but how about ::d (for discard)? >=20 Possibly only if you speak English ... I think numbers are better for this sort of thing. It seems to me that there are only really 3 things that can be done with a packet, forward it, discard it, or loop it (a special case of forward). As ::1 represents loop, using :f or :d for discard would suggest to me that :2 through :c or :e is reserved for some similar purpose in the future, however I don't think there are any. So I'd prefer ::2 to be used, because I don't think it implies reservation for the future, and is adjacent to what is close to the semantic opposite of discard. > > and we use a /32 from the very end of our current > > 2000::/3 range. That make both stand very out from all of our current > > addresses. >=20 > I agree that 3fff:ffff::/32 is a good idea for this purpose. 3ff* is > more or less useless for general purposes anyway given the historical > Teredo usage. >=20 > I don't like the idea of using a prefix from a block outside 2000::/3, > since we have been operating under the assumption that if we screw > something up in this /3 that we can start over in one of the others. I'd > hate to cripple that premise. >=20 The question is, if 2000::/3 becomes deprecated, does that imply blackholing does too? I think it does, which is why I'd prefer the space to be to be allocated from outside of it. IOW, it's address space that represents a function (similar to ::1, fe80::/10, fc::/7 etc.), so should be a functional allocation, rather than one from within the global Internet address space (that may be changed in the future). Regards, Mark. From pch-b2B3A6689@u-1.phicoh.com Fri Jul 15 10:55:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5253621F8BF7 for ; Fri, 15 Jul 2011 10:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQv+uTXeUP56 for ; Fri, 15 Jul 2011 10:55:15 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD0521F8BF4 for ; Fri, 15 Jul 2011 10:55:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QhmbX-0001mnC; Fri, 15 Jul 2011 19:55:11 +0200 Message-Id: To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: In-reply-to: Your message of "Fri, 15 Jul 2011 19:26:41 +0200 ." Date: Fri, 15 Jul 2011 19:55:03 +0200 Cc: John C Klensin , IPv6 Operations Subject: Re: [v6ops] Fwd: Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:55:15 -0000 In your letter dated Fri, 15 Jul 2011 19:26:41 +0200 you wrote: >Get on with the work of rewriting/combining it into one document. It >is for me a much more sound strategy. I've read the -experimental >draft and I don't think it is the sort of document we should publish. > >And with some hindsight, we should have combined -historic and >-advisory into one and not attempted to run them side-by-side through >the system :( I think it is much better to keep them separate. 6to4 relies on third parties running relays. It is important that they keep doing so. For that group you don't want a document tells them why not to use 6to4 and then still expect people make it work. I agree that the -experimental draft could use some work. Independent of whether marking 6to4 as experimental is a good idea or not. From moore@network-heretics.com Fri Jul 15 11:33:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC0221F8BDB for ; Fri, 15 Jul 2011 11:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgffYV+8IO3P for ; Fri, 15 Jul 2011 11:33:58 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id EE75E21F8BD3 for ; Fri, 15 Jul 2011 11:33:57 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id A09AB21346; Fri, 15 Jul 2011 14:33:57 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 15 Jul 2011 14:33:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=uxBN6F/LEzelxA42BOBaLPRxpkA=; b=GMI+uLiWr1ZAuZ8m87mn/jGuetRO0AsOh3NO8bb9UFNc601Aau8HjFhnVUG3hy4ee038298kYHf6dtZTC3OZHFXA0cEENz+eX6xX2Cga22xvkw4vKZqYL2BowR6YGsNLkunuV+fQtf2al7PDu1ZxzwC+qnytV70a/4f9xOjoMeY= X-Sasl-enc: DeaMrJA2oBd3E4qYrDaUKiZj48x+T0oApMbFDEt6oary 1310754837 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 7FA944035E0; Fri, 15 Jul 2011 14:33:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Fri, 15 Jul 2011 14:33:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <945C00EF-B7D2-452C-87DE-C2352CD9B596@network-heretics.com> References: To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: John C Klensin , IPv6 Operations Subject: Re: [v6ops] Fwd: Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 18:33:58 -0000 On Jul 15, 2011, at 1:55 PM, Philip Homburg wrote: > I agree that the -experimental draft could use some work. Independent = of > whether marking 6to4 as experimental is a good idea or not. I've had some very useful feedback in private mail, including a couple = of important points that need to be captured, e.g.: - 6to4 was never intended (at least, I don't recall it being intended) = to be used by access providers as a means of providing IPv6 service to = their customers. It's not especially well suited for this, especially = given that there's really no good way for an access provider to ensure = that the return traffic from native v6 networks is routed back to its = customers. 6rd is a much better choice for that use case. - Some routers are being shipped which claim to support IPv6 but which = only support 6to4. I don't think this is appropriate either, because = 6to4 has inherently diminishing applicability and the reason a customer = might want a v6-compatible router is so he can upgrade to v6 later. = Routers that advertise v6 support need to support native v6 in addition = to whatever transition mechanisms they choose to support.=20 (there's more detail than that - the above is just a summary) I'll try to get a revision out right after Quebec. =20 Keith From john-ietf@jck.com Fri Jul 15 08:55:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7F321F8A4F; Fri, 15 Jul 2011 08:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmMagDMO204I; Fri, 15 Jul 2011 08:55:21 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id CA4BF21F853A; Fri, 15 Jul 2011 08:55:20 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QhkjX-000DI0-MS; Fri, 15 Jul 2011 11:55:20 -0400 Date: Fri, 15 Jul 2011 11:55:18 -0400 From: John C Klensin To: IETF Discussion Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Fri, 15 Jul 2011 11:45:12 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 15:55:22 -0000 Hi. I've been thinking about this and having a few off-list conversations and want to make a suggestion that draws together a few others. Since many people don't like my long notes with the conclusion at the end, this one is suggestion-first. If the suggestion offends you sufficiently, you can just stop reading there. Recommendation: (1) Abandon the effort to classify the specifications as Historic. It is at best a symbolic act that few people outside the IETF community will even notice, much less act differently because we have done it. Instead, let's try to focus on what is actually important, not classification and name-called ("curse you, you Historic protocol" :-( ). (2) Pull the "-advice" document back from the RFC Editor queue and fold the actual substantive content of the "-historic" document into it, preferably as a very clear and very prominent Applicability Statement. If this is what v6ops believes, the statement might reasonably say something like: (2a) This protocol, if not used very carefully, leads to bad operational situations in which things get lost and the problems are hard to diagnose. We strongly recommend that it not ever be a default and that it not be used except under special circumstances and with great care. (2b) Even then, we recommend that it not be used unless all of those configuring routing information and all the systems along the routing path are run by experts who both understanding the issues and are willing to accept responsibility. (2c) If you do decide to use the thing, the "advice" recommendations in the rest of this document are mandatory and MUST be followed to avoid serious operational problems. I haven't included either Randy's colorful language or mine in the example above, but the intent should be clear. Depending on how much detail the community thinks is useful, there is a good deal of potentially-useful text in draft-moore-6to4-experimental as well as in the "-historic" draft. The resulting document should explicitly update RFC3056 and RFC3068. Taking that action will send a much stronger "you need to read that document before doing anything with this one" message to most of the people who are familiar with how things work than a reclassification of the base documents. For those who aren't familiar with how things work, all of these approaches, including moving 6to4 to Historic, are pointless. That is all. This can and should be made to sound like mature engineering advice, which it presumably is, and not like small children throwing mud at each other. Explanation and Rants: (ii) I think moving _this_ protocol to Experimental is just silly. We use Experimental for things that are pre-standardization or not sufficiently mature to be standardized. Although the bar is higher, there are elements of "experiment" in every Proposed Standard --that is why we have a multiple-step standardization process. If there is really something to be learned from 6to4 operated in a different way, then the right action to take would be to propose a 6to4bis that outlines the characteristics of the protocol, eliminates anything we have concluded should not be done, and outlines the desired experiment. That document might reasonably be listed as updating RFC3056 and RFC3068 as well. (i) Presumably our goal is to get IPv6 deployed and provide advice useful to its deployment, independent of any particular piece of protocol or transition arrangement. At least one of the many reasons we haven't seen more deployment is that we keep sending messages to the broader community that, however unintentionally, discourage that deployment. In the early days of IPv6, we did that by advertising (or letting others who were presumed to be speaking for us advertise) that IPv6 was completely ready and that transition was going to be easy, cheap, and seamless. For those who had to make decisions as to when to deploy IPv6, sufficient investigation tp discover that some of that story was untrue became sufficient motivation to back away from IPv6 entirely until we got our acts together. In more recent years, we have continued to deliver the message that the IETF (and, to a lesser extent the RIRs) are simply confused about what advice to give and therefore that IPv6 isn't ready for someone to deploy who suffers from limited resources and a strong desire to do it only when all of the ducks are lined up. Every time we propose a new transition model or denounce an old one without what seems to be an externally-convincing analysis of the complete picture, we make things worse by distributing yet another chapter of "even the IETF has no real idea how to transition to IPv6". If we are serious about encouraging deployment of IPv6 -- and I hope we are -- then it is time to stop the apparent war among transition strategies. It seems to me that the document that is needed is a vastly strengthened (and probably standards-track) version of RFC 6180 (a rather nice document that I would encourage those who are engaged in the 6to4 debate on the IETF list to read), but one that goes beyond such statements as There are several types of tunneling mechanisms, including manually configured IPv6-over-IPv4 tunnels [RFC4213], 6to4 [RFC3056], automatic host-based tunnels [RFC4380], tunnel brokers [RFC3053], running IPv6 over MPLS with IPv6 Provider Edge Routers (6PE) [RFC4798], the use of Virtual Private Networks (VPNs) or mobility tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454] [RFC5555] [RFC5844], and many others. (from Section 4.2) and into a serious discussion of the scenarios that are the best match to different of these strategies (and others). If we don't know, then let's say, explicitly, that we haven't had quite enough experience to provide a differential chart of when particular techniques can be used but that they are out their, with their strengths and weaknesses, for situations to which they seem well-adapted. It is almost possible to infer from 6180's conclusions that almost all transition mechanisms are equivalent, at least within groups, and those that aren't are best dealt with by public burning. Clearly we don't believe the first part of that; we should get away from the appearance of believing the second. And, again and most important, if we want to see IPv6 deployed, we need a clear message that we actually understand what we are doing, that we have a coherent picture, and that our process is not one of lurching among solutions, hoping that each one will be the magic bullet, and then denouncing any that turn out to not have sufficient magical properties. The marketplace knows how to deal with the message we are sending with debates about recategorization and we have already seen the answer: it isn't the universal deployment of IPv6 before now or any time soon. john From pch-b2B3A6689@u-1.phicoh.com Fri Jul 15 10:35:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D251621F8B8C; Fri, 15 Jul 2011 10:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDHbGPv9-qUK; Fri, 15 Jul 2011 10:35:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 9D56521F8B70; Fri, 15 Jul 2011 10:35:08 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QhmI4-0001iqC; Fri, 15 Jul 2011 19:35:04 +0200 Message-Id: To: RJ Atkinson From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> In-reply-to: Your message of "Fri, 15 Jul 2011 09:31:12 -0400 ." Date: Fri, 15 Jul 2011 19:35:01 +0200 X-Mailman-Approved-At: Fri, 15 Jul 2011 11:45:12 -0700 Cc: v6ops@ietf.org, ipv6@ietf.org Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 17:35:09 -0000 In your letter dated Fri, 15 Jul 2011 09:31:12 -0400 you wrote: >To some extent, I would prefer an approach where IPv6 Ops would work >on that informational document (threats/concerns, operational use cases, >existing mitigations that could be deployed) first. Then, if there >were use cases not adequately covered by the material in that (proposed) >IPv6 Ops WG document, the IPv6 WG could use that IPv6 Ops WG document >to examine potential protocol specification changes on a much more >informed basis. I could be wrong, but the impression I got from the various ops lists is that the way you deal with this attack is to avoid using RFC-4862 and/or RFC-4861. For example: - Just use link local on a link between two routers - Configure a much longer prefix (/120) - Have /128s on separate interfaces - Use a static neighbor cache and then disable ND - (From draft-gashinsky-v6nd-enhance) Have hosts inject /128s And there is also - Use a statefull firewall (and break end-to-end connectivity). draft-gashinsky-v6nd-enhance give a nice overview, but more importantly already tries to modify RFC-4861. If v6ops first wants to spend time writing a requirements document, then that's fine with me. But to me it seems more productive to explore the design space, write an informational document about that and then solicit feedback from v6ops on whether there are any options that seem to make some kind of sense in their environment. >Operator input on this topic would be strongly >beneficial since this is fundamentally an operations issue. I would classify a protocol that is at the heart of IPv6 and that is subject of a relatively low-tech DoS as a protocol problem and not as an ops problem. (Of course, it remains an ops problem until the protocol is fixed) From john-ietf@jck.com Fri Jul 15 11:29:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6147621F8B94 for ; Fri, 15 Jul 2011 11:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzZzUauzlvHT for ; Fri, 15 Jul 2011 11:29:34 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id C8DA221F8B8A for ; Fri, 15 Jul 2011 11:29:33 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qhn8j-000GIo-49; Fri, 15 Jul 2011 14:29:29 -0400 Date: Fri, 15 Jul 2011 14:29:28 -0400 From: John C Klensin To: =?UTF-8?Q?Roger_J=C3=B8rgensen?= , IPv6 Operations Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Fri, 15 Jul 2011 11:45:12 -0700 Subject: Re: [v6ops] Fwd: Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 18:29:34 -0000 Ack. I removed it only because I'm not a participant in the WG (I have enough aggravating problems at the applications layer) and don't have posting privileges on that list. But I'm certainly willing to have anything I say on the subject copied to v6ops if that is useful to the WG. john --On Friday, July 15, 2011 19:26 +0200 Roger J=C3=B8rgensen wrote: > no point in removing v6ops@ for the to: list >=20 >=20 > ---------- Forwarded message ---------- > From: Roger J=C3=B8rgensen > Date: Fri, Jul 15, 2011 at 7:25 PM > Subject: Re: Another look at 6to4 (and other IPv6 transition > issues) To: John C Klensin , Brian E > Carpenter > Cc: rogerj@gmail.com >=20 >=20 > +1 (as in G+) from me. >=20 > Get on with the work of rewriting/combining it into one > document. It is for me a much more sound strategy. I've read > the -experimental draft and I don't think it is the sort of > document we should publish. >... From john-ietf@jck.com Fri Jul 15 11:52:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4A221F8BF8; Fri, 15 Jul 2011 11:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isLL5FU6LYyR; Fri, 15 Jul 2011 11:52:33 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF5021F854A; Fri, 15 Jul 2011 11:52:33 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QhnV2-000GNf-UT; Fri, 15 Jul 2011 14:52:33 -0400 Date: Fri, 15 Jul 2011 14:52:32 -0400 From: John C Klensin To: Joel Jaeggli Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 18:52:34 -0000 --On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli wrote: > So the rational for the advice document not being combined > with the standards action in it is that the later has some > polarizing impact, the advice document does not. the advice > document is through and done, historic is not. Joel (and others), I understand the rationale. At the risk of repeating myself, I simply do not think it works or is appropriate. Recategorizing set of documents as "Historic" is an extremely blunt instrument. If we do it in a consistent and logical fashion, the advice document would have to go to Historic along with the base documents because giving advice about a piece of ancient history is meaningless. That is not what most people who like the advice document intended, at least as I understood the consensus on that Last Call. Worse, for those who are successfully operating 6to4 and finding it useful, reclassifying the specifications to Historic sends a clear message that, from their perspective at least, the IETF is clueless (since "Historic" essentially says the thing is useless and/or that no one is using it... and they know better because they are a counterexample). The consequence of that, in turn, is that they either simply ignore the advice or conclude that they should postpone IPv6 deployment until the IETF gives advice that is both coherent and believable. I think there are probably a dozen "right" ways to do this, with the differences depending on issues that I haven't followed v6ops or 6to4 deployment closely enough to have opinions about. What they have in common is a real analysis of issues and some meaningful recommendations ("-advice" seems to do much of that) and the used of "updates" to effectively incorporate that advice and guidance into the base spec. If that is better done with a standalone document that references the base spec and the advice document, updating all of them, I'm fine with it (although, under that scenario, I'd prefer to have the advice document on standards track). Finally, if we had a wonderful transition model that would work well in all situations, then it would make sense to recommend it and depreciate everything else. We don't. What we have are a bunch of mechanisms, each with advantages and disadvantages, some much better adapted to particular situations than others. It would be easier if we had a good single solution, but we don't... that is life, or at least engineering. Given that, we serve the community much better with analyses and explanations of tradeoffs (and RFC 6180 is, IMO, a really good start) than we do by going through exercises of figuring out what to denounce. IMO, the _only_ thing we should be categorically denouncing are tactics and strategies that encourage people to put off getting serious about IPv6. Unfortunately, trying to slap a "Historic" label on one particular transition strategy, or to rank transition strategies that have proven useful to some actors on the basis of how much various of us loathe them, are about denunciation and, however unintentionally, with the risk of encouraging people to sit and wait, not about progress or network engineering. back to lurking... john From joelja@bogus.com Fri Jul 15 11:53:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25B421F8C23 for ; Fri, 15 Jul 2011 11:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7fFOyHCCF3b for ; Fri, 15 Jul 2011 11:53:35 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 018E621F8C22 for ; Fri, 15 Jul 2011 11:53:34 -0700 (PDT) Received: from [10.187.125.226] (254.sub-166-250-32.myvzw.com [166.250.32.254]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6FIrSfK002333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2011 18:53:30 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Joel Jaeggli In-Reply-To: Date: Fri, 15 Jul 2011 11:53:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <076B8399-DDAC-4F02-9682-4E516F2E3403@bogus.com> References: To: John C Klensin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 15 Jul 2011 18:53:31 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] Fwd: Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 18:53:35 -0000 I added you to the approved list on as soon as I moderated the message. On Jul 15, 2011, at 11:29 AM, John C Klensin wrote: > Ack. >=20 > I removed it only because I'm not a participant in the WG (I > have enough aggravating problems at the applications layer) and > don't have posting privileges on that list. But I'm certainly > willing to have anything I say on the subject copied to v6ops if > that is useful to the WG. >=20 > john >=20 >=20 > --On Friday, July 15, 2011 19:26 +0200 Roger J=F8rgensen > wrote: >=20 >> no point in removing v6ops@ for the to: list >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: Roger J=F8rgensen >> Date: Fri, Jul 15, 2011 at 7:25 PM >> Subject: Re: Another look at 6to4 (and other IPv6 transition >> issues) To: John C Klensin , Brian E >> Carpenter >> Cc: rogerj@gmail.com >>=20 >>=20 >> +1 (as in G+) from me. >>=20 >> Get on with the work of rewriting/combining it into one >> document. It is for me a much more sound strategy. I've read >> the -experimental draft and I don't think it is the sort of >> document we should publish. >> ... >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From joelja@bogus.com Fri Jul 15 12:17:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEB421F8C1E; Fri, 15 Jul 2011 12:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiYqLVGIMwpK; Fri, 15 Jul 2011 12:17:25 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8069021F8C12; Fri, 15 Jul 2011 12:17:25 -0700 (PDT) Received: from [10.187.125.226] (254.sub-166-250-32.myvzw.com [166.250.32.254]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6FJHLFX003131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2011 19:17:23 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Fri, 15 Jul 2011 12:17:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71D5A97D-7119-4082-BC87-6505370CE800@bogus.com> References: To: John C Klensin X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 15 Jul 2011 19:17:24 +0000 (UTC) Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 19:17:26 -0000 On Jul 15, 2011, at 11:52 AM, John C Klensin wrote: >=20 >=20 > --On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli > wrote: >=20 >> So the rational for the advice document not being combined >> with the standards action in it is that the later has some >> polarizing impact, the advice document does not. the advice >> document is through and done, historic is not. >=20 > Joel (and others), >=20 > I understand the rationale. At the risk of repeating myself, I > simply do not think it works or is appropriate. And there are people that disagree with you on that. > Recategorizing > set of documents as "Historic" is an extremely blunt instrument. > If we do it in a consistent and logical fashion, the advice > document would have to go to Historic along with the base > documents because giving advice about a piece of ancient history > is meaningless. That is not what most people who like the > advice document intended, at least as I understood the consensus > on that Last Call. > Finally, if we had a wonderful transition model that would work > well in all situations, then it would make sense to recommend it > and depreciate everything else. You missed the boat about a decade back I guess. Transition technologies = (none of them) are a substitute for actual deployment. They should = naturally decline in popularity and in fact in the portions of the = internet where we can measure them they are. Right now if we try and fit = a story to the evidence that is happening because of host changes, and = not because of deployment. ipv4 is becoming less usable and it's taking = autotunnels with it, nobody here has a proposal that changes that. > We don't. What we have are a > bunch of mechanisms, each with advantages and disadvantages, > some much better adapted to particular situations than others. > It would be easier if we had a good single solution, but we > don't... that is life, or at least engineering. Given that, we > serve the community much better with analyses and explanations > of tradeoffs (and RFC 6180 is, IMO, a really good start) than we > do by going through exercises of figuring out what to denounce. > IMO, the _only_ thing we should be categorically denouncing are > tactics and strategies that encourage people to put off getting > serious about IPv6. Unfortunately, trying to slap a "Historic" > label on one particular transition strategy, or to rank > transition strategies that have proven useful to some actors on > the basis of how much various of us loathe them, are about > denunciation and, however unintentionally, with the risk of > encouraging people to sit and wait, not about progress or > network engineering. >=20 > back to lurking... > john >=20 >=20 From Fred.L.Templin@boeing.com Fri Jul 15 12:37:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B936721F8C35; Fri, 15 Jul 2011 12:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvUmQs1w+GO9; Fri, 15 Jul 2011 12:37:51 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id BB81621F8C32; Fri, 15 Jul 2011 12:37:51 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p6FJbcJR022084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Jul 2011 14:37:41 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p6FJbc43017597; Fri, 15 Jul 2011 12:37:38 -0700 (PDT) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p6FJbbUQ017573 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 15 Jul 2011 12:37:38 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Fri, 15 Jul 2011 12:37:37 -0700 From: "Templin, Fred L" To: Joel Jaeggli , John C Klensin Date: Fri, 15 Jul 2011 12:37:36 -0700 Thread-Topic: Another look at 6to4 (and other IPv6 transition issues) Thread-Index: AcxDI+EB7Z+L/w3xRMqKXIeVwrML3AAAogVw Message-ID: References: <71D5A97D-7119-4082-BC87-6505370CE800@bogus.com> In-Reply-To: <71D5A97D-7119-4082-BC87-6505370CE800@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 19:37:52 -0000 Hi Joel,=20 > ipv4 is becoming less usable and it's=20 > taking autotunnels with it, nobody here has a proposal that=20 > changes that. As far as I can tell, IPv4 is not becoming less usable within my organization's network. Thanks - Fred fred.l.templin@boeing.com= From Ted.Lemon@nominum.com Fri Jul 15 12:43:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986D521F8C3F; Fri, 15 Jul 2011 12:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvUX-AyxfPsD; Fri, 15 Jul 2011 12:43:18 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7067321F8B48; Fri, 15 Jul 2011 12:43:18 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTiCYVRycy09fVcn7dQVBnxAuAfeOuEeX@postini.com; Fri, 15 Jul 2011 12:43:18 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4C3251B813B; Fri, 15 Jul 2011 12:43:17 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 22CCD190059; Fri, 15 Jul 2011 12:43:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from exchange-01.WIN.NOMINUM.COM (64.89.228.50) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 15 Jul 2011 12:43:17 -0700 Received: from vpna-148.vpn.nominum.com (64.89.227.148) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 15 Jul 2011 12:43:16 -0700 MIME-Version: 1.0 (Apple Message framework v1242) Content-Type: text/plain; charset="us-ascii" From: Ted Lemon In-Reply-To: Date: Fri, 15 Jul 2011 15:43:12 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <6BD654DE-880B-43BD-89A4-1BB065AC2B1B@nominum.com> References: <71D5A97D-7119-4082-BC87-6505370CE800@bogus.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1242) Cc: "v6ops@ietf.org Operations" , IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 19:43:19 -0000 On Jul 15, 2011, at 3:37 PM, Templin, Fred L wrote: >> ipv4 is becoming less usable and it's=20 >> taking autotunnels with it, nobody here has a proposal that=20 >> changes that. >=20 > As far as I can tell, IPv4 is not becoming less > usable within my organization's network. You realize that you have not contradicted what Joel said, right? = The IETF's business isn't making sure that Boeing's networks are = functional, much as we might collectively wish you well in that regard. From brian.e.carpenter@gmail.com Fri Jul 15 13:34:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6B521F8C47; Fri, 15 Jul 2011 13:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75J4kUL6F7Rk; Fri, 15 Jul 2011 13:34:44 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 560C121F8C3D; Fri, 15 Jul 2011 13:34:44 -0700 (PDT) Received: by fxe4 with SMTP id 4so3954804fxe.27 for ; Fri, 15 Jul 2011 13:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=N/eNqSmoQ9LPsdTgyh5xmvayB6bNBPcd0wxPF3Hh1ls=; b=GJZwfRWfoEgbLG5YE35H1HFkvX2SZg9Y+CSsR77MJfuFvGL/0QhwCS3x2wiiF+G1WR 1eZ5WKXdJXrtyc7CuZXsKvChTs+GC8Sbs9nosdmmozjblnxFNYOFzltUK5zYOJCRIJLf PEFRZ9cInNMZcdolp2wl61iyETPlQVQIyWviA= Received: by 10.223.1.201 with SMTP id 9mr5880637fag.91.1310762083283; Fri, 15 Jul 2011 13:34:43 -0700 (PDT) Received: from ?IPv6:2001:388:f000::35? ([2001:388:f000::35]) by mx.google.com with ESMTPS id e10sm995743fak.42.2011.07.15.13.34.39 (version=SSLv3 cipher=OTHER); Fri, 15 Jul 2011 13:34:42 -0700 (PDT) Message-ID: <4E20A44E.3060203@gmail.com> Date: Sat, 16 Jul 2011 08:34:22 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John C Klensin References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 20:34:45 -0000 On 2011-07-16 03:55, John C Klensin wrote: > (2) Pull the "-advice" document back from the RFC Editor queue > and fold the actual substantive content of the "-historic" > document into it, preferably as a very clear and very prominent > Applicability Statement. I am very strongly against this. The advisory document received extremely strong support and excellent technical input from a wide cross section of the IPv-anything operational community and has been fully approved and is ready to go. I originally hoped it could be published for World IPv6 Day, but having missed that date, it remains urgent to get it out there, and to publicise it to operators who are not aware of the issues. We can spend another few months debating the exact form of words for a normative document advising implementors to do what most of them are now doing; I don't care and it basically doesn't matter except in the IETF's tiny world. That isn't what's important. What's important is to get as many operators as possible doing what they can to ameliorate the situation. Brian From mark@townsley.net Fri Jul 15 13:57:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AD221F8BAD for ; Fri, 15 Jul 2011 13:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOrx7zFCA5bb for ; Fri, 15 Jul 2011 13:57:07 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AEAFA21F8BA9 for ; Fri, 15 Jul 2011 13:57:06 -0700 (PDT) Received: by wwe5 with SMTP id 5so1114036wwe.13 for ; Fri, 15 Jul 2011 13:57:05 -0700 (PDT) Received: by 10.216.235.207 with SMTP id u57mr3494731weq.42.1310763425494; Fri, 15 Jul 2011 13:57:05 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id f1sm952816wed.14.2011.07.15.13.57.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jul 2011 13:57:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <945C00EF-B7D2-452C-87DE-C2352CD9B596@network-heretics.com> Date: Fri, 15 Jul 2011 22:57:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8AACE4F4-3FF3-4E8F-B6FC-0CF7536C1F5A@townsley.net> References: <945C00EF-B7D2-452C-87DE-C2352CD9B596@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) Cc: John C Klensin , IPv6 Operations Subject: Re: [v6ops] Fwd: Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 20:57:07 -0000 On Jul 15, 2011, at 8:33 PM, Keith Moore wrote: > - Some routers are being shipped which claim to support IPv6 but which = only support 6to4. I don't think this is appropriate either, because = 6to4 has inherently diminishing applicability and the reason a customer = might want a v6-compatible router is so he can upgrade to v6 later. = Routers that advertise v6 support need to support native v6 in addition = to whatever transition mechanisms they choose to support.=20 Sadly, the time to have made that point was around 2005 before 6to4 = without any native support whatsoever made it into the most widely = followed home router recommendations for IPv6 at the time.=20 - Mark= From john-ietf@jck.com Fri Jul 15 14:01:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A0221F8C0E; Fri, 15 Jul 2011 14:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMkUzicQMmXq; Fri, 15 Jul 2011 14:01:33 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id D603921F8C0A; Fri, 15 Jul 2011 14:01:32 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QhpVr-000ISk-Gy; Fri, 15 Jul 2011 17:01:31 -0400 Date: Fri, 15 Jul 2011 17:01:30 -0400 From: John C Klensin To: Brian E Carpenter Message-ID: In-Reply-To: <4E20A44E.3060203@gmail.com> References: <4E20A44E.3060203@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 21:01:34 -0000 --On Saturday, July 16, 2011 08:34 +1200 Brian E Carpenter wrote: >... > We can spend another few months debating the exact form of > words for a normative document advising implementors to do > what most of them are now doing; I don't care and it basically > doesn't matter except in the IETF's tiny world. That isn't > what's important. What's important is to get as many operators > as possible doing what they can to ameliorate the situation. Brian, It seems to me that you can take two positions here, but not both as the same time. Position #1: What the IETF does, and how it classifies things, actually make a difference. If that is true then the advice document should look a lot more mandatory and should certainly be shown as updating the 6to4 base documents (I note that the latter decision could be made without reopening the document in any significant way). Whether it is part of the advice document or not, an applicability statement that discusses what is really going on is important and reclassification to Historic would be stupid. If nothing else, unless it reclassifies your advice doc to Historic as well, reclassification to Historic would be appeal-bait. And classifying your document as Historic also would rather dilute the message. Position #2: How the IETF classifies things makes very little difference in this space because people will follow advice that seems sensible and ignore everything else. If so, it makes little difference how your document is approved or where it is published. For example, it could have come through the Independent Stream or been pushed into CCR. No problem. And the "Historic" effort is a huge waste of the community's time, no matter how it comes out. Just my opinion -- you will probably continue to disagree. best, john From moore@network-heretics.com Fri Jul 15 14:18:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB0121F8564 for ; Fri, 15 Jul 2011 14:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy5vv+CTijUt for ; Fri, 15 Jul 2011 14:18:07 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id B5B0B21F8560 for ; Fri, 15 Jul 2011 14:18:06 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 677D9202CB; Fri, 15 Jul 2011 17:18:06 -0400 (EDT) Received: from web1.messagingengine.com ([10.202.2.211]) by compute1.internal (MEProxy); Fri, 15 Jul 2011 17:18:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:from:to:cc:mime-version:content-transfer-encoding:content-type:references:subject:in-reply-to:date; s=smtpout; bh=iqqV8ADip/B4IU/lJrsloxX0XgA=; b=u2pQH/rAicPhFJ0Z3iQA4lf3gKruyvNrRgdhMEh5SjXe8N1Niv9pbP6Lx4Uy6HAGP7uqEVk1mwGAHY3hlhaeiOUhtnxd1An6HD1gcQTeLsfcudrbwzwSPpyUBpNG8yxiGVYQQBzVaSul9SeCasPPES6tUENApllNPORUnVC0f/4= Received: by web1.messagingengine.com (Postfix, from userid 99) id 276459A0276; Fri, 15 Jul 2011 17:18:06 -0400 (EDT) Message-Id: <1310764686.8223.2152271157@webmail.messagingengine.com> X-Sasl-Enc: LVfoIU4FHkHKBWigUbjzWSh3xb1gKcbHJD1YbspTdx2M 1310764686 From: "Keith Moore" To: "Mark Townsley" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Mailer: MessagingEngine.com Webmail Interface References: <945C00EF-B7D2-452C-87DE-C2352CD9B596@network-heretics.com> <8AACE4F4-3FF3-4E8F-B6FC-0CF7536C1F5A@townsley.net> In-Reply-To: <8AACE4F4-3FF3-4E8F-B6FC-0CF7536C1F5A@townsley.net> Date: Fri, 15 Jul 2011 17:18:06 -0400 Cc: John C Klensin , IPv6 Operations Subject: Re: [v6ops] Fwd: Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 21:18:11 -0000 -- Keith Moore moore@network-heretics.com On Fri, 15 Jul 2011 22:57 +0200, "Mark Townsley" wrote: > > On Jul 15, 2011, at 8:33 PM, Keith Moore wrote: > > > - Some routers are being shipped which claim to support IPv6 but which only support 6to4. I don't think this is appropriate either, because 6to4 has inherently diminishing applicability and the reason a customer might want a v6-compatible router is so he can upgrade to v6 later. Routers that advertise v6 support need to support native v6 in addition to whatever transition mechanisms they choose to support. > > Sadly, the time to have made that point was around 2005 before 6to4 > without any native support whatsoever made it into the most widely > followed home router recommendations for IPv6 at the time. Better late than never. And better to say precisely what is meant than to say something vague, loud, and likely to be misinterpreted. Keith From Fred.L.Templin@boeing.com Fri Jul 15 16:10:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A28B21F8BDC; Fri, 15 Jul 2011 16:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tytketj4C7Ob; Fri, 15 Jul 2011 16:10:22 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACB721F8B86; Fri, 15 Jul 2011 16:10:21 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p6FNAC5Y029109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Jul 2011 16:10:15 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p6FNA7b9028117; Fri, 15 Jul 2011 16:10:07 -0700 (PDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p6FNA409028026 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 15 Jul 2011 16:10:06 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Fri, 15 Jul 2011 16:10:05 -0700 From: "Templin, Fred L" To: Ted Lemon Date: Fri, 15 Jul 2011 16:10:04 -0700 Thread-Topic: [v6ops] Another look at 6to4 (and other IPv6 transition issues) Thread-Index: AcxDJ3QqjlOP9YhATMa7q2+nrXLFPQAGvlQw Message-ID: References: <71D5A97D-7119-4082-BC87-6505370CE800@bogus.com> <6BD654DE-880B-43BD-89A4-1BB065AC2B1B@nominum.com> In-Reply-To: <6BD654DE-880B-43BD-89A4-1BB065AC2B1B@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org Operations" , IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 23:10:22 -0000 =20 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 > Sent: Friday, July 15, 2011 12:43 PM > To: Templin, Fred L > Cc: v6ops@ietf.org Operations; IETF Discussion > Subject: Re: [v6ops] Another look at 6to4 (and other IPv6=20 > transition issues) >=20 > On Jul 15, 2011, at 3:37 PM, Templin, Fred L wrote: > >> ipv4 is becoming less usable and it's=20 > >> taking autotunnels with it, nobody here has a proposal that=20 > >> changes that. > >=20 > > As far as I can tell, IPv4 is not becoming less > > usable within my organization's network. >=20 > You realize that you have not contradicted what Joel said,=20 > right? The IETF's business isn't making sure that=20 > Boeing's networks are functional, much as we might=20 > collectively wish you well in that regard. If the IETF wishes organizations such as ours well, then they should be willing to provide operational guidance. RFCs 4057 and 4852 were a small step in that direction, while 'draft-templin-v6ops-isops' provides actionable information. Fred= From joelja@bogus.com Fri Jul 15 16:11:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBCA21F8B8E; Fri, 15 Jul 2011 16:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfZX4Zv4jmrI; Fri, 15 Jul 2011 16:11:14 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5997721F8B30; Fri, 15 Jul 2011 16:11:14 -0700 (PDT) Received: from [192.168.50.12] (24-221-29-56.pools.static.spcsdns.net [24.221.29.56]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6FNAeSc007915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2011 23:10:51 GMT (envelope-from joelja@bogus.com) References: <71D5A97D-7119-4082-BC87-6505370CE800@bogus.com> From: Joel Jaeggli Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: <2D86AA95-BC5F-4313-844B-A89485DA7220@bogus.com> Date: Fri, 15 Jul 2011 13:28:46 -0700 To: "Templin, Fred L" Mime-Version: 1.0 (iPad Mail 8J2) X-Mailer: iPad Mail (8J2) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 15 Jul 2011 23:11:11 +0000 (UTC) Cc: John C Klensin , "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 23:11:15 -0000 Joel's widget number 2 On Jul 15, 2011, at 12:37, "Templin, Fred L" wro= te: > Hi Joel,=20 >=20 >> ipv4 is becoming less usable and it's=20 >> taking autotunnels with it, nobody here has a proposal that=20 >> changes that. >=20 > As far as I can tell, IPv4 is not becoming less > usable within my organization's network. Stasis is great if you can get it... There are two drafts proposing the use o= f shared address space space to be assigned by ARIN for LSN that will proba= bly turn up in opsawg. Whether the get it or not the LSNs will be deployed. And yeah I think Boeing probably has enough v4 addresses for a while. Joel >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 From dougb@dougbarton.us Fri Jul 15 21:58:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CCA21F876A for ; Fri, 15 Jul 2011 21:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSRLgdosQHN2 for ; Fri, 15 Jul 2011 21:58:19 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id DB3BD21F8766 for ; Fri, 15 Jul 2011 21:58:18 -0700 (PDT) Received: (qmail 31252 invoked by uid 399); 16 Jul 2011 04:58:13 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 16 Jul 2011 04:58:13 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E211A60.1020601@dougbarton.us> Date: Fri, 15 Jul 2011 21:58:08 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Smith References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> <4E1FAFFF.7050506@dougbarton.us> <20110716032335.102b0503@opy.nosense.org> In-Reply-To: <20110716032335.102b0503@opy.nosense.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 04:58:20 -0000 On 07/15/2011 10:53, Mark Smith wrote: > On Thu, 14 Jul 2011 20:11:59 -0700 > Doug Barton wrote: > >> On 07/09/2011 02:03, Roger Jrgensen wrote: >>> I suggest we use ::f >> >> I like the idea of using an alpha, but how about ::d (for discard)? >> > > Possibly only if you speak English ... ... or Spanish (descartar) :) Although thinking about it, if we use 3fff:ffff::/32 for the network then ::f might make more sense. > I think numbers are better for this sort of thing. I wouldn't necessarily argue against using a number, and ::2 wouldn't hurt anything. I just thought it would be interesting to use something with at least some mnemonic value. > It seems to me that there are only really 3 things that can be done > with a packet, forward it, discard it, or loop it (a special case of > forward). As ::1 represents loop, using :f or :d for discard would > suggest to me that :2 through :c or :e is reserved for some similar > purpose in the future, however I don't think there are any. So I'd > prefer ::2 to be used, because I don't think it implies reservation for > the future, and is adjacent to what is close to the semantic opposite > of discard. Personally I think you might be overthinking this bit, but reasonable minds can differ here. >>> and we use a /32 from the very end of our current >>> 2000::/3 range. That make both stand very out from all of our current >>> addresses. >> >> I agree that 3fff:ffff::/32 is a good idea for this purpose. 3ff* is >> more or less useless for general purposes anyway given the historical >> Teredo usage. >> >> I don't like the idea of using a prefix from a block outside 2000::/3, >> since we have been operating under the assumption that if we screw >> something up in this /3 that we can start over in one of the others. I'd >> hate to cripple that premise. >> > > The question is, if 2000::/3 becomes deprecated, does that imply > blackholing does too? I think it does, which is why I'd prefer the > space to be to be allocated from outside of it. IOW, it's address space > that represents a function (similar to ::1, fe80::/10, fc::/7 etc.), so > should be a functional allocation, rather than one from within the > global Internet address space (that may be changed in the future). Now I believe you're definitely overthinking it. If we screw up 2000::/3 so badly that we need to move on then we can define another range for blackholing if we need to. Let's only foul one sandbox at a time. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Jul 16 02:15:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4D221F85E3 for ; Sat, 16 Jul 2011 02:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.508 X-Spam-Level: X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb5QldVFeCZU for ; Sat, 16 Jul 2011 02:15:20 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id AA8CE21F85E1 for ; Sat, 16 Jul 2011 02:15:19 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qi0xr-0006Lw-7H; Sat, 16 Jul 2011 18:45:11 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 78E6B3B342; Sat, 16 Jul 2011 18:45:10 +0930 (CST) Date: Sat, 16 Jul 2011 18:45:09 +0930 From: Mark Smith To: Doug Barton Message-ID: <20110716184509.475340a7@opy.nosense.org> In-Reply-To: <4E211A60.1020601@dougbarton.us> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> <4E1FAFFF.7050506@dougbarton.us> <20110716032335.102b0503@opy.nosense.org> <4E211A60.1020601@dougbarton.us> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 09:15:20 -0000 On Fri, 15 Jul 2011 21:58:08 -0700 Doug Barton wrote: > On 07/15/2011 10:53, Mark Smith wrote: > > On Thu, 14 Jul 2011 20:11:59 -0700 > > Doug Barton wrote: > >=20 > >> On 07/09/2011 02:03, Roger J=C3=B8rgensen wrote: > >>> I suggest we use ::f > >> > Now I believe you're definitely overthinking it.=20 I don't think so. I'm consider the amount of additional operational work involved to change a discard address in parallel with a unicast prefix. There should be a tangible benefit from making operational changes, yet having to renumber a discard address would provide none. >If we screw up 2000::/3 > so badly that we need to move on then we can define another range for > blackholing if we need to. Replacing the global unicast address space should only involve replacing the global unicast address space. We've already moved from one global unicast address space to another (3ffe::/16 -> 2000::/3). Fortunately that didn't also involve renumbering ::1, fe80::/10, etc. because they were wisely chosen to be outside of 3ffe::/16 and 2000::/3.=20 > Let's only foul one sandbox at a time. >=20 >=20 Lets not create unnecessary work either. > Doug >=20 > --=20 >=20 > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go >=20 > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ >=20 From rogerj@gmail.com Sat Jul 16 02:40:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E42C21F8620 for ; Sat, 16 Jul 2011 02:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJHleQa73RW4 for ; Sat, 16 Jul 2011 02:40:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1AC21F861A for ; Sat, 16 Jul 2011 02:40:37 -0700 (PDT) Received: by wwe5 with SMTP id 5so1309183wwe.13 for ; Sat, 16 Jul 2011 02:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=l0Wx4rEyTw7VF/cFsPwjVuZl8n3+I7SRCqpCV8KQ6dk=; b=i4HP5Rhd12L3tfPjG5onp4DJ8MzBo6fAfekFa6xlsgLG9eKst9esuQMC7T/1mIC3vc DAgE3w8cHbuMO2dVprzhPfrFLkfrIQ6mFaFOHK5GYt54fprjSOuhZGkwsJxqmrCQV1GM OzEhT0i6GLCLfvzurdO0PeMnmosL7m65id6Ls= MIME-Version: 1.0 Received: by 10.227.42.34 with SMTP id q34mr2100931wbe.83.1310809236253; Sat, 16 Jul 2011 02:40:36 -0700 (PDT) Received: by 10.227.155.197 with HTTP; Sat, 16 Jul 2011 02:40:36 -0700 (PDT) In-Reply-To: <20110716184509.475340a7@opy.nosense.org> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> <4E1FAFFF.7050506@dougbarton.us> <20110716032335.102b0503@opy.nosense.org> <4E211A60.1020601@dougbarton.us> <20110716184509.475340a7@opy.nosense.org> Date: Sat, 16 Jul 2011 11:40:36 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Mark Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 09:40:38 -0000 On Sat, Jul 16, 2011 at 11:15 AM, Mark Smith wrote: > On Fri, 15 Jul 2011 21:58:08 -0700 > Doug Barton wrote: >> On 07/15/2011 10:53, Mark Smith wrote: >> > On Thu, 14 Jul 2011 20:11:59 -0700 >> > Doug Barton wrote: >> >> On 07/09/2011 02:03, Roger J=F8rgensen wrote: >> >>> I suggest we use ::f > >> Now I believe you're definitely overthinking it. >>If we screw up 2000::/3 >> so badly that we need to move on then we can define another range for >> blackholing if we need to. > > Replacing the global unicast address space should only involve > replacing the global unicast address space. > > We've already moved from one global unicast address space to > another (3ffe::/16 -> 2000::/3). Fortunately that didn't also involve > renumbering ::1, fe80::/10, etc. because they were wisely chosen to be > outside of 3ffe::/16 and 2000::/3. One way to think about it is something along these lines, if it is something very linked with 2000::/3 (policy or otherwise, eui-64 can be claimed to be so.....) then we should use that address space. If it linked with IPv6 more than an address range (this seems to be the case here) then we should use something outside our current IP range (2000::/3). And whenever we decide to try again and start using another range, 3000::/3 or so... guess when that time come we have other features that only affect that range and not 2000::/3 but the discard might be the same. --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From fred@cisco.com Sat Jul 16 10:38:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B94121F874E; Sat, 16 Jul 2011 10:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.375 X-Spam-Level: X-Spam-Status: No, score=-104.375 tagged_above=-999 required=5 tests=[AWL=-1.776, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0a8raq2w8mF; Sat, 16 Jul 2011 10:38:56 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AB82521F8726; Sat, 16 Jul 2011 10:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2712; q=dns/txt; s=iport; t=1310837937; x=1312047537; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=VkPSyHw9FzxlRz9YqZ/7CcrwQ1APEkUiZofALL+GoCA=; b=PWwQfPJznQjI0tjDUu5IO+de+WraAq0FEbP4I8rCtu069ZSnwhhOZJW1 aoc1AIn8GHmrxTFXmnYTZ87RKNbnm9FyNMWNoE+/eMKbVVw3pfKf2ThPG GFXI3RPyNfs8W4Glgk2t6AeZ7GPHACxB0snv38iburPw5qIVOGhq964qx s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGjMIU6rRDoH/2dsb2JhbABSp3V3iHyiWJ1DhV1fBIdUixKFAYt0 X-IronPort-AV: E=Sophos;i="4.67,214,1309737600"; d="scan'208";a="3602199" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 16 Jul 2011 17:38:55 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6GHcsaH030148; Sat, 16 Jul 2011 17:38:54 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Sat, 16 Jul 2011 10:38:54 -0700 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Sat, 16 Jul 2011 10:38:54 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 16 Jul 2011 10:38:45 -0700 Message-Id: <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, ipv6@ietf.org Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 17:38:57 -0000 On Jul 15, 2011, at 6:31 AM, RJ Atkinson wrote: > I apologise for being unclear. The document I was trying to propose = in the quoted text above was NOT about protocol changes, but instead = would focus on extant mitigations -- so the document I was proposing = would more obviously seem to fit in IPv6 Ops WG. Sounds reasonable to me. One general consideration in this note. In addition to the fact of = multiple prefixes on a LAN, IPv6 Privacy Addresses (RFC 4491) are a case = in which a single interface (and therefore MAC address) might = legitimately have multiple addresses within the same prefix. Unless I am = mistaken, Windows by default creates an address daily but keeps each = such address active for a week, so any case in which Windows would use = one IPv4 address, at any given time it will consider seven IPv6 = addresses to be active. In addition, virtual machines in data centers = amplify address use; one could imagine the address of a virtual machine = serving a single user or service to be the counterpart of a = locator+identifier in the sense that RFC 1992 uses the terms. So a part = of the advice to implementers is to expect a much larger number of = active addresses at any given time to be normal. There are of course ways to simplify that in implementation. In a = host/router's neighbor tables, it would make sense to keep a "used" = flag. At least for routers (which normally have most of the hosts in a = subnet as neighbors most of the time), it is common to periodically = ARP/ND each address unicast and cull the table if it fails to respond = (rather than simply timing the address out). One could modify that = slightly by setting a flag in the neighbor entry when a datagram is sent = to the address, and on the periodic sweep culling addresses that were = not used and refreshing addresses that have been used. There is also a place for LRU-style behavior. If the neighbor table is = finite in size, keep an LRU list, moving used and new entries to the = tail and simply overwriting entries from the front when needed. If there = is no hard bound on the neighbor table besides the size of memory, one = could imagine sweeping at a rate comparable to its size - every mumble = time units culling/refreshing a percentage of the table.=20 Where I worry is the concept of a hard limit on address count per MAC = address, due to the existence of virtual hosts. Speaking as a vendor of = the equipment we're concerned about here, I would rather provide an = option that enables the administrator to buy more memory if that's = what's needed than force him into a situation that might be suboptimal = for his network.=20= From fred@cisco.com Sat Jul 16 10:42:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4856421F869D; Sat, 16 Jul 2011 10:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.304 X-Spam-Level: X-Spam-Status: No, score=-104.304 tagged_above=-999 required=5 tests=[AWL=-1.705, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAJZo2+1idxh; Sat, 16 Jul 2011 10:42:04 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CA56621F867D; Sat, 16 Jul 2011 10:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=562; q=dns/txt; s=iport; t=1310838124; x=1312047724; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=qRYEiywIbn+Ijn38ZdtLkFVXcIginHYmJHR8J9vslFQ=; b=FRFaEZeClZUugOrQdsHEDzAt4yihDQWljvJ2RnuicezjJJG+xryn5+lM kcFnmXp1wVAKVLTjMvuEcCCCWIRsLCU5pDbMW4q0oFKtOlkyYFW9f2geN lJ+0wmrlNqUclf/hVfmC5SbAiSH5c9nxsvH+lkYSlcc6th2ZaBkZBWFOQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABDNIU6rRDoH/2dsb2JhbABSp3V3iHyiWJ1DhV1fBIdUixKFAYt0 X-IronPort-AV: E=Sophos;i="4.67,214,1309737600"; d="scan'208";a="3602996" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2011 17:42:04 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6GHg3hG031554; Sat, 16 Jul 2011 17:42:03 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Sat, 16 Jul 2011 10:42:03 -0700 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Sat, 16 Jul 2011 10:42:03 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 16 Jul 2011 10:41:55 -0700 Message-Id: References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, v6ops@ietf.org, RJ Atkinson Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 17:42:06 -0000 On Jul 15, 2011, at 10:35 AM, Philip Homburg wrote: > I could be wrong, but the impression I got from the various ops lists = is that > the way you deal with this attack is to avoid using RFC-4862 and/or = RFC-4861. I can imagine using DHCPv6 instead of SLAAC (RFC 4862 and the RS/RA = component of RFC 4861). The counterpart to ARP is the NS/NA component of = RFC 4861; I think you might find that helpful to keep. That said, I do think you may find SLAAC more scalable than DHCPv6 = address allocation. At least that's why it was developed.= From rbonica@juniper.net Sat Jul 16 13:12:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E8A21F881B; Sat, 16 Jul 2011 13:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaa3qAWzYMih; Sat, 16 Jul 2011 13:12:01 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE8D21F859E; Sat, 16 Jul 2011 13:11:42 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTiHwfpv1w6VyV6I8zrWYsDtPu0mDVHCI@postini.com; Sat, 16 Jul 2011 13:12:01 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 16 Jul 2011 13:03:57 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Sat, 16 Jul 2011 16:03:57 -0400 From: Ronald Bonica To: Joel Jaeggli , John C Klensin Date: Sat, 16 Jul 2011 16:03:55 -0400 Thread-Topic: Another look at 6to4 (and other IPv6 transition issues) Thread-Index: AcxDI90BTawX0D64SXGpYpjtR2s/SgAzLLkQ Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3DEEA84@EMBX01-WF.jnpr.net> References: <71D5A97D-7119-4082-BC87-6505370CE800@bogus.com> In-Reply-To: <71D5A97D-7119-4082-BC87-6505370CE800@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 20:12:02 -0000 Hi John, I think that most of the rancor around RFCs 3056 and 3068 is due to RFC 202= 6's very terse definition of HISTORIC. According to RFC 2026, "A specificat= ion that has been superseded by a more recent specification or is for any o= ther reason considered to be obsolete is assigned to the Historic level." T= hat's the entire definition. Anything more is read into it. Granted, the phrase "for any other reason considered to be obsolete" is pre= tty subjective. In this thread, I have seen people interpret that phrase as= follows: "the IETF thinks that there are no longer any valid use cases for this tech= nology" "the IETF recommends that you remove this technology from your network" "the IETF believes that nobody is using this technology" I doubt if any of these interpretations are valid, because the IETF is not = in a good position to evaluate what is in use or tell an operator how to ru= n a network. A more likely interpretation is as follows: "the IETF is not likely to invest effort in the technology in the future" "the IETF does not encourage (or discourage) new deployments of this techno= logy. Ron > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > Joel Jaeggli > Sent: Friday, July 15, 2011 3:17 PM > To: John C Klensin > Cc: v6ops@ietf.org; IETF Discussion > Subject: Re: Another look at 6to4 (and other IPv6 transition issues) >=20 >=20 > On Jul 15, 2011, at 11:52 AM, John C Klensin wrote: >=20 > > > > > > --On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli > > wrote: > > > >> So the rational for the advice document not being combined > >> with the standards action in it is that the later has some > >> polarizing impact, the advice document does not. the advice > >> document is through and done, historic is not. > > > > Joel (and others), > > > > I understand the rationale. At the risk of repeating myself, I > > simply do not think it works or is appropriate. >=20 > And there are people that disagree with you on that. >=20 > > Recategorizing > > set of documents as "Historic" is an extremely blunt instrument. > > If we do it in a consistent and logical fashion, the advice > > document would have to go to Historic along with the base > > documents because giving advice about a piece of ancient history > > is meaningless. That is not what most people who like the > > advice document intended, at least as I understood the consensus > > on that Last Call. >=20 > >=20 > > Finally, if we had a wonderful transition model that would work > > well in all situations, then it would make sense to recommend it > > and depreciate everything else. >=20 > You missed the boat about a decade back I guess. Transition > technologies (none of them) are a substitute for actual deployment. > They should naturally decline in popularity and in fact in the portions > of the internet where we can measure them they are. Right now if we try > and fit a story to the evidence that is happening because of host > changes, and not because of deployment. ipv4 is becoming less usable > and it's taking autotunnels with it, nobody here has a proposal that > changes that. >=20 > > We don't. What we have are a > > bunch of mechanisms, each with advantages and disadvantages, > > some much better adapted to particular situations than others. > > It would be easier if we had a good single solution, but we > > don't... that is life, or at least engineering. Given that, we > > serve the community much better with analyses and explanations > > of tradeoffs (and RFC 6180 is, IMO, a really good start) than we > > do by going through exercises of figuring out what to denounce. > > IMO, the _only_ thing we should be categorically denouncing are > > tactics and strategies that encourage people to put off getting > > serious about IPv6. Unfortunately, trying to slap a "Historic" > > label on one particular transition strategy, or to rank > > transition strategies that have proven useful to some actors on > > the basis of how much various of us loathe them, are about > > denunciation and, however unintentionally, with the risk of > > encouraging people to sit and wait, not about progress or > > network engineering. > > > > back to lurking... > > john > > > > >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From moore@network-heretics.com Sat Jul 16 13:49:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA55821F88A5; Sat, 16 Jul 2011 13:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0XgFrlGt16J; Sat, 16 Jul 2011 13:49:38 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id BA97321F88A1; Sat, 16 Jul 2011 13:49:38 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id E2917221E4; Sat, 16 Jul 2011 16:49:37 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Sat, 16 Jul 2011 16:49:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=NXIi8yN2nTwEbi1SeyNmVfET6sg=; b=VwQ+mBSYU/QeFJFAzZSZqrGi3xdrlQO0nDBiV0tiHi452sNB2gwlzIzy/EzdY/IQguGzWjBxnS5zE/o5Z1JPSXe8O/5WVYP3iaqL9LeTXuL+HqfznRQANGBTwsp7x4JvZTpVb44rUGqjCHZiq84RLZ7Ymw61heWFbYhJy8Mm++o= X-Sasl-enc: KoY5m9VTCqjEm4P5W04HLuAijN8T8C5sePl4FCSPCuOv 1310849377 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 804E8440898; Sat, 16 Jul 2011 16:49:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3DEEA84@EMBX01-WF.jnpr.net> Date: Sat, 16 Jul 2011 16:49:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4F5203D0-E4CC-4E52-A953-E90049032C2D@network-heretics.com> References: <71D5A97D-7119-4082-BC87-6505370CE800@bogus.com> <13205C286662DE4387D9AF3AC30EF456D3F3DEEA84@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1084) Cc: John C Klensin , "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 20:49:39 -0000 On Jul 16, 2011, at 4:03 PM, Ronald Bonica wrote: > Hi John, >=20 > I think that most of the rancor around RFCs 3056 and 3068 is due to = RFC 2026's very terse definition of HISTORIC. According to RFC 2026, "A = specification that has been superseded by a more recent specification or = is for any other reason considered to be obsolete is assigned to the = Historic level." That's the entire definition. Anything more is read = into it. >=20 > Granted, the phrase "for any other reason considered to be obsolete" = is pretty subjective. In this thread, I have seen people interpret that = phrase as follows: >=20 > "the IETF thinks that there are no longer any valid use cases for this = technology" > "the IETF recommends that you remove this technology from your = network" > "the IETF believes that nobody is using this technology" >=20 > I doubt if any of these interpretations are valid, because the IETF is = not in a good position to evaluate what is in use or tell an operator = how to run a network. A more likely interpretation is as follows: > "the IETF is not likely to invest effort in the technology in the = future" Such a determination seems premature. There are some ideas floating = around for protocol fixes to deal with some of the operational problems = associated with 6to4. It's too early to know whether there are = significant flaws with them or whether they can get traction. = Admittedly, v4 address space exhaustion along with the introduction of = LSN means that 6to4 has diminishing applicability. But for those nets = and hosts that still have access to the public IPv4 internet, it's = conceivable that the reliability of 6to4 can be considerably improved. = (Though of course it will never be as good as be as a well-run native v6 = service.) At some point, some evaluation of cost vs. benefit needs to = be made; and the "cost" of not fixing 6to4 needs to consider the = consequences of using other tunneled transition mechanisms besides 6to4. = =20 Put another way: Given that there are admittedly several operational = issues associated with 6to4, there are at least four strategies that = might be employed: 1. Encourage changes to the operational practices that are causing = problems that are associated with 6to4. 2. Discourage all use of 6to4 in the strongest possible terms. 3. Discourage use of 6to4 except in the cases where it is believed it = can work well. 4. Improve the 6to4 protocol to address some of the issues. IMO, -advisory tries to do #1; -historic tries to do #2; -experimental = tries to do #3. #4 is something I hope can be discussed, informally, in = Quebec. We should have a better idea after the meeting how workable = this is. Keith From john-ietf@jck.com Sat Jul 16 15:52:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7656321F89AC; Sat, 16 Jul 2011 15:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO+X4+-kfWPM; Sat, 16 Jul 2011 15:52:44 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0C521F89A7; Sat, 16 Jul 2011 15:52:43 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QiDix-000DjH-Sg; Sat, 16 Jul 2011 18:52:40 -0400 X-Vipre-Scanned: 0028B17B00262A0028B2C8-TDI Date: Sat, 16 Jul 2011 18:52:38 -0400 From: John C Klensin To: Ronald Bonica , Joel Jaeggli Message-ID: In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3DEEA84@EMBX01-WF.jnpr.net> References: <71D5A97D-7119-4082-BC87-6505370CE800@bogus.com> <13205C286662DE4387D9AF3AC30EF456D3F3DEEA84@EMBX01-WF.jnpr.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 22:52:45 -0000 --On Saturday, July 16, 2011 16:03 -0400 Ronald Bonica wrote: > Hi John, > > I think that most of the rancor around RFCs 3056 and 3068 is > due to RFC 2026's very terse definition of HISTORIC. According > to RFC 2026, "A specification that has been superseded by a > more recent specification or is for any other reason > considered to be obsolete is assigned to the Historic level." > That's the entire definition. Anything more is read into it. If you include a certain amount of oral tradition that predates and surrounds 2026 in "read into it", I agree. It may be worth remembering that 2026, like most similar documents, didn't invent anything but was intended to reflect a community consensus that existed about what should be done. Documents like 2026 never capture that consensus exactly or comprehensively. Whether that informal consensus means anything once we write something down is a question that we rarely ask ourselves, probably for good reason. > Granted, the phrase "for any other reason considered to be > obsolete" is pretty subjective. In this thread, I have seen > people interpret that phrase as follows: > > "the IETF thinks that there are no longer any valid use cases > for this technology" "the IETF recommends that you remove this > technology from your network" "the IETF believes that nobody > is using this technology" > I doubt if any of these interpretations are valid, because the > IETF is not in a good position to evaluate what is in use or > tell an operator how to run a network. I think the first interpretation can be valid although it must be used with great caution. For example, I think we might all agree that there are no remaining valid use cases for NCP, despite the fact that TCP/IP could be argued to have replaced it rather than precisely superceding it. Another, perhaps better, example is that Novell IPX is almost certainly dead ("proprietary protocol abandoned by its owner" is a pretty good predictor of "no valid use cases"). We wouldn't think using it for anything in a contemporary network would be useful even if, e.g., it has better scaling properties. Interestingly, while RFC 1234 and 1553 were were moved to Historic, we have one Full Standard (RFC 1123, STD 49), an Informational document (RFC 1634), a Proposed Standard (RFC 1420), and a some Experimental documents (RFC 1791, RFC 1792). That pretty much covers the whole range of possibilities. If I didn't have the view that housekeeping exercises that require community review and consensus were usually a poor use of resources (see other note today), getting this whole pack swept into Historic on the "no valid remaining use cases" principle would be entirely appropriate. One could still not prove that no one is using it: I have every reason to believe that someone out there is still running Netware and happy about it. > A more likely interpretation is as follows: > "the IETF is not likely to invest effort in the technology in > the future" "the IETF does not encourage (or discourage) new > deployments of this technology. Noting in passing that these sorts of statements are quite close to the uses 2026 prescribes for Applicability Statements (and for which we have even more precedent and oral tradition), if the first of those is an adequate reason for identifying something as historic, I recommend that we immediately move RFC 791 to Historic. Certainly we are likely to invest more effort in the development of the technology. Now, some people would read such a move as either an indication, as you suggest above, that the IETF thought no one was using it any more, or that there were no remaining valid use cases, etc., immediately turning us into a laughingstock. But, by logic that suggests moving 6to4 to Historic on the grounds that the IETF is not going to invest effort in the technology. So I think we disagree. best, john > > Ron > > >> -----Original Message----- >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On >> Behalf Of Joel Jaeggli >> Sent: Friday, July 15, 2011 3:17 PM >> To: John C Klensin >> Cc: v6ops@ietf.org; IETF Discussion >> Subject: Re: Another look at 6to4 (and other IPv6 transition >> issues) >> >> >> On Jul 15, 2011, at 11:52 AM, John C Klensin wrote: >> >> > >> > >> > --On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli >> > wrote: >> > >> >> So the rational for the advice document not being combined >> >> with the standards action in it is that the later has some >> >> polarizing impact, the advice document does not. the advice >> >> document is through and done, historic is not. >> > >> > Joel (and others), >> > >> > I understand the rationale. At the risk of repeating >> > myself, I simply do not think it works or is appropriate. >> >> And there are people that disagree with you on that. >> >> > Recategorizing >> > set of documents as "Historic" is an extremely blunt >> > instrument. If we do it in a consistent and logical >> > fashion, the advice document would have to go to Historic >> > along with the base documents because giving advice about a >> > piece of ancient history is meaningless. That is not what >> > most people who like the advice document intended, at least >> > as I understood the consensus on that Last Call. >> >> >> >> > Finally, if we had a wonderful transition model that would >> > work well in all situations, then it would make sense to >> > recommend it and depreciate everything else. >> >> You missed the boat about a decade back I guess. Transition >> technologies (none of them) are a substitute for actual >> deployment. They should naturally decline in popularity and >> in fact in the portions of the internet where we can measure >> them they are. Right now if we try and fit a story to the >> evidence that is happening because of host changes, and not >> because of deployment. ipv4 is becoming less usable and it's >> taking autotunnels with it, nobody here has a proposal that >> changes that. >> >> > We don't. What we have are a >> > bunch of mechanisms, each with advantages and disadvantages, >> > some much better adapted to particular situations than >> > others. It would be easier if we had a good single >> > solution, but we don't... that is life, or at least >> > engineering. Given that, we serve the community much >> > better with analyses and explanations of tradeoffs (and RFC >> > 6180 is, IMO, a really good start) than we do by going >> > through exercises of figuring out what to denounce. IMO, >> > the _only_ thing we should be categorically denouncing are >> > tactics and strategies that encourage people to put off >> > getting serious about IPv6. Unfortunately, trying to slap >> > a "Historic" label on one particular transition strategy, >> > or to rank transition strategies that have proven useful to >> > some actors on the basis of how much various of us loathe >> > them, are about denunciation and, however unintentionally, >> > with the risk of encouraging people to sit and wait, not >> > about progress or network engineering. >> > >> > back to lurking... >> > john >> > >> > >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Jul 16 18:55:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE3621F881B for ; Sat, 16 Jul 2011 18:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDWF+algG4mc for ; Sat, 16 Jul 2011 18:55:28 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id DA9B121F8829 for ; Sat, 16 Jul 2011 18:55:27 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QiGZo-0008Ay-Bv; Sun, 17 Jul 2011 11:25:24 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id A2B9C3B342; Sun, 17 Jul 2011 11:25:23 +0930 (CST) Date: Sun, 17 Jul 2011 11:25:22 +0930 From: Mark Smith To: Nick Hilliard Message-ID: <20110717112522.2c8e3b21@opy.nosense.org> In-Reply-To: <4E2164FF.9090001@inex.ie> References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> <4E1FAFFF.7050506@dougbarton.us> <20110716032335.102b0503@opy.nosense.org> <4E211A60.1020601@dougbarton.us> <20110716184509.475340a7@opy.nosense.org> <4E2164FF.9090001@inex.ie> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 01:55:28 -0000 On Sat, 16 Jul 2011 11:16:31 +0100 Nick Hilliard wrote: > On 16/07/2011 10:40, Roger J=C3=B8rgensen wrote: > > And whenever we decide to try again and start using another range, > > 3000::/3 or so... >=20 > nit: 2000::/3 is 2000:: to 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff >=20 > I am very pleased at the colours that everyone is suggesting for my > bikeshed. Very elegant, all of them - thank you. >=20 If you believe there are more substantive issues, why haven't you either already dealt with them in the ID, or started a topic of conversation about them here? As for who's bikeshed it is, it's all of ours if it becomes an RFC, not just yours. > Nick From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Jul 16 19:02:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFDB21F86C2; Sat, 16 Jul 2011 19:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.285 X-Spam-Level: X-Spam-Status: No, score=-1.285 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mbuE2-YHwv2; Sat, 16 Jul 2011 19:02:44 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33321F86C1; Sat, 16 Jul 2011 19:02:44 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QiGgo-0008KX-Hp; Sun, 17 Jul 2011 11:32:38 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 319473B342; Sun, 17 Jul 2011 11:32:38 +0930 (CST) Date: Sun, 17 Jul 2011 11:32:37 +0930 From: Mark Smith To: Fred Baker Message-ID: <20110717113237.0137abcd@opy.nosense.org> In-Reply-To: <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, v6ops@ietf.org, RJ Atkinson Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 02:02:45 -0000 On Sat, 16 Jul 2011 10:38:45 -0700 Fred Baker wrote: > > On Jul 15, 2011, at 6:31 AM, RJ Atkinson wrote: > > > I apologise for being unclear. The document I was trying to propose in the quoted text above was NOT about protocol changes, but instead would focus on extant mitigations -- so the document I was proposing would more obviously seem to fit in IPv6 Ops WG. > > Sounds reasonable to me. > > > Where I worry is the concept of a hard limit on address count per MAC address, due to the existence of virtual hosts. Speaking as a vendor of the equipment we're concerned about here, I would rather provide an option that enables the administrator to buy more memory if that's what's needed than force him into a situation that might be suboptimal for his network. The quite novel technique of allocation transient addresses to applications/processes to assist with firewalling also takes advantage of IPv6's large address space and that hosts can have multiple addresses at once. It'd be a shame to loose the opportunity to do that or similar innovative things with the large IPv6 address space - "Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host", Peter M. Gleitz and Steven M. Bellovin https://www.cs.columbia.edu/~smb/papers/tarp.pdf ___________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From msk@cloudmark.com Sat Jul 16 20:27:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7178B21F8663; Sat, 16 Jul 2011 20:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.916 X-Spam-Level: X-Spam-Status: No, score=-103.916 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxzzR37quLGZ; Sat, 16 Jul 2011 20:27:40 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0E84721F8661; Sat, 16 Jul 2011 20:27:40 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 16 Jul 2011 20:27:39 -0700 From: "Murray S. Kucherawy" To: John C Klensin , Brian E Carpenter Date: Sat, 16 Jul 2011 20:27:39 -0700 Thread-Topic: Another look at 6to4 (and other IPv6 transition issues) Thread-Index: AcxDMm0rkhKxPxQdSnShFXBOOYLS0wA/p8VQ Message-ID: References: <4E20A44E.3060203@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 03:27:40 -0000 > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of J= ohn C Klensin > Sent: Friday, July 15, 2011 2:02 PM > To: Brian E Carpenter > Cc: v6ops@ietf.org; IETF Discussion > Subject: Re: Another look at 6to4 (and other IPv6 transition issues) >=20 > Position #2: How the IETF classifies things makes very little > difference in this space because people will follow advice that > seems sensible and ignore everything else. If so, it makes > little difference how your document is approved or where it is > published. For example, it could have come through the > Independent Stream or been pushed into CCR. No problem. And > the "Historic" effort is a huge waste of the community's time, > no matter how it comes out. Well, if this is the prevailing opinion, we can certainly simplify our proc= edures substantially by eliminating about half of the document states we ma= intain now, including reducing the standards track down to a single state. From dougb@dougbarton.us Sat Jul 16 22:30:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F59521F85EC for ; Sat, 16 Jul 2011 22:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wZTzFgq4BJw for ; Sat, 16 Jul 2011 22:30:30 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0C65321F84E6 for ; Sat, 16 Jul 2011 22:30:29 -0700 (PDT) Received: (qmail 2483 invoked by uid 399); 17 Jul 2011 05:30:25 -0000 Received: from unknown (HELO 65-241-43-4.globalsuite.net) (dougb@dougbarton.us@65.241.43.4) by mail2.fluidhosting.com with ESMTPAM; 17 Jul 2011 05:30:25 -0000 X-Originating-IP: 65.241.43.4 X-Sender: dougb@dougbarton.us Message-ID: <4E22736E.8080709@dougbarton.us> Date: Sat, 16 Jul 2011 22:30:22 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110706 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Smith References: <201107051355.p65Dt0V18672@ftpeng-update.cisco.com> <20110706002619.39b94073@opy.nosense.org> <014D2174-2855-4BED-AE05-DB51C80D4A10@cisco.com> <4E14D0D6.9010709@inex.ie> <20110707105517.0bf3b556@opy.nosense.org> <4E1FAFFF.7050506@dougbarton.us> <20110716032335.102b0503@opy.nosense.org> <4E211A60.1020601@dougbarton.us> <20110716184509.475340a7@opy.nosense.org> In-Reply-To: <20110716184509.475340a7@opy.nosense.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 05:30:31 -0000 On 07/16/2011 02:15, Mark Smith wrote: > On Fri, 15 Jul 2011 21:58:08 -0700 > Doug Barton wrote: > >> On 07/15/2011 10:53, Mark Smith wrote: >>> On Thu, 14 Jul 2011 20:11:59 -0700 >>> Doug Barton wrote: >>> >>>> On 07/09/2011 02:03, Roger Jrgensen wrote: >>>>> I suggest we use ::f >>>> > >> Now I believe you're definitely overthinking it. > > I don't think so. I'm consider the amount of additional operational work > involved to change a discard address in parallel with a unicast > prefix. There should be a tangible benefit from making operational > changes, yet having to renumber a discard address would provide none. > >> If we screw up 2000::/3 >> so badly that we need to move on then we can define another range for >> blackholing if we need to. > > Replacing the global unicast address space should only involve > replacing the global unicast address space. Just to be clear, moving out of 2000::/3 would not be "replacing the GUA space." 4291 says (essentially) that everything except ff00::/8 is global unicast. The reason to move out of 2000::/3 would be that we realize we've made some fundamentally bad architectural decisions and need to hit reset. If that happens the ideal situation would be that we have the maximum number of alternatives, unhampered by placing a special-purpose prefix in an otherwise green field. > We've already moved from one global unicast address space to > another (3ffe::/16 -> 2000::/3). Um .... I'm not sure how to respond to that. The 6bone was purposely carved out of the last bit of 2000::/3 with the idea of abandoning it designed into the launch. But it's still one big, happy GUA family. > Fortunately that didn't also involve > renumbering ::1, fe80::/10, etc. because they were wisely chosen to be > outside of 3ffe::/16 and 2000::/3. Certainly ::1 was designed (I believe wisely) never to change. Personally (and I mean no offense by this) I've always been the tiniest bit dubious about the use of the f* special purpose prefixes, but I don't think at this point we have any reason to believe that harm will come from it. :) But let's review your scenario for a minute. Let's say that a discard network is desirable (I'm not convinced on that point yet, but I'm willing to be). Let's say further that we follow Roger's suggestion and use the last /32 in 2000::/3 (3fff:ffff::/32, which I've already said I think is a great idea since the 6bone and old-Teredo prefixes have pretty much rendered 3ff* useless for general purposes). Now disaster strikes and we need to start all over again by moving out of 2000::/3. In this scenario the discard network will be in the old /3, so it will be then what you're suggesting that we do now (the special-purpose prefix will be outside the shiny new network). Also, assuming that we do have to move out of 2000::/3, I don't see that it's a foregone conclusion that we would have to assign a new discard network in any case. If you do, perhaps you could explain your reasoning? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From pch-b2B3A6689@u-1.phicoh.com Sun Jul 17 01:54:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE81121F8634; Sun, 17 Jul 2011 01:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kF+QGQBKFcr; Sun, 17 Jul 2011 01:54:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 5008121F862F; Sun, 17 Jul 2011 01:54:35 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QiN79-0001jMC; Sun, 17 Jul 2011 10:54:15 +0200 Message-Id: To: Mark Smith From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> In-reply-to: Your message of "Sun, 17 Jul 2011 11:32:37 +0930 ." <20110717113237.0137abcd@opy.nosense.org> Date: Sun, 17 Jul 2011 10:53:53 +0200 Cc: RJ Atkinson , v6ops@ietf.org, ipv6@ietf.org Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 08:54:38 -0000 In your letter dated Sun, 17 Jul 2011 11:32:37 +0930 you wrote: >The quite novel technique of allocation transient addresses to >applications/processes to assist with firewalling also takes advantage >of IPv6's large address space and that hosts can have multiple >addresses at once. It'd be a shame to loose the opportunity to do that >or similar innovative things with the large IPv6 address space - A more scalable approach is to simply route a /96 to the host. There paper already suggests that: "If necessary in a given environment, this could be faked by hav- "ing a host pretend to be a stub router; however, this would require "the host to participate in routing protocols, which is generally "considered to be a bad idea. A better solution would be to extend "NDP to handle host address prefix lengths. I guess the authors didn't know about DHCPv6 prefix delegation. I think the same applies to hosts with lots of VMs: maintaining a potentially large number of NC entries for a single MAC address is unlikely to scale. This is what routing is designed for. From sander@steffann.nl Sun Jul 17 04:59:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF8321F86AE; Sun, 17 Jul 2011 04:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOKtNoz6waYC; Sun, 17 Jul 2011 04:59:10 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id F3FD621F862F; Sun, 17 Jul 2011 04:59:09 -0700 (PDT) Received: from macpro.10ww.steffann.nl (unknown [IPv6:2001:610:6ce:1:224:36ff:feef:1d89]) by mail.sintact.nl (Postfix) with ESMTP id C66BD2002; Sun, 17 Jul 2011 13:54:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: Date: Sun, 17 Jul 2011 13:54:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , ipv6@ietf.org Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 11:59:11 -0000 Hi, > I think the same applies to hosts with lots of VMs: maintaining a = potentially > large number of NC entries for a single MAC address is unlikely to = scale. > This is what routing is designed for. Then why are there 64 bits in the IID? And I don't think it has anything = to do with the MAC address. 1000 IPv6 addresses on 10 MAC addresses = scales as well as 1000 IPv6 addresses on 1000 MAC addresses. It might = make a difference for the switch, but not for ND/NC. - Sander PS: I consider having the possibility of having a large amount of IPv6 = addresses on one interface a great feature, not something I would want = to limit. From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jul 17 05:23:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FA921F85CB; Sun, 17 Jul 2011 05:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9wkJBk8qlnX; Sun, 17 Jul 2011 05:23:29 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id E2D4C21F85B8; Sun, 17 Jul 2011 05:23:28 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QiQNW-00061G-7q; Sun, 17 Jul 2011 21:53:22 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 88A153B346; Sun, 17 Jul 2011 21:53:21 +0930 (CST) Date: Sun, 17 Jul 2011 21:53:20 +0930 From: Mark Smith To: Sander Steffann Message-ID: <20110717215320.73e71245@opy.nosense.org> In-Reply-To: References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , ipv6@ietf.org Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 12:23:29 -0000 On Sun, 17 Jul 2011 13:54:06 +0200 Sander Steffann wrote: > Hi, > > > I think the same applies to hosts with lots of VMs: maintaining a potentially > > large number of NC entries for a single MAC address is unlikely to scale. > > This is what routing is designed for. > > Then why are there 64 bits in the IID? And I don't think it has anything to do with the MAC address. 1000 IPv6 addresses on 10 MAC addresses scales as well as 1000 IPv6 addresses on 1000 MAC addresses. It might make a difference for the switch, but not for ND/NC. > As people have observed, this is also a problem with IPv4 and ARP with a large enough subnet, so it isn't unique to IPv6, it's just that the size of IPv6 subnets is large and therefore it becomes more of an issue. I think the ultimate root cause is that the creation of neighbor cache entries is triggered by data plane traffic, rather than created by a control plane protocol i.e. a neighbor registration protocol. I think that means that what ever mitigations are put in place, they'll likely always be fundamentally vulnerable to data plane traffic attacks. If changing the way ND NS/NAs work is an option, then it might be better to adopt or use as a model the 6lowpan neighbor registration protocols, or perhaps review the ES-IS protocol as a model. That is obviously a large and wholesale change, however I think it would be the only way to truly eliminate any data plane traffic attacks on neighbor resolution. > - Sander > PS: I consider having the possibility of having a large amount of IPv6 addresses on one interface a great feature, not something I would want to limit. > Regards, Mark. From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jul 17 06:18:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C8621F862F; Sun, 17 Jul 2011 06:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTASfi42E9Ki; Sun, 17 Jul 2011 06:18:43 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD1A21F861E; Sun, 17 Jul 2011 06:18:43 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QiRF3-0007Cw-3U; Sun, 17 Jul 2011 22:48:41 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 7BD853B346; Sun, 17 Jul 2011 22:48:40 +0930 (CST) Date: Sun, 17 Jul 2011 22:48:40 +0930 From: Mark Smith To: Mark Smith Message-ID: <20110717224840.574ab41f@opy.nosense.org> In-Reply-To: <20110717215320.73e71245@opy.nosense.org> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, IPv6 Operations Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 13:18:44 -0000 On Sun, 17 Jul 2011 21:53:20 +0930 Mark Smith wrote: > On Sun, 17 Jul 2011 13:54:06 +0200 > Sander Steffann wrote: > > > Hi, > > > > > I think the same applies to hosts with lots of VMs: maintaining a potentially > > > large number of NC entries for a single MAC address is unlikely to scale. > > > This is what routing is designed for. > > > > Then why are there 64 bits in the IID? And I don't think it has anything to do with the MAC address. 1000 IPv6 addresses on 10 MAC addresses scales as well as 1000 IPv6 addresses on 1000 MAC addresses. It might make a difference for the switch, but not for ND/NC. > > > > As people have observed, this is also a problem with IPv4 and ARP with > a large enough subnet, so it isn't unique to IPv6, it's just that the > size of IPv6 subnets is large and therefore it becomes more of an issue. > > I think the ultimate root cause is that the creation of neighbor cache > entries is triggered by data plane traffic, rather than created by a > control plane protocol i.e. a neighbor registration protocol. I think > that means that what ever mitigations are put in place, they'll likely > always be fundamentally vulnerable to data plane traffic attacks. > > If changing the way ND NS/NAs work is an option, then it might be > better to adopt or use as a model the 6lowpan neighbor registration > protocols, or perhaps review the ES-IS protocol as a model. That is > obviously a large and wholesale change, however I think it would be the > only way to truly eliminate any data plane traffic attacks on neighbor > resolution. > Actually, that level of change might not be that necessary. If the destination address for the Duplicate Address Detection probes was changed to the all-nodes rather than the solicited nodes multicast address, then all receving nodes could immediately create a neighbor cache entry for the new device if one doesn't already exist. From that point on, Neighbor Unreachability Detection would then take care of maintaining the neighbor cache entry, and deleting it if the host disappears. > > - Sander > > PS: I consider having the possibility of having a large amount of IPv6 addresses on one interface a great feature, not something I would want to limit. > > > > Regards, > Mark. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From pch-b2B3A6689@u-1.phicoh.com Sun Jul 17 06:35:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973BA21F8620; Sun, 17 Jul 2011 06:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.039 X-Spam-Level: X-Spam-Status: No, score=-8.039 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7Dgof6j7ffj; Sun, 17 Jul 2011 06:35:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id C682521F8565; Sun, 17 Jul 2011 06:35:09 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QiRUo-0001h5C; Sun, 17 Jul 2011 15:34:58 +0200 Message-Id: To: Mark Smith From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> In-reply-to: Your message of "Sun, 17 Jul 2011 21:53:20 +0930 ." <20110717215320.73e71245@opy.nosense.org> Date: Sun, 17 Jul 2011 15:34:38 +0200 Cc: ipv6@ietf.org, IPv6 Operations Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 13:35:10 -0000 In your letter dated Sun, 17 Jul 2011 21:53:20 +0930 you wrote: >I think the ultimate root cause is that the creation of neighbor cache >entries is triggered by data plane traffic, rather than created by a >control plane protocol i.e. a neighbor registration protocol. I think >that means that what ever mitigations are put in place, they'll likely >always be fundamentally vulnerable to data plane traffic attacks. I don't think that is true. But that is for later. >If changing the way ND NS/NAs work is an option, then it might be >better to adopt or use as a model the 6lowpan neighbor registration >protocols, or perhaps review the ES-IS protocol as a model. That is >obviously a large and wholesale change, however I think it would be the >only way to truly eliminate any data plane traffic attacks on neighbor >resolution. I think we should just put the various design options on the table. See how they work, how many changes they require etc. But before that, the question now on the table is whether v6ops wants to spend more time figuring out what can be done with the current standards and/or what guidance they can give for new options. From pch-b2B3A6689@u-1.phicoh.com Sun Jul 17 06:37:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D2521F8557; Sun, 17 Jul 2011 06:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.332 X-Spam-Level: X-Spam-Status: No, score=-8.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tt9suM-KPHMO; Sun, 17 Jul 2011 06:37:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0097C21F8551; Sun, 17 Jul 2011 06:37:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QiRWn-0001i7C; Sun, 17 Jul 2011 15:37:01 +0200 Message-Id: To: Mark Smith From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> In-reply-to: Your message of "Sun, 17 Jul 2011 22:48:40 +0930 ." <20110717224840.574ab41f@opy.nosense.org> Date: Sun, 17 Jul 2011 15:37:00 +0200 Cc: ipv6@ietf.org, IPv6 Operations Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 13:37:10 -0000 In your letter dated Sun, 17 Jul 2011 22:48:40 +0930 you wrote: >Actually, that level of change might not be that necessary. If the >destination address for the Duplicate Address Detection probes was >changed to the all-nodes rather than the solicited nodes multicast >address, then all receving nodes could immediately create a neighbor >cache entry for the new device if one doesn't already exist. From that >point on, Neighbor Unreachability Detection would then take care of >maintaining the neighbor cache entry, and deleting it if the host >disappears. And then a router reboots. How does it find out about all the nodes already there? From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jul 17 07:11:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A9421F8505; Sun, 17 Jul 2011 07:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=1.261, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsmGQbnfLQV7; Sun, 17 Jul 2011 07:11:13 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2071221F8550; Sun, 17 Jul 2011 07:11:11 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QiS3m-0008Du-Ah; Sun, 17 Jul 2011 23:41:06 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id E157F3B346; Sun, 17 Jul 2011 23:41:05 +0930 (CST) Date: Sun, 17 Jul 2011 23:41:05 +0930 From: Mark Smith To: Philip Homburg Message-ID: <20110717234105.04069322@opy.nosense.org> In-Reply-To: References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, IPv6 Operations Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 14:11:13 -0000 On Sun, 17 Jul 2011 15:37:00 +0200 Philip Homburg wrote: > In your letter dated Sun, 17 Jul 2011 22:48:40 +0930 you wrote: > >Actually, that level of change might not be that necessary. If the > >destination address for the Duplicate Address Detection probes was > >changed to the all-nodes rather than the solicited nodes multicast > >address, then all receving nodes could immediately create a neighbor > >cache entry for the new device if one doesn't already exist. From that > >point on, Neighbor Unreachability Detection would then take care of > >maintaining the neighbor cache entry, and deleting it if the host > >disappears. > > And then a router reboots. How does it find out about all the nodes already > there? > Good point, there would need to be a message to solicit addresses. An NS to the all nodes address with an unspecified (::) target address perhaps. So perhaps the changes required would be mostly limited to - - DADs to all-nodes rather than solicited node addresses - nodes receiving the DAD use that to create a neighbor cache entry - NUD takes care of maintaining the validity of those entries - ND NS to all nodes with an unspecified target address solicits NAs from all nodes to cover the router (or any device) reboot situation Anycast addresses would be an issue because DAD isn't performed by them. Perhaps a special "DAD" could be performed for them which causes the receiving devices to record their presence, but a normal NS/NA transaction for the anycast address is triggered if the anycast address is attempted to be used and hasn't been fully resolved. From pch-b2B3A6689@u-1.phicoh.com Sun Jul 17 07:57:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0BD21F874B; Sun, 17 Jul 2011 07:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.518 X-Spam-Level: X-Spam-Status: No, score=-8.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inuKdcx04I3q; Sun, 17 Jul 2011 07:57:30 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 07CB621F869C; Sun, 17 Jul 2011 07:57:30 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QiSmU-0001iBC; Sun, 17 Jul 2011 16:57:18 +0200 Message-Id: To: Mark Smith From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> In-reply-to: Your message of "Sun, 17 Jul 2011 23:41:05 +0930 ." <20110717234105.04069322@opy.nosense.org> Date: Sun, 17 Jul 2011 16:57:06 +0200 Cc: ipv6@ietf.org, IPv6 Operations Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 14:57:31 -0000 [I dropped v6ops] In your letter dated Sun, 17 Jul 2011 23:41:05 +0930 you wrote: >Good point, there would need to be a message to solicit addresses. An >NS to the all nodes address with an unspecified (::) target address >perhaps. > >So perhaps the changes required would be mostly limited to - > >- DADs to all-nodes rather than solicited node addresses >- nodes receiving the DAD use that to create a neighbor cache entry >- NUD takes care of maintaining the validity of those entries >- ND NS to all nodes with an unspecified target address solicits NAs > from all nodes to cover the router (or any device) reboot situation So my proposal would be to add an option to RA. This option specifies a time over which nodes should distrubute updating the router (random number between zero and the timeout). At the selected time, the node then starts NUD on the router. Note that it has to do that for all of its addresses. Which is not part of ND at the moment. This should be enough. When a node boots it sends an RS. When a node adds a new address (not triggered by an RA) it may need to go over its list of routers and update them. Routers can always add the option to their RAs. But an alternative is to do that only when they become overloaded. From huitema@microsoft.com Sun Jul 17 09:09:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C98C21F84E3; Sun, 17 Jul 2011 09:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.774 X-Spam-Level: X-Spam-Status: No, score=-10.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWj2cfErGGR4; Sun, 17 Jul 2011 09:09:33 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id DDF0821F84EF; Sun, 17 Jul 2011 09:09:31 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 17 Jul 2011 09:09:31 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.323.2; Sun, 17 Jul 2011 09:09:31 -0700 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.52]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Sun, 17 Jul 2011 09:09:30 -0700 From: Christian Huitema To: Philip Homburg , Mark Smith Thread-Topic: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Thread-Index: AQHMRJHLOaNFypP8jkSb4kdkNNCU2pTwpJNw Date: Sun, 17 Jul 2011 16:09:29 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 16:09:33 -0000 >So perhaps the changes required would be mostly limited to - > >- DADs to all-nodes rather than solicited node addresses >- nodes receiving the DAD use that to create a neighbor cache entry >- NUD takes care of maintaining the validity of those entries >- ND NS to all nodes with an unspecified target address solicits NAs > from all nodes to cover the router (or any device) reboot situation I am not sure this addresses the problem too well. The DOS issue manifests = itself at the gateway, and the main issue is the remote DOS: attacker sends= packets to a very large number of putative IPv6 addresses in the subnet ma= naged by the local gateway, causing the size of the neighbor cache to explo= de. If we want to protect the cache in the gateway, let's do that. The solu= tion has to be a tweak in the implementation of ND in the gateway, along th= e lines of: - Upon arrival of a packet from the local network: - If the source address is already in ND cache, keep it there - if the source address is not already in the ND cache: Perform some quota check on the source MAC address, If the quota is exceeded, drop the packet to protect against local DOS If the quota is not exceeded, perform ND for the source address - Upon arrival of a packet bound to the local subnet - If the destination address is already in ND cache, route the packet; - If the destination address is not in ND cache: If the table is "too full," drop the packet Else, perform ND The basic idea is that remote parties should only be sending to addresses t= hat have already been discovered in the local subnet. This is, in a way, a = weak form of stateful filtering. It needs to be implemented softly, because= routers/gateways sometime lose their memory, so we want to allow for some = dynamic learning if the tables are not already populated. The proposed tweaks amount to making ND learn faster. They are fine in gene= ral, but they have the side effect of making local DOS easier. A local atta= cker could generate a large number of addresses, etc. -- Christian Huitema From moore@network-heretics.com Sun Jul 17 09:49:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA0E21F8572; Sun, 17 Jul 2011 09:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asOVBGvymxFi; Sun, 17 Jul 2011 09:49:18 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id B62F821F8571; Sun, 17 Jul 2011 09:49:18 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 4AE8220B59; Sun, 17 Jul 2011 12:49:18 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 17 Jul 2011 12:49:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=+shK3DVam7QeuXt48s1v9+z4u+w=; b=GyxajoIuzazOEjbWPR9ithgZOIp6ueECtZJvp/TETD1LonP92ymNUY8NJY9/Dbgyv63FNuFBm39Rbjr5+qyTCv1wtz4fHOQMDSnVIU+ZFnKH8BFk+fR+o/fRlrCwUHU+1qpB4iJrBdvAhpDx8aEnJQFpfyZiY7zBU6Tvewjh1hw= X-Sasl-enc: aL1Le2Bf6TDFXl62x2aJKl+yD6qrs/bxH1gAVR0N7mvX 1310921357 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id C3D574416E8; Sun, 17 Jul 2011 12:49:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Date: Sun, 17 Jul 2011 12:49:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <53A6850D-5B2F-458D-AE35-53AF978AC630@network-heretics.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> To: Christian Huitema X-Mailer: Apple Mail (2.1084) Cc: Philip Homburg , IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 16:49:19 -0000 On Jul 17, 2011, at 12:09 PM, Christian Huitema wrote: >> So perhaps the changes required would be mostly limited to - >>=20 >> - DADs to all-nodes rather than solicited node addresses >> - nodes receiving the DAD use that to create a neighbor cache entry >> - NUD takes care of maintaining the validity of those entries >> - ND NS to all nodes with an unspecified target address solicits NAs >> from all nodes to cover the router (or any device) reboot situation >=20 > I am not sure this addresses the problem too well. The DOS issue = manifests itself at the gateway, and the main issue is the remote DOS: = attacker sends packets to a very large number of putative IPv6 addresses = in the subnet managed by the local gateway, causing the size of the = neighbor cache to explode. If we want to protect the cache in the = gateway, let's do that. The solution has to be a tweak in the = implementation of ND in the gateway, along the lines of: >=20 > - Upon arrival of a packet from the local network: > - If the source address is already in ND cache, keep it there > - if the source address is not already in the ND cache: > Perform some quota check on the source MAC address, > If the quota is exceeded, drop the packet to protect against = local DOS > If the quota is not exceeded, perform ND for the source address >=20 > - Upon arrival of a packet bound to the local subnet > - If the destination address is already in ND cache, route the packet; > - If the destination address is not in ND cache: > If the table is "too full," drop the packet > Else, perform ND >=20 > The basic idea is that remote parties should only be sending to = addresses that have already been discovered in the local subnet. This = is, in a way, a weak form of stateful filtering. It needs to be = implemented softly, because routers/gateways sometime lose their memory, = so we want to allow for some dynamic learning if the tables are not = already populated. >=20 > The proposed tweaks amount to making ND learn faster. They are fine in = general, but they have the side effect of making local DOS easier. A = local attacker could generate a large number of addresses, etc. As a defense against remote attack, I'm thinking that routers should = limit the percentage of their ND caches that are associated with = nonexistent hosts. I suspect there are circumstances when it makes = sense to have "passive" hosts, perhaps even large numbers of them, which = the local router isn't aware of until traffic from outside arrives for = them. =20 It might also make sense to rate-limit ND messages sent as a result of = inbound traffic - if this rate of such ND messages exceeds a certain = threshold, drop incoming packets for hosts not in the ND cache at = random. Regarding local attack, I doubt that the right thing to do is for = routers to give preference to addresses already in the ND cache. It = seems like that would just invite DoS attack, by having the attacking = host flood the router's ND cache at regular intervals (especially if the = ND cache entry timeout were a constant). A better idea might be for = routers to give preference to addresses that are actually being used to = exchange traffic. That might mean associating a count or timestamp with = each ND cache entry. (which admittedly can introduce its own set of = issues under certain conditions). And I wonder whether ND cache entries should have a "half-life" rather = than a strict timeout. That still leaves the possibility of an attack where a local host = generates large numbers of addresses, and actually uses each of them to = exchange traffic with a remote host. As long as hosts can easily and = quickly change their interfaces' MAC addresses, I don't see an easy way = to deal with that.... though perhaps platforms could rate-limit the = ability of applications to do that. Keith From sander@steffann.nl Sun Jul 17 11:46:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C42E21F856D; Sun, 17 Jul 2011 11:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjx+q9j5e5mx; Sun, 17 Jul 2011 11:46:57 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id AE0A421F8565; Sun, 17 Jul 2011 11:46:57 -0700 (PDT) Received: from macpro.10ww.steffann.nl (unknown [IPv6:2001:610:6ce:1:224:36ff:feef:1d89]) by mail.sintact.nl (Postfix) with ESMTP id 583712004; Sun, 17 Jul 2011 20:41:55 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: <53A6850D-5B2F-458D-AE35-53AF978AC630@network-heretics.com> Date: Sun, 17 Jul 2011 20:41:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <22D9631E-38CE-4B74-91E0-C352DE3A8768@steffann.nl> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <53A6850D-5B2F-458D-AE35-53AF978AC630@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) Cc: Christian Huitema , IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 18:46:58 -0000 Hi, > As a defense against remote attack, I'm thinking that routers should = limit the percentage of their ND caches that are associated with = nonexistent hosts. I suspect there are circumstances when it makes = sense to have "passive" hosts, perhaps even large numbers of them, which = the local router isn't aware of until traffic from outside arrives for = them. =20 >=20 > It might also make sense to rate-limit ND messages sent as a result of = inbound traffic - if this rate of such ND messages exceeds a certain = threshold, drop incoming packets for hosts not in the ND cache at = random. It might be a good idea to increase the timers on the hosts that are in = the cache, or to start refreshing those cache entries actively before = they run out. In such a situation we might want to keep the pool of = verified existing hosts as large as possible to keep the dropping of = good packets to a minimum. Sander From dr@cluenet.de Sun Jul 17 11:56:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D8B21F84D5; Sun, 17 Jul 2011 11:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7e9Pb3lhJFT; Sun, 17 Jul 2011 11:56:21 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id C0C6921F84D4; Sun, 17 Jul 2011 11:56:20 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 1DA00108094; Sun, 17 Jul 2011 20:56:19 +0200 (CEST) Date: Sun, 17 Jul 2011 20:56:19 +0200 From: Daniel Roesen To: v6ops@ietf.org, "ipv6@ietf.org" Message-ID: <20110717185619.GA29575@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, "ipv6@ietf.org" References: <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 18:56:21 -0000 On Sun, Jul 17, 2011 at 04:09:29PM +0000, Christian Huitema wrote: > The basic idea is that remote parties should only be sending to > addresses that have already been discovered in the local subnet. Breaks with any VRRP setup. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From v6ops@globis.net Sun Jul 17 12:00:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1124B21F86BC; Sun, 17 Jul 2011 12:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12sj79fX93bA; Sun, 17 Jul 2011 12:00:44 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id E5A7B21F86C4; Sun, 17 Jul 2011 12:00:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BB6EC87004E; Sun, 17 Jul 2011 21:00:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F39jp6GCTD3M; Sun, 17 Jul 2011 21:00:13 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 6FFF08700DE; Sun, 17 Jul 2011 21:00:13 +0200 (CEST) Message-ID: <4E23313D.4040906@globis.net> Date: Sun, 17 Jul 2011 21:00:13 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: ipv6@ietf.org, IPv6 Operations Content-Type: multipart/alternative; boundary="------------010509050804070209080500" Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 19:00:45 -0000 This is a multi-part message in MIME format. --------------010509050804070209080500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > Subject: > Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? > From: > Philip Homburg > Date: > Sun, 17 Jul 2011 15:37:00 +0200 > > To: > Mark Smith > CC: > ipv6@ietf.org, IPv6 Operations > > Precedence: > list > References: > > <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> > > <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> > <20110717113237.0137abcd@opy.nosense.org> > > > <20110717215320.73e71245@opy.nosense.org> > <20110717224840.574ab41f@opy.nosense.org> > In-Reply-To: > Your message of "Sun, 17 Jul 2011 22:48:40 +0930 ." > <20110717224840.574ab41f@opy.nosense.org> > Message-ID: > > Message: > 8 > > > In your letter dated Sun, 17 Jul 2011 22:48:40 +0930 you wrote: > >> >Actually, that level of change might not be that necessary. If the >> >destination address for the Duplicate Address Detection probes was >> >changed to the all-nodes rather than the solicited nodes multicast >> >address, then all receving nodes could immediately create a neighbor >> >cache entry for the new device if one doesn't already exist. From that >> >point on, Neighbor Unreachability Detection would then take care of >> >maintaining the neighbor cache entry, and deleting it if the host >> >disappears. >> > > And then a router reboots. How does it find out about all the nodes already > there? > > > It's not just a router rebooting that's a problem: a temporarily split-brain L2 link (think spanning tree thrashing at the time when a node registers) could cause the same problem. There has to be some time related or event related (or both) trigger to refresh (not just when a L3 event like a node restart or interface up/down occurs). Something has to give IMVHO, because AFAIK all of the current mitigation measures all rely on scarcity of either attacker or target addresses, which just isn't reality assuming mass-deployment of SLAAC. How can you effectively (rate) filter if you can't tell good from bad? I agree with Philip that there should be a number of options put on the table, and the various trade offs examined. The conclusion might be that there needs to be various forms of ND, that are media dependent. Or small tweaks might help. Or it might be that the current compromise really is the best achievable. But let's see. regards, RayH --------------010509050804070209080500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Subject:
Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ?
From:
Philip Homburg <pch-v6ops@u-1.phicoh.com>
Date:
Sun, 17 Jul 2011 15:37:00 +0200
To:
Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
CC:
ipv6@ietf.org, IPv6 Operations <v6ops@ietf.org>
Precedence:
list
References:
<D4F95C5E-20A3-4B1E-8211-07B7831F3E89@gmail.com> <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <E3161138-0CAA-44E8-A329-E71408D0AE61@gmail.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <m1QiN79-0001jMC@stereo.hq.phicoh.net> <A1924BC2-B42D-4A06-8122-ABFF325E1CF4@steffann.nl> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org>
In-Reply-To:
Your message of "Sun, 17 Jul 2011 22:48:40 +0930 ." <20110717224840.574ab41f@opy.nosense.org>
Message-ID:
<m1QiRWn-0001i7C@stereo.hq.phicoh.net>
Message:
8		 

In your letter dated Sun, 17 Jul 2011 22:48:40 +0930 you wrote:
  
>Actually, that level of change might not be that necessary. If the
>destination address for the Duplicate Address Detection probes was
>changed to the all-nodes rather than the solicited nodes multicast
>address, then all receving nodes could immediately create a neighbor
>cache entry for the new device if one doesn't already exist. From that
>point on, Neighbor Unreachability Detection would then take care of
>maintaining the neighbor cache entry, and deleting it if the host
>disappears. 
    

And then a router reboots. How does it find out about all the nodes already
there?
It's not just a router rebooting that's a problem: a temporarily split-brain L2 link (think spanning tree thrashing at the time when a node registers) could cause the same problem. There has to be some time related or event related (or both) trigger to refresh (not just when a L3 event like a node restart or interface up/down occurs).

Something has to give IMVHO, because AFAIK all of the current mitigation measures all rely on scarcity of either attacker or target addresses, which just isn't reality assuming mass-deployment of SLAAC.

How can you effectively (rate) filter if you can't tell good from bad?

I agree with Philip that there should be a number of options put on the table, and the various trade offs examined.

The conclusion might be that there needs to be various forms of ND, that are media dependent. Or small tweaks might help.
Or it might be that the current compromise really is the best achievable. But let's see.

regards,
RayH
--------------010509050804070209080500-- From huitema@microsoft.com Sun Jul 17 13:14:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F38721F86AC; Sun, 17 Jul 2011 13:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.739 X-Spam-Level: X-Spam-Status: No, score=-10.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v00Aa24md0E8; Sun, 17 Jul 2011 13:14:58 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id A314221F86A2; Sun, 17 Jul 2011 13:14:58 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 17 Jul 2011 13:14:57 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.323.2; Sun, 17 Jul 2011 13:14:58 -0700 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.52]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Sun, 17 Jul 2011 13:14:57 -0700 From: Christian Huitema To: Daniel Roesen , "v6ops@ietf.org" , "ipv6@ietf.org" Thread-Topic: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? Thread-Index: AQHMRLqgDrnSMVwba0mziuhfQBJqRJTw8AMA Date: Sun, 17 Jul 2011 20:14:56 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F1BC20B@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <20110717185619.GA29575@srv03.cluenet.de> In-Reply-To: <20110717185619.GA29575@srv03.cluenet.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 20:14:59 -0000 > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of D= aniel Roesen > On Sun, Jul 17, 2011 at 04:09:29PM +0000, Christian Huitema wrote: >> The basic idea is that remote parties should only be sending to=20 >> addresses that have already been discovered in the local subnet. > > Breaks with any VRRP setup. VRPP is probably a special case of a router losing its memory...=20 In any case, as Ray Hunter noted, you need to somehow "tell good from bad" = if you want to filter effectively. My suggestion is that an address from wh= ich traffic has been sourced locally is more likely to be "good" than an ad= dress that appears for the first time in a packet coming from afar. This is= effectively the property used by most stateful firewalls, so there is some= operational experience with that.=20 There are indeed a few issues, e.g. the local server who expects remote TCP= connections but remains otherwise silent, or the router that was just rebo= oted, or swapped in, and has no idea about the current working set. The sol= ution to the server issue has to be some kind of keep-alive, e.g. with ND. = The solution to the "router with no memory" is probably a looser control du= ring a "learning" period, possibly combined with some form of fast ND refre= sh. Of course, there are no good solutions against a local host who is actively= trying to DOS a local router. Keith pointed out that local hosts can gener= ate as many MAC addresses as they want... But then, there are meatspace sol= utions to this kind of things. -- Christian Huitema From john-ietf@jck.com Sun Jul 17 13:32:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA3F21F85CE; Sun, 17 Jul 2011 13:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPLPGWuhH8rM; Sun, 17 Jul 2011 13:32:36 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id B1F2121F85C6; Sun, 17 Jul 2011 13:32:35 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QiY0v-000464-DU; Sun, 17 Jul 2011 16:32:33 -0400 X-Vipre-Scanned: 02D25EC200269D02D2600F-TDI Date: Sun, 17 Jul 2011 16:32:32 -0400 From: John C Klensin To: "Murray S. Kucherawy" , Brian E Carpenter Message-ID: <62EC33D058BC86D3A48291DE@[192.168.1.128]> In-Reply-To: References: <4E20A44E.3060203@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 20:32:36 -0000 --On Saturday, July 16, 2011 20:27 -0700 "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On >> Behalf Of John C Klensin Sent: Friday, July 15, 2011 2:02 PM >> To: Brian E Carpenter >> Cc: v6ops@ietf.org; IETF Discussion >> Subject: Re: Another look at 6to4 (and other IPv6 transition >> issues) >> >> Position #2: How the IETF classifies things makes very little >> difference in this space because people will follow advice >> that seems sensible and ignore everything else. If so, it >> makes little difference how your document is approved or >> where it is published. For example, it could have come >> through the Independent Stream or been pushed into CCR. No >> problem. And the "Historic" effort is a huge waste of the >> community's time, no matter how it comes out. > > Well, if this is the prevailing opinion, we can certainly > simplify our procedures substantially by eliminating about > half of the document states we maintain now, including > reducing the standards track down to a single state. I certainly would not claim it is the prevailing opinion. I believe it is true and have seen it in action many times but, beyond that, have no idea. Also remember that the Standards Track (including BCP or not), Experimmental, Informational, Historic breakdown is somewhat orthogonal to the maturity levels within Standards Track. That said, I believe, based in part on consensus in at least one WG that focused on the topic, that, as our standards have become more complex, with more features, options, and interactions, the embodiment of the "maturity level" idea as a single set of category-identifiers has outlived its usefulness. The reality is that some features of a particular specification may be well-tested and very mature while others may still be a bit questionable and that some specifications may be more appropriate to some environments and less appropriate to others. >From that point of view, forcing entire protocols or specifications into one category or another does both the IETF community and the users of the specs a disservice: we should be telling people what we think of a spec, how mature things are, and what the issues are, if necessary on a characteristic-by-characteristic basis, not pretending that assignment of a label communicates significant information. >From that point of view, reducing the number of categories increases the odds of classifications being misleading and communicating little real information, if only from "very likely" to "near-certain". But, again, that is just IMO. john From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Jul 17 16:31:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060F721F84FA; Sun, 17 Jul 2011 16:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoCXsC7PN8hy; Sun, 17 Jul 2011 16:31:22 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 321A521F84F8; Sun, 17 Jul 2011 16:31:22 -0700 (PDT) Received: from 182-239-169-246.ip.adam.com.au ([182.239.169.246] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Qiant-0001Ev-KQ; Mon, 18 Jul 2011 09:01:17 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 0B8CB3B342; Mon, 18 Jul 2011 09:01:17 +0930 (CST) Date: Mon, 18 Jul 2011 09:01:16 +0930 From: Mark Smith To: Christian Huitema Message-ID: <20110718090116.73f183e1@opy.nosense.org> In-Reply-To: <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Philip Homburg , IPv6 Operations , "ipv6@ietf.org" Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 23:31:23 -0000 Hi Christian, On Sun, 17 Jul 2011 16:09:29 +0000 Christian Huitema wrote: > >So perhaps the changes required would be mostly limited to - > > > >- DADs to all-nodes rather than solicited node addresses > >- nodes receiving the DAD use that to create a neighbor cache entry > >- NUD takes care of maintaining the validity of those entries > >- ND NS to all nodes with an unspecified target address solicits NAs > > from all nodes to cover the router (or any device) reboot situation > > I am not sure this addresses the problem too well. The DOS issue manifests itself at the gateway, and the main issue is the remote DOS: attacker sends packets to a very large number of putative IPv6 addresses in the subnet managed by the local gateway, causing the size of the neighbor cache to explode. If we want to protect the cache in the gateway, let's do that. I agree the attack is most likely going to be aimed at a remote router, however I've also realised that a local host cache may also be a target on a multi-user host. With virtualisation and (groan) "cloud computing", these are becoming more common again. > The solution has to be a tweak in the implementation of ND in the gateway, along the lines of: > > - Upon arrival of a packet from the local network: > - If the source address is already in ND cache, keep it there > - if the source address is not already in the ND cache: > Perform some quota check on the source MAC address, > If the quota is exceeded, drop the packet to protect against local DOS > If the quota is not exceeded, perform ND for the source address > > - Upon arrival of a packet bound to the local subnet > - If the destination address is already in ND cache, route the packet; > - If the destination address is not in ND cache: > If the table is "too full," drop the packet > Else, perform ND > > The basic idea is that remote parties should only be sending to addresses that have already been discovered in the local subnet. This is, in a way, a weak form of stateful filtering. It needs to be implemented softly, because routers/gateways sometime lose their memory, so we want to allow for some dynamic learning if the tables are not already populated. > > The proposed tweaks amount to making ND learn faster. They are fine in general, but they have the side effect of making local DOS easier. A local attacker could generate a large number of addresses, etc. > True, it is vulnerable to a local DoS, although I think thats much better than a remote DoS, because I think local attackers have more of a vested interest in the router being available, and local segments are fairly commonly controlled. In SP environments, there are a lot of spoofing related attacks e.g. RAs, so the measures that SPs put in place to sanitise their customers' traffic tends to mitigate these local DoS attacks. I definitely see addressing the remote DoS to be the main priority. If the solutions to that can also help mitigate some of the local DoS methods that's all the better, however I think they're less of a threat, and ones we've already had experience with because similar ones exist in IPv4. Regards, Mark. From fred@cisco.com Sun Jul 17 16:45:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F96721F8754; Sun, 17 Jul 2011 16:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.069 X-Spam-Level: X-Spam-Status: No, score=-105.069 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3kG1azmRXCN; Sun, 17 Jul 2011 16:45:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 54E8221F8757; Sun, 17 Jul 2011 16:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2356; q=dns/txt; s=iport; t=1310946313; x=1312155913; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=brZIgxBAsFrLB/BWdXhkkQ9wMe6iWoFt/PNuC8ONFB8=; b=Fbq+2Bmor67zAMQsAmIgRwPTpmyDXkFeZ8BDHgwV3q7ai2UdLrx1WEIH i5OxtYq/HrOceO1qJH4esKyXDWgWAkxyCaS9zEGVsb5sVAuxdoHxre1kx Tcd/wPW+Q5NgxLdUDTpBt3/CaKIK32GzkV5x44hTXqRlES92iLXJUcsms A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOVyI06rRDoH/2dsb2JhbABRp3J3iHykZp0HhV1fBIdUixKFAYt0 X-IronPort-AV: E=Sophos;i="4.67,219,1309737600"; d="scan'208";a="3781211" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jul 2011 23:45:12 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6HNjB92007099; Sun, 17 Jul 2011 23:45:11 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Sun, 17 Jul 2011 16:45:12 -0700 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Sun, 17 Jul 2011 16:45:12 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sun, 17 Jul 2011 16:44:46 -0700 Message-Id: <529A223D-1FDE-41D8-944F-35BB78F93382@cisco.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, v6ops@ietf.org, RJ Atkinson Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 23:45:14 -0000 On Jul 17, 2011, at 1:53 AM, Philip Homburg wrote: > In your letter dated Sun, 17 Jul 2011 11:32:37 +0930 you wrote: >> The quite novel technique of allocation transient addresses to >> applications/processes to assist with firewalling also takes = advantage >> of IPv6's large address space and that hosts can have multiple >> addresses at once. It'd be a shame to loose the opportunity to do = that >> or similar innovative things with the large IPv6 address space - >=20 > A more scalable approach is to simply route a /96 to the host. There = paper > already suggests that: >=20 > "If necessary in a given environment, this could be faked by hav- > "ing a host pretend to be a stub router; however, this would require > "the host to participate in routing protocols, which is generally > "considered to be a bad idea. A better solution would be to extend > "NDP to handle host address prefix lengths. >=20 > I guess the authors didn't know about DHCPv6 prefix delegation. >=20 > I think the same applies to hosts with lots of VMs: maintaining a = potentially > large number of NC entries for a single MAC address is unlikely to = scale. > This is what routing is designed for. One issue to think about has to do with virtual machines. If I have one = physical platform that appears to the network to be many virtual = platforms, I would likely want to give it many IPv6 addresses. In a = cloud computing environment, if I move a virtual machine from one = platform to another, I would like to move the address and its routing, = by changing the MAC address associated with the IPv6 address. Forcing a = /96 here would limit my options - to change the routing, I would be = forced to change the address, which is something in a cloud computing = environment that I don't want to do. I could imagine a mix of the proposals, though. I could imagine using a = /80 for a rack or a /96 per platform for virtual machines that reside = there, with a smattering of /128s within the data center for virtual = machines that have moved - and if there was a long term movement, I = could imagine renumbering the machine by adding a new address to it in = its new /96, changing the DNS name, waiting an appropriate interval, and = then removing the old address's /128 from routing and from the virtual = machine.= From joelja@bogus.com Sun Jul 17 17:54:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E6121F8A55; Sun, 17 Jul 2011 17:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.071 X-Spam-Level: X-Spam-Status: No, score=-103.071 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otJ5Xs6X+DCp; Sun, 17 Jul 2011 17:54:19 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B674E21F8A58; Sun, 17 Jul 2011 17:54:18 -0700 (PDT) Received: from zorch.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6I0s9aD059879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Jul 2011 00:54:10 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <529A223D-1FDE-41D8-944F-35BB78F93382@cisco.com> Date: Sun, 17 Jul 2011 17:54:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <69169B31-1608-41D5-82C7-A649FA959AA7@bogus.com> References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <529A223D-1FDE-41D8-944F-35BB78F93382@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 18 Jul 2011 00:54:13 +0000 (UTC) Cc: RJ Atkinson , v6ops@ietf.org, ipv6@ietf.org Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 00:54:19 -0000 On Jul 17, 2011, at 4:44 PM, Fred Baker wrote: >=20 > On Jul 17, 2011, at 1:53 AM, Philip Homburg wrote: >=20 >> In your letter dated Sun, 17 Jul 2011 11:32:37 +0930 you wrote: >>> The quite novel technique of allocation transient addresses to >>> applications/processes to assist with firewalling also takes = advantage >>> of IPv6's large address space and that hosts can have multiple >>> addresses at once. It'd be a shame to loose the opportunity to do = that >>> or similar innovative things with the large IPv6 address space - >>=20 >> A more scalable approach is to simply route a /96 to the host. There = paper >> already suggests that: >>=20 >> "If necessary in a given environment, this could be faked by hav- >> "ing a host pretend to be a stub router; however, this would require >> "the host to participate in routing protocols, which is generally >> "considered to be a bad idea. A better solution would be to extend >> "NDP to handle host address prefix lengths. >>=20 >> I guess the authors didn't know about DHCPv6 prefix delegation. >>=20 >> I think the same applies to hosts with lots of VMs: maintaining a = potentially >> large number of NC entries for a single MAC address is unlikely to = scale. >> This is what routing is designed for. >=20 > One issue to think about has to do with virtual machines. If I have = one physical platform that appears to the network to be many virtual = platforms, I would likely want to give it many IPv6 addresses. In a = cloud computing environment, if I move a virtual machine from one = platform to another, I would like to move the address and its routing, = by changing the MAC address associated with the IPv6 address. Forcing a = /96 here would limit my options - to change the routing, I would be = forced to change the address, which is something in a cloud computing = environment that I don't want to do. Practically speaking you can also achieve the host mobility that large = layer-2's achieve through an l3 mobility approach. eg. the host uses an = igp to advertise it's availability (that is, the nexthop for a prefix = which it has bound to it) within the datacenter... This (could) reduce = the visibility of the subnet to which the host is attached. (it doesn't = have to be externally reachable for example, host address assignments = may be independent of local topology etc. I can't say I've done it with = end systems but we do do a similar thing with load balancers (which are = linux boxes running bgp), where they are ebgp peered with the DC border = using a private AS and you you can take a load-balancer or prefix out of = service or move it by withdrawing the prefix on one load balancer or = advertise it on another. vmware vmotion for example is happy to work across layer-3 networks, the = hosts however need intervention when their numbering changes. > I could imagine a mix of the proposals, though. I could imagine using = a /80 for a rack or a /96 per platform for virtual machines that reside = there, with a smattering of /128s within the data center for virtual = machines that have moved - and if there was a long term movement, I = could imagine renumbering the machine by adding a new address to it in = its new /96, changing the DNS name, waiting an appropriate interval, and = then removing the old address's /128 from routing and from the virtual = machine. I was mostly interested in solving the problem independently of the = subnet size. My assumption is that due to slaac, that I'm going to be = using /64 subnets for networks which have hosts on them... while much of = the exposed side of a DC probably doesn't rely on slaac and is in fact = point-to-point links, places where hosts connect probably are. if the = mac address ends up being encoded in the address at any point it seems a = little silly to split the difference between /64 and /80, both are = trivially big enough to blow up the unpoliced ND cache or dos the = routers cpu. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From bingxuere@gmail.com Sun Jul 17 18:57:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A1321F8A55 for ; Sun, 17 Jul 2011 18:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR7UTwXzj-lK for ; Sun, 17 Jul 2011 18:57:40 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B14E521F8879 for ; Sun, 17 Jul 2011 18:57:40 -0700 (PDT) Received: by iwn39 with SMTP id 39so2865374iwn.31 for ; Sun, 17 Jul 2011 18:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=0qgLnR7Sn7tX+ljpNuGSF7rGHoWlu3xIKO1s3yH9qEE=; b=qabyfeKQ7gQMxeJX2gsTD0Y9r0b6u54is+dqs51GZ4wFJPlQrmfiyZx9IcVm1kNB9v pAzyDz1bDkVEUq4U/9/aJD7AeD1oji7r9Cr8ox/pEzP7DQSEv+Zg5lGUn7HN0loQLlfS AQisY269A/3ZIMx9cE+yfQ1MN1hJFLst2a0vQ= Received: by 10.231.82.197 with SMTP id c5mr5362517ibl.131.1310954260157; Sun, 17 Jul 2011 18:57:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.12.133 with HTTP; Sun, 17 Jul 2011 18:57:20 -0700 (PDT) From: Qiong Date: Mon, 18 Jul 2011 09:57:20 +0800 Message-ID: To: v6ops@ietf.org, Fred Baker Content-Type: multipart/alternative; boundary=000e0cdf13defe548e04a84e5237 Subject: [v6ops] IPv6 content transition X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 01:57:41 -0000 --000e0cdf13defe548e04a84e5237 Content-Type: text/plain; charset=UTF-8 Dear all, We have updated the draft for IPv6 content transition ( http://www.ietf.org/id/draft-sunq-v6ops-contents-transition-01.txt). It describes one deployment model of NAT64, aiming at rapidly increasing the amount of IPv6 accessible contents for users from IPv6 Internet. We have deployed it in Hunan province, and there are six sites (including the official website of China Telecom) have migrated through this approach. And it has also been exhibited on world IPv6 day. We sincerely have comments from you and hopeful to have a discussion on this approach in the incoming IETF 81th. Refer to the report on "The official website of China Telecom launches IPv6 address to visit formally" http://networkvip.net/archives/the-official-website-of-china-telecom-launches-ipv6-address-to-visit-formally.html Thank you very much for your interests. Best regards Qiong SUN --000e0cdf13defe548e04a84e5237 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

We have = updated the draft for IPv6 content transition (=C2=A0http://www.ietf.org/id/draft-sunq-v6ops= -contents-transition-01.txt). It describes one deployment model of NAT6= 4, aiming at rapidly increasing the amount of IPv6 accessible contents for = users from IPv6 Internet. We have=C2=A0deployed it in Hunan province, and there are six sites (inc= luding the official website of China Telecom) have=C2=A0migrated through th= is approach.=C2=A0And i= t has also been=C2=A0exhibited on world IPv6 day.

We sincerel= y have comments from you and hopeful to have a discussion on this approach = in the incoming IETF 81th.
--000e0cdf13defe548e04a84e5237-- From joelja@bogus.com Sun Jul 17 22:40:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641A321F86EB for ; Sun, 17 Jul 2011 22:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.186 X-Spam-Level: X-Spam-Status: No, score=-102.186 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3tP3Inn+p-Q for ; Sun, 17 Jul 2011 22:40:53 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1C12021F86BA for ; Sun, 17 Jul 2011 22:40:52 -0700 (PDT) Received: from zorch.lan (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6I5elNW083073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Jul 2011 05:40:47 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--199519366 From: Joel Jaeggli In-Reply-To: Date: Sun, 17 Jul 2011 22:40:45 -0700 Message-Id: References: To: Qiong X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 18 Jul 2011 05:40:48 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 content transition X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 05:40:54 -0000 --Apple-Mail-2--199519366 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, so perhaps i'm confused, but basically this draft says, put a v6 = address on your load balancer and you can serve content to v6 clients. faithd (which does the nat64 portion of what is described here) was = commmited into the kame project codebase something like 1997/01/25 I think this is all very well and good but it's not real new, since = basically every load balancer vendor out there has a white paper stating = pretty much the same thing. http://www.google.com/search?q=3Dipv6+load+balancer+whitepaper turns up f5 h3c a10 vmware microsft white-papers for the top 5 hits.=20 As an observation, l4 and higher load balancers are generally agnostic = about the address family of the source and destination address family = anyway so in some cases they're not even network address translators = per-say. On Jul 17, 2011, at 6:57 PM, Qiong wrote: > Dear all, >=20 > We have updated the draft for IPv6 content transition ( = http://www.ietf.org/id/draft-sunq-v6ops-contents-transition-01.txt). It = describes one deployment model of NAT64, aiming at rapidly increasing = the amount of IPv6 accessible contents for users from IPv6 Internet. We = have deployed it in Hunan province, and there are six sites (including = the official website of China Telecom) have migrated through this = approach. And it has also been exhibited on world IPv6 day. >=20 > We sincerely have comments from you and hopeful to have a discussion = on this approach in the incoming IETF 81th. >=20 > Refer to the report on "The official website of China Telecom launches = IPv6 address to visit formally" > = http://networkvip.net/archives/the-official-website-of-china-telecom-launc= hes-ipv6-address-to-visit-formally.html >=20 > Thank you very much for your interests. >=20 > Best regards >=20 > Qiong SUN >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-2--199519366 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi, = so perhaps i'm confused, but basically this draft says, put a v6 address = on your load balancer and you can serve content to v6 = clients.

faithd  (which does the nat64 portion = of what is described here) was commmited into the kame project codebase = something like 1997/01/25

I think this is all = very well and good but it's not real new, since basically every load = balancer vendor out there has a white paper stating pretty much the same = thing.


turns up f5 h3c a10 vmware microsft white-papers for the = top 5 hits. 

As an observation, l4 and = higher load balancers are generally agnostic about the address family of = the source and destination address family anyway so in some cases = they're not even network address translators = per-say.

On Jul 17, 2011, at 6:57 PM, Qiong = wrote:

Dear all,

We have updated the draft for IPv6 content transition = ( ). It = describes one deployment model of NAT64, aiming at rapidly increasing = the amount of IPv6 accessible contents for users from IPv6 Internet. We = have deployed it in Hunan province, and there are six = sites (including the official website of China Telecom) = have migrated through this approach. And it has also = been exhibited on world IPv6 day.

We sincerely have comments from you = and hopeful to have a discussion on this approach in the incoming IETF = 81th.

= --Apple-Mail-2--199519366-- From bingxuere@gmail.com Mon Jul 18 03:43:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B262021F8BAB for ; Mon, 18 Jul 2011 03:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqxxyLcKxwFM for ; Mon, 18 Jul 2011 03:43:46 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD0A721F8BA8 for ; Mon, 18 Jul 2011 03:43:46 -0700 (PDT) Received: by iye7 with SMTP id 7so3207798iye.31 for ; Mon, 18 Jul 2011 03:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OC7VyOmjH1s3hkBQfkq+fV+QqmVIoMDuHVh+LMLufGQ=; b=CJyYbiK5FjP57gJ/gJLlD09D0mYhlG8+Ol/M/InWD/23sMJVQJF9UPVAKsRe46M+xe 1pJKaD23dD459zCXkr6qDpqic9I64b7KWXFcrC0tSRtpylC3OqcLf4te3OjoNP4xYrZR hcX3ZyuSUvtlJilhjUpHTsFByzMjCPIk/TcHg= Received: by 10.231.82.197 with SMTP id c5mr5722016ibl.131.1310985826156; Mon, 18 Jul 2011 03:43:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.12.133 with HTTP; Mon, 18 Jul 2011 03:43:26 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Mon, 18 Jul 2011 18:43:26 +0800 Message-ID: To: Joel Jaeggli Content-Type: multipart/alternative; boundary=000e0cdf13de793fb204a855acef Cc: v6ops@ietf.org Subject: Re: [v6ops] IPv6 content transition X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 10:43:50 -0000 --000e0cdf13de793fb204a855acef Content-Type: text/plain; charset=UTF-8 Hi, Joel, Thanks very much for your comments. Actually, our deployment model is not designed for load balancer specifically. *It is a shared platform which could offer the transition service for many CP/SPs at the same time and it is usually located in the entrance of IPv4 IDC.* In my understanding, load balancers are mostly used by individual ICPs, while In our situation, we have found that a great many small-to-medium CP/SPs (with/without load balancers) are quite willing to transit to IPv6 with this NAT64 platform. On the one hand, they do not need to upgrade their load balancer at the current stage in order to support IPv6. On the other hand, they can still make use of IPv4 security infrastructure in the data center and rapidly increasing the contents accessible through IPv6. Our document is not a new protocol, but a deployment model for NAT64 in CP/SP side. And we would give some measurement results later. We are lacking of IPv6 contents for such a long time. We hope this deployment model can be regarded as an encouraging way to rapidly increase IPv6 contents. It is quite simple and straightforward. And it can offer IPv6 service in such a short time. So why not use it in our network ? Best wishes Qiong SUN On Mon, Jul 18, 2011 at 1:40 PM, Joel Jaeggli wrote: > Hi, so perhaps i'm confused, but basically this draft says, put a v6 > address on your load balancer and you can serve content to v6 clients. > > faithd (which does the nat64 portion of what is described here) was > commmited into the kame project codebase something like 1997/01/25 > > I think this is all very well and good but it's not real new, since > basically every load balancer vendor out there has a white paper stating > pretty much the same thing. > > http://www.google.com/search?q=ipv6+load+balancer+whitepaper > > turns up f5 h3c a10 vmware microsft white-papers for the top 5 hits. > > As an observation, l4 and higher load balancers are generally agnostic > about the address family of the source and destination address family anyway > so in some cases they're not even network address translators per-say. > > On Jul 17, 2011, at 6:57 PM, Qiong wrote: > > Dear all, > > We have updated the draft for IPv6 content transition ( > http://www.ietf.org/id/draft-sunq-v6ops-contents-transition-01.txt). It > describes one deployment model of NAT64, aiming at rapidly increasing the > amount of IPv6 accessible contents for users from IPv6 Internet. We have deployed > it in Hunan province, and there are six sites (including the official > website of China Telecom) have migrated through this approach. And it has > also been exhibited on world IPv6 day. > > We sincerely have comments from you and hopeful to have a discussion on > this approach in the incoming IETF 81th. > > Refer to the report on "The official website of China Telecom launches IPv6 > address to visit formally" > > http://networkvip.net/archives/the-official-website-of-china-telecom-launches-ipv6-address-to-visit-formally.html > > Thank you very much for your interests. > > Best regards > > Qiong SUN > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > --000e0cdf13de793fb204a855acef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Joel,

Thanks very much for your comments. Actually, = our deployment model is not designed for load balancer specifically. It = is a shared platform which could offer the transition service for many CP/S= Ps at the same time and it is usually located in the entrance of IPv4 IDC.<= /b>

In my understanding, load balancers are mostly used by = individual ICPs, while In our situation, we have found that a great many sm= all-to-medium CP/SPs (with/without load balancers) are quite willing to tra= nsit to IPv6 with this NAT64 platform. On the one hand, they do not need to= upgrade their load balancer at the current stage in order to support IPv6.= On the other hand, they can still make use of IPv4 security=C2=A0infrastru= cture=C2=A0in the data center and=C2=A0rapidly increasing the contents acce= ssible through IPv6.=C2=A0

Our document is not a new protocol, but a deployment mo= del for NAT64 in CP/SP side. And we would give some measurement results lat= er.=C2=A0

We are lacking of IPv6 contents for such= a long time.=C2=A0We hope this deployment model can be regarded as an enco= uraging way to rapidly increase IPv6 contents. It is quite simple and strai= ghtforward. And it can offer IPv6 service in such a short time. So why not = use it in our network ?

Best wishes


Qio= ng SUN


On Mon, Jul 18, 2011 at= 1:40 PM, Joel Jaeggli <joelja@bogus.com> wrote:
Hi, so = perhaps i'm confused, but basically this draft says, put a v6 address o= n your load balancer and you can serve content to v6 clients.

faithd =C2=A0(which does the nat64 portion of what is descri= bed here) was commmited into the kame project codebase something like 1997/= 01/25

I think this is all very well and good but i= t's not real new, since basically every load balancer vendor out there = has a white paper stating pretty much the same thing.


turns up f5 h3c a10 = vmware microsft white-papers for the top 5 hits.=C2=A0

As an observation, l4 and higher load balancers are gen= erally agnostic about the address family of the source and destination addr= ess family anyway so in some cases they're not=C2=A0even network addres= s translators per-say.

On Jul 17, 2011, = at 6:57 PM, Qiong wrote:

Dear all,

We have updated the= draft for IPv6 content transition (=C2=A0http://www.ietf.org/id/draft-sunq-v= 6ops-contents-transition-01.txt). It describes one de= ployment model of NAT64, aiming at rapidly increasing the amount of IPv6 ac= cessible contents for users from IPv6 Internet. We have=C2=A0deployed it in Hunan province, and there are six sites (including the o= fficial website of China Telecom) have=C2=A0migrated through this approach.= =C2=A0And it has also been=C2=A0exhibited on world IPv6 d= ay.
<= br>
We sincerely have comments from you and hopeful = to have a discussion on this approach in the incoming IETF 81th.

Refer to the report on "Th= e official website of China Telecom launches IPv6 address to visit formally= "

Thank you very much for your interests.

Best regards

Qiong SUN

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


--000e0cdf13de793fb204a855acef-- From gilbert_kim@vanguard.com Mon Jul 18 04:12:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C97321F8B94 for ; Mon, 18 Jul 2011 04:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKpJV+zquHFa for ; Mon, 18 Jul 2011 04:12:09 -0700 (PDT) Received: from pslva865.vanguard.com (pslva865.vanguard.com [192.175.204.35]) by ietfa.amsl.com (Postfix) with ESMTP id E86DE21F8B95 for ; Mon, 18 Jul 2011 04:12:08 -0700 (PDT) Received: from pslna811.vanguard.com (pslna811.vanguard.com [10.221.33.197]) by pslva865.vanguard.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p6IBC2s5023296 for ; Mon, 18 Jul 2011 07:12:02 -0400 X-DKIM: Sendmail DKIM Filter v2.5.6 pslva865.vanguard.com p6IBC2s5023296 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=vanguard.com; s=vanguard; t=1310987522; bh=WvWuMqBAV0krRn8lgNk1x2PPXr0=; l=823; h=Subject:From:To:Message-ID:Date:MIME-Version:Content-type; b=jLlh c/NQV+Wz6Dx/MxwK6vd1HEiSoEowyhbZGEbSyGS9/AwYXMqW+rCYUv3R4ZEOJH5pXzQ Wsn4Mm404c5X6Dw== Received: from pslna867.vanguard.com (pslna867.vanguard.com [10.221.65.44]) by pslna811.vanguard.com (8.14.3/8.14.3) with ESMTP id p6IBC2xs015937 for ; Mon, 18 Jul 2011 07:12:02 -0400 Received: from vgi4mail.vanguard.com (pvnva784.vanguard.com [10.17.128.144]) by pslna867.vanguard.com (Sentrion-MTA-4.1.1/Sentrion-MTA-4.1.1) with ESMTP id p6IBBfUq026588 for ; Mon, 18 Jul 2011 07:11:41 -0400 Auto-Submitted: auto-generated From: gilbert_kim@vanguard.com To: v6ops@ietf.org Message-ID: Date: Mon, 18 Jul 2011 07:11:39 -0400 X-MIMETrack: Serialize by Router on VGI4Mail/VGI(Release 8.5.2FP2|March 22, 2011) at 07/18/2011 07:11:41 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [v6ops] Gilbert Kim is out of office. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 11:12:16 -0000 I will be out of the office starting 07/18/2011 and will not return until 08/01/2011. I am currently out of the country with limited access to email. If you need immediate assistance please contact Scott Yarosh. ---------------------------------------------------------------------- CONFIDENTIALITY STATEMENT. The information contained in this e-mail message, including attachments, is the confidential information of, and/or is the property of, Vanguard. The information is intended for use solely by the individual or entity named in the message. If you are not an intended recipient or you received this in error, then any review, printing, copying, or distribution of any such information is prohibited, and please notify the sender immediately by reply e-mail and then delete this e-mail from your system. From gvandeve@cisco.com Mon Jul 18 07:28:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20ACD21F8C46 for ; Mon, 18 Jul 2011 07:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2sJg2iadcsc for ; Mon, 18 Jul 2011 07:28:56 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 815AB21F8C34 for ; Mon, 18 Jul 2011 07:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=9787; q=dns/txt; s=iport; t=1310999335; x=1312208935; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=PcwbXNy5nkctgqnRRZA+1STnIePtxX4Mr6lxUGqIbJ4=; b=PgrxsH8qvaNSd73m+6lNMPU+JCKjfrtjXbFUqmjet6/QHPgotnxFZiaF hS1bsFK4/ahL9IbktUpHHX+rt+b0MUDkAlUqMrOeIY5LcG+PRwMc+Gw/E qk6vhiudOsT6WR/k+ex6Q2dnOz0XONqZaLiC21jdaSLhWzW/p/oFmzt8H M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABZCJE6Q/khR/2dsb2JhbABUG4I4nQSIHXetMJ19hV1fBJdwi00 X-IronPort-AV: E=Sophos;i="4.67,222,1309737600"; d="scan'208,217";a="43022259" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 18 Jul 2011 14:28:54 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6IESsbm010340; Mon, 18 Jul 2011 14:28:54 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Jul 2011 16:28:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4557.04BA71A3" Date: Mon, 18 Jul 2011 16:28:53 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E504065C91@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-moore-6to4-experimental-00.txt Thread-Index: Acw/QMfETJWTdKomQs620V/Rs/fO9QGFT3QQ References: From: "Gunter Van de Velde (gvandeve)" To: "Keith Moore" , X-OriginalArrivalTime: 18 Jul 2011 14:28:54.0218 (UTC) FILETIME=[05699AA0:01CC4557] Subject: Re: [v6ops] draft-moore-6to4-experimental-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 14:28:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4557.04BA71A3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Imho the concept fight "Historical vs Experimental" does not make sense and seems a religious discussion...=20 =20 6to4 was used in production and helped many people when v6 was not ubiquitous, so experimental=20 makes no sense to me as that is a state of a protocol when it was developed and had no real production=20 examples beyond a lab or simple linux implementation. Imho 6to4 should be deprecated to avoid people=20 will do further standardization (or even use the technology) and hence historical status seems best fit. =20 G/ =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Keith Moore Sent: 10 July 2011 22:34 To: v6ops@ietf.org WG Subject: [v6ops] draft-moore-6to4-experimental-00.txt =20 Apparently, the draft got hung up in the submission process. The secretariat said they'd post it if I emailed them a copy with the correct boilerplate, which I believe I did, but they may still be backlogged. Anyway, it can be downloaded here: =20 http://home.earthlink.net/~heretic/data/draft-moore-6to4-experimental-00 .txt =20 I'm not asking that v6ops take this on, but I'd appreciate any comments from v6ops participants in private mail. After I get some feedback, I'll revise the draft and circulate it more widely. =20 Keith =20 ------_=_NextPart_001_01CC4557.04BA71A3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Imho the concept fight “Historical vs Experimental” does = not make sense and seems a religious discussion… =

 

6to4 was used in production and helped many people when v6 was not = ubiquitous, so experimental

makes no sense to me as that is a state of a protocol when it was = developed and had no real production

examples beyond a lab or simple linux implementation. Imho 6to4 = should be deprecated to avoid people

will do further standardization (or even use the technology) and = hence historical status seems best fit.

 

G/

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Keith Moore
Sent: 10 July 2011 22:34
To: = v6ops@ietf.org WG
Subject: [v6ops] = draft-moore-6to4-experimental-00.txt

 

Apparently, the draft got hung up in the submission = process.  The secretariat said they'd post it if I emailed them a = copy with the correct boilerplate, which I believe I did, but they may = still be backlogged.  Anyway, it can be downloaded = here:

 

http://home.earthlink.net/~heretic/data/draft-moore-6to4-exp= erimental-00.txt

 

I'm not asking that v6ops take this on, but I'd = appreciate any comments from v6ops participants in private mail.   =  After I get some feedback, I'll revise the draft and circulate it = more widely.

 

Keith

 

------_=_NextPart_001_01CC4557.04BA71A3-- From moore@network-heretics.com Mon Jul 18 07:41:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A77121F8B4C for ; Mon, 18 Jul 2011 07:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NujXj+riwlOr for ; Mon, 18 Jul 2011 07:41:06 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFB021F8573 for ; Mon, 18 Jul 2011 07:41:06 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id E2AE22098D; Mon, 18 Jul 2011 10:41:05 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 18 Jul 2011 10:41:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=aSfQ6Fo/IOqMENvS/aiMImFtbRk=; b=uKTeQlTWi7JWnoj5SHlDwnGxCOuVW0ELg519QtKE7kM25r3xSpuU2kNq00VwJsdukRMI4tbovZ0SgEYy/C4TJ+WrcGaEBE+eummveJzjkqbbG0i6OiJ2Z2zxShHD3a8n74tgIt2krGutHG8HE9MP8sK9rwuAs4yyTA1JeT+Iwas= X-Sasl-enc: ulzXoX391AQuwqywTkJOlgjFkl0pWmflZSLGb7TPYc/u 1311000064 Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 4F87044274B; Mon, 18 Jul 2011 10:41:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5--167101662 From: Keith Moore In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504065C91@XMB-AMS-101.cisco.com> Date: Mon, 18 Jul 2011 10:41:03 -0400 Message-Id: References: <4269EA985EACD24987D82DAE2FEC62E504065C91@XMB-AMS-101.cisco.com> To: Gunter Van de Velde (gvandeve) X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-moore-6to4-experimental-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 14:41:10 -0000 --Apple-Mail-5--167101662 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I probably should make this clearer in the next version of = -experimental. But I believe specifically that 6to4 can be useful to = experiment with better ways of traversing the v4/v6 boundary (e.g. to = avoid path asymmetry) and that such experimentation can help produce = transition mechanisms that are better than any of 6to4, Teredo, and = statically configured tunnels. Keith On Jul 18, 2011, at 10:28 AM, Gunter Van de Velde (gvandeve) wrote: > Imho the concept fight =93Historical vs Experimental=94 does not make = sense and seems a religious discussion=85 > =20 > 6to4 was used in production and helped many people when v6 was not = ubiquitous, so experimental > makes no sense to me as that is a state of a protocol when it was = developed and had no real production > examples beyond a lab or simple linux implementation. Imho 6to4 should = be deprecated to avoid people > will do further standardization (or even use the technology) and hence = historical status seems best fit. > =20 > G/ > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Keith Moore > Sent: 10 July 2011 22:34 > To: v6ops@ietf.org WG > Subject: [v6ops] draft-moore-6to4-experimental-00.txt > =20 > Apparently, the draft got hung up in the submission process. The = secretariat said they'd post it if I emailed them a copy with the = correct boilerplate, which I believe I did, but they may still be = backlogged. Anyway, it can be downloaded here: > =20 > = http://home.earthlink.net/~heretic/data/draft-moore-6to4-experimental-00.t= xt > =20 > I'm not asking that v6ops take this on, but I'd appreciate any = comments from v6ops participants in private mail. After I get some = feedback, I'll revise the draft and circulate it more widely. > =20 > Keith > =20 --Apple-Mail-5--167101662 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = probably should make this clearer in the next version of -experimental. =  But I believe specifically that 6to4 can be useful to experiment = with better ways of traversing the v4/v6 boundary (e.g. to avoid path = asymmetry) and that such experimentation can help produce transition = mechanisms that are better than any of 6to4, Teredo, and statically = configured = tunnels.

Keith


On= Jul 18, 2011, at 10:28 AM, Gunter Van de Velde (gvandeve) = wrote:

Imho the concept fight = =93Historical vs Experimental=94 does not make sense and seems a = religious discussion=85
 
6to4 was used in production and = helped many people when v6 was not ubiquitous, so = experimental
makes = no sense to me as that is a state of a protocol when it was developed = and had no real production
examples beyond a lab or simple = linux implementation. Imho 6to4 should be deprecated to avoid = people
will = do further standardization (or even use the technology) and hence = historical status seems best fit.
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or= g] On Behalf = Of Keith = Moore
Sent: 10= July 2011 22:34
To: v6ops@ietf.org WG
Subject: [v6ops] = draft-moore-6to4-experimental-00.txt
 
Apparently, the draft got = hung up in the submission process.  The secretariat said they'd = post it if I emailed them a copy with the correct boilerplate, which I = believe I did, but they may still be backlogged.  Anyway, it can be = downloaded here:
> = http://networkvip.net/archives/the-official-website-of-china-telecom-launc= hes-ipv6-address-to-visit-formally.html >>=20 >> Thank you very much for your interests. >>=20 >> Best regards >>=20 >> Qiong SUN >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 --Apple-Mail-3--166344591 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi, Joel,

Thanks very much for your = comments. Actually, our deployment model is not designed for load = balancer specifically. It is a shared platform which could offer the = transition service for many CP/SPs at the same time and it is usually = located in the entrance of IPv4 = IDC.

I don't think changing = the name of the devices changes what it does. If the distinction is that = the box is multi-tenant that doesn't seem like much of a = distinction.

In my = understanding, load balancers are mostly used by individual ICPs, while = In our situation, we have found that a great many small-to-medium CP/SPs = (with/without load balancers) are quite willing to transit to IPv6 with = this NAT64 platform. On the one hand, they do not need to upgrade their = load balancer at the current stage in order to support IPv6. On the = other hand, they can still make use of IPv4 = security infrastructure in the data center and rapidly = increasing the contents accessible through IPv6. 

Our document is not a new protocol, but a deployment = model for NAT64 in CP/SP side. And we would give some measurement = results later. 

We are lacking of IPv6 = contents for such a long time. We hope this deployment model can be = regarded as an encouraging way to rapidly increase IPv6 = contents.

The problem that content = providers have is not that they can't deploy a AAAA record and route one = ip address to a load balancer.

= It is quite simple and straightforward. And it can offer IPv6 service in = such a short time. So why not use it in our network = ?

Indeed, why not? Does the draft = advance the knowledge of the art?

Best = wishes


Qiong = SUN


On Mon, Jul 18, 2011 at = 1:40 PM, Joel Jaeggli <joelja@bogus.com> = wrote:
Hi, so perhaps i'm confused, but = basically this draft says, put a v6 address on your load balancer and = you can serve content to v6 clients.

faithd  (which does the nat64 portion of what is = described here) was commmited into the kame project codebase something = like 1997/01/25

I think this is all very well = and good but it's not real new, since basically every load balancer = vendor out there has a white paper stating pretty much the same = thing.


turns up f5 h3c a10 vmware microsft = white-papers for the top 5 hits. 

As an observation, l4 and higher load balancers are = generally agnostic about the address family of the source and = destination address family anyway so in some cases they're not even = network address translators per-say.

On Jul 17, = 2011, at 6:57 PM, Qiong wrote:

Dear all,

We have updated the draft for IPv6 content = transition ( http://www.ietf.org/id/draft-sunq-v6ops-contents-transit= ion-01.txt). It describes one deployment model of = NAT64, aiming at rapidly increasing the amount of IPv6 accessible = contents for users from IPv6 Internet. We have deployed it in Hunan province, and there are = six sites (including the official website of China Telecom) = have migrated through this approach. And it has also been exhibited on world = IPv6 day.

We = sincerely have comments from you and hopeful to have a discussion on = this approach in the incoming IETF 81th.

Refer = to the report on "The official website of China Telecom launches IPv6 = address to visit formally"

Thank = you very much for your interests.

Best = regards

Qiong = SUN

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



= --Apple-Mail-3--166344591-- From jnc@mercury.lcs.mit.edu Mon Jul 18 08:33:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E965921F8C66; Mon, 18 Jul 2011 08:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P11+R79K22pF; Mon, 18 Jul 2011 08:33:39 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5882321F8B91; Mon, 18 Jul 2011 08:33:39 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C849F18C08C; Mon, 18 Jul 2011 11:33:37 -0400 (EDT) To: ietf@ietf.org Message-Id: <20110718153337.C849F18C08C@mercury.lcs.mit.edu> Date: Mon, 18 Jul 2011 11:33:37 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: v6ops@ietf.org, jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:33:40 -0000 > From: Ronald Bonica > RFC 2026's very terse definition of HISTORIC. According to RFC 2026, > "A specification that has been superseded by a more recent > specification or is for any other reason considered to be obsolete > is assigned to the Historic level." That's the entire definition. > Anything more is read into it. > ... > A more likely interpretation is as follows: > "the IETF is not likely to invest effort in the technology in the > future" > "the IETF does not encourage (or discourage) new deployments of this > technology. But in giving other interpretations, are you thereby not comitting the exact error you call out above: "Anything more is read into it."? To me, "Historic" has always (including pre-2026) meant just what the orginal meaning of the word is (caveat - see below) - something that is now likely only of interest to people who are looking into the history of networking. (The dictionary definition is "Based on or concerned with events in history".) I think "obsolete" is probably the best one-word description (and note that 'obsolete' != 'obsolescent'). (Caveat: technically, it probably should have been 'historical', not "historic" - "historic" actually means 'in the past, but very noteworthy', e.g. 'CYCLADES was a historic networking design', so not every historical protocol is historic.) Noel From fred@cisco.com Mon Jul 18 08:43:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3AE21F8C57 for ; Mon, 18 Jul 2011 08:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.812 X-Spam-Level: X-Spam-Status: No, score=-103.812 tagged_above=-999 required=5 tests=[AWL=-1.213, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p5506zXlX5o for ; Mon, 18 Jul 2011 08:43:50 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B015F21F8BDC for ; Mon, 18 Jul 2011 08:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=245; q=dns/txt; s=iport; t=1311003830; x=1312213430; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=uStX5OX284Fr83bK6BeLecl0+/hWQ8LLKDWZmzJIq/M=; b=RnQLX6wPh9s0S0Se8fsFdT/06htvNzTJFWY+zVEul79599iU69EQrjRp qoR2IICEbhaS3vyThxDa2mofsbpy7CRfOu96Om6CcooSzYdMrIb+481Fh UP9dMu38unmHQJNnv4kzIyRmjgEkJv6HX+2GbQt4mZnIk0yGKY3SI8Lvz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAABUJE6rRDoH/2dsb2JhbABUp3d3rA+BI54DhV1fBIdUixKFAYt0 X-IronPort-AV: E=Sophos;i="4.67,222,1309737600"; d="scan'208";a="3990958" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jul 2011 15:43:49 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6IFhnq8019873 for ; Mon, 18 Jul 2011 15:43:49 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Mon, 18 Jul 2011 08:43:49 -0700 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Mon, 18 Jul 2011 08:43:49 -0700 From: Fred Baker Date: Mon, 18 Jul 2011 08:43:41 -0700 Message-Id: To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] WG Chair Office Hours X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:43:51 -0000 As we did at IETF-80, Joel and I will be holding office hours at = IETF-81. We invite anyone who would like to talk with the chairs on any = v6ops-relevant topic to join us. We will be in room 301A from 14:00-15:00 EDT on Monday 25 July.= From joelja@bogus.com Mon Jul 18 09:51:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A8821F8B93; Mon, 18 Jul 2011 09:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.764 X-Spam-Level: X-Spam-Status: No, score=-102.764 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxmNRWnrAr6J; Mon, 18 Jul 2011 09:51:01 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6B21F8B8A; Mon, 18 Jul 2011 09:51:00 -0700 (PDT) Received: from [172.16.24.51] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6IGovJo053129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Jul 2011 16:50:57 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Mon, 18 Jul 2011 09:50:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> To: Sander Steffann X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 18 Jul 2011 16:50:59 +0000 (UTC) Cc: IPv6 Operations , ipv6@ietf.org Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 16:51:01 -0000 On Jul 17, 2011, at 4:54 AM, Sander Steffann wrote: > Hi, >=20 >> I think the same applies to hosts with lots of VMs: maintaining a = potentially >> large number of NC entries for a single MAC address is unlikely to = scale. >> This is what routing is designed for. >=20 > Then why are there 64 bits in the IID? And I don't think it has = anything to do with the MAC address. 1000 IPv6 addresses on 10 MAC = addresses scales as well as 1000 IPv6 addresses on 1000 MAC addresses. = It might make a difference for the switch, but not for ND/NC. ieee eui-64 uses 64 bits therefore some interface types (firewire ports = for example) have 64 bit mac address. we will eventually run out of 48 = bit mac addresses given there are only 16.7 million oui blocks... > - Sander > PS: I consider having the possibility of having a large amount of IPv6 = addresses on one interface a great feature, not something I would want = to limit. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From rbonica@juniper.net Mon Jul 18 13:21:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ECF21F85E2; Mon, 18 Jul 2011 13:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEXqVz+mv7Xh; Mon, 18 Jul 2011 13:21:33 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1360721F85DB; Mon, 18 Jul 2011 13:21:32 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTiSVyySGmUz1tBhVssk6ei6AodyqLn7i@postini.com; Mon, 18 Jul 2011 13:21:33 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 18 Jul 2011 13:20:59 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 18 Jul 2011 16:20:58 -0400 From: Ronald Bonica To: Noel Chiappa , "ietf@ietf.org" Date: Mon, 18 Jul 2011 16:20:57 -0400 Thread-Topic: Another look at 6to4 (and other IPv6 transition issues) Thread-Index: AcxFYBJdjQlIlq+EQTO5NLN5FfVsZgAKAEPA Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F3F4A5F7@EMBX01-WF.jnpr.net> References: <20110718153337.C849F18C08C@mercury.lcs.mit.edu> In-Reply-To: <20110718153337.C849F18C08C@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 20:21:34 -0000 Noel, Given that each of us reads something different into the definition of HIST= ORIC, is there any hope that this thread will ever converge? Ron > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > Sent: Monday, July 18, 2011 11:34 AM > To: ietf@ietf.org > Cc: jnc@mercury.lcs.mit.edu; v6ops@ietf.org > Subject: RE: Another look at 6to4 (and other IPv6 transition issues) >=20 > > From: Ronald Bonica >=20 > > RFC 2026's very terse definition of HISTORIC. According to RFC > 2026, > > "A specification that has been superseded by a more recent > > specification or is for any other reason considered to be > obsolete > > is assigned to the Historic level." That's the entire definition. > > Anything more is read into it. > > ... > > A more likely interpretation is as follows: > > "the IETF is not likely to invest effort in the technology in the > > future" > > "the IETF does not encourage (or discourage) new deployments of > this > > technology. >=20 > But in giving other interpretations, are you thereby not comitting the > exact error you call out above: "Anything more is read into it."? >=20 > To me, "Historic" has always (including pre-2026) meant just what the > orginal meaning of the word is (caveat - see below) - something that is > now likely only of interest to people who are looking into the history > of > networking. (The dictionary definition is "Based on or concerned with > events in history".) I think "obsolete" is probably the best one-word > description (and note that 'obsolete' !=3D 'obsolescent'). >=20 > (Caveat: technically, it probably should have been 'historical', not > "historic" - "historic" actually means 'in the past, but very > noteworthy', > e.g. 'CYCLADES was a historic networking design', so not every > historical > protocol is historic.) >=20 > Noel From jason_livingood@cable.comcast.com Mon Jul 18 13:38:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A635821F8B08 for ; Mon, 18 Jul 2011 13:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.134 X-Spam-Level: X-Spam-Status: No, score=-101.134 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+yVOMFWcYfL for ; Mon, 18 Jul 2011 13:38:27 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 044C921F8B03 for ; Mon, 18 Jul 2011 13:38:26 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.45141894; Mon, 18 Jul 2011 14:42:42 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Mon, 18 Jul 2011 16:38:13 -0400 From: "Livingood, Jason" To: "v6ops@ietf.org" Thread-Topic: Feedback on latest v6-aaaa-whitelisting-implications I-D Thread-Index: AQHMRYqD4Ctj4G0x3Uu9c+9phEadrQ== Date: Mon, 18 Jul 2011 20:38:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.13] Content-Type: multipart/alternative; boundary="_000_CA4A11FC2FF89jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: [v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 20:38:27 -0000 --_000_CA4A11FC2FF89jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Since this document achieved rough consensus and passed WGLC in v6ops, it w= ent on to IESG and IETF review. The IESG asked for a number of changes, inc= luding that some sections be reorganized to better present the information = in the document. In addition, sections attempting to describe the motivatio= ns of implementers was also expanded (such as Section 4.1 on volume-based c= oncerns at http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting= -implications-06#section-4.1, plus Section 4.3 at http://tools.ietf.org/htm= l/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06#section-4.3). I believe that overall this had the effect of improving the document. Never= theless, the WG chairs and I feel it is appropriate to have the WG look at = this document again to see if there's additional feedback based on the upda= ted document. To this end, I'm on the WG agenda on 26 July and ask for any = additional feedback (http://www.ietf.org/proceedings/81/agenda/v6ops.html). The latest document is available at: http://tools.ietf.org/html/draft-ietf-= v6ops-v6-aaaa-whitelisting-implications-06 One note for the next =9607 update (per the request of an IESG member): - Possibly remove the last sentence of Section 5.1 (http://tools.ietf.org/h= tml/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06#section-5.1). Tha= t sentence was suggested by one IESG member and another had concerns with t= hat. So I'm trying to sort through that now (I've suggested removing the la= st sentence). Regards, Jason --_000_CA4A11FC2FF89jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9A9A6CA0A6643947B847DFBE61541108@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Since this document achieved rough consensus and passed WGLC in v6ops,= it went on to IESG and IETF review. The IESG asked for a number of changes= , including that some sections be reorganized to better present the informa= tion in the document. In addition, sections attempting to describe the motivations of implementers was also e= xpanded (such as Section 4.1 on volume-based concerns at http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitel= isting-implications-06#section-4.1, plus Section 4.3 at http://tools.ietf.o= rg/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06#section-4.3).  

The latest document is available at: http://too= ls.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06<= /div>

One note for the next =9607 update (per the request of an IESG member)= : 
- Possibly remove the last sentence of Section 5.1 (http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelistin= g-implications-06#section-5.1). That sentence was suggested by one IESG member and another had concerns wi= th that. So I'm trying to sort through that now (I've suggested removing th= e last sentence). 


Regards,
Jason
--_000_CA4A11FC2FF89jasonlivingoodcablecomcastcom_-- From ek@google.com Mon Jul 18 16:26:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D3F21F8575 for ; Mon, 18 Jul 2011 16:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.927 X-Spam-Level: X-Spam-Status: No, score=-105.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW2LVG4VxjHS for ; Mon, 18 Jul 2011 16:26:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4BA21F8572 for ; Mon, 18 Jul 2011 16:26:30 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p6INQSYn013902 for ; Mon, 18 Jul 2011 16:26:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311031589; bh=8m+q+Pd5z4UBfDx80H9jBv8pGT0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=bBvN78RYMa7wHoVloxS9xY/zxZYPNQtyQ2h4El4lAnyNMdzGsYg4sJGyw5VmVNj8h 39Xtc1gc0eIKaZVMUm+LQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=Ye+RdZ9CgayVJI0VADPK03UfoOevajFIlGn9tyR/EdSyYeUbRm44HQ4/skISR/OVB am4JKSfK+lzxRkEKrWj5g== Received: from pvc21 (pvc21.prod.google.com [10.241.209.149]) by kpbe19.cbf.corp.google.com with ESMTP id p6INPuTY029428 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 18 Jul 2011 16:26:27 -0700 Received: by pvc21 with SMTP id 21so4846283pvc.39 for ; Mon, 18 Jul 2011 16:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wWxTjQR5HtnXHW8wCrxWrGxA/FSgyrlNiA87R2S4IO0=; b=Mvq/ChsxTOIwdJSB3h8Eq0SDy3ci5XnmA+H6GLmOKao8pozOF30EwoGhk13VC0JJiX Ug9DqYAhFCMwcDW2PLuQ== MIME-Version: 1.0 Received: by 10.142.213.5 with SMTP id l5mr3454655wfg.153.1311031587014; Mon, 18 Jul 2011 16:26:27 -0700 (PDT) Received: by 10.142.216.21 with HTTP; Mon, 18 Jul 2011 16:26:26 -0700 (PDT) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F3F4A5F7@EMBX01-WF.jnpr.net> References: <20110718153337.C849F18C08C@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F3F4A5F7@EMBX01-WF.jnpr.net> Date: Tue, 19 Jul 2011 08:26:26 +0900 Message-ID: From: Erik Kline To: Ronald Bonica Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "v6ops@ietf.org" , Noel Chiappa , "ietf@ietf.org" Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 23:26:31 -0000 > Given that each of us reads something different into the definition of HISTORIC, is there any hope that this thread will ever converge? I don't see any "progress". We may just have to blacklist any resolvers that have 6to4 clients behind them and leave it at that. From brian.e.carpenter@gmail.com Mon Jul 18 16:42:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1241321F8788; Mon, 18 Jul 2011 16:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.616 X-Spam-Level: X-Spam-Status: No, score=-103.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RU61tLxi4u5; Mon, 18 Jul 2011 16:42:31 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10C0321F8762; Mon, 18 Jul 2011 16:42:30 -0700 (PDT) Received: by vws12 with SMTP id 12so3462484vws.31 for ; Mon, 18 Jul 2011 16:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=L54OR94jEXM3DUj1En8efj/XBFlApJZE3Jj/iuCSmHs=; b=TyxwcuyeDL56ofu3QFVGjE100mpqcaJoII0BhCTuVrtxoCMqBqim3v3hl1SBFTa0zo yNGiSljF3Siy070f7uC2syWHIOjFynjXQlhImk58BTRfRGAfmiQpCmhCMml6cO1aFLnO 0h1ZHfLvpYryw/BGW1imx0JftJnCaG/s2VSn0= Received: by 10.52.176.74 with SMTP id cg10mr1275355vdc.242.1311032550565; Mon, 18 Jul 2011 16:42:30 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id y4sm2007156vdv.37.2011.07.18.16.42.27 (version=SSLv3 cipher=OTHER); Mon, 18 Jul 2011 16:42:29 -0700 (PDT) Message-ID: <4E24C4E1.8050406@gmail.com> Date: Tue, 19 Jul 2011 11:42:25 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Erik Kline References: <20110718153337.C849F18C08C@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F3F4A5F7@EMBX01-WF.jnpr.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , Noel Chiappa , "ietf@ietf.org" Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 23:42:32 -0000 On 2011-07-19 11:26, Erik Kline wrote: >> Given that each of us reads something different into the definition of HISTORIC, is there any hope that this thread will ever converge? > > I don't see any "progress". > > We may just have to blacklist any resolvers that have 6to4 clients > behind them and leave it at that. Why? How would that help anybody? What would help is following the steps in the -advisory document. (Discussing how many angels can dance on the head of an RFC certainly won't help either. Could we all stop now please?) Brian From jacniq@gmail.com Mon Jul 18 20:27:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7287421F8782 for ; Mon, 18 Jul 2011 20:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.101 X-Spam-Level: X-Spam-Status: No, score=-3.101 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6kX61pIckkf for ; Mon, 18 Jul 2011 20:27:56 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6895921F8779 for ; Mon, 18 Jul 2011 20:27:56 -0700 (PDT) Received: by vws12 with SMTP id 12so3559688vws.31 for ; Mon, 18 Jul 2011 20:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Um4Xq44zckMMEpcRNr+J60b7s5nGZpY00u5lz3/EYsg=; b=aOfAl9UpzsLyzbjvwjhAOVmHCpctGXrdawGrHUBx7swXA4Zh58Hd1/lp/zziOe7uis h6yt9BMJfC4fTUitxID+LNacSsEjlnQkR15aCKiik3zSsxG4Oc+nawFBfUkRQlIvsc7w gVulwNu0Zj759VNbKmOPE70gnZujFmzG22WC8= MIME-Version: 1.0 Received: by 10.52.30.197 with SMTP id u5mr6586200vdh.121.1311046075392; Mon, 18 Jul 2011 20:27:55 -0700 (PDT) Received: by 10.52.111.138 with HTTP; Mon, 18 Jul 2011 20:27:55 -0700 (PDT) In-Reply-To: <8D91796F-E5D9-420A-88B1-5C99D17BA931@bogus.com> References: <8D91796F-E5D9-420A-88B1-5C99D17BA931@bogus.com> Date: Tue, 19 Jul 2011 11:27:55 +0800 Message-ID: From: Jacni Qin To: Joel Jaeggli Content-Type: multipart/alternative; boundary=bcaec51d2d7a9ba3e504a863b336 Cc: v6ops@ietf.org, Qiong Subject: Re: [v6ops] IPv6 content transition X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 03:27:58 -0000 --bcaec51d2d7a9ba3e504a863b336 Content-Type: text/plain; charset=ISO-8859-1 hi Joel, Thanks a lot for the comments, inline please, On Mon, Jul 18, 2011 at 10:53 PM, Joel Jaeggli wrote: > > > On Jul 18, 2011, at 3:43 AM, Qiong wrote: > > Hi, Joel, > > Thanks very much for your comments. Actually, our deployment model is not > designed for load balancer specifically. *It is a shared platform which > could offer the transition service for many CP/SPs at the same time and it > is usually located in the entrance of IPv4 IDC.* > > > I don't think changing the name of the devices changes what it does. If the > distinction is that the box is multi-tenant that doesn't seem like much of a > distinction. > Jacni>: Sorry, I guess the text about relationships/co-location with load balancer in the draft makes it confusing. If I understand it correctly, there are many different approaches implemented on load balancers currently, some are NAT based, some are of higher layers. While the simple deployment model discussed in the draft is just based on NAT64, but the box is not necessarily to be colocated on the load balancer. I agree with you that the load balancers can achieve the same goal by means of their own, or in this way, if they can be NAT based and with new NAT64 functions enabled. > In my understanding, load balancers are mostly used by individual ICPs, > while In our situation, we have found that a great many small-to-medium > CP/SPs (with/without load balancers) are quite willing to transit to IPv6 > with this NAT64 platform. On the one hand, they do not need to upgrade their > load balancer at the current stage in order to support IPv6. On the other > hand, they can still make use of IPv4 security infrastructure in the data > center and rapidly increasing the contents accessible through IPv6. > > Our document is not a new protocol, but a deployment model for NAT64 in > CP/SP side. And we would give some measurement results later. > > We are lacking of IPv6 contents for such a long time. We hope this > deployment model can be regarded as an encouraging way to rapidly increase > IPv6 contents. > > > The problem that content providers have is not that they can't deploy a > AAAA record and route one ip address to a load balancer. > Jacni>: IMHO, they share the same requirement of adding AAAA records. > It is quite simple and straightforward. And it can offer IPv6 service in > such a short time. So why not use it in our network ? > > > Indeed, why not? Does the draft advance the knowledge of the art? > Jacni>: In short, as we all know, the most important thing for now is to encourage the IPv6 deployments in every aspect. What we are doing is just to use one product from IETF (NAT64) for this purpose, no new protocols. And it works (please see the examples). So we wrote an informational document to share what we've learned, and to discuss with you that whether this is a good way, if so, we can move forward. Cheers, Jacni > Best wishes > > > Qiong SUN > > > On Mon, Jul 18, 2011 at 1:40 PM, Joel Jaeggli wrote: > >> Hi, so perhaps i'm confused, but basically this draft says, put a v6 >> address on your load balancer and you can serve content to v6 clients. >> >> faithd (which does the nat64 portion of what is described here) was >> commmited into the kame project codebase something like 1997/01/25 >> >> I think this is all very well and good but it's not real new, since >> basically every load balancer vendor out there has a white paper stating >> pretty much the same thing. >> >> http://www.google.com/search?q=ipv6+load+balancer+whitepaper >> >> turns up f5 h3c a10 vmware microsft white-papers for the top 5 hits. >> >> As an observation, l4 and higher load balancers are generally agnostic >> about the address family of the source and destination address family anyway >> so in some cases they're not even network address translators per-say. >> >> On Jul 17, 2011, at 6:57 PM, Qiong wrote: >> >> Dear all, >> >> We have updated the draft for IPv6 content transition ( >> http://www.ietf.org/id/draft-sunq-v6ops-contents-transition-01.txt). It >> describes one deployment model of NAT64, aiming at rapidly increasing the >> amount of IPv6 accessible contents for users from IPv6 Internet. We have deployed >> it in Hunan province, and there are six sites (including the official >> website of China Telecom) have migrated through this approach. And it has >> also been exhibited on world IPv6 day. >> >> We sincerely have comments from you and hopeful to have a discussion on >> this approach in the incoming IETF 81th. >> >> Refer to the report on "The official website of China Telecom launches >> IPv6 address to visit formally" >> >> http://networkvip.net/archives/the-official-website-of-china-telecom-launches-ipv6-address-to-visit-formally.html >> >> Thank you very much for your interests. >> >> Best regards >> >> Qiong SUN >> >> _______________________________________________ >> 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 > > --bcaec51d2d7a9ba3e504a863b336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Joel,

Thanks a lot for the comm= ents, inline please,

On Mon, Jul 1= 8, 2011 at 10:53 PM, Joel Jaeggli <joelja@bogus.com> wrote:


On Jul 18, 2011, at 3:43 AM, Qiong wrote:=

Hi, Joel,

Thanks very much= for your comments. Actually, our deployment model is not designed for load= balancer specifically. It is a shared platform which could offer the tr= ansition service for many CP/SPs at the same time and it is usually located= in the entrance of IPv4 IDC.

I don't think changing the name = of the devices changes what it does. If the distinction is that the box is = multi-tenant that doesn't seem like much of a distinction.

Jacni&g= t;: Sorry, I guess the text about relationships/co-location with load balan= cer in the draft makes it confusing.
If I understand it correctly, there= are many different approaches implemented on load balancers currently, som= e are NAT based, some are of higher layers. While the simple deployment mod= el discussed in the draft is just based on NAT64, but the box is not necess= arily to be colocated on the load balancer.

I agree with you that the load balancers can achieve the same goal by m= eans of their own, or in this way, if they can be NAT based and with new NA= T64 functions enabled.

=

In my understanding, load balancers are mostly used by individual ICPs= , while In our situation, we have found that a great many small-to-medium C= P/SPs (with/without load balancers) are quite willing to transit to IPv6 wi= th this NAT64 platform. On the one hand, they do not need to upgrade their = load balancer at the current stage in order to support IPv6. On the other h= and, they can still make use of IPv4 security=A0infrastructure=A0in the dat= a center and=A0rapidly increasing the contents accessible through IPv6.=A0<= /div>

Our document is not a new protocol, but a deployment mo= del for NAT64 in CP/SP side. And we would give some measurement results lat= er.=A0

We are lacking of IPv6 contents for such a = long time.=A0We hope this deployment model can be regarded as an encouragin= g way to rapidly increase IPv6 contents.

The problem that content providers h= ave is not that they can't deploy a AAAA record and route one ip addres= s to a load balancer.

Jacni>: IMHO, they share the same requirement = of adding AAAA records.


It is quite simple and straightforward. And it can offer IPv6 service= in such a short time. So why not use it in our network ?

Indeed, why not? Does the draft advance the know= ledge of the art?

J= acni>: In short, as we all know, the most important thing for now is to = encourage the IPv6 deployments in every aspect. What we are doing is just t= o use one product from IETF (NAT64) for this purpose, no new protocols.
And it works (please see the examples). So we wrote an informational docume= nt to share what we've learned, and to discuss with you that whether th= is is a good way, if so, we can move forward.


Cheers,
Jacni
=

Best wishes


Qiong SUN


On Mon, Jul 18, 2011 at 1:40 PM, Joel = Jaeggli <joelja@bogus.com> wrote:
Hi, so p= erhaps i'm confused, but basically this draft says, put a v6 address on= your load balancer and you can serve content to v6 clients.

faithd =A0(which does the nat64 portion of what is described= here) was commmited into the kame project codebase something like 1997/01/= 25

I think this is all very well and good but it&#= 39;s not real new, since basically every load balancer vendor out there has= a white paper stating pretty much the same thing.


turns up f5 h3c a10 = vmware microsft white-papers for the top 5 hits.=A0

As an observation, l4 and higher load balancers are gen= erally agnostic about the address family of the source and destination addr= ess family anyway so in some cases they're not=A0even network address t= ranslators per-say.

On Jul 17, 2011, at 6:57 PM, Q= iong wrote:

=
Dear all,

We have updated the= draft for IPv6 content transition (=A0http://www.ietf.org/id/draft-sunq-v6op= s-contents-transition-01.txt). It describes one deplo= yment model of NAT64, aiming at rapidly increasing the amount of IPv6 acces= sible contents for users from IPv6 Internet. We have=A0= deployed it in Hunan province, and there are six sites (including the offic= ial website of China Telecom) have=A0migrated through this approach.=A0And it has also been=A0exhibited on world IPv6 day. <= br>
We sincerely have comments from you and hopeful = to have a discussion on this approach in the incoming IETF 81th.

Refer to the report on "Th= e official website of China Telecom launches IPv6 address to visit formally= "

Thank you very much for your interests.

Best regards

Qiong SUN

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




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


--bcaec51d2d7a9ba3e504a863b336-- From pch-b2B3A6689@u-1.phicoh.com Tue Jul 19 00:28:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7213521F86DB; Tue, 19 Jul 2011 00:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4zAPBJ43KIZ; Tue, 19 Jul 2011 00:28:22 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 76C7E21F85F2; Tue, 19 Jul 2011 00:28:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1Qj4j1-0001iTC; Tue, 19 Jul 2011 09:28:15 +0200 Message-Id: To: Erik Kline From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <20110718153337.C849F18C08C@mercury.lcs.mit.edu> <13205C286662DE4387D9AF3AC30EF456D3F3F4A5F7@EMBX01-WF.jnpr.net> In-reply-to: Your message of "Tue, 19 Jul 2011 08:26:26 +0900 ." Date: Tue, 19 Jul 2011 09:28:12 +0200 Cc: "v6ops@ietf.org" , "ietf@ietf.org" Subject: Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 07:28:22 -0000 In your letter dated Tue, 19 Jul 2011 08:26:26 +0900 you wrote: >> Given that each of us reads something different into the definition of HISTO >RIC, is there any hope that this thread will ever converge? > >I don't see any "progress". > >We may just have to blacklist any resolvers that have 6to4 clients >behind them and leave it at that. I don't think there is any need to be overly dramatic about it. I firmly belive that 6to4 should be moved to historic. But at the same time, I was looking for a poorly performing IPv6 connection to test happy eyeballs and didn't find it. 6to4 can just work. So a less aggressive approach might be in order. (If you look at the numbers, there are fewer and fewer 6to4 connections to dual-stack sites because modern operating system releases will prefer IPv4 over 6to4. Of the users who didn't upgrade, there is about 20% with a completely broken 6to4 setup. What remains is slightly higher latency due to non-optimal placement of relays) From v6ops@globis.net Wed Jul 20 01:14:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF8021F88DC for ; Wed, 20 Jul 2011 01:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6N1mSMUlHH4 for ; Wed, 20 Jul 2011 01:14:29 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 755C321F889F for ; Wed, 20 Jul 2011 01:14:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 484E1870021; Wed, 20 Jul 2011 10:14:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HnsCLA1xjvt; Wed, 20 Jul 2011 10:14:18 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id CE3378700CA; Wed, 20 Jul 2011 10:14:18 +0200 (CEST) Message-ID: <4E268E5A.6020602@globis.net> Date: Wed, 20 Jul 2011 10:14:18 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "Livingood, Jason" , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="------------050607030501020409010606" Subject: Re: [v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 08:14:31 -0000 This is a multi-part message in MIME format. --------------050607030501020409010606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have read this updated document (draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06) I have no substantial comments on content, and support the reorganized structure. Neither of the following two minor comments should be considered any reason to delay the draft if they can't be honored or incorporated. 1. Is it worth mentioning the risk to CGN on de-whitelisting in 7.3.1? These are expensive devices with potentially limited capacity. There has also been a desire expressed by some providers on the v6ops list to be able to reduce IPv4 traffic gradually over time, so that IPv4 and CGN can be turned off in a controlled manner. Suggestion: s/IPv4 network links/IPv4 network links and devices, especially those facilitating the IPv4 to IPv6 transition,/ 2. suggest relocating the entire paragraph containing the example in 4.2 "In this case, a DNS recursive resolver operator expressed a short-term concern that their IPv6 network infrastructure was not yet ready to handle the large traffic volume that may be associated with the hosts in their network connecting to the websites of these domains." as-is to section 4.1 volume based concerns. regards, RayH > Subject: > [v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D > From: > "Livingood, Jason" > Date: > Mon, 18 Jul 2011 20:38:12 +0000 > > To: > "v6ops@ietf.org" > > Precedence: > list > MIME-Version: > 1.0 > Message-ID: > > Content-Type: > multipart/alternative; > boundary="_000_CA4A11FC2FF89jasonlivingoodcablecomcastcom_" > Message: > 2 > > > Since this document achieved rough consensus and passed WGLC in v6ops, > it went on to IESG and IETF review. The IESG asked for a number of > changes, including that some sections be reorganized to better present > the information in the document. In addition, sections attempting to > describe the motivations of implementers was also expanded (such as > Section 4.1 on volume-based concerns at > http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06#section-4.1, > plus Section 4.3 at > http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06#section-4.3). > > > I believe that overall this had the effect of improving the document. > /Nevertheless, the WG chairs and I feel it is appropriate to have the > WG look at this document again to see if there's additional feedback > based on the updated document. /To this end, I'm on the WG agenda on > 26 July and ask for any additional feedback > (http://www.ietf.org/proceedings/81/agenda/v6ops.html). > > The latest document is available at: > http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06 > > One note for the next --07 update (per the request of an IESG member): > - Possibly remove the last sentence of Section 5.1 > (http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06#section-5.1). > That sentence was suggested by one IESG member and another had > concerns with that. So I'm trying to sort through that now (I've > suggested removing the last sentence). > > > Regards, > Jason --------------050607030501020409010606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have read this updated document  (draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06)

I have no substantial comments on content, and support the reorganized structure.

Neither of the following two minor comments should be considered any reason to delay the draft if they can't be honored or incorporated.

1. Is it worth mentioning the risk to CGN on de-whitelisting in 7.3.1? These are expensive devices with potentially limited capacity. There has also been a desire expressed by some providers on the v6ops list to be able to reduce IPv4 traffic gradually over time, so that IPv4 and CGN can be turned off in a controlled manner.

Suggestion:
s/IPv4 network links/IPv4 network links and devices, especially those facilitating the IPv4 to IPv6 transition,/
2. suggest relocating the entire paragraph containing the example in 4.2 "In this case, a DNS recursive resolver operator expressed a short-term concern that their IPv6 network infrastructure was not yet ready to handle the large traffic volume that may be associated with the hosts in their network connecting to the websites of these domains." as-is to section 4.1 volume based concerns.

regards,
RayH
Subject:
[v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D
From:
"Livingood, Jason" <Jason_Livingood@cable.comcast.com>
Date:
Mon, 18 Jul 2011 20:38:12 +0000
To:
"v6ops@ietf.org" <v6ops@ietf.org>
Precedence:
list
MIME-Version:
1.0
Message-ID:
<CA4A11FC.2FF89%jason_livingood@cable.comcast.com>
Content-Type:
multipart/alternative; boundary="_000_CA4A11FC2FF89jasonlivingoodcablecomcastcom_"
Message:
2

Since this document achieved rough consensus and passed WGLC in v6ops, it went on to IESG and IETF review. The IESG asked for a number of changes, including that some sections be reorganized to better present the information in the document. In addition, sections attempting to describe the motivations of implementers was also expanded (such as Section 4.1 on volume-based concerns at http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06#section-4.1, plus Section 4.3 at http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06#section-4.3).  

I believe that overall this had the effect of improving the document. Nevertheless, the WG chairs and I feel it is appropriate to have the WG look at this document again to see if there's additional feedback based on the updated document. To this end, I'm on the WG agenda on 26 July and ask for any additional feedback (http://www.ietf.org/proceedings/81/agenda/v6ops.html). 


One note for the next –07 update (per the request of an IESG member): 
- Possibly remove the last sentence of Section 5.1 (http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06#section-5.1). That sentence was suggested by one IESG member and another had concerns with that. So I'm trying to sort through that now (I've suggested removing the last sentence). 



Regards,
Jason
--------------050607030501020409010606-- From ek@google.com Wed Jul 20 01:46:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21EE21F8876 for ; Wed, 20 Jul 2011 01:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.934 X-Spam-Level: X-Spam-Status: No, score=-105.934 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Aksl+W7+t9q for ; Wed, 20 Jul 2011 01:46:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3638821F8783 for ; Wed, 20 Jul 2011 01:46:50 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p6K8knTD011196 for ; Wed, 20 Jul 2011 01:46:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311151609; bh=lYEgIBIv0TvZFqMG8yeQOvv0qzM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=roz88/x3vA+vc64OOiglCwjQgLTYk1GijDTTmBZwC0saPhai+rTuAlEBBLb+2YJty ksb5NqaiJvboTSYeSHNxw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=k6HbOC34lEfdb62a4FiZ327mhGQ9vG+mN16nvOr3vFjJ677zlUG6TimwHQZt3oq2+ TT19qFNEixuzmEI4A25Kw== Received: from pzk6 (pzk6.prod.google.com [10.243.19.134]) by hpaq14.eem.corp.google.com with ESMTP id p6K8kk79015635 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 01:46:48 -0700 Received: by pzk6 with SMTP id 6so1613pzk.40 for ; Wed, 20 Jul 2011 01:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7zbdGRIrAYfI5szExM0SO2t9MfTYM9GmbNBggd718hE=; b=rLqRX0ZTC+jmpPMEVJSc2dUBGkbtYNgLmEhs5Jn9HOsV460weJGfUXM/OGvO2ht/lP uibf1IDaSwzq1xSrMtzw== MIME-Version: 1.0 Received: by 10.143.20.21 with SMTP id x21mr3913999wfi.39.1311151606291; Wed, 20 Jul 2011 01:46:46 -0700 (PDT) Received: by 10.142.216.21 with HTTP; Wed, 20 Jul 2011 01:46:46 -0700 (PDT) In-Reply-To: <4E268E5A.6020602@globis.net> References: <4E268E5A.6020602@globis.net> Date: Wed, 20 Jul 2011 17:46:46 +0900 Message-ID: From: Erik Kline To: Ray Hunter Content-Type: multipart/alternative; boundary=00504502c5f9bd5e3404a87c4598 X-System-Of-Record: true Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 08:46:51 -0000 --00504502c5f9bd5e3404a87c4598 Content-Type: text/plain; charset=UTF-8 -1, still. Section 4.3 seems like fluff; I hadn't noticed that bit before. The second paragraph of section 3.2 seems irrelevant. The conclusion at the end of section 3.2 that whitelisting represents some form of access control is still completely wrong. What CDNs do is not about geography: it's about client experience. AAAA policy is fundamentally no different. --00504502c5f9bd5e3404a87c4598 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -1, still.

Section 4.3 seems like fluff; I hadn't no= ticed that bit before.

The second paragraph of sec= tion 3.2 seems irrelevant.

The conclusion at the end of = section 3.2 that whitelisting represents some form of access control is sti= ll completely wrong. =C2=A0What CDNs do is not about geography: it's ab= out client experience. =C2=A0AAAA policy is fundamentally no different.
--00504502c5f9bd5e3404a87c4598-- From pch-b2B3A6689@u-1.phicoh.com Wed Jul 20 03:26:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C068921F86EE for ; Wed, 20 Jul 2011 03:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhD7XN9AzPOp for ; Wed, 20 Jul 2011 03:26:04 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id EC1F621F86E5 for ; Wed, 20 Jul 2011 03:26:02 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QjTyX-0001fyC; Wed, 20 Jul 2011 12:25:57 +0200 Message-Id: To: "Livingood, Jason" From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Mon, 18 Jul 2011 20:38:12 +0000 ." Date: Wed, 20 Jul 2011 12:25:40 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 10:26:16 -0000 In your letter dated Mon, 18 Jul 2011 20:38:12 +0000 you wrote: >I believe that overall this had the effect of improving the document. Never >theless, the WG chairs and I feel it is appropriate to have the WG look at >this document again to see if there's additional feedback based on the >updated document. It may be worth pointing out in Section 4.1 or Section 5.3, that, at least in theory, adding AAAA at random with a probability density function that increases over time (and short TTLs) is another way to slowly increase IPv6 traffic to a site. From jason_livingood@cable.comcast.com Wed Jul 20 06:05:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD3621F88E5 for ; Wed, 20 Jul 2011 06:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.434 X-Spam-Level: X-Spam-Status: No, score=-101.434 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0P-+QppAfHx for ; Wed, 20 Jul 2011 06:05:13 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9FF21F88A5 for ; Wed, 20 Jul 2011 06:05:13 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.45373156; Wed, 20 Jul 2011 07:09:37 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Wed, 20 Jul 2011 09:05:05 -0400 From: "Livingood, Jason" To: Erik Kline , Ray Hunter Thread-Topic: [v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D Thread-Index: AQHMRrUNUxkxdap2lEK+RO/+2ZBGypT1KMAAgAAFGwA= Date: Wed, 20 Jul 2011 13:05:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.11] Content-Type: multipart/alternative; boundary="_000_CA4C4822301F4jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 13:05:14 -0000 --_000_CA4C4822301F4jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 7/20/11 4:46 AM, "Erik Kline" > wrot= e: -1, still. Section 4.3 seems like fluff; I hadn't noticed that bit before. [JL] I added Section 4.3 following a conversation with Milo at Google (at a= BITAG meeting in Boulder a couple months ago). If you guys don't feel it i= s important, I'm happy to remove it =97 it was solely intended to better he= lp folks understand the position that content providers like Google, Yahoo,= Microsoft, and others are under. The key thing Milo was trying to get acro= ss was that when a service is free, if there's an issue (such as an IPv6-re= lated impairment) someone can just easily switch to a competing service, wh= ereas if it was a paid service the end user is more likely to call the prov= ider to sort through the issue and less likely to switch to a competitor. [JL] Let me know what you'd like to do here =97 this was just intended to b= etter explain concerns and motivations of domains that whitelist. The second paragraph of section 3.2 seems irrelevant. [JL] I think that was a suggested paragraph by someone in the WG and am hap= py to remove it if the WG wishes. I will add this to the list of questions = I raise with the WG next week to get a sense of the room, but if people are= okay removing that paragraph, please say so here. The conclusion at the end of section 3.2 that whitelisting represents some = form of access control is still completely wrong. What CDNs do is not abou= t geography: it's about client experience. AAAA policy is fundamentally no= different. [JL] I don't disagree with you that whitelisting is about the client experi= ence in one sense. But certainly whitelisting controls access to AAAA RRs, = which means it is a form of policy or access control (to records). - Jason --_000_CA4C4822301F4jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 7/20/11 4:46 AM, "Erik Kline" <ek@google.com> wrote:

-1, still.

Section 4.3 seems like fluff; I hadn't noticed that bit before.

[JL] I added Section 4.3 following a conversation with Milo at Google = (at a BITAG meeting in Boulder a couple months ago). If you guys don't feel= it is important, I'm happy to remove it =97 it was solely intended to bett= er help folks understand the position that content providers like Google, Yahoo, Microsoft, and others are under= . The key thing Milo was trying to get across was that when a service is fr= ee, if there's an issue (such as an IPv6-related impairment) someone can ju= st easily switch to a competing service, whereas if it was a paid service the end user is more likely to c= all the provider to sort through the issue and less likely to switch to a c= ompetitor. 

[JL] Let me know what you'd like to do here =97 this was just intended= to better explain concerns and motivations of domains that whitelist.

The second paragraph of section 3.2 seems irrelevant.

[JL] I think that was a suggested paragraph by someone in the WG and a= m happy to remove it if the WG wishes. I will add this to the list of quest= ions I raise with the WG next week to get a sense of the room, but if peopl= e are okay removing that paragraph, please say so here.

The conclusion at the end of section 3.2 that whitelisting represents = some form of access control is still completely wrong.  What CDNs do i= s not about geography: it's about client experience.  AAAA policy is f= undamentally no different.

[JL] I don't disagree with you that whitelisting is about the client e= xperience in one sense. But certainly whitelisting controls access to AAAA = RRs, which means it is a form of policy or access control (to records).&nbs= p;

- Jason






--_000_CA4C4822301F4jasonlivingoodcablecomcastcom_-- From ek@google.com Wed Jul 20 07:08:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D354921F86BE for ; Wed, 20 Jul 2011 07:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9VWJGLuaobK for ; Wed, 20 Jul 2011 07:08:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4782E21F86C0 for ; Wed, 20 Jul 2011 07:08:35 -0700 (PDT) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p6KE8YYf005796 for ; Wed, 20 Jul 2011 07:08:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311170914; bh=X33J7QlBpMru+QC2WRurGrnSnAs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=n8VMBgFQ2yvQQTzWnJCrUVkml9FNMBH/95SOP665tIbZjXFXTCPhG/A2eW6aaPxK8 A9WCltEK+EZkXHRUR/vuA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=K3Duo4oS0glzNT+tKTAZKz0/yGpSJI3yZEqDuiF9AXc9fZWrznpXaSJO7QTAdG1e/ L3usqT2Wpr9wMaWoivH+g== Received: from gyd5 (gyd5.prod.google.com [10.243.49.197]) by kpbe16.cbf.corp.google.com with ESMTP id p6KE8Onh028867 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 07:08:33 -0700 Received: by gyd5 with SMTP id 5so104093gyd.3 for ; Wed, 20 Jul 2011 07:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=V86z5QB6AfYyFyBSfgTAejPItNiwwwl3IHBuo8mrnlU=; b=yxfmEExQ1yBmklWPjUo7Oj5PSi+TGCNifa9yH39vXUE1Oxmtfdd1YG65+d1bxdKO7k TGba69zRwPMX8roPR/ag== MIME-Version: 1.0 Received: by 10.142.6.1 with SMTP id 1mr3981716wff.267.1311170912776; Wed, 20 Jul 2011 07:08:32 -0700 (PDT) Received: by 10.142.216.21 with HTTP; Wed, 20 Jul 2011 07:08:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Jul 2011 23:08:32 +0900 Message-ID: From: Erik Kline To: "Livingood, Jason" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 14:08:35 -0000 > The conclusion at the end of section 3.2 that whitelisting represents som= e > form of access control is still completely wrong. =C2=A0What CDNs do is n= ot about > geography: it's about client experience. =C2=A0AAAA policy is fundamental= ly no > different. > > [JL] I don't disagree with you that whitelisting is about the client > experience in one sense. But certainly whitelisting controls access to AA= AA > RRs, which means it is a form of policy or access control (to records). > - Jason That's really not how it read. That seems awfully...I don't know what. The implication of a phrase like "access control", in this general context, to me seems like controlling access to the content. This clearly sounds like the kind of thing that would invite legal or regulatory investigation, as some of your other documents have intimated. I haven't read the latest version of your same document for BITAG yet. Does it contain similarly potentially misleading language? From mark@townsley.net Wed Jul 20 15:19:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC1421F8A71 for ; Wed, 20 Jul 2011 15:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.124 X-Spam-Level: X-Spam-Status: No, score=-3.124 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl0NDV-Fr3zN for ; Wed, 20 Jul 2011 15:19:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C94821F8A6F for ; Wed, 20 Jul 2011 15:19:28 -0700 (PDT) Received: by wyj26 with SMTP id 26so545547wyj.31 for ; Wed, 20 Jul 2011 15:19:27 -0700 (PDT) Received: by 10.216.160.78 with SMTP id t56mr7983245wek.14.1311200366377; Wed, 20 Jul 2011 15:19:26 -0700 (PDT) Received: from [192.168.1.11] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id r48sm460144weq.26.2011.07.20.15.19.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 15:19:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-33195692 From: Mark Townsley In-Reply-To: Date: Thu, 21 Jul 2011 00:19:20 +0200 Message-Id: References: <4269EA985EACD24987D82DAE2FEC62E504065C91@XMB-AMS-101.cisco.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-moore-6to4-experimental-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 22:19:29 -0000 --Apple-Mail-4-33195692 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 18, 2011, at 4:41 PM, Keith Moore wrote: > I probably should make this clearer in the next version of = -experimental. But I believe specifically that 6to4 can be useful to = experiment with better ways of traversing the v4/v6 boundary (e.g. to = avoid path asymmetry) and that such experimentation can help produce = transition mechanisms that are better than any of 6to4, Teredo, and = statically configured tunnels. OK, what better ways are you proposing that are not already well = explored in 6rd, 6a44, etc?=20 - Mark >=20 > Keith >=20 >=20 > On Jul 18, 2011, at 10:28 AM, Gunter Van de Velde (gvandeve) wrote: >=20 >> Imho the concept fight =93Historical vs Experimental=94 does not make = sense and seems a religious discussion=85 >> =20 >> 6to4 was used in production and helped many people when v6 was not = ubiquitous, so experimental >> makes no sense to me as that is a state of a protocol when it was = developed and had no real production >> examples beyond a lab or simple linux implementation. Imho 6to4 = should be deprecated to avoid people >> will do further standardization (or even use the technology) and = hence historical status seems best fit. >> =20 >> G/ >> =20 >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Keith Moore >> Sent: 10 July 2011 22:34 >> To: v6ops@ietf.org WG >> Subject: [v6ops] draft-moore-6to4-experimental-00.txt >> =20 >> Apparently, the draft got hung up in the submission process. The = secretariat said they'd post it if I emailed them a copy with the = correct boilerplate, which I believe I did, but they may still be = backlogged. Anyway, it can be downloaded here: >> =20 >> = http://home.earthlink.net/~heretic/data/draft-moore-6to4-experimental-00.t= xt >> =20 >> I'm not asking that v6ops take this on, but I'd appreciate any = comments from v6ops participants in private mail. After I get some = feedback, I'll revise the draft and circulate it more widely. >> =20 >> Keith >> =20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-4-33195692 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I probably should make this = clearer in the next version of -experimental.  But I believe = specifically that 6to4 can be useful to experiment with better ways of = traversing the v4/v6 boundary (e.g. to avoid path asymmetry) and that = such experimentation can help produce transition mechanisms that are = better than any of 6to4, Teredo, and statically configured = tunnels.

OK, what better ways are = you proposing that are not already well explored in 6rd, 6a44, = etc? 

- Mark

Imho the concept fight = =93Historical vs Experimental=94 does not make sense and seems a = religious discussion=85
 
6to4 was used in production and = helped many people when v6 was not ubiquitous, so = experimental
makes = no sense to me as that is a state of a protocol when it was developed = and had no real production
examples beyond a lab or simple = linux implementation. Imho 6to4 should be deprecated to avoid = people
will = do further standardization (or even use the technology) and hence = historical status seems best fit.
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or= g] On Behalf = Of Keith = Moore
Sent: 10= July 2011 22:34
To: v6ops@ietf.org WG
Subject: [v6ops] = draft-moore-6to4-experimental-00.txt
 
Apparently, the draft got = hung up in the submission process.  The secretariat said they'd = post it if I emailed them a copy with the correct boilerplate, which I = believe I did, but they may still be backlogged.  Anyway, it can be = downloaded here:
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail-4-33195692-- From moore@network-heretics.com Wed Jul 20 15:31:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81CF21F8555 for ; Wed, 20 Jul 2011 15:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtQ3GCcn-K4X for ; Wed, 20 Jul 2011 15:31:17 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0691D21F8557 for ; Wed, 20 Jul 2011 15:31:16 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 9EE0520907; Wed, 20 Jul 2011 18:31:16 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 20 Jul 2011 18:31:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=spEqQtwHaaSWV/3vaCqujfuoGJ8=; b=an f45IphEDGiqQW1jLuH2WUvq79N2HnKmSQFx1EC9uKOhJP6QW8tnaHuNdKdwWLD/b DfCJx0lWNt+R6dKGlcn9Lpgm6rKRhYJzXDCUWDu4+3ujSZJHxx94Wut3SvdFDMiE HJ/nQJkfv/wT9dKhOAV6NXey7xdkmozr+FtHml0yE= X-Sasl-enc: hC3GbLUghdY3F39quSP23td7zRj18e374p57pLm31JI6 1311201076 Received: from [10.164.210.65] (unknown [149.48.225.2]) by mail.messagingengine.com (Postfix) with ESMTPA id 696AA45231D; Wed, 20 Jul 2011 18:31:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 20 Jul 2011 18:31:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4269EA985EACD24987D82DAE2FEC62E504065C91@XMB-AMS-101.cisco.com> To: Mark Townsley X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-moore-6to4-experimental-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 22:31:19 -0000 On Jul 20, 2011, at 6:19 PM, Mark Townsley wrote: >=20 > On Jul 18, 2011, at 4:41 PM, Keith Moore wrote: >=20 >> I probably should make this clearer in the next version of = -experimental. But I believe specifically that 6to4 can be useful to = experiment with better ways of traversing the v4/v6 boundary (e.g. to = avoid path asymmetry) and that such experimentation can help produce = transition mechanisms that are better than any of 6to4, Teredo, and = statically configured tunnels. >=20 > OK, what better ways are you proposing that are not already well = explored in 6rd, 6a44, etc?=20 I'm not going to detail them publicly just yet. I know better than to = invite people to take pot shots at a proposal before it's worked out in = sufficient detail. I hope that next week will present some = opportunities to discuss the ideas informally with other people who are = interested in solving this problem. Maybe somebody will identify a way = to strengthen the proposal, or maybe somebody will identify a fatal = flaw. Either way, I should have a better sense in a week or two about = how workable these ideas are. Keith From lorenzo@google.com Wed Jul 20 17:15:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C867721F861E for ; Wed, 20 Jul 2011 17:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDDWjO6IzF7T for ; Wed, 20 Jul 2011 17:15:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3832B21F8544 for ; Wed, 20 Jul 2011 17:15:18 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p6L0FIVI004471 for ; Wed, 20 Jul 2011 17:15:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311207318; bh=w2p8UaVlNU2K8c3B/z4d9evo814=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=uY6QtbTqMGxOeyNg4MRSJGtCh7sKiSjUh7aptXofz1TpJXXueGB3+0Ehz72mdTkNc SSzcRzMU1jT1edpQWKF2A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=manhyZ/yRcIur3qFWC/wtDvgkEpRimBvu8rbWgu3itOYKvh4VncC1yK4N5+XabN+y BEaj6qW8BChlYWCJB3+Og== Received: from pvg11 (pvg11.prod.google.com [10.241.210.139]) by wpaz29.hot.corp.google.com with ESMTP id p6L0FG2V001893 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 20 Jul 2011 17:15:17 -0700 Received: by pvg11 with SMTP id 11so1030719pvg.27 for ; Wed, 20 Jul 2011 17:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lNagM89j0IcQHD/c/FHqXFVpWvgMRK2SIstM7kyacCQ=; b=pBQoM1XebZCQul2y5aAtBtzyIjZXzYmDgkW9m+mi8vET/itIgPZIJZIwnkzvQG2k6L GX67T7muLmD+HCp2C3nA== Received: by 10.142.69.7 with SMTP id r7mr4348123wfa.319.1311207316209; Wed, 20 Jul 2011 17:15:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.242.4 with HTTP; Wed, 20 Jul 2011 17:14:56 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Wed, 20 Jul 2011 17:14:56 -0700 Message-ID: To: "Livingood, Jason" Content-Type: multipart/alternative; boundary=001636e0ab864f3ec604a8893e01 X-System-Of-Record: true Cc: "v6ops@ietf.org WG" , Ray Hunter Subject: Re: [v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 00:15:19 -0000 --001636e0ab864f3ec604a8893e01 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 20, 2011 at 6:05 AM, Livingood, Jason < Jason_Livingood@cable.comcast.com> wrote: > [JL] I don't disagree with you that whitelisting is about the client > experience in one sense. But certainly whitelisting controls access to AAAA > RRs, which means it is a form of policy or access control (to records). > Whitelisting is not a form of access control. It is a way of improving the performance and reliability of a service. In the same way that major websites can return IP (v4 or v6) addresses of servers that are geographically close to users to offer the best performance, they can choose not to return IPv6 addresses to users that will have performance or reliability problems (e.g., broken IPv6). In both cases, the resource that is requested (e.g., a HTTP URL) is available regardless of where the server is or what protocol family is used. So "access control" is not an appropriate description. It should be removed from the document. --001636e0ab864f3ec604a8893e01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 20, 2011 at 6:05 AM, Livingood, Jaso= n <Jason_Livingood@cable.comcast.com> wrote:
[JL] I don't disagree with you that whitelisting is about the clie= nt experience in one sense. But certainly whitelisting controls access to A= AAA RRs, which means it is a form of policy or access control (to records).= =A0

Whitelisting is no= t a form of access control. It is a way of improving the performance and re= liability of a service.

In the same way that major= websites can return IP (v4 or v6) addresses of servers that are geographic= ally close to users to offer the best performance, they can choose not to r= eturn IPv6 addresses to users that will have performance or reliability pro= blems (e.g., broken IPv6).

In both cases, the resource that is requested (e.g., a = HTTP URL) is available regardless of where the server is or what protocol f= amily is used. So "access control" is not an appropriate descript= ion. It should be removed from the document.
--001636e0ab864f3ec604a8893e01-- From moore@network-heretics.com Wed Jul 20 18:15:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1D621F8AE4 for ; Wed, 20 Jul 2011 18:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28RtqD7-BNvy for ; Wed, 20 Jul 2011 18:15:30 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id D4E8021F8AB9 for ; Wed, 20 Jul 2011 18:15:29 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 8AC3720CB8; Wed, 20 Jul 2011 21:15:29 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 20 Jul 2011 21:15:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=cMq lvxETmAQxxTMae1ZMLD8zHF4=; b=oX86J+hvHH90ThdlHWeDVR9L9n38DzzCtBE BSF6bToTSAS2sWfjg7eFILrO8goit4zeArkFiiwhsKZ2+ukOL49YiEfjm6Vv3sLB yqDYxQ2swwMcwDivW/zI7e9JLdiDp2wVmfAday05sSH7rttgNjErwHbZYc3CgFgJ Xo+HnYlQ= X-Sasl-enc: OldKH5a3dswHRZG5vFuZ6yuVmMDMBH6iMhmWzWC3AExW 1311210928 Received: from [10.59.1.76] (static-71-166-174-114.washdc.east.verizon.net [71.166.174.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 7E03E45244A; Wed, 20 Jul 2011 21:15:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-14-43760133 From: Keith Moore In-Reply-To: Date: Wed, 20 Jul 2011 21:15:25 -0400 Message-Id: <85837EF6-8845-4FD3-9F0D-52DD2A6D1EAD@network-heretics.com> References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 01:15:33 -0000 --Apple-Mail-14-43760133 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 20, 2011, at 8:14 PM, Lorenzo Colitti wrote: > On Wed, Jul 20, 2011 at 6:05 AM, Livingood, Jason = wrote: > [JL] I don't disagree with you that whitelisting is about the client = experience in one sense. But certainly whitelisting controls access to = AAAA RRs, which means it is a form of policy or access control (to = records).=20 >=20 > Whitelisting is not a form of access control. It is a way of improving = the performance and reliability of a service. I agree that "access control" is a misleading description of the effect = of whitelisting. Jason, I think I understand why you want to call it = that. But use of the term "access control" in that way is likely to = convey the wrong impression. Keith --Apple-Mail-14-43760133 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 20, 2011, at 8:14 PM, Lorenzo Colitti wrote:

On Wed, Jul 20, 2011 at 6:05 AM, Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:
[JL] I don't disagree with you that whitelisting is about the client experience in one sense. But certainly whitelisting controls access to AAAA RRs, which means it is a form of policy or access control (to records). 

Whitelisting is not a form of access control. It is a way of improving the performance and reliability of a service.

I agree that "access control" is a misleading description of the effect of whitelisting.   Jason, I think I understand why you want to call it that.   But use of the term "access control" in that way is likely to convey the wrong impression.

Keith

--Apple-Mail-14-43760133-- From brian.e.carpenter@gmail.com Wed Jul 20 18:23:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FCD11E8072 for ; Wed, 20 Jul 2011 18:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.614 X-Spam-Level: X-Spam-Status: No, score=-103.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa28rJg3YagK for ; Wed, 20 Jul 2011 18:23:13 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF52511E8071 for ; Wed, 20 Jul 2011 18:23:12 -0700 (PDT) Received: by qwc23 with SMTP id 23so639208qwc.31 for ; Wed, 20 Jul 2011 18:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Rd/kFEgEEQn7dzbd+1qRd65+NgNSvaKoV2K294DUK7o=; b=UtKsy2jDVJGQ12mlvuFGR2GLtRzVLQMC3mJHPaf6LL9Abr9mol7NsypDBZdpIyI+Ue m4fHDbexnF3CyZebGmKsyp98Zyvb+kv9OukPEmWRDURhilBtS/T4sc6nmF3GMKn/BzuT jztZy++nXz8rBDkMp+iPZsshEn3oOJEmF5ebY= Received: by 10.229.2.157 with SMTP id 29mr7651469qcj.62.1311211392407; Wed, 20 Jul 2011 18:23:12 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id q9sm529284qct.44.2011.07.20.18.23.10 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 18:23:11 -0700 (PDT) Message-ID: <4E277F86.6010204@gmail.com> Date: Thu, 21 Jul 2011 13:23:18 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations , draft-kuarsingh-wireline-incremental-ipv6@tools.ietf.org References: <20110704224043.6330.5474.idtracker@ietfa.amsl.com> In-Reply-To: <20110704224043.6330.5474.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 01:23:13 -0000 Hi, This is an interesting draft. Could the authors comment on whether they are suggesting significant differences to the procedures suggested in RFC 6264 (the Incremental CGN document)? In any case I think you need to refer to that RFC, in a positive or negative way at your choice ;-) Regards Brian Carpenter From brian.e.carpenter@gmail.com Wed Jul 20 18:34:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AB721F85A4 for ; Wed, 20 Jul 2011 18:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.614 X-Spam-Level: X-Spam-Status: No, score=-103.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7pHPQYe5euu for ; Wed, 20 Jul 2011 18:34:33 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA10A21F8585 for ; Wed, 20 Jul 2011 18:34:33 -0700 (PDT) Received: by vxi40 with SMTP id 40so709203vxi.31 for ; Wed, 20 Jul 2011 18:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n+nFuNKEOs48LXd4fbtHcJx/o8Trcy5/SKDZkkLoUnM=; b=LUqA31zOp34uFdxzV4LPBgR7X4wglSkXJVlbjRYzBg3NMuJsayOXkidgYhmLk4zAEd 25zuL3ftf/Lwx7CDwK/8VwOXVMwQUn7LZbrMK+w1VgNIJIr9e0LbY3RiElg1IWoPT3BF hK/1yiCJBnZW9CL62B5iz8LExJKuUeKkPoZPA= Received: by 10.52.92.2 with SMTP id ci2mr9448127vdb.428.1311212073198; Wed, 20 Jul 2011 18:34:33 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id j2sm430286vdv.16.2011.07.20.18.34.31 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 18:34:32 -0700 (PDT) Message-ID: <4E27822F.6040602@gmail.com> Date: Thu, 21 Jul 2011 13:34:39 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <20110711131232.28416.12529.idtracker@ietfa.amsl.com> In-Reply-To: <20110711131232.28416.12529.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-li-v6ops-load-balancing-requirement-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 01:34:34 -0000 Hi, Section 5.2 on selection policies for load balancing doesn't include flow-based statistical selection, which as far as I know is a very common method (e.g. for ECMP or LAG). Regards Brian Carpenter From brian.e.carpenter@gmail.com Wed Jul 20 18:51:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C46E21F8680 for ; Wed, 20 Jul 2011 18:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.613 X-Spam-Level: X-Spam-Status: No, score=-103.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u6SR5gthcVJ for ; Wed, 20 Jul 2011 18:51:36 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id BE06E21F85AA for ; Wed, 20 Jul 2011 18:51:36 -0700 (PDT) Received: by qyk29 with SMTP id 29so583501qyk.10 for ; Wed, 20 Jul 2011 18:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=stVUmRbHJ097wMiBgAPy03uv8VkRnzF/ICpLqgFZyo8=; b=Jz6pVg32cWH2s+JRdCho3pZ6r4q/kjV0kHchI8yNJ9B+YHKhBrA7kMuzTTdLOZelqR Sk9lHprA095zxPXhdy1I+KHH4X/yWyI+TkYDG1tCO2HT1flNTLi8iDT4r9egvhAHgd0Q JVBoXpq1xfV6WwHXUSpZf7YWsuxO9jSiosLtk= Received: by 10.224.218.9 with SMTP id ho9mr8447479qab.336.1311213095860; Wed, 20 Jul 2011 18:51:35 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id q9sm546461qct.32.2011.07.20.18.51.34 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 18:51:35 -0700 (PDT) Message-ID: <4E27862E.2020603@gmail.com> Date: Thu, 21 Jul 2011 13:51:42 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <20110711232904.20006.35639.idtracker@ietfa.amsl.com> In-Reply-To: <20110711232904.20006.35639.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-chown-v6ops-address-accountability-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 01:51:37 -0000 > 1. Introduction ... > In IPv6 networks, where hosts may use SLAAC [RFC4862] and Privacy > Addresses [RFC4941], it is quite possible that a host may use > multiple IPv6 addresses over time, possibly changing addresses used > frequently, or using multiple addresses concurrently. It is also standard for a subnet to have several simultaneous prefixes, in which case a host may use one or more addresses under each prefix concurrently. Any solution needs to be able to handle multiple simultaneous prefixes. Regards Brian Carpenter From victor.kuarsingh@gmail.com Wed Jul 20 20:35:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4940321F8906 for ; Wed, 20 Jul 2011 20:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psGTnh5j6U6C for ; Wed, 20 Jul 2011 20:35:12 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A56F221F88B6 for ; Wed, 20 Jul 2011 20:35:12 -0700 (PDT) Received: by ywp31 with SMTP id 31so464871ywp.31 for ; Wed, 20 Jul 2011 20:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=2tRpfgjONJPSTURyUveDmgVjxKoPYAuREvB/2lR0hG4=; b=XXuiHW885ubhIIMCZ3FSDbAzsqRjG4mZCRcxsgkSJcAfEq9NOxip9YWQvjdhYzbg+f dnHlwEXTCnYdon2LWcD8MicCLydHX5aNKQeHfE8gjmMK1oPqNDfoOw+WxK6VRB7GYV50 6YGT92VevC+fQbMNJgTfA5k1oLnieuMtTIEus= Received: by 10.151.2.1 with SMTP id e1mr68655ybi.375.1311219308230; Wed, 20 Jul 2011 20:35:08 -0700 (PDT) Received: from [192.168.1.128] (CPEc0c1c0d0d7b7-CM001a666bafe6.cpe.net.cable.rogers.com [99.230.122.203]) by mx.google.com with ESMTPS id y13sm970529ybj.28.2011.07.20.20.35.06 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 20:35:07 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 20 Jul 2011 23:35:02 -0400 From: Victor Kuarsingh To: Brian E Carpenter , IPv6 Operations Message-ID: Thread-Topic: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt In-Reply-To: <4E277F86.6010204@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 03:35:13 -0000 Brian, This draft (which requires more work) was to be a narrow scope option which can be used by operators if they so choose. The goal was to provide a "recipe" that could be used. In talking with some vendors, it appears that there are still customers (Operators) which are still confused and/or on the fence as to how they will approach IPv6 transition (sure I know may have it figured out - and that's great). This draft would need to point (rightfully so) to RFC6264 which outlines a good and boarder scope approach to IPv6 transition and use of CGN. There is also a link to the transition framework document (draft-ietf-v6ops-v4v6tran-framework) which this draft was to also follow. Due to the rawness of the -00 rev, much of the content I wanted to add is missing and would make it into a -01 rev. I am missing much content which I think is valuable for operator consumption and/or consideration Included in an updated additional content would be: - Defining logical waypoints which could be used by operators to move between phases (I.e. Condition of external content, internal services, tools/readiness, etc) - Better explanation for the rationale for choosing this specific mix of technologies and the phase order - I had specific reasoning as to what the traffic conditions may be like at each one of the phases as well (which supports the notion of keeping as little traffic on the CGN/Relay assist path as possible) - I would also add in options/suggestions as to how operators could grow their transition environment (supporting this mix of technologies), deal with routing etc. Again, this was to be quite operator focused and I was hoping that this type of information could help some operators who may be still in the early analysis phases develop an approach to add in IPv6 (with the obvious understanding that CGN will likely play a part in many networks - like it or not). I would be interesting in your (or others) thoughts. As I had described to someone else the other day, I think the IETF and folks have done an excellent job providing all the "ingredients" for IPv6 transition but wanted to help promote the "recipe" side now - as noted by draft-ietf-v6ops-v4v6tran-framework. Regards, Victor K On 11-07-20 9:23 PM, "Brian E Carpenter" wrote: >Hi, > >This is an interesting draft. Could the authors comment on whether >they are suggesting significant differences to the procedures >suggested in RFC 6264 (the Incremental CGN document)? In any case >I think you need to refer to that RFC, in a positive or negative way >at your choice ;-) > >Regards > Brian Carpenter >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Thu Jul 21 07:02:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9A921F8B0E for ; Thu, 21 Jul 2011 07:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBnCn-z3P9PW for ; Thu, 21 Jul 2011 07:02:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDC021F89BA for ; Thu, 21 Jul 2011 07:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3573; q=dns/txt; s=iport; t=1311256953; x=1312466553; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=9IW4J2AMogsYh7XpsiES09djjs0sZ6sDBliB+R633ns=; b=DOYMLW29r4SJO5hQvnk9d34x58mONKX4+JW+4pS6SR56KLG9+9Vehzcj onut3Rq/IR60Qu4rlvds+avYxJNw1L4p07aUc/69MKXwlYL7xJ9SICmsy PkBTZqcXUH+NzfpRs8WsYGTWCEV07n8g3tul0ZnZw8vzY/7HSTjz5Rx4U o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4AAFMwKE6tJXHA/2dsb2JhbABUmBqPUHenB54nhV9fBIdVkCmEWIcT X-IronPort-AV: E=Sophos;i="4.67,240,1309737600"; d="scan'208";a="5110349" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 21 Jul 2011 14:02:32 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6LE2WgA019668; Thu, 21 Jul 2011 14:02:32 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jul 2011 09:02:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jul 2011 09:02:31 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0575FDC5@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt Thread-Index: AcxHVz075/C+lqNiR5S1ZR3k3ID8ywAV4XEA References: <4E277F86.6010204@gmail.com> From: "Rajiv Asati (rajiva)" To: "Victor Kuarsingh" , "Brian E Carpenter" , "IPv6 Operations" X-OriginalArrivalTime: 21 Jul 2011 14:02:32.0461 (UTC) FILETIME=[D5D9E3D0:01CC47AE] Subject: Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 14:02:37 -0000 Victor, Do you plan on beefing up 'translation' based options in -01 version? Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Victor Kuarsingh > Sent: Wednesday, July 20, 2011 11:35 PM > To: Brian E Carpenter; IPv6 Operations > Subject: Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6- > 00.txt >=20 > Brian, >=20 > This draft (which requires more work) was to be a narrow scope option > which can be used by operators if they so choose. The goal was to provide > a "recipe" that could be used. In talking with some vendors, it appears > that there are still customers (Operators) which are still confused and/or > on the fence as to how they will approach IPv6 transition (sure I know may > have it figured out - and that's great). >=20 > This draft would need to point (rightfully so) to RFC6264 which outlines a > good and boarder scope approach to IPv6 transition and use of CGN. There > is also a link to the transition framework document > (draft-ietf-v6ops-v4v6tran-framework) which this draft was to also follow. >=20 > Due to the rawness of the -00 rev, much of the content I wanted to add is > missing and would make it into a -01 rev. I am missing much content which > I think is valuable for operator consumption and/or consideration >=20 > Included in an updated additional content would be: >=20 > - Defining logical waypoints which could be used by operators to move > between phases (I.e. Condition of external content, internal services, > tools/readiness, etc) > - Better explanation for the rationale for choosing this specific mix of > technologies and the phase order > - I had specific reasoning as to what the traffic conditions may be like > at each one of the phases as well (which supports the notion of keeping as > little traffic on the CGN/Relay assist path as possible) > - I would also add in options/suggestions as to how operators could grow > their transition environment (supporting this mix of technologies), deal > with routing etc. >=20 > Again, this was to be quite operator focused and I was hoping that this > type of information could help some operators who may be still in the > early analysis phases develop an approach to add in IPv6 (with the obvious > understanding that CGN will likely play a part in many networks - like it > or not). >=20 > I would be interesting in your (or others) thoughts. As I had described > to someone else the other day, I think the IETF and folks have done an > excellent job providing all the "ingredients" for IPv6 transition but > wanted to help promote the "recipe" side now - as noted by > draft-ietf-v6ops-v4v6tran-framework. >=20 > Regards, >=20 > Victor K >=20 >=20 > On 11-07-20 9:23 PM, "Brian E Carpenter" > wrote: >=20 > >Hi, > > > >This is an interesting draft. Could the authors comment on whether > >they are suggesting significant differences to the procedures > >suggested in RFC 6264 (the Incremental CGN document)? In any case > >I think you need to refer to that RFC, in a positive or negative way > >at your choice ;-) > > > >Regards > > Brian Carpenter > >_______________________________________________ > >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 joelja@bogus.com Thu Jul 21 08:44:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3B021F8A55 for ; Thu, 21 Jul 2011 08:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjJnkR-Pb5F2 for ; Thu, 21 Jul 2011 08:44:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EE31921F8997 for ; Thu, 21 Jul 2011 08:44:41 -0700 (PDT) Received: from [172.16.24.51] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6LFiV3E037692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Jul 2011 15:44:31 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6-95900450 From: Joel Jaeggli In-Reply-To: Date: Thu, 21 Jul 2011 08:44:25 -0700 Message-Id: <728E3EC5-1CE1-4D6B-9696-FE8B055A9E6C@bogus.com> References: To: Congxiao Bao X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 21 Jul 2011 15:44:33 +0000 (UTC) Cc: v6ops@ietf.org, congxiao@cernet.edu.cn Subject: Re: [v6ops] request for a presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 15:44:42 -0000 --Apple-Mail-6-95900450 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Meeting agenda is here: http://tools.ietf.org/wg/v6ops/agenda and as you can see we're kinda full up for our current two slots.=20 A quick glance through my list archive says this draft hasn't been = brought to the mailing list in any form since it's submission in march, = so we have no basis for assessing working group interest in advancing = this document. Lets do that. thanks joel On Jul 12, 2011, at 6:21 PM, Congxiao Bao wrote: > Hi Fred, >=20 > We would like to request a timeslot to present our draft in v6ops in = the coming ietf meeting. >=20 > Presenter : Wojciech Dec=20 > Title of the draft:Stateless 4Via6 Address Sharing > Url: = https://datatracker.ietf.org/doc/draft-dec-stateless-4v6/?include_text=3D1= >=20 > Thank you very much! >=20 > Congxiao _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-6-95900450 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://tools.ietf.org/wg/v6= ops/agenda

and as you can see we're kinda = full up for our current two slots. 

A = quick glance through my list archive says this draft hasn't been brought = to the mailing list in any form since it's submission in march, so we = have no basis for assessing working group interest in advancing this = document. Lets do = that.

thanks
joel

On Jul = 12, 2011, at 6:21 PM, Congxiao Bao wrote:

Hi Fred,

We would like to request = a timeslot to present our draft in v6ops in the coming ietf meeting.

Presenter : Wojciech Dec
Title of the draft:Stateless 4Via6 Address Sharing
Url: https://datatracker.ietf.org/doc/draft-dec-stateless-4v6/?i= nclude_text=3D1

Thank you very = much!

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

= --Apple-Mail-6-95900450-- From joelja@bogus.com Thu Jul 21 08:47:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8122221F8665 for ; Thu, 21 Jul 2011 08:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-bmZ6hQt44a for ; Thu, 21 Jul 2011 08:47:01 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id BC68921F869C for ; Thu, 21 Jul 2011 08:47:00 -0700 (PDT) Received: from [172.16.24.51] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6LFkrRY038016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Jul 2011 15:46:53 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8-96042520 From: Joel Jaeggli In-Reply-To: <728E3EC5-1CE1-4D6B-9696-FE8B055A9E6C@bogus.com> Date: Thu, 21 Jul 2011 08:46:47 -0700 Message-Id: References: <728E3EC5-1CE1-4D6B-9696-FE8B055A9E6C@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 21 Jul 2011 15:46:53 +0000 (UTC) Cc: v6ops@ietf.org, congxiao@cernet.edu.cn Subject: Re: [v6ops] request for a presentation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 15:47:01 -0000 --Apple-Mail-8-96042520 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii disregard, dealing with the queue out of order... joel On Jul 21, 2011, at 8:44 AM, Joel Jaeggli wrote: > Meeting agenda is here: >=20 > http://tools.ietf.org/wg/v6ops/agenda >=20 > and as you can see we're kinda full up for our current two slots.=20 >=20 > A quick glance through my list archive says this draft hasn't been = brought to the mailing list in any form since it's submission in march, = so we have no basis for assessing working group interest in advancing = this document. Lets do that. >=20 > thanks > joel >=20 > On Jul 12, 2011, at 6:21 PM, Congxiao Bao wrote: >=20 >> Hi Fred, >>=20 >> We would like to request a timeslot to present our draft in v6ops in = the coming ietf meeting. >>=20 >> Presenter : Wojciech Dec=20 >> Title of the draft:Stateless 4Via6 Address Sharing >> Url: = https://datatracker.ietf.org/doc/draft-dec-stateless-4v6/?include_text=3D1= >>=20 >> Thank you very much! >>=20 >> Congxiao _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-8-96042520 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Meeting agenda is = here:


and as you can see we're kinda = full up for our current two slots. 

A = quick glance through my list archive says this draft hasn't been brought = to the mailing list in any form since it's submission in march, so we = have no basis for assessing working group interest in advancing this = document. Lets do = that.

thanks
joel

On Jul = 12, 2011, at 6:21 PM, Congxiao Bao wrote:

Hi Fred,

We would like to request = a timeslot to present our draft in v6ops in the coming ietf meeting.

Presenter : Wojciech Dec
Title of the draft:Stateless 4Via6 Address Sharing
Url: https://datatracker.ietf.org/doc/draft-dec-stateless-4v6/?i= nclude_text=3D1

Thank you very = much!

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

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

= --Apple-Mail-8-96042520-- From michael_oreirdan@cable.comcast.com Thu Jul 21 11:22:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BF221F8785 for ; Thu, 21 Jul 2011 11:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.988 X-Spam-Level: X-Spam-Status: No, score=-103.988 tagged_above=-999 required=5 tests=[AWL=-2.254, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWMCxD60MMhd for ; Thu, 21 Jul 2011 11:22:06 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id B61A221F8752 for ; Thu, 21 Jul 2011 11:22:06 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.45637468; Thu, 21 Jul 2011 12:26:29 -0600 Received: from PACDCEXMB13.cable.comcast.com ([fe80::a89d:c32c:123a:9664]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Thu, 21 Jul 2011 14:21:53 -0400 From: "O'Reirdan, Michael" To: "v6ops@ietf.org" Thread-Topic: Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AQHMR9MX48R+MKwtbkO0KgAdYLlAew== Date: Thu, 21 Jul 2011 18:21:53 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.13] Content-Type: multipart/alternative; boundary="_000_CA4DE67E2620DMichaelOReirdanCableComcastcom_" MIME-Version: 1.0 Cc: "John R. Levine" , Joe St Sauveur , Dave Crocker Subject: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 18:22:07 -0000 --_000_CA4DE67E2620DMichaelOReirdanCableComcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chaps I would like to bring to your attention and solicit comments on the followi= ng draft. http://tools.ietf.org/html//draft-oreirdan-rosenwald-ipv6mail-transition-00 Thanks Mike O'Reirdan --_000_CA4DE67E2620DMichaelOReirdanCableComcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3DF2D4EE214E154FA8AF38F555BF938D@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Chaps 

I would like to bring to your attention and solicit comments on the fo= llowing draft.


Thanks

Mike O'Reirdan


--_000_CA4DE67E2620DMichaelOReirdanCableComcastcom_-- From jason_livingood@cable.comcast.com Thu Jul 21 12:50:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752AA21F8997 for ; Thu, 21 Jul 2011 12:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.194 X-Spam-Level: X-Spam-Status: No, score=-101.194 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+G6Zfk71qh6 for ; Thu, 21 Jul 2011 12:50:36 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id CE1AA21F898E for ; Thu, 21 Jul 2011 12:50:35 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.45656066; Thu, 21 Jul 2011 13:54:45 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Thu, 21 Jul 2011 15:50:16 -0400 From: "Livingood, Jason" To: "O'Reirdan, Michael" , "v6ops@ietf.org" Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AQHMR9MX48R+MKwtbkO0KgAdYLlAe5T3LzCA Date: Thu, 21 Jul 2011 19:50:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.13] Content-Type: multipart/alternative; boundary="_000_CA4DF9C630655jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "John R. Levine" , Joe St Sauveur , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 19:50:36 -0000 --_000_CA4DF9C630655jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for submitting the =9600, Mike. A few notes for reviewers: - This is a very early first draft (and is from some folks new to the IETF)= , so be gentle and give lots of good feedback - It seems we need to sort out the appearance of some RFC 2119 language in = here and whether it may be better to be less focused on 'recommendations fo= r=85' and more 'suggested phases of the transition of mail services to IPv6= ' (a slight tonal shift) I also suggest that the dates don't apply, since every mail provider is at = a different stage of readiness. As a result, sections 5, 6, and 7 probably = should not have dates and may instead be Phase 1, 2 and 3 or something like= that. Jason On 7/21/11 2:21 PM, "O'Reirdan, Michael" > wrote: Chaps I would like to bring to your attention and solicit comments on the followi= ng draft. http://tools.ietf.org/html//draft-oreirdan-rosenwald-ipv6mail-transition-00 Thanks Mike O'Reirdan _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_CA4DF9C630655jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Thanks for submitting the =9600, Mike. A few notes for reviewers:
- This is a very early first draft (and is from some folks new to the = IETF), so be gentle and give lots of good feedback
- It seems we need to sort out the appearance of some RFC 2119 languag= e in here and whether it may be better to be less focused on 'recommendatio= ns for=85' and more 'suggested phases of the transition of mail services to= IPv6' (a slight tonal shift)

I also suggest that the dates don't apply, since every mail provider i= s at a different stage of readiness. As a result, sections 5, 6, and 7 prob= ably should not have dates and may instead be Phase 1, 2 and 3 or something= like that.

Jason


On 7/21/11 2:21 PM, "O'Reirdan, Michael" <Michael_OReirdan@Cable.Comcast.com> wrote:

_______________________________________________ v6ops mailing list v6ops@ietf.org = https://www.ietf.org/mailman/listinfo/v6ops
--_000_CA4DF9C630655jasonlivingoodcablecomcastcom_-- From rogerj@gmail.com Thu Jul 21 13:18:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E36F21F891D for ; Thu, 21 Jul 2011 13:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KauQ7X2h+77q for ; Thu, 21 Jul 2011 13:18:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D16121F8915 for ; Thu, 21 Jul 2011 13:18:12 -0700 (PDT) Received: by wyj26 with SMTP id 26so1246930wyj.31 for ; Thu, 21 Jul 2011 13:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YkZYNYna9unj/PLkKSL8vWZxF92vJlQI+dYbuAqBvhM=; b=ccdVwr/eIrWhXyVIx24MSw9/F/0V2+10DqgfVSb2M7xed2iPk25u+/CK0bCTn8KsQ1 7fkW8Kh66xzaIPkbhNAbDNCkYpy8lNmMmfYqh4Gk7RKsFIvZoi4wRsxG9nmdpYoedNH8 /Hp1ZONN8WrBTWuDhON4xFALsCKhaxYTCOUgQ= MIME-Version: 1.0 Received: by 10.227.174.79 with SMTP id s15mr561866wbz.68.1311279491220; Thu, 21 Jul 2011 13:18:11 -0700 (PDT) Received: by 10.227.155.197 with HTTP; Thu, 21 Jul 2011 13:18:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Jul 2011 22:18:11 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: "Livingood, Jason" , "O'Reirdan, Michael" , Joe St Sauveur , Dave Crocker , johnl@iecc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 20:18:13 -0000 On Thu, Jul 21, 2011 at 9:50 PM, Livingood, Jason wrote: > I also suggest that the dates don't apply, since every mail provider is a= t a > different stage of readiness. As a result, sections 5, 6, and 7 probably > should not have dates and may instead be Phase 1, 2 and 3 or something li= ke > that. Just a first impression, good idea and the drafts will be useful as a backg= round document for education of IPv6 at work :-) And about the dates, they are actual quite useful since they give an idea a= bout the scale of the task at hand. But if they are replaced by phase 1 and up, then maybe add a line about suggested time frame for the total transition, and for each phase? --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From dwing@cisco.com Thu Jul 21 19:17:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACFA21F86AF for ; Thu, 21 Jul 2011 19:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.378 X-Spam-Level: X-Spam-Status: No, score=-105.378 tagged_above=-999 required=5 tests=[AWL=-3.379, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH5b4yIPyDSK for ; Thu, 21 Jul 2011 19:17:11 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BC1AF21F86C4 for ; Thu, 21 Jul 2011 19:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=9313; q=dns/txt; s=iport; t=1311301030; x=1312510630; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=6l74fvmotaTe2pBFvWgJ2sWWiURsBJVaj6DKPsvPuo4=; b=f/jPIjLooJ0CYfh2XZRzFlZMJhNbh2OURNm77g2NbXisIEqes32jgCku H5f7zIFTIIVh7JJvYZBlxIE29kv8VeUzuvf2XnJ0modmUV9T+Sbie8ZY1 1bUEkdE3NgvhiMGiIak9eB+C2RvrrRaH2uv1L+Ct7icSE9UXKAeY3Ssid o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AAL7cKE6rRDoI/2dsb2JhbABTl3WBa41hd4h8nmGeGIY/BIdVnBc X-IronPort-AV: E=Sophos;i="4.67,244,1309737600"; d="scan'208";a="5330621" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jul 2011 02:17:10 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6M2H8jF029835; Fri, 22 Jul 2011 02:17:08 GMT From: "Dan Wing" To: "'Philip Homburg'" , References: Your message of "Mon, 11 Jul 2011 09:15:03 -0700 ." <20110711161503.10931.6058.idtracker@ietfa.amsl.com> In-Reply-To: Date: Thu, 21 Jul 2011 19:17:08 -0700 Message-ID: <04fc01cc4815$753cbe50$5fb63af0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw//jrwLmwf/25hTe+0MPYY7eIASQIEehSA Content-Language: en-us Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 02:17:12 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Philip Homburg > Sent: Monday, July 11, 2011 12:06 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt > > I like this approach. Thanks. Sorry I have not summarized the changes to the list -- so thanks for commenting proactively. > By now, my own HE algorithm is quite complex and > it > would probably take a long time to get any kind of consensus about what > algorithm to use. Maybe later we could have a separate BCP that > outlines > how to construct a HE implementation. > > I'll start with some comments on specific parts of the draft and add > some > suggestions for other issues that could/should be addressed. > > Section 4.1 > > In my opinion the MUST is too strong. I think a SHOULD is more than > enough. > But more importantly, Section 4.2 qualifies that MUST. I think that > either > 4.1 should contain a description of when MUST can be violated or it > should > explicitly forward reference 4.2. In my opinion it is important that > requirements are as self-contained as possible. You're referring to: Happy Eyeballs implementations MUST follow the host's address preference policy or, if that policy is unknown, implementations MUST prefer IPv6 over IPv4. Justification: This reduces load on stateful IPv4 middleboxes (NAT and firewalls) and reduces IPv4 address sharing contention. and I guess you're referring to that first MUST ("MUST follow the host's address preference policy"). The qualification in 4.2 is really around implementations that maintain state -- which I see I never actually said clearly in the I-D itself. For example, the existing implementation in Chrome and Firefox doesn't involve section 4.2 at all, because they don't remember if IPv6 has always failed (except for their same origin policy). As for MUST versus SHOULD, how is this: A Happy Eyeballs implementations MUST follow the host's address preference policy, unless the conditions in Section 4.2 apply). If the host's policy is unknown or not attainable, implementations MUST prefer IPv6 over IPv4. I clarified 4.2 to better describe the implementation as stateful (that is, the implementation notices that IPv6 is always failing). > Section 4.2 > > In think that Section 4.2 should explain what 'failed' means. Is this sufficient? After making a connection attempt on the preferred address family (e.g., IPv6), and failing to establish a connection within a certain time period, a Happy Eyeballs implementation will decide to initiate a second connection attempt using the other address family (e.g., IPv4). > Obviously, > if a protocol doesn't work at all, it should be considered failed. But > I think > that in many cases, a tunnel that always adds 200 ms latency can be > considered > as failing as well. > > (my own algorithm just connects to whatever works best, without trying > to declare something as failed). I would classify the Chrome and Firefox algorithms as also connecting to what 'works best', giving IPv6 a ~200ms head start. > Section 5.5 > > I quickly read the (by now expired) draft on Same Origin Policy and I > didn't > find anything that directly deal with IP addresses. The Wiki page is a little better, and explains that there is no canonical definition of Same Origin Policy. A better reference might be "to avoid DNS rebinding attacks", which is what really encourages web browsers to sandbox their traffic to the same IP address without regard to DNS TTLs or anything else. But, I imagine that could be considered part of the "same origin policy". I'm not a browser person, so guidance for a better citation is certainly welcome. > If it were, then any setup that use a proxy would be in deep trouble. > > I think that 'origin' in this context is a domain, not a specific > address. > But I could be wrong. > > Suggestions > > 1) > > Playing with my own HE implementation I arrived a the following > prototype for > the library function that provides it: > > int tcp_connect_to_name(char *hostname, char *portname, int *gai_errp, > struct timeval *tv); > > I think application portability will be enhanced if HE implementations > provide > similar features. There is also no need for OS implementors to all > reinvent > the wheel. Mark Andrews had a different prototype. I don't have any preference, of course. But I want to finish this I-D. > 2) > > In practice, a DNS RR set may contain more than just one IPv4 and one > IPv6 > address. It may be a good idea to add some discussion about this.
It is possible that an DNS query for an A or AAAA resource record will return more than one A or AAAA address. When this occurs, it is RECOMMENDED that a Happy Eyeballs implementation order the responses following the host's address preference policy and then try the first address. If that fails after a certain time, the next address SHOULD be the IPv4 address. This means that a Happy Eyeballs implementation will not try other IPv6 addresses that are returned; effecitively, the Happy Eyeballs implementation will behave as if only one address was returned.
> 3) > > In practice, local IPv6 connections may still work while the link to > the > outside world is broken. What does 'failed' mean in this context? There are two broad categories of H.E. algorithms: 1. non-stateful algorithms, which don't remember how previous connections were successful or unsuccessful. The implementations in Chrome and Firefox are of this type. 2. stateful algorithms, which is what draft-ietf-v6ops-happy-eyeballs described previously. This was the manipulation of the "P" variable in the previous version of draft-ietf-v6ops-happy-eyeballs. For (1), failure doesn't mean anything -- it doesn't affect subsequent connections. For (2), I have tweaked Section 4.2 to more clearly explain what happens with failures. Specifically, failures to connect to the preferred address family (e.g., IPv6) can cause the algorithm to learn that failure always occurs and to prefer IPv4. Text currently reads: Some Happy Eyeballs algorithms will be stateful -- that is, the algorithm will remember that IPv6 always fails, or that IPv6 to certain prefixes always fails, and so on. This section describes such algorithms. After making a connection attempt on the preferred address family (e.g., IPv6), and failing to establish a connection within a certain time period, a Happy Eyeballs implementation will decide to initiate a second connection attempt using the other address family (e.g., IPv4). Such an implementation MAY make subsequent connection attempts on the successful address family (e.g., IPv4). Such an implementation MUST occasionally make connection attempts using the host's preferred address family, as it may have become functional. It is RECOMMENDED that implementations try the preferred address family at least every 10 minutes. Note: this can be achieved by connecting to both address families at the same time, which does not significantly harm the application's connection setup time for the successful address family. If connections using the preferred address family are successful, the preferred address family SHOULD be used for subsequent connections. > 4) > > What happens if I take the same algorithm as Google used in Chrome but > I > set the timer to 30 ms instead of 300? Is that considered an acceptable > HE > implementation according to this draft? Yes. The normative text does not define the duration of the delay between trying IPv6 and trying IPv4. In fact, you could try them both at the same time -- so long as the IPv6 one is "preferred" (by some definition of preferred), and the network is not thrashed with simultaneous connections. Complex algorithms, such as what we had earlier in draft-ietf-v6ops-happy-eyeballs, achieve this. As do simple algorithms such as what is in Chrome and Firefox. > 5) > > This draft sometimes talks about an entire address family (for example > Section 4.2) but in other places (Section 4) it's about addresses for > an > individual host. I think this should be make more clear in Sections 4.1 > and 4.2. I don't know how to best fix all of that, especially if we consider that a host could have an IPv4-mapped IPv6 address in DNS (ugly, but it happens) as well as a real IPv4 address. That is, I don't know if it's best to talk about "address family" or "address" throughout the document. -d > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nalini.elkins@insidethestack.com Thu Jul 21 21:38:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FAA21F8793 for ; Thu, 21 Jul 2011 21:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.363 X-Spam-Level: X-Spam-Status: No, score=-1.363 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM90JEMt0F47 for ; Thu, 21 Jul 2011 21:38:56 -0700 (PDT) Received: from nm1.access.bullet.mail.mud.yahoo.com (nm1.access.bullet.mail.mud.yahoo.com [66.94.237.202]) by ietfa.amsl.com (Postfix) with SMTP id C97B922800E for ; Thu, 21 Jul 2011 21:38:55 -0700 (PDT) Received: from [66.94.237.199] by nm1.access.bullet.mail.mud.yahoo.com with NNFMP; 22 Jul 2011 04:38:52 -0000 Received: from [66.94.237.97] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 22 Jul 2011 04:38:52 -0000 Received: from [127.0.0.1] by omp1002.access.mail.mud.yahoo.com with NNFMP; 22 Jul 2011 04:38:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 791282.58744.bm@omp1002.access.mail.mud.yahoo.com Received: (qmail 14075 invoked by uid 60001); 22 Jul 2011 04:38:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311309532; bh=T8eI+5s3VavaBJjLZ9HKb3ciVrOA2jTTe9YgKvDCwPc=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=gcbUNn5gKaKwR67xD9RL6MaYR/iVZwe5zHvkFQCrGmiydIZCkPPAbAbbtEurN2iIl7vV3rSiaQG1aaWCLSh8eS0r4oUuFzHBqGRYFYSLR9sNY+vZVoqS+1XKt8+1Q0v8d5uD6Xipi8dgpdsGHpqjpiIUc6GYnAX23XMTyxjIDuQ= X-YMail-OSG: N45IgnsVM1lo1771DfjKfVe4TjbNGe9CPps0vKOdc_tCGOZ dDLC6BgKztCZQ3RACOjI7qfqwC6plMFDwY4r_iR5MQvMvdm2wIwIXKKVDFSH CgXCEbFYHrQAOt9815n9PtHqu8y6lSZMFjvyIEHWvGjbFzQOhpknNP6tJMLE hJQPizjPpvhxrnukyc5qFXP1GaDlolJ0l94hgx1VO5GRcjlqqivLiGF9ZRHK ZHlpqLJIG9bEPR0xukUuBqe.wOLSzWlQMLaF7L5cX4zUCTzucb63gAbaaFqi nBz2_1ZdEUwkUCwDIWxW83pWeFJxTjDlvOrvzYrqlq_J2yrsPju3pM_XTvqL grOQKWIA.vEJUpAWxibBDGFJbzIN7RXotrNIAnFTXtRtElTWUP859HQmcLD7 6PPKlwvU.LyALli_8zenWbTq8SGs0H_Ajvep5m.D8cZ6kfaw8swhj4i.kEH2 r Received: from [24.6.68.48] by web2814.biz.mail.ne1.yahoo.com via HTTP; Thu, 21 Jul 2011 21:38:52 PDT X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.112.310352 Message-ID: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> Date: Thu, 21 Jul 2011 21:38:52 -0700 (PDT) From: nalini.elkins@insidethestack.com To: v6ops@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1009496781-1311309532=:77035" Subject: [v6ops] IPv6 Diagnostic Option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 04:38:57 -0000 --0-1009496781-1311309532=:77035 Content-Type: text/plain; charset=us-ascii Hello Folks, Would love to get feedback on an Internet Draft we have submitted. The issue we are addressing is that the IP Identification field which was available with IPv4 in the main header is available with IPv6 only in the Fragment Header. Please see: http://tools.ietf.org/id/draft-elkins-6man-ipv6-diagnostic-header-00.txt We do have a revision (version 01) which is attached and also a submission to the v6ops group. The submission system is closed so we will update it formally when it reopens on July 25th. Thanks! Nalini Elkins Inside Products, Inc. --0-1009496781-1311309532=:77035 Content-Type: text/plain; name="draft-elkins-6man-ipv6-diagnostic-header-01.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-elkins-6man-ipv6-diagnostic-header-01.txt" DQo2bWFuIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBOLiBFbGtpbnMNCkludGVybmV0IERyYWZ0 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElu c2lkZSBQcm9kdWN0cw0KSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgdHJh Y2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMLiBLcmF0emtlDQpF eHBpcmVzOiBKYW51YXJ5LCAyMDEyICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBJQk0NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0u IEFja2VybWFubg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBCQ0JTIG9mIE1pY2hpZ2FuDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBKdWx5IDIwMTENCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBJUHY2IERpYWdub3N0aWMgT3B0aW9uDQogICAgICAgICAg ICAgICAgICAgZHJhZnQtZWxraW5zLTZtYW4taXB2Ni1kaWFnbm9zdGljLWhl YWRlci0wMS50eHQNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQpUaGlzIElu dGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNl IHdpdGggdGhlIHByb3Zpc2lvbnMNCm9mIEJDUCA3OCBhbmQgQkNQIDc5Lg0K DQpJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrDQpGb3JjZSAoSUVURiksIGl0 cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gTm90ZSB0aGF0IG90 aGVyIGdyb3Vwcw0KbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3Vt ZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQoNCkludGVybmV0LURyYWZ0cyBh cmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4 IG1vbnRocyANCmFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9i c29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55IA0KdGltZS4gSXQg aXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJl ZmVyZW5jZSBtYXRlcmlhbA0Kb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQpUaGUgbGlzdCBvZiBjdXJyZW50 IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dA0KDQpUaGUgbGlz dCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJl IGFjY2Vzc2VkIGF0DQpodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s DQoNClRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gSmFudWFy eSA0LCAyMDEyLg0KDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KQ29weXJpZ2h0 IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZp ZWQgYXMgdGhlIGRvY3VtZW50DQphdXRob3JzLiBBbGwgcmlnaHRzIHJlc2Vy dmVkLg0KDQpUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFu ZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsIFByb3Zpc2lvbnMNClJlbGF0aW5n IHRvIElFVEYgRG9jdW1lbnRzIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9s aWNlbnNlLWluZm8pIGluIA0KZWZmZWN0IG9uIHRoZSBkYXRlIG9mIHB1Ymxp Y2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIFBsZWFzZSByZXZpZXcgdGhlc2Ug DQpkb2N1bWVudHMgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIg cmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCANCnJlc3BlY3QgdG8gdGhp cyBkb2N1bWVudC4NCg0KQWJzdHJhY3QNCg0KVGhlIElQdjQgbWFpbiBoZWFk ZXIgY29udGFpbmVkIGEgMTYtYml0IElQIElkZW50aWZpY2F0aW9uIChJUElE KSBmaWVsZA0KdG8gYmUgdXNlZCBmb3IgZnJhZ21lbnRhdGlvbiBhbmQgcmVh c3NlbWJseS4gIEluIHByYWN0aWNlLCB0aGlzIGZpZWxkIA0Kd2FzIGNvbW1v bmx5IHVzZWQgYnkgbmV0d29yayBkaWFnbm9zdGljaWFucyBmb3IgdHJhY2tp bmcgcGFja2V0cy4gSW4gDQpJUHY2LCB0aGUgSVBJRCBoYXMgYmVlbiBtb3Zl ZCB0byB0aGUgRnJhZ21lbnQgaGVhZGVyLiAgQSBuZXcgRGlhZ25vc3RpYw0K T3B0aW9uIGZvciBJUHY2IHdoaWNoIGNhbiBiZSBzZW50IHdpdGggZXZlcnkg cGFja2V0IGFzIGEgcGFydCBvZiB0aGUgDQpEZXN0aW5hdGlvbiBPcHRpb25z IEhlYWRlciB3aXRoIGEgNjQtYml0IElQSUQgaXMgZGVmaW5lZCBpbiB0aGlz IA0KZG9jdW1lbnQuDQoNCkVsa2lucyAgICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSA0LCAyMDEyICAgICAgICAgICBbUGFnZSAwMV0NCg0K DA0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgIElQdjYgRGlh Z25vc3RpYyBPcHRpb24gICAgICAgSnVseSAyMDExDQoNClRhYmxlIG9mIENv bnRlbnRzDQoNCjEuIEludHJvZHVjdGlvbiAuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAyDQoyLiBDb252 ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQgLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4gMw0KMy4gQXBwbGljYWJpbGl0eSAgLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u IDMNCjQuIElQdjYgRGlhZ25vc3RpY3MgSGVhZGVyIEZvcm1hdCAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAzDQogICA0LjEuIERlc3Rp bmF0aW9uIE9wdGlvbnMgSGVhZGVyIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4gNA0KICAgNC4yLiBEaWFnbm9zdGljIE9wdGlvbiAuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDUNCiAg IDQuMy4gSW1wbGVtZW50YXRpb24gQ29uc2lkZXJhdGlvbnMgLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLiA2DQo1LiBCYWNrd2FyZCBDb21wYXRp YmlsaXR5IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4gNg0KNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDYNCjcuIElBTkEg Q29uc2lkZXJhdGlvbnMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLiA2DQoxMC4gUmVmZXJlbmNlcyAuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4g NiANCiAgICAxMC4xLiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiA3IA0KICAgIDEwLjIuIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uIDcNCjExLiBBY2tub3dsZWRnbWVudHMgLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiA4DQoN Cg0KMS4gSW50cm9kdWN0aW9uDQoNCkluIElQdjQsIHRoZSAxNiBiaXQgSVAg SWRlbnRpZmljYXRpb24gKElQSUQpIGZpZWxkIGlzIGxvY2F0ZWQgYXQgYW4g DQpvZmZzZXQgb2YgNCBieXRlcyBpbnRvIHRoZSBJUHY0IGhlYWRlciBhbmQg aXMgZGVzY3JpYmVkIGluIFJGQzc5MSANCltSRkM3OTFdLiBJbiBJUHY2LCBp dCBpcyBhIDMyIGJpdCBmaWVsZCBjb250YWluZWQgaW4gdGhlIEZyYWdtZW50 IEhlYWRlcg0KZGVmaW5lZCBieSBzZWN0aW9uIDQuNSBvZiBSRkMyNDYwIFtS RkMyNDYwXS4gVW5mb3J0dW5hdGVseSwgdW5sZXNzIA0KZnJhZ21lbnRhdGlv biBpcyBiZWluZyBkb25lIGJ5IHRoZSBzb3VyY2Ugbm9kZSwgdGhlIHBhY2tl dCB3aWxsIG5vdA0KY29udGFpbiB0aGlzIEZyYWdtZW50IEhlYWRlciwgYW5k IHRoZXJlZm9yZSB3aWxsIGhhdmUgbm8gSWRlbnRpZmljYXRpb24NCmZpZWxk Lg0KDQpUaGUgaW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgSVBJRCBmaWVsZCBp cyB0byBlbmFibGUgZnJhZ21lbnRhdGlvbiBhbmQNCnJlYXNzZW1ibHksIGFu ZCBhcyBjdXJyZW50bHkgc3BlY2lmaWVkIGlzIHJlcXVpcmVkIHRvIGJlIHVu aXF1ZSB3aXRoaW4NCnRoZSBtYXhpbXVtIHNlZ21lbnQgbGlmZXRpbWUgKE1T TCkgb24gYWxsIGRhdGFncmFtcy4gVGhlIE1TTCBpcyBvZnRlbiAyDQptaW51 dGVzLg0KDQpJbiBwcmFjdGljZSwgdGhlIElQSUQgZmllbGQgaXMgdXNlZCBm b3IgbW9yZSB0aGFuIGZyYWdtZW50YXRpb24uDQpEdXJpbmcgbmV0d29yayBk aWFnbm9zdGljcywgcGFja2V0IHRyYWNlcyBtYXkgYmUgdGFrZW4gYXQgbXVs dGlwbGUgDQpwbGFjZXMgYWxvbmcgdGhlIHBhdGggb3IgYXQgdGhlIHNvdXJj ZSBhbmQgZGVzdGluYXRpb24uIFRoZW4sIHBhY2tldHMgDQpjYW4gYmUgbWF0 Y2hlZCBieSBsb29raW5nIGF0IHRoZSBJUElELiBPYnZpb3VzbHksIHRoZSB0 aW1lIGF0IGVhY2ggDQpkZXZpY2Ugd2lsbCBkaWZmZXIgYWNjb3JkaW5nIHRv IHRoZSBjbG9jayBvbiB0aGF0IGRldmljZTsgc28gYW5vdGhlciANCm1ldHJp YyBpcyByZXF1aXJlZC4gVGhpcyBtZXRob2Qgb2YgdGFraW5nIG11bHRpcGxl IHRyYWNlcyBhbG9uZyB0aGUgcGF0aA0KaXMgb2Ygc3BlY2lhbCB1c2Ugb24g bGFyZ2UgbXVsdGktdGllciBuZXR3b3JrcyB0byBzZWUgd2hlcmUgdGhlIHBh Y2tldA0KbG9zcyBvciBwYWNrZXQgY29ycnVwdGlvbiBpcyBoYXBwZW5pbmcu ICBNdWx0aS10aWVyIG5ldHdvcmtzIGFyZSB0aG9zZSANCndoaWNoIGhhdmUg bXVsdGlwbGUgcm91dGVycyBvciBzd2l0Y2hlcyBvbiB0aGUgcGF0aCBiZXR3 ZWVuIHRoZSBzZW5kZXINCmFuZCB0aGUgcmVjZWl2ZXIuDQoNClRoZSBpbmNs dXNpb24gb2YgdGhpcyBvcHRpb24gbWFrZXMgaXQgZWFzaWVyIGZvciBhIGRl dmljZSBpbiB0aGUgbWlkZGxlDQpvZiB0aGUgbmV0d29yayBvciBvbiB0aGUg cmVjZWl2aW5nIGVuZCBvZiB0aGUgbmV0d29yayB0byBpZGVudGlmeSBmbG93 cyANCmJlbG9uZ2luZyB0byBhIHNpbmdsZSBub2RlLCBldmVuIGlmIHRoYXQg bm9kZSBtaWdodCBoYXZlIGEgZGlmZmVyZW50IElQDQphZGRyZXNzLiBGb3Ig ZXhhbXBsZSwgaWYgdGhlIHNlbmRpbmcgbm9kZSBpcyBhIG1vYmlsZSBsYXB0 b3Agd2l0aCBhIA0Kd2lyZWxlc3MgY29ubmVjdGlvbiB0byB0aGUgSW50ZXJu ZXQuICANCg0KRWxraW5zICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBK YW51YXJ5IDQsIDIwMTIgICAgICAgICAgIFtQYWdlIDAyXQ0KDQoMDQoNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgSVB2NiBEaWFnbm9zdGlj IE9wdGlvbiAgICAgICBKdWx5IDIwMTENCg0KDQpIYXZpbmcgc2FpZCB0aGF0 LCBhIGtub3duIHByb2JsZW0gd2l0aCB0aGUgdW5pcXVlbmVzcyBvZiB0aGUg SVB2NCBJRCBpcyANCnRoYXQgc2luY2UgdGhlIGZpZWxkIGlzIG9ubHkgMTYg Yml0cywgdGhlbiBmb3IgaGlnaCBzcGVlZCBkZXZpY2VzLCANCndyYXBwaW5n IHdpbGwgb2NjdXIuIEFzIGRpc2N1c3NlZCBpbiBSRkM0OTYzIFtSRkM0OTYz XSBhbmQgDQpkcmFmdC1pZXRmLWludGFyZWEtaXB2NC1pZC11cGRhdGUtMDIu dHh0IFtEcmFmdC1pcHY0LWlkXSwgaWYgdGhlIA0KdW5pcXVlbmVzcyByZXF1 aXJlbWVudCB3ZXJlIHN0cmljdGx5IGVuZm9yY2VkLCBhbGwgY29ubmVjdGlv bnMgd291bGQgYmUgDQpsaW1pdGVkIHRvIGEgbWF4aW11bSBzcGVlZCBvZiA2 LjQgTWJwcy4gQ2xlYXJseSwgdGhpcyB1bmlxdWVuZXNzIA0KcmVxdWlyZW1l bnQgaXMgd2lkZWx5IGlnbm9yZWQuDQoNCkluIGZhY3QsIHRoZSBpbXBsZW1l bnRhdGlvbiBvZiB0aGUgSVBJRCBmaWVsZCB2YXJpZXMuICBTb21lIA0KaW1w bGVtZW50YXRpb25zIGhhdmUgdGhlIHNhbWUgSVBJRCBjb3VudGVyIGZvciBh bGwgY29ubmVjdGlvbnM7IHNvbWUgDQpoYXZlIGFuIElQSUQgY291bnRlciBv biBhIHBlciBjb25uZWN0aW9uIGJhc2lzLiAgU29tZSBpbXBsZW1lbnRhdGlv bnMNCmluY3JlbWVudCB0aGUgSVBJRCBieSBvbmUgZWFjaCB0aW1lIGEgcGFj a2V0IGlzIHNlbnQgb3V0OyBzb21lDQppbmNyZW1lbnQgYnkgdHdvLiAgDQoN CkluIElQdjYsIHRoZSBJUElEIGZpZWxkLCB3aGljaCBpcyBpbiB0aGUgRnJh Z21lbnQgSGVhZGVyLCBoYXMgYmVlbiANCmluY3JlYXNlZCB0byAzMiBiaXRz LiBUaGlzIG1heSBuZWVkIHRvIGJlIHJlY29uc2lkZXJlZCBhcyBkYXRhIHJh dGVzIA0KaW5jcmVhc2UgYnV0IGlmIHRoZSBJUElEIGlzIHVzZWQgZm9yIGZy YWdtZW50YXRpb24gYW5kIHJlYXNzZW1ibHkgDQphbG9uZSwgdGhlIHJlcXVp cmVtZW50IGZvciB1bmlxdWVuZXNzIHdpdGhpbiB0aGUgTVNMIHBlcmlvZCBp cyANCmdlbmVyYWxseSBub3QgYW4gaXNzdWUgdG9kYXkuIFJGQzQ5NjMgW1JG QzQ5NjNdIGRpc2N1c3NlcyB0aGUgaXNzdWUgb2YgDQpyZWFzc2VtYmx5IGVy cm9ycyBhdCBoaWdoIGRhdGEgcmF0ZXMgZm9yIElQdjQgd2l0aCBhIDE2LWJp dCBjb3VudGVyLg0KDQpIb3dldmVyLCBmb3IgaXRzIGRlLWZhY3RvIGRpYWdu b3N0aWMgbW9kZSB1c2FnZSwgYW4gSVBJRCBuZWVkcyB0byBiZSANCmF2YWls YWJsZSB3aGV0aGVyIG9yIG5vdCBmcmFnbWVudGF0aW9uIG9jY3VycywgYW5k IG5lZWRzIHRvIGJlIHVuaXF1ZQ0KaW4gdGhlIGNvbnRleHQgb2YgdGhlIGVu dGlyZSBzZXNzaW9uLCBhbmQgYWNyb3NzIGFsbCB0aGUgY29ubmVjdGlvbnMN CmNvbnRyb2xsZWQgYnkgdGhlIHN0YWNrLiBUaGUgcHJvYmxlbSBvZiAzMiBi aXQgY291bnRlcnMgaXMga25vd24NCmFuZCBoYXMgYmVlbiByZXNvbHZlZCBp biBhcmVhcyBzdWNoIGFzIFNOTVAgY291bnRlcnMgYnkgY3JlYXRpbmcgDQo2 NC1iaXQgY291bnRlcnMgYXMgZGVzY3JpYmVkIGluIFJGQzI4NjMgW1JGQzI4 NjNdLg0KDQpUaGlzIGRvY3VtZW50IHdpbGwgYWRkcmVzcyBhIHdheSB0byBt YWtlIHRoZSBJUHY2IElQSUQgZmllbGQgYXZhaWxhYmxlIA0KYW5kIHVuaXF1 ZSBmb3IgaXRzIHZhbHVhYmxlIGRpYWdub3N0aWMgdXNhZ2UuIEEgRGlhZ25v c3RpYyBPcHRpb24gd2hpY2gNCmlzIGFuIGltcGxlbWVudGF0aW9uIG9mIHRo ZSBEZXN0aW5hdGlvbiBPcHRpb25zIEhlYWRlciBpcyBwcm9wb3NlZA0Kd2hp Y2ggbWF5IGJlIHNlbnQgYnkgc3RhY2tzIGluIGRpYWdub3N0aWMgbW9kZS4g VGhlIGltcGxlbWVudGF0aW9uDQpNQVkgcHJvdmlkZSB0aGUgb3B0aW9uIG9m IGVpdGhlciB0dXJuaW5nIG9uIHRoZSBEaWFnbm9zdGljIE9wdGlvbiBmb3IN CmFsbCBjb25uZWN0aW9ucyBvciB0dXJuIGl0IG9uIGp1c3QgZm9yIHNwZWNp ZmljIGNvbm5lY3Rpb25zLiAgVGhlIG1vcmUNCnNvcGhpc3RpY2F0ZWQgdXNh Z2Ugb2YgdGhpcyBvcHRpb24gd291bGQgYmUgdG8gc2VuZCBpdCBmb3IgYSBz aW5nbGUNCmNvbm5lY3Rpb24gb25seS4NCg0KDQoyLiBDb252ZW50aW9ucyB1 c2VkIGluIHRoaXMgZG9jdW1lbnQNCg0KVGhlIGtleSB3b3JkcyAiTVVTVCIs ICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1Qi LCANCiJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJN QVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIA0KZG9jdW1lbnQgYXJlIHRv IGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMyMTE5IFtSRkMy MTE5XS4NCg0KRWxraW5zICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBK YW51YXJ5IDQsIDIwMTIgICAgICAgICAgIFtQYWdlIDAzXQ0KDQoMDQoNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgSVB2NiBEaWFnbm9zdGlj IE9wdGlvbiAgICAgICBKdWx5IDIwMTENCg0KDQozLiAgQXBwbGljYWJpbGl0 eQ0KDQpUaGUgYmFzZSBJUHY2IHN0YW5kYXJkLCBSRkMyNDYwLCBbUkZDMjQ2 MF0gYWxsb3dzIHRoZSB1c2Ugb2YgDQpleHRlbnNpb24gaGVhZGVycyBzdWNo IGFzIHRoZSBEZXN0aW5hdGlvbiBPcHRpb25zIEhlYWRlciBpbiBvcmRlcg0K dG8gZW5jb2RlIG9wdGlvbmFsIGRlc3RpbmF0aW9uIGluZm9ybWF0aW9uIGlu IGFuIElQdjYgcGFja2V0LiANCkV4dGVuZGVkIGRpYWdub3N0aWMgaW5mb3Jt YXRpb24gc3VjaCBhcyB0aGlzIE1VU1QgYmUgc2VudCBieSANCmltcGxlbWVu dGF0aW9ucyB1cG9uIHJlcXVlc3QuIFRoZSBwcm9wb3NlZCBEaWFnbm9zdGlj IE9wdGlvbiBpcyBhbiANCmltcGxlbWVudGF0aW9uIG9mIHRoZSBEZXN0aW5h dGlvbiBPcHRpb25zIEhlYWRlci4NCg0KDQo0LiAgSVB2NiBEaWFnbm9zdGlj IE9wdGlvbiBGb3JtYXQNCg0KNC4xICBEZXN0aW5hdGlvbiBPcHRpb25zIEhl YWRlcg0KDQpUaGUgRGVzdGluYXRpb24gT3B0aW9ucyBIZWFkZXIgaXMgdXNl ZCB0byBjYXJyeSBvcHRpb25hbCBpbmZvcm1hdGlvbg0KdGhhdCBuZWVkIGJl IGV4YW1pbmVkIG9ubHkgYnkgYSBwYWNrZXQncyBkZXN0aW5hdGlvbiBub2Rl KHMpLiBUaGUgDQpEZXN0aW5hdGlvbiBPcHRpb25zIEhlYWRlciBpcyBpZGVu dGlmaWVkIGJ5IGEgTmV4dCBIZWFkZXIgdmFsdWUgb2YgNjANCmluIHRoZSBp bW1lZGlhdGVseSBwcmVjZWRpbmcgaGVhZGVyIGFuZCBpcyBkZWZpbmVkIGlu IFJGQzI0NjAgW1JGQzI0NjBdLg0KDQoNCjQuMi4gIElQdjYgRGlhZ25vc3Rp YyBPcHRpb24gDQoNClRoZSBJUHY2IERpYWdub3N0aWMgT3B0aW9uIGlzIGFu IGltcGxlbWVudGF0aW9uIG9mIHRoZSBEZXN0aW5hdGlvbg0KT3B0aW9ucyBI ZWFkZXIgKE5leHQgSGVhZGVyIHZhbHVlID0gNjApLiBJdCBpcyB1c2VkIGlu IGEgcGFja2V0IHNlbnQNCmJ5IGEgbm9kZSB0byBmYWNpbGl0YXRlIGRpYWdu b3N0aWNzIGJ5IGluZm9ybWluZyB0aGUgcmVjaXBpZW50IGFuZA0KcGFzc2l2 ZSB2aWV3ZXJzIG9mIHRoZSBwYWNrZXQgc3VjaCBhcyBwYWNrZXQgY2FwdHVy ZSBmYWNpbGl0aWVzIG9mIA0KdGhlIHBhY2tldCdzIElQIElkZW50aWZpZXIu IA0KDQpUaGUgSVB2NiBEaWFnbm9zdGljIE9wdGlvbiBpcyBlbmNvZGVkIGlu IHR5cGUtbGVuZ3RoLXZhbHVlIChUTFYpIA0KZm9ybWF0IGFzIGZvbGxvd3M6 DQoNCg0KMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAg IDIgICAgICAgICAgICAgICAgICAgMw0KMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQor LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgIE9wdGlvbiBU eXBlICB8IE9wdGlvbiBMZW5ndGggfA0KKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQorICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw0K fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCisgICAgICAgICAgICAgICAgICAgICAg ICAgSVAgSWRlbnRpZmllciAgICAgICAgICAgICAgICAgICAgICAgICArDQp8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsNCnwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQpF bGtpbnMgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgNCwg MjAxMiAgICAgICAgICAgW1BhZ2UgMDRdDQoNCgwNCg0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICBJUHY2IERpYWdub3N0aWMgT3B0aW9uICAg ICAgIEp1bHkgMjAxMQ0KDQoNCk9wdGlvbiBUeXBlDQoNClRCRCA9IDB4WFgg KFRCRCkgIFtUbyBiZSBhc3NpZ25lZCBieSBJQU5BXSBbUkZDMjc4MF0NCg0K DQpPcHRpb24gTGVuZ3RoDQoNCjgtYml0IHVuc2lnbmVkIGludGVnZXIuIExl bmd0aCBvZiB0aGUgb3B0aW9uLCBpbiBvY3RldHMsIGV4Y2x1ZGluZyB0aGUN Ck9wdGlvbiBUeXBlIGFuZCBPcHRpb24gTGVuZ3RoIGZpZWxkcy4gVGhpcyBm aWVsZCBNVVNUIGJlIHNldCB0byA2NC4NCg0KDQpJUCBJZGVudGlmaWVyDQoN ClRoZSBJUCBJZGVudGlmaWVyIG9mIHRoZSBwYWNrZXQgZm9yIDY0IGJpdHMu DQoNClRoZSBhbGlnbm1lbnQgcmVxdWlyZW1lbnQgZm9yIHRoZSBJUCBJZGVu dGlmaWVyIG9wdGlvbiBpcyA4bis2Lg0KDQpUaGUgdHdvIGhpZ2hlc3Qtb3Jk ZXIgYml0cyBvZiB0aGUgT3B0aW9uIFR5cGUgZmllbGQgYXJlIGVuY29kZWQg dG8gDQppbmRpY2F0ZSBzcGVjaWZpYyBwcm9jZXNzaW5nIG9mIHRoZSBvcHRp b247IGZvciB0aGUgSVAgSWRlbnRpZmllcg0Kb3B0aW9uLCB0aGVzZSB0d28g Yml0cyBNVVNUIGJlIHNldCB0byAwMC4gVGhpcyBpbmRpY2F0ZXMgdGhlIGZv bGxvd2luZw0KcHJvY2Vzc2luZyByZXF1aXJlbWVudHM6DQoNCiAgIG8gIDAw IC0gc2tpcCBvdmVyIHRoaXMgb3B0aW9uIGFuZCBjb250aW51ZSBwcm9jZXNz aW5nIHRoZSBoZWFkZXIuDQogICANCiAgIG8gIFRoZSBkYXRhIHdpdGhpbiB0 aGUgb3B0aW9uIGNhbm5vdCBjaGFuZ2UgZW4gcm91dGUgdG8gdGhlIHBhY2tl dCdzDQogICAgICBmaW5hbCBkZXN0aW5hdGlvbi4NCgkgIA0KICAgICAgVGhl IElQdjYgRGlhZ25vc3RpYyBPcHRpb24gTVVTVCBiZSBwbGFjZWQgYXMgZm9s bG93czoNCgkgIA0KICAgbyAgQWZ0ZXIgdGhlIFJvdXRpbmcgSGVhZGVyLCBp ZiB0aGF0IGhlYWRlciBpcyBwcmVzZW50DQogICANCiAgIG8gIEJlZm9yZSB0 aGUgRnJhZ21lbnQgSGVhZGVyLCBpZiB0aGF0IGhlYWRlciBpcyBwcmVzZW50 DQoNCiAgIG8gIEJlZm9yZSB0aGUgQUggSGVhZGVyIG9yIEVTUCBIZWFkZXIs IGlmIGVpdGhlciBvbmUgb2YgdGhvc2UgDQogICAgICBoZWFkZXJzIGFyZSBw cmVzZW50Lg0KDQpGb3IgZWFjaCBJUHY2IHBhY2tldCBoZWFkZXIsIHRoZSBJ UHY2IERpYWdub3N0aWMgT3B0aW9uIE1VU1QgTk9UIGFwcGVhcg0KbW9yZSB0 aGFuIG9uY2UuIEhvd2V2ZXIsIGFuIGVuY2Fwc3VsYXRlZCBwYWNrZXQgTUFZ IGNvbnRhaW4gYSBzZXBhcmF0ZQ0KSVB2NiBEaWFnbm9zdGljIE9wdGlvbiBh c3NvY2lhdGVkIHdpdGggZWFjaCBlbmNhcHN1bGF0aW5nIElQIGhlYWRlci4N Cg0KVGhlIGluY2x1c2lvbiBvZiBhIElQdjYgRGlhZ25vc3RpYyBPcHRpb24g aW4gYSBwYWNrZXQgYWZmZWN0cyB0aGUgDQpyZWNlaXZpbmcgbm9kZSdzIHBy b2Nlc3Npbmcgb2Ygb25seSB0aGlzIHNpbmdsZSBwYWNrZXQuIE5vIHN0YXRl IGlzIA0KY3JlYXRlZCBvciBtb2RpZmllZCBpbiB0aGUgcmVjZWl2aW5nIG5v ZGUgYXMgYSByZXN1bHQgb2YgcmVjZWl2aW5nIGEgDQpJUHY2IERpYWdub3N0 aWMgT3B0aW9uIGluIGEgcGFja2V0Lg0KDQpFbGtpbnMgICAgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEphbnVhcnkgNCwgMjAxMiAgICAgICAgICAgW1Bh Z2UgMDVdDQoNCgwNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg ICBJUHY2IERpYWdub3N0aWMgT3B0aW9uICAgICAgIEp1bHkgMjAxMQ0KDQoN CjQuMy4gIEltcGxlbWVudGF0aW9uIENvbnNpZGVyYXRpb25zDQoNCkluIGlt cGxlbWVudGF0aW9uLCBhbiBpbXBsZW1lbnRpbmcgc3RhY2sgbWF5IHNlbmQg dGhpcyBhZGRpdGlvbmFsIGhlYWRlcg0KZm9yIGFsbCBjb25uZWN0aW9ucywg cGVyIGhpZ2hlciBsZXZlbCBwcm90b2NvbCBvciBpbiBhIG1vcmUgDQpzb3Bo aXN0aWNhdGVkIHVzYWdlLCBmb3IgYSBzaW5nbGUgY29ubmVjdGlvbiBvciBm bG93IG9ubHkuDQoNClRoZSBpbml0aWF0aW9uIG9mIHRoaXMgaGVhZGVyIE1V U1QgYmUgZG9uZSB2aWEgYSAnRGVidWcgb24nLydEZWJ1ZyBvZmYnIA0Kc3dp dGNoLiBUaGF0IGlzLCBhIGRpYWdub3N0aWNpYW4gbWF5IGRlY2lkZSB0aGF0 IHRoaXMgaGVhZGVyIGlzIHJlcXVpcmVkDQpmb3IgYSBjZXJ0YWluIHRpbWVm cmFtZSBvciBmb3IgYSBjZXJ0YWluIHNldCBvZiBwYWNrZXRzIGFmdGVyIGEg bmV0d29yaw0KcHJvYmxlbSBpcyBlbmNvdW50ZXJlZC4gVGhlIGRpYWdub3N0 aWNpYW4gbWF5IHRoZW4gaXNzdWUgYSBjb21tYW5kIHRvIA0KdGhlIHN0YWNr IGluZGljYXRpbmcgdGhhdCBhZGRpdGlvbiBvZiB0aGUgSVAgSWRlbnRpZmll ciBoZWFkZXIgc2hvdWxkIA0Kbm93IGJlZ2luLiBUaGlzIGlzIHRoZSAnRGVi dWcgb24nIHN0YXRlLiBBZnRlciBhIGNlcnRhaW4gYW1vdW50IG9mIHRpbWUs DQp0aGVuICdEZWJ1ZyBvZmYnIHNob3VsZCBiZSBpc3N1ZWQgYXMgYSBjb21t YW5kLiAgQWx0ZXJuYXRpdmVseSwgdGhlIA0Kc3RhY2sgbWF5IGhhdmUgYSBm aXhlZCB0aW1lIChmb3IgZXhhbXBsZSwgNSBtaW51dGVzKSBhZnRlciB3aGlj aCBkZWJ1ZyANCm1vZGUgd2lsbCBhdXRvbWF0aWNhbGx5IGJlIHR1cm5lZCBv ZmYuIEluIHRoZWlyIGRlZmF1bHQgY29uZmlndXJhdGlvbiwgDQpJUHY2IG5v ZGVzIFNIT1VMRCBOT1QgaW5jbHVkZSB0aGlzIG9wdGlvbiBpbiBJUHY2IHBh Y2tldHMgdGhhdCB0aGV5IA0Kb3JpZ2luYXRlLiAgVGhhdCBpcywgdGhlIHN3 aXRjaCBvciBzdGF0ZSBTSE9VTEQgZGVmYXVsdCB0byAnRGVidWcgb2ZmJy4N Cg0KQWRkaXRpb25hbGx5LCBpbXBsZW1lbnRlcnMgTVVTVCBwZXJtaXQgYSBz eXN0ZW0gYWRtaW5pc3RyYXRvciB0byBlbmFibGUNCm9yIGRpc2FibGUgaW5j bHVkaW5nIHRoaXMgb3B0aW9uIGluIG9yaWdpbmF0ZWQgSVB2NiBwYWNrZXRz IG9uIGF0IGxlYXN0DQphIHBlci1VcHBlci1Qcm90b2NvbCBiYXNpcyAoZS5n LiBhdCBsZWFzdCBwcm92aWRlIGVuYWJsZS9kaXNhYmxlIA0Kc2VwYXJhdGUg a25vYnMgZm9yIElDTVAsIFVEUCwgVENQLCBvciBTQ1RQLCBpbiBhZGRpdGlv biB0byBhIGtub2IgdG8gDQplbmFibGUgb3IgZGlzYWJsZSBmb3IgYWxsIElQ djYgcGFja2V0cyksIGFuZCBTSE9VTEQgcGVybWl0IGl0IGFsc28gdG8gDQpi ZSBlbmFibGVkIG9yIGRpc2FibGVkIG9uIGEgcGVyLWZsb3cgYmFzaXMuICBU aGlzIGNvbmZpZ3VyYXRpb24gDQpmbGV4aWJpbGl0eSB3b3VsZCBpbmNyZWFz ZSB0aGUgcG90ZW50aWFsIHZhbHVlIG9mIHRoaXMgbmV3IG9wdGlvbiwgYW5k IA0Kd291bGQgbm90IGluY3JlYXNlIGltcGxlbWVudGF0aW9uIGNvbXBsZXhp dHkgdW5kdWx5Lg0KDQpBZGRpdGlvbmFsbHksIHdlIHN1Z2dlc3QgdGhhdCBz dGFja3MgaW1wbGVtZW50IGEgc2VwYXJhdGUgSVBJRCBjb3VudGVyDQpwZXIg Y29ubmVjdGlvbiByYXRoZXIgdGhhbiBhIHNpbmdsZSBjb3VudGVyIGZvciBh bGwgY29ubmVjdGlvbnMuIA0KDQoNCjUuIEJhY2t3YXJkIENvbXBhdGliaWxp dHkNCg0KVGhlIHNjaGVtZSBwcm9wb3NlZCBpbiB0aGlzIGRvY3VtZW50IGlz IGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBhbGwgDQp0aGUgY3VycmVudGx5 IGRlZmluZWQgSVB2NiBleHRlbnNpb24gaGVhZGVycy4gQWNjb3JkaW5nIHRv IFJGQzI0NjAgDQpbUkZDMjQ2MF0sIGlmIHRoZSBkZXN0aW5hdGlvbiBub2Rl IGRvZXMgbm90IHJlY29nbml6ZSB0aGlzIG9wdGlvbiwgaXQgDQpzaG91bGQg c2tpcCBvdmVyIHRoaXMgb3B0aW9uIGFuZCBjb250aW51ZSBwcm9jZXNzaW5n IHRoZSBoZWFkZXIuDQoNCg0KRWxraW5zICAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBKYW51YXJ5IDQsIDIwMTIgICAgICAgICAgIFtQYWdlIDA2XQ0K DQoMDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgSVB2NiBE aWFnbm9zdGljIE9wdGlvbiAgICAgICBKdWx5IDIwMTENCg0KNi4gU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMNCg0KVGhpcyBvcHRpb24gbWlnaHQgYmUgdXNl ZnVsIHRvIHNlY3VyaXR5IGdhdGV3YXlzIHNlZWtpbmcgdG8gaWRlbnRpZnkg DQpvcGVyYXRpb25hbCBzZWN1cml0eSBpc3N1ZXMgb3IgaW4gcHJldmVudGlu ZyBSZXBsYXkgQXR0YWNrcy4NCg0KDQo3LiBJQU5BIENvbnNpZGVyYXRpb25z DQoNCkEgRGVzdGluYXRpb24gT3B0aW9uIHJlcXVpcmVzIGFuIElQdjYgT3B0 aW9uIE51bWJlciBvciBUeXBlIFtSRkMyNDYwXSANCndoaWNoIGlzIDggYml0 cy4NCg0KSEVYLi4uLi4uLi4uYWN0Li5jaGcuLnJlc3QgKDUgYml0cykNCi0t LS0gICAgICAgIC0tLS0gLS0tICAtLS0tDQpUQkQgICAgICAgICAgMDAgICAw ICAgIFRCRCAgIElQdjYgRGlhZ25vc3RpYyBPcHRpb24NCg0KRm9yIHRoZSBJ UHY2IE9wdGlvbiBOdW1iZXIgKFR5cGUpLCB0aGUgZmlyc3QgdHdvIGJpdHMg aW5kaWNhdGUgdGhhdCANCnRoZSBJUHY2IG5vZGUgc2tpcCBvdmVyIHRoaXMg b3B0aW9uIGFuZCBjb250aW51ZSBwcm9jZXNzaW5nIHRoZSBoZWFkZXIgDQpp ZiBpdCBkb2VzIG5vdCByZWNvZ25pc2UgdGhlIG9wdGlvbiB0eXBlLiAgVGhl IHRoaXJkIGJpdCBpbmRpY2F0ZXMgDQp0aGF0IHRoZSBPcHRpb24gRGF0YSBt dXN0IG5vdCBjaGFuZ2UgZW4tcm91dGUsIHdoaWNoIHBlcm1pdHMgdGhpcw0K b3B0aW9uIHRvIGJlIHByb3RlY3RlZCBieSB0aGUgSVAgQXV0aGVudGljYXRp b24gSGVhZGVyLg0KDQoNCjEwLiBSZWZlcmVuY2VzDQoNCjEwLjEuIE5vcm1h dGl2ZSBSZWZlcmVuY2VzDQoNCltSRkM3OTFdIFBvc3RlbCwgSi4sICJJbnRl cm5ldCBQcm90b2NvbCIsIFJGQyA3OTEgLyBTVEQgNSwgU2VwdGVtYmVyDQox OTgxLg0KDQpbUkZDMjQ2MF0gRGVlcmluZywgUy4gYW5kIFIuIEhpbmRlbiwg IkludGVybmV0IFByb3RvY29sLCBWZXJzaW9uIDYNCihJUHY2KSBTcGVjaWZp Y2F0aW9uIiwgUkZDIDI0NjAsIERlY2VtYmVyIDE5OTguDQoNCltSRkMyODYz XSBLLiBNY0Nsb2docmllLCBLLiwgS2FzdGVuaG9seiwgRi4gIlRoZSBJbnRl cmZhY2VzIEdyb3VwIA0KTUlCIiwgUkZDIDI4NjMsIEp1bmUgMjAwMC4NCg0K W1JGQzIxMTldIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4g UkZDcyB0byBJbmRpY2F0ZSANClJlcXVpcmVtZW50IExldmVscyIsIEJDUCAx NCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCltSRkMyNzgwXSBCcmFkbmVy LCBTLiwgUGF4c29uLCBWLiAiSUFOQSBBbGxvY2F0aW9uIEd1aWRlbGluZXMg DQpGb3IgVmFsdWVzIEluIHRoZSBJbnRlcm5ldCBQcm90b2NvbCBhbmQgUmVs YXRlZCBIZWFkZXJzIiwgUkZDIDI3ODAsDQpNYXJjaCAyMDAwLg0KU2VlIGFs c286DQpodHRwOmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvaXB2 Ni1wYXJhbWV0ZXJzDQoNCg0KMTAuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNl cw0KDQpbUkZDNDk2M10gSGVmZm5lciwgSi4sIE1hdGhpcywgTS4sIENoYW5k bGVyLCBCLiwgIklQdjQgUmVhc3NlbWJseSANCkVycm9ycyBhdCBIaWdoIERh dGEgUmF0ZXMiLCBSRkMgNDk2MywgSnVseSAyMDA3Lg0KDQpbRHJhZnQtaXB2 NC1pZF0gVG91Y2gsIEouLCAiVXBkYXRlZCBTcGVjaWZpY2F0aW9uIG9mIHRo ZSBJUHY0IElEIA0KRmllbGQiLCBkcmFmdC1pZXRmLWludGFyZWEtaXB2NC1p ZC11cGRhdGUtMDIudHh0LCBNYXJjaCAyMDExDQoNCkVsa2lucyAgICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA0LCAyMDEyICAgICAgICAg ICBbUGFnZSAwN10NCg0KDA0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgIElQdjYgRGlhZ25vc3RpYyBPcHRpb24gICAgICAgSnVseSAyMDEx DQoNCg0KMTEuIEFja25vd2xlZGdtZW50cw0KDQpUaGUgYXV0aG9ycyB3b3Vs ZCBsaWtlIHRvIHRoYW5rIEZyZWQgQmFrZXIsIEJpbGwgSm91cmlzLCBKb3Nl IElzaWRybyANClIuIEouIEF0a2luc29uIGFuZCBKYW1lcyBBc2h0b24gZm9y IHRoZWlyIHJldmlld3MgYW5kIHN1Z2dlc3Rpb25zIHRoYXQNCm1hZGUgdGhp cyBkb2N1bWVudCBiZXR0ZXIuDQoNClRoaXMgZG9jdW1lbnQgd2FzIHByZXBh cmVkIHVzaW5nIDItV29yZC12Mi4wLnRlbXBsYXRlLmRvdC4NCg0KDQpBdXRo b3JzJyBBZGRyZXNzZXMNCiAgIE5hbGluaSBFbGtpbnMNCiAgIEluc2lkZSBQ cm9kdWN0cywgSW5jLg0KICAgMzZBIFVwcGVyIENpcmNsZQ0KICAgQ2FybWVs IFZhbGxleSwgQ0ENCiAgIFVuaXRlZCBTdGF0ZXMNCg0KICAgUGhvbmU6ICsx IDgzMSA2NTkgODM2MA0KICAgRW1haWw6IG5hbGluaS5lbGtpbnNAaW5zaWRl dGhlc3RhY2suY29tDQoNCg0KICAgTGF3cmVuY2UgS3JhdHprZQ0KICAgSUJN DQogICA4MTIxIEdsZW5icml0dGxlIFdheQ0KICAgUmFsZWlnaCwgTkMgMjc2 MTUNCiAgIFVuaXRlZCBTdGF0ZXMgDQoNCiAgIFBob25lOiArMSA4MDAtODc2 LTg4MDENCiAgIEVtYWlsOiBrcmF0emtlQHVzLmlibS5jb20NCg0KDQogICBN aWNoYWVsIEFja2VybWFubg0KICAgQmx1ZSBDcm9zcyBCbHVlIFNoaWVsZCBv ZiBNaWNoaWdhbg0KICAgUC5PLiBCb3ggMjg4OA0KICAgRGV0cm9pdCwgTWlj aGlnYW4gNDgyMzENCiAgIFVuaXRlZCBTdGF0ZXMNCg0KICAgUGhvbmU6ICsx IDMxMCA0NjAgNDA4MA0KICAgRW1haWw6IG1hY2tlcm1hbm5AYmNic21pLmNv bQ0KDQpFbGtpbnMgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEphbnVh cnkgNCwgMjAxMiAgICAgICAgICAgW1BhZ2UgMDhdDQoMCg== --0-1009496781-1311309532=:77035 Content-Type: text/plain; name="draft-elkins-v6ops-ipv6-diagnostic-header-00.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-elkins-v6ops-ipv6-diagnostic-header-00.txt" DQo2bWFuIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBOLiBFbGtpbnMNCkludGVybmV0IERyYWZ0 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElu c2lkZSBQcm9kdWN0cw0KSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgdHJh Y2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMLiBLcmF0emtlDQpF eHBpcmVzOiBKYW51YXJ5LCAyMDEyICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBJQk0NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0u IEFja2VybWFubg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBCQ0JTIG9mIE1pY2hpZ2FuDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBKdWx5IDIwMTENCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBJUHY2IERpYWdub3N0aWMgT3B0aW9uDQogICAgICAgICAg ICAgIGRyYWZ0LWVsa2lucy12Nm9wcy1pcHY2LWRpYWdub3N0aWMtaGVhZGVy LTAwLnR4dA0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNClRoaXMgSW50ZXJu ZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0 aCB0aGUgcHJvdmlzaW9ucw0Kb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCklu dGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIElu dGVybmV0IEVuZ2luZWVyaW5nIFRhc2sNCkZvcmNlIChJRVRGKSwgaXRzIGFy ZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQgb3RoZXIg Z3JvdXBzDQptYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRz IGFzIEludGVybmV0LURyYWZ0cy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBk cmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9u dGhzIA0KYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xl dGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgDQp0aW1lLiBJdCBpcyBp bmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJl bmNlIG1hdGVyaWFsDQpvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iDQoNClRoZSBsaXN0IG9mIGN1cnJlbnQgSW50 ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KaHR0cDovL3d3dy5p ZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQoNClRoZSBsaXN0IG9m IEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNj ZXNzZWQgYXQNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCg0K VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKYW51YXJ5IDQs IDIwMTIuDQoNCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQpDb3B5cmlnaHQgKGMp IDIwMTEgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBh cyB0aGUgZG9jdW1lbnQNCmF1dGhvcnMuIEFsbCByaWdodHMgcmVzZXJ2ZWQu DQoNClRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRo ZSBJRVRGIFRydXN0J3MgTGVnYWwgUHJvdmlzaW9ucw0KUmVsYXRpbmcgdG8g SUVURiBEb2N1bWVudHMgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vu c2UtaW5mbykgaW4gDQplZmZlY3Qgb24gdGhlIGRhdGUgb2YgcHVibGljYXRp b24gb2YgdGhpcyBkb2N1bWVudC4gUGxlYXNlIHJldmlldyB0aGVzZSANCmRv Y3VtZW50cyBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdo dHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIA0KcmVzcGVjdCB0byB0aGlzIGRv Y3VtZW50Lg0KDQpBYnN0cmFjdA0KDQpUaGUgSVB2NCBtYWluIGhlYWRlciBj b250YWluZWQgYSAxNi1iaXQgSVAgSWRlbnRpZmljYXRpb24gKElQSUQpIGZp ZWxkDQp0byBiZSB1c2VkIGZvciBmcmFnbWVudGF0aW9uIGFuZCByZWFzc2Vt Ymx5LiAgSW4gcHJhY3RpY2UsIHRoaXMgZmllbGQgDQp3YXMgY29tbW9ubHkg dXNlZCBieSBuZXR3b3JrIGRpYWdub3N0aWNpYW5zIGZvciB0cmFja2luZyBw YWNrZXRzLiBJbiANCklQdjYsIHRoZSBJUElEIGhhcyBiZWVuIG1vdmVkIHRv IHRoZSBGcmFnbWVudCBoZWFkZXIuICBUaGUgbG9zcyBvZiB0aGlzDQpmaWVs ZCBpcyBhIGhpbmRyYW5jZSB0byBkaWFnbm9zdGljcy4NCg0KRWxraW5zICAg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDQsIDIwMTIgICAg ICAgICAgIFtQYWdlIDAxXQ0KDQoMDQoNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgSVB2NiBEaWFnbm9zdGljIE9wdGlvbiAgICAgICBKdWx5 IDIwMTENCg0KVGFibGUgb2YgQ29udGVudHMNCg0KMS4gSW50cm9kdWN0aW9u IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uIDINCjYuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAzIA0KNy4g SUFOQSBDb25zaWRlcmF0aW9ucyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uIDMgDQoxMC4gUmVmZXJlbmNlcyAuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4gMyANCiAgICA0LjEuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiAzIA0KICAgIDQu Mi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uIDMNCjExLiBBY2tub3dsZWRnbWVudHMgLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LiA0DQoNCg0KMS4gSW50cm9kdWN0aW9uDQoNCkluIElQdjQsIHRoZSAxNiBi aXQgSVAgSWRlbnRpZmljYXRpb24gKElQSUQpIGZpZWxkIGlzIGxvY2F0ZWQg YXQgYW4gDQpvZmZzZXQgb2YgNCBieXRlcyBpbnRvIHRoZSBJUHY0IGhlYWRl ciBhbmQgaXMgZGVzY3JpYmVkIGluIFJGQzc5MSANCltSRkM3OTFdLiBJbiBJ UHY2LCBpdCBpcyBhIDMyIGJpdCBmaWVsZCBjb250YWluZWQgaW4gdGhlIEZy YWdtZW50IEhlYWRlcg0KZGVmaW5lZCBieSBzZWN0aW9uIDQuNSBvZiBSRkMy NDYwIFtSRkMyNDYwXS4gVW5mb3J0dW5hdGVseSwgdW5sZXNzIA0KZnJhZ21l bnRhdGlvbiBpcyBiZWluZyBkb25lIGJ5IHRoZSBzb3VyY2Ugbm9kZSwgdGhl IHBhY2tldCB3aWxsIG5vdA0KY29udGFpbiB0aGlzIEZyYWdtZW50IEhlYWRl ciwgYW5kIHRoZXJlZm9yZSB3aWxsIGhhdmUgbm8gSWRlbnRpZmljYXRpb24N CmZpZWxkLg0KDQpUaGUgaW50ZW5kZWQgcHVycG9zZSBvZiB0aGUgSVBJRCBm aWVsZCBpcyB0byBlbmFibGUgZnJhZ21lbnRhdGlvbiBhbmQNCnJlYXNzZW1i bHksIGFuZCBhcyBjdXJyZW50bHkgc3BlY2lmaWVkIGlzIHJlcXVpcmVkIHRv IGJlIHVuaXF1ZSB3aXRoaW4NCnRoZSBtYXhpbXVtIHNlZ21lbnQgbGlmZXRp bWUgKE1TTCkgb24gYWxsIGRhdGFncmFtcy4gVGhlIE1TTCBpcyBvZnRlbiAy DQptaW51dGVzLg0KDQpJbiBwcmFjdGljZSwgdGhlIElQSUQgZmllbGQgaXMg dXNlZCBmb3IgbW9yZSB0aGFuIGZyYWdtZW50YXRpb24uDQpEdXJpbmcgbmV0 d29yayBkaWFnbm9zdGljcywgcGFja2V0IHRyYWNlcyBtYXkgYmUgdGFrZW4g YXQgbXVsdGlwbGUgDQpwbGFjZXMgYWxvbmcgdGhlIHBhdGggb3IgYXQgdGhl IHNvdXJjZSBhbmQgZGVzdGluYXRpb24uIFRoZW4sIHBhY2tldHMgDQpjYW4g YmUgbWF0Y2hlZCBieSBsb29raW5nIGF0IHRoZSBJUElELiBPYnZpb3VzbHks IHRoZSB0aW1lIGF0IGVhY2ggDQpkZXZpY2Ugd2lsbCBkaWZmZXIgYWNjb3Jk aW5nIHRvIHRoZSBjbG9jayBvbiB0aGF0IGRldmljZTsgc28gYW5vdGhlciAN Cm1ldHJpYyBpcyByZXF1aXJlZC4gVGhpcyBtZXRob2Qgb2YgdGFraW5nIG11 bHRpcGxlIHRyYWNlcyBhbG9uZyB0aGUgcGF0aA0KaXMgb2Ygc3BlY2lhbCB1 c2Ugb24gbGFyZ2UgbXVsdGktdGllciBuZXR3b3JrcyB0byBzZWUgd2hlcmUg dGhlIHBhY2tldA0KbG9zcyBvciBwYWNrZXQgY29ycnVwdGlvbiBpcyBoYXBw ZW5pbmcuICBNdWx0aS10aWVyIG5ldHdvcmtzIGFyZSB0aG9zZSANCndoaWNo IGhhdmUgbXVsdGlwbGUgcm91dGVycyBvciBzd2l0Y2hlcyBvbiB0aGUgcGF0 aCBiZXR3ZWVuIHRoZSBzZW5kZXINCmFuZCB0aGUgcmVjZWl2ZXIuDQoNClRo ZSBpbmNsdXNpb24gb2YgdGhpcyBvcHRpb24gbWFrZXMgaXQgZWFzaWVyIGZv ciBhIGRldmljZSBpbiB0aGUgbWlkZGxlDQpvZiB0aGUgbmV0d29yayBvciBv biB0aGUgcmVjZWl2aW5nIGVuZCBvZiB0aGUgbmV0d29yayB0byBpZGVudGlm eSBmbG93cyANCmJlbG9uZ2luZyB0byBhIHNpbmdsZSBub2RlLCBldmVuIGlm IHRoYXQgbm9kZSBtaWdodCBoYXZlIGEgZGlmZmVyZW50IElQDQphZGRyZXNz LiBGb3IgZXhhbXBsZSwgaWYgdGhlIHNlbmRpbmcgbm9kZSBpcyBhIG1vYmls ZSBsYXB0b3Agd2l0aCBhIA0Kd2lyZWxlc3MgY29ubmVjdGlvbiB0byB0aGUg SW50ZXJuZXQuICANCg0KRWxraW5zICAgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBKYW51YXJ5IDQsIDIwMTIgICAgICAgICAgIFtQYWdlIDAyXQ0KDQoM DQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgSVB2NiBEaWFn bm9zdGljIE9wdGlvbiAgICAgICBKdWx5IDIwMTENCg0KDQpIYXZpbmcgc2Fp ZCB0aGF0LCBhIGtub3duIHByb2JsZW0gd2l0aCB0aGUgdW5pcXVlbmVzcyBv ZiB0aGUgSVB2NCBJRCBpcyANCnRoYXQgc2luY2UgdGhlIGZpZWxkIGlzIG9u bHkgMTYgYml0cywgdGhlbiBmb3IgaGlnaCBzcGVlZCBkZXZpY2VzLCANCndy YXBwaW5nIHdpbGwgb2NjdXIuIEFzIGRpc2N1c3NlZCBpbiBSRkM0OTYzIFtS RkM0OTYzXSBhbmQgDQpkcmFmdC1pZXRmLWludGFyZWEtaXB2NC1pZC11cGRh dGUtMDIudHh0IFtEcmFmdC1pcHY0LWlkXSwgaWYgdGhlIA0KdW5pcXVlbmVz cyByZXF1aXJlbWVudCB3ZXJlIHN0cmljdGx5IGVuZm9yY2VkLCBhbGwgY29u bmVjdGlvbnMgd291bGQgYmUgDQpsaW1pdGVkIHRvIGEgbWF4aW11bSBzcGVl ZCBvZiA2LjQgTWJwcy4gQ2xlYXJseSwgdGhpcyB1bmlxdWVuZXNzIA0KcmVx dWlyZW1lbnQgaXMgd2lkZWx5IGlnbm9yZWQuDQoNCkluIGZhY3QsIHRoZSBp bXBsZW1lbnRhdGlvbiBvZiB0aGUgSVBJRCBmaWVsZCB2YXJpZXMuICBTb21l IA0KaW1wbGVtZW50YXRpb25zIGhhdmUgdGhlIHNhbWUgSVBJRCBjb3VudGVy IGZvciBhbGwgY29ubmVjdGlvbnM7IHNvbWUgDQpoYXZlIGFuIElQSUQgY291 bnRlciBvbiBhIHBlciBjb25uZWN0aW9uIGJhc2lzLiAgU29tZSBpbXBsZW1l bnRhdGlvbnMNCmluY3JlbWVudCB0aGUgSVBJRCBieSBvbmUgZWFjaCB0aW1l IGEgcGFja2V0IGlzIHNlbnQgb3V0OyBzb21lDQppbmNyZW1lbnQgYnkgdHdv LiAgDQoNCkluIElQdjYsIHRoZSBJUElEIGZpZWxkLCB3aGljaCBpcyBpbiB0 aGUgRnJhZ21lbnQgSGVhZGVyLCBoYXMgYmVlbiANCmluY3JlYXNlZCB0byAz MiBiaXRzLiBUaGlzIG1heSBuZWVkIHRvIGJlIHJlY29uc2lkZXJlZCBhcyBk YXRhIHJhdGVzIA0KaW5jcmVhc2UgYnV0IGlmIHRoZSBJUElEIGlzIHVzZWQg Zm9yIGZyYWdtZW50YXRpb24gYW5kIHJlYXNzZW1ibHkgDQphbG9uZSwgdGhl IHJlcXVpcmVtZW50IGZvciB1bmlxdWVuZXNzIHdpdGhpbiB0aGUgTVNMIHBl cmlvZCBpcyANCmdlbmVyYWxseSBub3QgYW4gaXNzdWUgdG9kYXkuIFJGQzQ5 NjMgW1JGQzQ5NjNdIGRpc2N1c3NlcyB0aGUgaXNzdWUgb2YgDQpyZWFzc2Vt Ymx5IGVycm9ycyBhdCBoaWdoIGRhdGEgcmF0ZXMgZm9yIElQdjQgd2l0aCBh IDE2LWJpdCBjb3VudGVyLg0KDQpIb3dldmVyLCBmb3IgaXRzIGRlLWZhY3Rv IGRpYWdub3N0aWMgbW9kZSB1c2FnZSwgYW4gSVBJRCBuZWVkcyB0byBiZSAN CmF2YWlsYWJsZSB3aGV0aGVyIG9yIG5vdCBmcmFnbWVudGF0aW9uIG9jY3Vy cywgYW5kIG5lZWRzIHRvIGJlIHVuaXF1ZQ0KaW4gdGhlIGNvbnRleHQgb2Yg dGhlIGVudGlyZSBzZXNzaW9uLCBhbmQgYWNyb3NzIGFsbCB0aGUgY29ubmVj dGlvbnMNCmNvbnRyb2xsZWQgYnkgdGhlIHN0YWNrLiBUaGUgcHJvYmxlbSBv ZiAzMiBiaXQgY291bnRlcnMgaXMga25vd24NCmFuZCBoYXMgYmVlbiByZXNv bHZlZCBpbiBhcmVhcyBzdWNoIGFzIFNOTVAgY291bnRlcnMgYnkgY3JlYXRp bmcgDQo2NC1iaXQgY291bnRlcnMgYXMgZGVzY3JpYmVkIGluIFJGQzI4NjMg W1JGQzI4NjNdLg0KDQoNCjYuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoN ClRoZXJlIGFyZSBubyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4NCg0KDQo3 LiBJQU5BIENvbnNpZGVyYXRpb25zDQoNClRoZXJlIGFyZSBubyBJQU5BIGNv bnNpZGVyYXRpb25zLg0KDQoNCjEwLiBSZWZlcmVuY2VzDQoNCjEwLjEuIE5v cm1hdGl2ZSBSZWZlcmVuY2VzDQoNCltSRkM3OTFdIFBvc3RlbCwgSi4sICJJ bnRlcm5ldCBQcm90b2NvbCIsIFJGQyA3OTEgLyBTVEQgNSwgU2VwdGVtYmVy DQoxOTgxLg0KDQpbUkZDMjQ2MF0gRGVlcmluZywgUy4gYW5kIFIuIEhpbmRl biwgIkludGVybmV0IFByb3RvY29sLCBWZXJzaW9uIDYNCihJUHY2KSBTcGVj aWZpY2F0aW9uIiwgUkZDIDI0NjAsIERlY2VtYmVyIDE5OTguDQoNCltSRkMy ODYzXSBLLiBNY0Nsb2docmllLCBLLiwgS2FzdGVuaG9seiwgRi4gIlRoZSBJ bnRlcmZhY2VzIEdyb3VwIA0KTUlCIiwgUkZDIDI4NjMsIEp1bmUgMjAwMC4N Cg0KDQoxMC4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCltSRkM0OTYz XSBIZWZmbmVyLCBKLiwgTWF0aGlzLCBNLiwgQ2hhbmRsZXIsIEIuLCAiSVB2 NCBSZWFzc2VtYmx5IA0KRXJyb3JzIGF0IEhpZ2ggRGF0YSBSYXRlcyIsIFJG QyA0OTYzLCBKdWx5IDIwMDcuDQoNCltEcmFmdC1pcHY0LWlkXSBUb3VjaCwg Si4sICJVcGRhdGVkIFNwZWNpZmljYXRpb24gb2YgdGhlIElQdjQgSUQgDQpG aWVsZCIsIGRyYWZ0LWlldGYtaW50YXJlYS1pcHY0LWlkLXVwZGF0ZS0wMi50 eHQsIE1hcmNoIDIwMTENCg0KRWxraW5zICAgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBKYW51YXJ5IDQsIDIwMTIgICAgICAgICAgIFtQYWdlIDAzXQ0K DQoMDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgSVB2NiBE aWFnbm9zdGljIE9wdGlvbiAgICAgICBKdWx5IDIwMTENCg0KDQoxMS4gQWNr bm93bGVkZ21lbnRzDQoNClRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhh bmsgRnJlZCBCYWtlciwgQmlsbCBKb3VyaXMsIEpvc2UgSXNpZHJvIA0KUi4g Si4gQXRraW5zb24gYW5kIEphbWVzIEFzaHRvbiBmb3IgdGhlaXIgcmV2aWV3 cyBhbmQgc3VnZ2VzdGlvbnMgdGhhdA0KbWFkZSB0aGlzIGRvY3VtZW50IGJl dHRlci4NCg0KVGhpcyBkb2N1bWVudCB3YXMgcHJlcGFyZWQgdXNpbmcgMi1X b3JkLXYyLjAudGVtcGxhdGUuZG90Lg0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nl cw0KICAgTmFsaW5pIEVsa2lucw0KICAgSW5zaWRlIFByb2R1Y3RzLCBJbmMu DQogICAzNkEgVXBwZXIgQ2lyY2xlDQogICBDYXJtZWwgVmFsbGV5LCBDQQ0K ICAgVW5pdGVkIFN0YXRlcw0KDQogICBQaG9uZTogKzEgODMxIDY1OSA4MzYw DQogICBFbWFpbDogbmFsaW5pLmVsa2luc0BpbnNpZGV0aGVzdGFjay5jb20N Cg0KDQogICBMYXdyZW5jZSBLcmF0emtlDQogICBJQk0NCiAgIDgxMjEgR2xl bmJyaXR0bGUgV2F5DQogICBSYWxlaWdoLCBOQyAyNzYxNQ0KICAgVW5pdGVk IFN0YXRlcyANCg0KICAgUGhvbmU6ICsxIDgwMC04NzYtODgwMQ0KICAgRW1h aWw6IGtyYXR6a2VAdXMuaWJtLmNvbQ0KDQoNCiAgIE1pY2hhZWwgQWNrZXJt YW5uDQogICBCbHVlIENyb3NzIEJsdWUgU2hpZWxkIG9mIE1pY2hpZ2FuDQog ICBQLk8uIEJveCAyODg4DQogICBEZXRyb2l0LCBNaWNoaWdhbiA0ODIzMQ0K ICAgVW5pdGVkIFN0YXRlcw0KDQogICBQaG9uZTogKzEgMzEwIDQ2MCA0MDgw DQogICBFbWFpbDogbWFja2VybWFubkBiY2JzbWkuY29tDQoNCkVsa2lucyAg ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA0LCAyMDEyICAg ICAgICAgICBbUGFnZSAwNF0NCgwK --0-1009496781-1311309532=:77035-- From victor.kuarsingh@gmail.com Thu Jul 21 21:51:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DC521F85C7 for ; Thu, 21 Jul 2011 21:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7hUV2SH9wfI for ; Thu, 21 Jul 2011 21:51:20 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57CCC21F85C6 for ; Thu, 21 Jul 2011 21:51:20 -0700 (PDT) Received: by gxk19 with SMTP id 19so1102667gxk.31 for ; Thu, 21 Jul 2011 21:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=3f6+2TGec3SQE2nr3m04PbWEeVJs1tRvP8drzlPp7y0=; b=bJ5dH0pb9u0cpUTdAN+P8JKSmDl6Xbdp2IMYXYe7d7to/AYPFzs+EZNK9GQze2+dY7 Go9zQgotJh1sDsuXMWDkeme64kblk1qqIMjm4Ch5UDeMAEvNAP715eLb1o1n/3+xyLql ZakxkK4GLNmCmCXwCqVVKHILWurZNdgK7tT2Y= Received: by 10.90.255.12 with SMTP id c12mr1463431agi.1.1311310279743; Thu, 21 Jul 2011 21:51:19 -0700 (PDT) Received: from [192.168.1.128] (CPEc0c1c0d0d7b7-CM001a666bafe6.cpe.net.cable.rogers.com [99.230.122.203]) by mx.google.com with ESMTPS id p40sm2169580ann.33.2011.07.21.21.51.16 (version=SSLv3 cipher=OTHER); Thu, 21 Jul 2011 21:51:18 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Fri, 22 Jul 2011 00:51:11 -0400 From: Victor Kuarsingh To: "Rajiv Asati (rajiva)" , Brian E Carpenter , IPv6 Operations Message-ID: Thread-Topic: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0575FDC5@XMB-RCD-111.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 04:51:21 -0000 Rajiv, I had considered some additional content around translation. Most of the current content surrounds the option of Native Dual Stack using CGN as the IPv4 path assist when IPv4 runs out. This particular draft then provides an incremental future option to optimize the (if necessary) translation for IPv4 with DS-Lite. I had stuck with technologies (thus far) which are currently deployable, or are near-deployable. Did you have a specific additional option in mind which may be of consideration? Although I had not specified anything else, given that phase 3 is a future option, there could be more then one listed (although I was looking to make it relevant to operators focusing on existing code and functionality - to the best extent possible). As an Example: One additional option that was noted to me offline was NAT64. I think NAT64 poses challenges in the near to mid term future (in Wireline Networks) since there is way too much IPv4-only equipment in customer prem today. I am hesitant to promote options which are based on eliminating variables I don't control - consumer controlled and operated equipment. Therefore assumed Dual Stack home for the foreseeable future (the realist in me). On the NAT64 note, I do think it is usable in some environments (like some Wireless services), but I stuck with common Wireline environments for now. Regards, Victor K On 11-07-21 10:02 AM, "Rajiv Asati (rajiva)" wrote: >Victor, > >Do you plan on beefing up 'translation' based options in -01 version? > >Cheers, >Rajiv > From roland.bless@kit.edu Thu Jul 21 22:41:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE4321F866A; Thu, 21 Jul 2011 22:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETJGdMEovsHQ; Thu, 21 Jul 2011 22:41:53 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9A22A21F8669; Thu, 21 Jul 2011 22:41:52 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1Qk8Ub-0001kM-Na; Fri, 22 Jul 2011 07:41:51 +0200 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1Qk8Ub-0004nJ-JS; Fri, 22 Jul 2011 07:41:45 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 788C6A800D4; Fri, 22 Jul 2011 07:41:45 +0200 (CEST) Message-ID: <4E290D99.3030300@kit.edu> Date: Fri, 22 Jul 2011 07:41:45 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> In-Reply-To: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1311313311.417554000 Cc: ipv6@ietf.org Subject: Re: [v6ops] IPv6 Diagnostic Option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 05:41:54 -0000 Hi, On 22.07.2011 06:38, nalini.elkins@insidethestack.com wrote: > Would love to get feedback on an Internet Draft we have submitted. > The issue we are addressing is that the IP Identification field which > was available with IPv4 in the main header is available with IPv6 > only in the Fragment Header. I don't think that your proposed solution is necessary, since IPv6 has the Flow Label, that - if set by the source - may be very well suited for your purpose (tracking flows along a path). Please see http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/ for more details. Kind regards, Roland From ek@google.com Thu Jul 21 23:35:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3644511E8086 for ; Thu, 21 Jul 2011 23:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVWF4ZHqZyLo for ; Thu, 21 Jul 2011 23:35:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 726D411E8075 for ; Thu, 21 Jul 2011 23:35:40 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p6M6ZdOe002345 for ; Thu, 21 Jul 2011 23:35:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311316539; bh=kRxK+sWY51G7WW35LXKetz0sROs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=rvQkpbu9JXDcqvju1lUq7AuDr0MqyHBy25r69OGVh9WsKXonvGpDOQM9JOytYaaJ0 aRy9yTY4rOZ8w8AAYbXEg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=n1lMcD61CynWY3v2gjeyYj8Yz5Vf/yAPsNgET9yljKj1QOrAhKHTkQs86ufN7qN+V dhgcjBH6yTH4KLaDGF7yw== Received: from qyk38 (qyk38.prod.google.com [10.241.83.166]) by hpaq11.eem.corp.google.com with ESMTP id p6M6YtHj023358 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 21 Jul 2011 23:35:38 -0700 Received: by qyk38 with SMTP id 38so1207428qyk.20 for ; Thu, 21 Jul 2011 23:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ioT0gSkT6dA+jd5vmIusFdyjhJj6uUO4BeADtmOmLsU=; b=M1IrWQ6H5/fpV2lN8ivPhzl2g16oxjPbYRfpzLrPlAyfmD8pjVeTS6gnxbQkeznMpy NCfQtj4VCE/QOrrVxEeQ== MIME-Version: 1.0 Received: by 10.224.200.5 with SMTP id eu5mr976844qab.189.1311316537786; Thu, 21 Jul 2011 23:35:37 -0700 (PDT) Received: by 10.229.136.66 with HTTP; Thu, 21 Jul 2011 23:35:37 -0700 (PDT) In-Reply-To: <4E290D99.3030300@kit.edu> References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> <4E290D99.3030300@kit.edu> Date: Fri, 22 Jul 2011 15:35:37 +0900 Message-ID: From: Erik Kline To: Roland Bless Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: v6ops@ietf.org, ipv6@ietf.org Subject: Re: [v6ops] IPv6 Diagnostic Option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 06:35:41 -0000 > I don't think that your proposed solution is necessary, since > IPv6 has the Flow Label, that - if set by the source - may be > very well suited for your purpose (tracking flows along a path). > Please see http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/ > for more details. Agreed. I also think use of the flowlabel will prove operationally simpler. Some devices drop IPv6 packets that have any kind of headers, even fragment headers, since they lack the ability to look beyond these headers at line rate. From roland.bless@kit.edu Fri Jul 22 00:59:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E23F21F869E; Fri, 22 Jul 2011 00:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpC5DPeEb1US; Fri, 22 Jul 2011 00:59:55 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD4D21F869D; Fri, 22 Jul 2011 00:59:54 -0700 (PDT) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1QkAeA-0006zQ-OA; Fri, 22 Jul 2011 09:59:52 +0200 Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by irams1.ira.uni-karlsruhe.de with esmtp port 25 id 1QkAeA-0003kj-Dc; Fri, 22 Jul 2011 09:59:46 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 3FD52A80036; Fri, 22 Jul 2011 09:59:46 +0200 (CEST) Message-ID: <4E292DF2.5000607@kit.edu> Date: Fri, 22 Jul 2011 09:59:46 +0200 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Erik Kline References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> <4E290D99.3030300@kit.edu> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1311321592.459773000 Cc: v6ops@ietf.org, ipv6@ietf.org Subject: Re: [v6ops] IPv6 Diagnostic Option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 07:59:56 -0000 Hi Erik, On 22.07.2011 08:35, Erik Kline wrote: >> I don't think that your proposed solution is necessary, since >> IPv6 has the Flow Label, that - if set by the source - may be >> very well suited for your purpose (tracking flows along a path). >> Please see http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/ >> for more details. > > I also think use of the flowlabel will prove operationally simpler. Yes, fully agree since a) the Flow Label is part of the standard common IPv6 header, thus always present and easier to process (even in the fast path) as you also pointed out. b) Useful Flow Label support in end-systems (i.e., setting the Flow Label correctly) is more likely than support for this newly suggested additional option, once it would have been adopted. c) it is really unclear how you would enable the use of the proposed option in end-systems on demand. In case of debugging a network problem you need to enable this option later, if not too late. Regards, Roland From arturo.servin@gmail.com Fri Jul 22 04:37:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27E221F87BD; Fri, 22 Jul 2011 04:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd6JFf3YtSrx; Fri, 22 Jul 2011 04:37:13 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB2621F8793; Fri, 22 Jul 2011 04:37:12 -0700 (PDT) Received: by qwc23 with SMTP id 23so1759066qwc.31 for ; Fri, 22 Jul 2011 04:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=w3JeqfAVcBJtcInSOvBhvYsRvx/fY4TXfWKVO1WO9cM=; b=mQLC6MQsQPSBy6GBFv32g6dGPstyG4EsD5mG2arIKgl9ij01B0rT41/d/5Ud3mO9qM oNQ191NQoVm37rIx0Yh+AH/w2yxRynKKjFfyBKN4cXSn5QJ5Dn7slkEXuhjacG7qdKdv 1/ik51m0+dadZHMhzexpYocvtsNAa4nQSkDvI= Received: by 10.224.179.195 with SMTP id br3mr1205083qab.284.1311334632355; Fri, 22 Jul 2011 04:37:12 -0700 (PDT) Received: from [192.168.1.101] (r186-48-209-197.dialup.adsl.anteldata.net.uy [186.48.209.197]) by mx.google.com with ESMTPS id w12sm856284qct.12.2011.07.22.04.37.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jul 2011 04:37:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <4E292DF2.5000607@kit.edu> Date: Fri, 22 Jul 2011 08:37:06 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9B486090-29D8-41C9-87B2-01D5F8D9FECE@gmail.com> References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> <4E290D99.3030300@kit.edu> <4E292DF2.5000607@kit.edu> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org Subject: Re: [v6ops] IPv6 Diagnostic Option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 11:37:13 -0000 Nalini Basically I agree with what others said. If there were any reason for not using the flow label, I think = you should state it very clearly in the document.=20 Regards, .as On 22 Jul 2011, at 04:59, Roland Bless wrote: > Hi Erik, >=20 > On 22.07.2011 08:35, Erik Kline wrote: >>> I don't think that your proposed solution is necessary, since >>> IPv6 has the Flow Label, that - if set by the source - may be >>> very well suited for your purpose (tracking flows along a path). >>> Please see = http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/ >>> for more details. >>=20 >> I also think use of the flowlabel will prove operationally simpler. >=20 > Yes, fully agree since > a) the Flow Label is part of the standard common IPv6 header, thus > always present and easier to process (even in the fast path) as > you also pointed out. > b) Useful Flow Label support in end-systems (i.e., setting the Flow > Label correctly) is more likely than support for this newly > suggested additional option, once it would have been adopted. > c) it is really unclear how you would enable the use of the proposed > option in end-systems on demand. In case of debugging a network > problem you need to enable this option later, if not too late. >=20 > Regards, > Roland > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gert@space.net Fri Jul 22 06:48:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CD021F89A1 for ; Fri, 22 Jul 2011 06:48:48 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3trMswO6zh0 for ; Fri, 22 Jul 2011 06:48:47 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8039C21F8515 for ; Fri, 22 Jul 2011 06:48:46 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id EFC8DF853D for ; Fri, 22 Jul 2011 15:48:44 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A71C1F853F for ; Fri, 22 Jul 2011 15:48:44 +0200 (CEST) Received: (qmail 53525 invoked by uid 1007); 22 Jul 2011 15:48:44 +0200 Date: Fri, 22 Jul 2011 15:48:44 +0200 From: Gert Doering To: "Livingood, Jason" Message-ID: <20110722134844.GP2304@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 13:48:48 -0000 Hi, On Thu, Jul 21, 2011 at 07:50:15PM +0000, Livingood, Jason wrote: > I also suggest that the dates don't apply, since every mail provider is at a different stage of readiness. As a result, sections 5, 6, and 7 probably should not have dates and may instead be Phase 1, 2 and 3 or something like that. I think that the dates in there are actually the main contribution of that draft. Create the necessary push for those that still have no IPv6 on their mail systems to do it in a *timely* way. Gert Doering -- running an IPv6-enabled MTA since about 10 years or so -- 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 (89) 32356-444 USt-IdNr.: DE813185279 From moore@network-heretics.com Fri Jul 22 07:00:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2820121F85CA for ; Fri, 22 Jul 2011 07:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnQi79YeBqb8 for ; Fri, 22 Jul 2011 07:00:05 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9089121F85A3 for ; Fri, 22 Jul 2011 07:00:05 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 41C7021260; Fri, 22 Jul 2011 10:00:05 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 22 Jul 2011 10:00:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=DoidgBOoim2165Io0h/FY0D/VhQ=; b=On 78VQnaagAOBdTCXskXJOZS7UVwaxdW/dHxRKbuhl4LRGOQWOGhYq1oVZ93Nl9fhM LfZMtHI0nYZg+vO97XL3WNZ5LkNwsJGa+lrvV4+OW1F8J0bXCasE5ERaNFuYaz1U Kf5ctn276ORhvwhCM1CJOPBf1Iww6+cPLktE1FIMk= X-Sasl-enc: 1zji2Jccl9EOigDDU4E04MCqHZddxm0pzK4mj74aq7qe 1311343205 Received: from [10.59.1.76] (static-71-166-174-114.washdc.east.verizon.net [71.166.174.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 8F932406271; Fri, 22 Jul 2011 10:00:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110722134844.GP2304@Space.Net> Date: Fri, 22 Jul 2011 09:59:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110722134844.GP2304@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1084) Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:00:06 -0000 On Jul 22, 2011, at 9:48 AM, Gert Doering wrote: > On Thu, Jul 21, 2011 at 07:50:15PM +0000, Livingood, Jason wrote: >> I also suggest that the dates don't apply, since every mail provider = is at a different stage of readiness. As a result, sections 5, 6, and 7 = probably should not have dates and may instead be Phase 1, 2 and 3 or = something like that. >=20 > I think that the dates in there are actually the main contribution of > that draft. Create the necessary push for those that still have no > IPv6 on their mail systems to do it in a *timely* way. I think the dates in the draft are completely disconnected from reality. Keith From gert@space.net Fri Jul 22 07:17:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4F421F8876 for ; Fri, 22 Jul 2011 07:17:28 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ-9ROHNgD5x for ; Fri, 22 Jul 2011 07:17:28 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBCE21F886C for ; Fri, 22 Jul 2011 07:17:27 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id A2D44F853E for ; Fri, 22 Jul 2011 16:17:26 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8364EF8549 for ; Fri, 22 Jul 2011 16:17:26 +0200 (CEST) Received: (qmail 63641 invoked by uid 1007); 22 Jul 2011 16:17:26 +0200 Date: Fri, 22 Jul 2011 16:17:26 +0200 From: Gert Doering To: Keith Moore Message-ID: <20110722141726.GS2304@Space.Net> References: <20110722134844.GP2304@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zMxPFfwyjSN7AMOh" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker , "John R. Levine" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:17:28 -0000 --zMxPFfwyjSN7AMOh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jul 22, 2011 at 09:59:35AM -0400, Keith Moore wrote: > On Jul 22, 2011, at 9:48 AM, Gert Doering wrote: >=20 > > I think that the dates in there are actually the main contribution of > > that draft. Create the necessary push for those that still have no > > IPv6 on their mail systems to do it in a *timely* way. >=20 > I think the dates in the draft are completely disconnected from reality. Indeed, given that IPv6 testing should have been done long ago, and we should already be well into Phase 2. 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 (89) 32356-444 USt-IdNr.: DE813185279 --zMxPFfwyjSN7AMOh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTimGdqkuBuNlUUl1AQJzGgQAqnyjnIX6DEFUXhe04HPFZgfAIhyAK39w G5jqkJVJne0tqkhnilzPVF5Td0dSmn65OD2ldkQeCBU25igNiFP3tbISS3SXKkDc sMsrhmKrxIa23ijnMBch+gXVGa3iXKaDGTEbsEKALDeNTiwV1Mt9KDghuU5x4GIJ TVVKLi7oEPg= =XH1L -----END PGP SIGNATURE----- --zMxPFfwyjSN7AMOh-- From moore@network-heretics.com Fri Jul 22 07:33:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E909C21F846A for ; Fri, 22 Jul 2011 07:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrT8As-zcF+Z for ; Fri, 22 Jul 2011 07:33:32 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA0A21F8453 for ; Fri, 22 Jul 2011 07:33:32 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id CAD962017A; Fri, 22 Jul 2011 10:33:31 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 22 Jul 2011 10:33:31 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=owHmDah5MKxD2nZqGzFa2m/5fXk=; b=RV aql7LMNfqLTBc0/XV6hJ3VPPTPYcppE2wGeeSEXhzNP/kFAp/YxNK8AvBhHxBc5V R1kCJqdMbnD/pWZfO5hG4OWHeB086Y1pA8yVsNGnjtreYxvAZckvuMQgWgzcXi8T k16rV6CuwpVRR1dKTAcY5VOUfOL0/ljHMCFQleIOo= X-Sasl-enc: 4grxh5eSX6toskHHXfpGn9ZSSJcfeZuOvbl5namKqpbT 1311345211 Received: from [10.59.1.76] (static-71-166-174-114.washdc.east.verizon.net [71.166.174.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 31AA441234A; Fri, 22 Jul 2011 10:33:31 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110722141726.GS2304@Space.Net> Date: Fri, 22 Jul 2011 10:33:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1084) Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:33:33 -0000 On Jul 22, 2011, at 10:17 AM, Gert Doering wrote: > On Fri, Jul 22, 2011 at 09:59:35AM -0400, Keith Moore wrote: >> On Jul 22, 2011, at 9:48 AM, Gert Doering wrote: >>=20 >>> I think that the dates in there are actually the main contribution = of >>> that draft. Create the necessary push for those that still have no >>> IPv6 on their mail systems to do it in a *timely* way. >>=20 >> I think the dates in the draft are completely disconnected from = reality. >=20 > Indeed, given that IPv6 testing should have been done long ago, and > we should already be well into Phase 2. but of course, we're years away from being able to do that on any kind = of widespread scale, due to lack of deployment of native v6, and lack of = an efficient and generally-applicable transition mechanism. Keith From gert@space.net Fri Jul 22 07:48:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4737621F8AF4 for ; Fri, 22 Jul 2011 07:48:46 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7EDkOVskImF for ; Fri, 22 Jul 2011 07:48:45 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 58EC521F8AF3 for ; Fri, 22 Jul 2011 07:48:44 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 139E3F8544 for ; Fri, 22 Jul 2011 16:48:44 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 039C4F854C for ; Fri, 22 Jul 2011 16:48:44 +0200 (CEST) Received: (qmail 84127 invoked by uid 1007); 22 Jul 2011 16:48:43 +0200 Date: Fri, 22 Jul 2011 16:48:43 +0200 From: Gert Doering To: Keith Moore Message-ID: <20110722144843.GV2304@Space.Net> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UyRhYLlBUOwBnHrp" Content-Disposition: inline In-Reply-To: <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker , "John R. Levine" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:48:46 -0000 --UyRhYLlBUOwBnHrp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jul 22, 2011 at 10:33:30AM -0400, Keith Moore wrote: > > Indeed, given that IPv6 testing should have been done long ago, and > > we should already be well into Phase 2. >=20 > but of course, we're years away from being able to do that on any kind=20 > of widespread scale, due to lack of deployment of native v6, and lack=20 > of an efficient and generally-applicable transition mechanism. You're certainly living in a different reality than I am :-) Recent studies show that about 50% of the ISPs connected to the 3 largest exchange points in Europe already have native IPv6. Many of them not "all the way to the end customers", but sufficient to enable IPv6 to mail servers. My private MX has had (native!) IPv6 since about 10 years, and our corporate MX got native IPv6 a few months ago (due to antispam-vendor=20 challenges, not due to lack of support in the network or the MTA itself). Many of the mailing lists that I read are transported over IPv6 since years (like cisco-nsp, or v6ops). Recently, a few of the largest e-mail service providers in germany, t-online.de and Strato turned on IPv6 on their MXes (Strato for all their "entry level webspace + mail" shared platform customers, which according to their press release hosts ~4 million different customer domains)... 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 (89) 32356-444 USt-IdNr.: DE813185279 --UyRhYLlBUOwBnHrp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTimNy6kuBuNlUUl1AQKFdgP/S+C0x7sj810gjDLS02pMecbiZPS3MsNR ZJ/6j4wKFTBG6kdf8y8BdbmuBsI0yqDBUPFAlzvcXtSsufWysZD92ma3ElDxdJiN 4TheAbHS+dSQm9oHDT136nXT6vk3UWGrMoSLdYWI4zzEm+LWS0nk98c+M/HsKsku RTTsKCyUwFc= =tvK5 -----END PGP SIGNATURE----- --UyRhYLlBUOwBnHrp-- From moore@network-heretics.com Fri Jul 22 08:01:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B1621F867A for ; Fri, 22 Jul 2011 08:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAQOQ1anAFcN for ; Fri, 22 Jul 2011 08:01:23 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 47A2321F854E for ; Fri, 22 Jul 2011 08:01:23 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 933DE21377; Fri, 22 Jul 2011 11:01:20 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 22 Jul 2011 11:01:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=ksxdWnbk3FIB468Hhb/QjIadgSM=; b=t6 IJ+fttqCWhecjqOYoJt4ey/BNWulUuTpp1537tLqqWVqcMNyGERO4QIN/kSYQ9OW ofW/ytMjVOMkavGlOoT9CKe8b4dYWVfhrSMPRszg+jcNYDKNBeyj6Zri9+1dkceC DhhtQUi4XQJlzgFRAZeGF8Vqz7nmKllmV+r9pNvbU= X-Sasl-enc: bhb7IvM9nUAhCQ6Fl3M4MoSYhRlNqL5il2QJnzA7/k72 1311346880 Received: from [149.48.166.192] (unknown [149.48.166.192]) by mail.messagingengine.com (Postfix) with ESMTPA id 7DD504124F8; Fri, 22 Jul 2011 11:01:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110722144843.GV2304@Space.Net> Date: Fri, 22 Jul 2011 11:01:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1084) Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 15:01:25 -0000 On Jul 22, 2011, at 10:48 AM, Gert Doering wrote: > Recent studies show that about 50% of the ISPs connected to the 3 = largest > exchange points in Europe already have native IPv6. Many of them not > "all the way to the end customers", but sufficient to enable IPv6 to > mail servers. Only for the ISPs' mail servers. Not for their customers' mail = servers. It's the "all the way to end customers" bit that matters, and = universal availability there is years away. > My private MX has had (native!) IPv6 since about 10 years, and our > corporate MX got native IPv6 a few months ago (due to antispam-vendor=20= > challenges, not due to lack of support in the network or the MTA = itself). I congratulate you. But neither that nor the other examples you cited = are a good indication of what's available to everyone. Keith From gert@space.net Fri Jul 22 08:20:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A8921F8B08 for ; Fri, 22 Jul 2011 08:20:56 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUvAvv5k6+xn for ; Fri, 22 Jul 2011 08:20:55 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD5321F8B1B for ; Fri, 22 Jul 2011 08:20:53 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 0112FF8541 for ; Fri, 22 Jul 2011 17:20:53 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id DC4ABF8547 for ; Fri, 22 Jul 2011 17:20:52 +0200 (CEST) Received: (qmail 9207 invoked by uid 1007); 22 Jul 2011 17:20:52 +0200 Date: Fri, 22 Jul 2011 17:20:52 +0200 From: Gert Doering To: Keith Moore Message-ID: <20110722152052.GX2304@Space.Net> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F85KFVxTQmf/0nzl" Content-Disposition: inline In-Reply-To: <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker , "John R. Levine" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 15:20:56 -0000 --F85KFVxTQmf/0nzl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jul 22, 2011 at 11:01:19AM -0400, Keith Moore wrote: > On Jul 22, 2011, at 10:48 AM, Gert Doering wrote: >=20 > > Recent studies show that about 50% of the ISPs connected to the 3 large= st > > exchange points in Europe already have native IPv6. Many of them not > > "all the way to the end customers", but sufficient to enable IPv6 to > > mail servers. >=20 > Only for the ISPs' mail servers. Not for their customers' mail servers.= =20 Our customers' mail servers are in our hosting facility, and can have=20 native IPv6 just fine. > It's the "all the way to end customers" bit that matters, and=20 > universal availability there is years away. You don't need universal availability on the last DSL line to have IPv6 *on servers*. Which are usually not located behind consumer products. IPv6 on business links is available today. > > My private MX has had (native!) IPv6 since about 10 years, and our > > corporate MX got native IPv6 a few months ago (due to antispam-vendor= =20 > > challenges, not due to lack of support in the network or the MTA itself= ). >=20 > I congratulate you. But neither that nor the other examples you cited=20 > are a good indication of what's available to everyone. Everyone can have a web + e-mail presence at strato.de - with nice anti-spam filtering, and IPv6. Their service offering is very explicitely targeting "everyone"... But as I said, I live in a reality where (native!) IPv6 has arrived years= =20 ago, and I like that place. 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 (89) 32356-444 USt-IdNr.: DE813185279 --F85KFVxTQmf/0nzl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTimVVKkuBuNlUUl1AQJQ8QQAqgOHuEQwSF155UPis8LmNfltMHXkT/iU e5dAsrVtJKZvmSGSjh0uUs/B6pj4+Ca3YWtPVVaLRwF5hNnfM1tATdgYx2n22P8P IafQ1irVvZzabRZD2HaFSHAOwn/9aGlU/HVLzkoQ2i+uB/G0GVQH4dZPu0whWFLS stRhi7UI3Y4= =Gtn1 -----END PGP SIGNATURE----- --F85KFVxTQmf/0nzl-- From pch-b2B3A6689@u-1.phicoh.com Fri Jul 22 08:34:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28F421F8B29 for ; Fri, 22 Jul 2011 08:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.562 X-Spam-Level: X-Spam-Status: No, score=-4.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdAOr+GSidtE for ; Fri, 22 Jul 2011 08:34:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id CB81A21F8B27 for ; Fri, 22 Jul 2011 08:34:37 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QkHkJ-0001iVC; Fri, 22 Jul 2011 17:34:35 +0200 Message-Id: To: Keith Moore From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> In-reply-to: Your message of "Fri, 22 Jul 2011 11:01:19 -0400 ." <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> Date: Fri, 22 Jul 2011 17:34:26 +0200 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 15:34:38 -0000 In your letter dated Fri, 22 Jul 2011 11:01:19 -0400 you wrote: >On Jul 22, 2011, at 10:48 AM, Gert Doering wrote: >> Recent studies show that about 50% of the ISPs connected to the 3 largest >> exchange points in Europe already have native IPv6. Many of them not >> "all the way to the end customers", but sufficient to enable IPv6 to >> mail servers. > >Only for the ISPs' mail servers. Not for their customers' mail servers. It' >s the "all the way to end customers" bit that matters, and universal availabil >ity there is years away. I don't see why it's the 'all the way to end customers' bit that matters. Huge amounts of e-mail go to and from big players. And as always, most of them don't do anything. For websites, individual users have to have IPv6 otherwise they can reach content over IPv6. And latency is important. For mail, in most cases there are ISP (or other) operated mail servers involved. From cb.list6@gmail.com Fri Jul 22 08:40:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F1D21F8B2F for ; Fri, 22 Jul 2011 08:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD32GAOdmkDP for ; Fri, 22 Jul 2011 08:40:53 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BEE2B21F8B29 for ; Fri, 22 Jul 2011 08:40:52 -0700 (PDT) Received: by wwe5 with SMTP id 5so1588263wwe.13 for ; Fri, 22 Jul 2011 08:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kWtXLp1ZskOD5dU4xt/VTsVe0JEsW7mItMnxtiJfWBY=; b=cDuI/a4rAAoHbx0RzaqyyTwEQJHW2SucULJuA1Ui/mVJpJruhVl8/C0W2jR4Ut9X9b pPJzqL1FGyMnZWxQSowYPdzY1/m2rYsuvzN192IFTFdkQbUoMnhEIsLHWRsdfkbtECoB ce39e4+Nb7gsQ1pxnLeH9dHh7/FLziTLXYlKU= MIME-Version: 1.0 Received: by 10.217.3.17 with SMTP id q17mr1847746wes.107.1311349251838; Fri, 22 Jul 2011 08:40:51 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Fri, 22 Jul 2011 08:40:51 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Fri, 22 Jul 2011 08:40:51 -0700 (PDT) In-Reply-To: <20110722134844.GP2304@Space.Net> References: <20110722134844.GP2304@Space.Net> Date: Fri, 22 Jul 2011 08:40:51 -0700 Message-ID: From: Cameron Byrne To: Gert Doering Content-Type: multipart/alternative; boundary=20cf301e2f275514c004a8aa4a98 Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 15:40:53 -0000 --20cf301e2f275514c004a8aa4a98 Content-Type: text/plain; charset=ISO-8859-1 On Jul 22, 2011 6:49 AM, "Gert Doering" wrote: > > Hi, > > On Thu, Jul 21, 2011 at 07:50:15PM +0000, Livingood, Jason wrote: > > I also suggest that the dates don't apply, since every mail provider is at a different stage of readiness. As a result, sections 5, 6, and 7 probably should not have dates and may instead be Phase 1, 2 and 3 or something like that. > > I think that the dates in there are actually the main contribution of > that draft. Create the necessary push for those that still have no > IPv6 on their mail systems to do it in a *timely* way. > +1 for the dates being good as well. Like w6d, I really believe it helps having meaningful dates for organizations to work towards. Cb > Gert Doering > -- running an IPv6-enabled MTA since about 10 years or so > -- > 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 (89) 32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --20cf301e2f275514c004a8aa4a98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 22, 2011 6:49 AM, "Gert Doering" <gert@space.net> wrote:
>
> Hi,
>
> On Thu, Jul 21, 2011 at 07:50:15PM +0000, Livingood, Jason wrote:
> > I also suggest that the dates don't apply, since every mail p= rovider is at a different stage of readiness. As a result, sections 5, 6, a= nd 7 probably should not have dates and may instead be Phase 1, 2 and 3 or = something like that.
>
> I think that the dates in there are actually the main contribution of<= br> > that draft. =A0Create the necessary push for those that still have no<= br> > IPv6 on their mail systems to do it in a *timely* way.
>

+1 for the dates being good as well.

Like w6d, I really believe it helps having meaningful dates for organiza= tions to work towards.

Cb

> Gert Doering
> =A0 =A0 =A0 =A0-- running an IPv6-enabled MTA since about 10 years or = so
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vorstand: S= ebastian v. Bomhard
> Joseph-Dollinger-Bogen 14 =A0 =A0 =A0 =A0 =A0Aufsichtsratsvors.: A. Gr= undner-Culemann
> D-80807 Muenchen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HRB: 136055 (AG M= uenchen)
> Tel: +49 (89) 32356-444 =A0 =A0 =A0 =A0 =A0 =A0USt-IdNr.: DE813185279<= br> > _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--20cf301e2f275514c004a8aa4a98-- From nick@inex.ie Fri Jul 22 08:44:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A680A21F8B3A for ; Fri, 22 Jul 2011 08:44:08 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf35KAL3Ym9K for ; Fri, 22 Jul 2011 08:44:08 -0700 (PDT) Received: from prometheus.inex.ie (prometheus.inex.ie [IPv6:2001:7f8:18:2::148]) by ietfa.amsl.com (Postfix) with ESMTP id B0F3921F8B33 for ; Fri, 22 Jul 2011 08:44:07 -0700 (PDT) Received: from prometheus.inex.ie (localhost [127.0.0.1]) by prometheus.inex.ie (Postfix) with ESMTP id 250C728426 for ; Fri, 22 Jul 2011 16:40:59 +0100 (IST) X-Virus-Scanned: amavisd-new at inex.ie Received: from promethus.inex.ie ([127.0.0.1]) by prometheus.inex.ie (prometheus.inex.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOksGv88L8Os for ; Fri, 22 Jul 2011 16:40:57 +0100 (IST) Received: from crumpet.foobar.org (unknown [IPv6:2001:4d68:2002:100:a5c7:e8f5:22f6:dfa]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: operations) by promethus.inex.ie (Postfix) with ESMTPSA id 73C4F28424 for ; Fri, 22 Jul 2011 16:40:57 +0100 (IST) Message-ID: <4E299A09.4030704@inex.ie> Date: Fri, 22 Jul 2011 16:40:57 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> In-Reply-To: <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> X-Enigmail-Version: 1.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 15:44:08 -0000 On 22/07/2011 15:33, Keith Moore wrote: > [...] lack of an efficient and generally-applicable transition > mechanism. It's probably my operator-tinted spectacles acting up, but I don't see what transition mechanisms have to do with this draft. Email servers generally reside on provider-controlled infrastructure, which (in the scale of things) is relatively simple to get up and running on IPv6. Ok, if you're a Comcast or a Google, it's going to be hard - like any other transition to a new class of service. But most providers don't operate at that scale and can implement this sort of thing relatively easily, and certainly within the very conservative timescales indicated. It's the last mile which is the problem, and email service infrastructure tends not to be hosted on the last mile these days. If you're on a last-mile connection, all that's necessary is to ensure that there is a good failover mechanism between your MUA and the MTA/MSA - and this is something which already works reasonably well. But that is out of scope for this draft. If you're hosting infrastructure on the last mile, then you deserve what you get. I'm sure you can still pull out corner cases where ipv6 transport to provider networks is difficult. But for the majority of provider networks, getting IPv6 into the core infrastructure is not hard. Nick From fred@cisco.com Fri Jul 22 08:59:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED0A21F8B37 for ; Fri, 22 Jul 2011 08:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.482 X-Spam-Level: X-Spam-Status: No, score=-103.482 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBtltHC323EO for ; Fri, 22 Jul 2011 08:59:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 07B0921F8B36 for ; Fri, 22 Jul 2011 08:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=767; q=dns/txt; s=iport; t=1311350379; x=1312559979; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=j3vt7gT8sQ9IJwYfT3dSA3dPiKOdFm1GsqrQ4JdFokw=; b=Xb8r8UCBKLxiSCAQ2NWH4Egqau+JzTM6kvFVdvR0Gk7efobErqqZqns+ qYkZGaIaxtxvr+oXn7sL0QT5icAGm/tOSkG0HaB0v47H1tA1H2ajtLX3k 6pMomvv5BBOGad06VrLMIspcpD/ABl8qIAY2UINNSJXQ5IPu7F3O8jjYR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACieKU6rRDoH/2dsb2JhbABTp0d3iHycV54zhWBfBIdVixmFB4t4 X-IronPort-AV: E=Sophos;i="4.67,248,1309737600"; d="scan'208";a="5536912" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 22 Jul 2011 15:59:38 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6MFxbAM006691; Fri, 22 Jul 2011 15:59:37 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Fri, 22 Jul 2011 08:59:37 -0700 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Fri, 22 Jul 2011 08:59:37 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <20110722152052.GX2304@Space.Net> Date: Fri, 22 Jul 2011 08:59:27 -0700 Message-Id: <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 15:59:39 -0000 On Jul 22, 2011, at 8:20 AM, Gert Doering wrote: > You don't need universal availability on the last DSL line to have = IPv6 *on servers*.=20 and by the way, the entire series of MUA/MTA and MTA/MTA links don't = have to have IPv6 for it to be used on some of them. If one end user is = IPv6-only, the other is IPv4-only, and at least one MTA in between is = dual, nobody should notice an issue. My initial comment to Michael, when he pointed the draft out to me, was = that email seems like the poster child of an easy application to add = IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support it = already and the current OS's support IPv6. The primary thing preventing = mail/IPv6 is network IPv6 deployment, which is in progress.= From nalini.elkins@insidethestack.com Fri Jul 22 09:03:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9992F21F8B48 for ; Fri, 22 Jul 2011 09:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX6LYCiq8Zax for ; Fri, 22 Jul 2011 09:03:11 -0700 (PDT) Received: from nm27-vm1.access.bullet.mail.mud.yahoo.com (nm27-vm1.access.bullet.mail.mud.yahoo.com [66.94.236.228]) by ietfa.amsl.com (Postfix) with SMTP id 37A6021F8B37 for ; Fri, 22 Jul 2011 09:03:11 -0700 (PDT) Received: from [66.94.237.195] by nm27.access.bullet.mail.mud.yahoo.com with NNFMP; 22 Jul 2011 16:03:07 -0000 Received: from [66.94.237.116] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 22 Jul 2011 16:03:07 -0000 Received: from [127.0.0.1] by omp1021.access.mail.mud.yahoo.com with NNFMP; 22 Jul 2011 16:03:07 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 827037.52208.bm@omp1021.access.mail.mud.yahoo.com Received: (qmail 7131 invoked by uid 60001); 22 Jul 2011 16:03:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311350587; bh=Nza1SIJoEDTGbFKLgocPXlRKFgsKAJpqT8kaHwMsu1Q=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=YvOlptHXzjrT4CYCzK2Va6sCJlar9C91Cb6LJzbF/QhK4ETO7ryGLFQn3vPEllN5KG9Q9ZjebjOyzByvB6ymPJ5H+1/VXDSMVwXuABRxPh3wUkqEpwFOXEc5RSQrl5N6UX+FUyer13+rDmekHBdV0JOY5Bnel+qy3BVob+q640E= X-YMail-OSG: Vohx_TEVM1lYvOO701BP3jPJEro6D9zHPZKLWEcxm73SHV0 PbtuogXiWUyI.p9Qa34Dr1m9UVwAIg4El1mlATvDI1oq8wA2e.DAOSApkUf2 Du.CGQLNG.3QqwqrL30EAewSLn8tznfGsJtEh_FG4m.gq5f325XNtt9rBHV. GkBpUsE65xF6bIL7X30NuEjUt0qx.BI133BZ8MMYJ8j_M8oDR_m3dHXUxgYf 1I4cX0eVR.PcoCF4caYgHgnk5AQLob4FpNmHkBRlj3PjYeLXpm5iTHgEjK__ Z4uOfPrgmzNXfX_nuH6josTT_FJmUj6m6SD8t8EgI24fgZ_T81Cm3TwWzVm7 ACne7IoP0lLLLOhHrcnbm1GJk_xsPoSvq8TtexAxLMABphdo5HmXa3G0Kp4E XH7yOcXcW_S_.6xxj6j0W3F.WqkpMGay8Et9fBQ3psWtwbMH7ucndQRcSv4n 4fdER.juX1Wc1MUFMsulvRNxZNvusUgDIrQ-- Received: from [24.6.68.48] by web2808.biz.mail.ne1.yahoo.com via HTTP; Fri, 22 Jul 2011 09:03:06 PDT X-Mailer: YahooMailClassic/14.0.3 YahooMailWebService/0.8.112.310352 Message-ID: <1311350586.900.YahooMailClassic@web2808.biz.mail.ne1.yahoo.com> Date: Fri, 22 Jul 2011 09:03:06 -0700 (PDT) From: nalini.elkins@insidethestack.com To: v6ops@ietf.org, ipv6@ietf.org In-Reply-To: <4E290D99.3030300@kit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [v6ops] IPv6 Diagnostic Option X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 16:03:11 -0000 Thanks to all for your comments. But, there may be some confusion as to what we are trying to achieve. The Proposed Flow Label field, in our opinion, does not meet our requirements. The reasons are as follows: 1. The Flow Label, as defined, is a unique and (generally speaking) static identifier per flow. Its purpose is to distinguish one flow from another. 2. Our proposed field increments per packet WITHIN a flow. The intended purpose is to distinguish one packet from another not one flow from another. 3. The Flow Label is only 20 bits which is not sufficient to hold even the existing 32 bit ID. We are proposing a 64-bit ID. Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com --- On Thu, 7/21/11, Roland Bless wrote: > From: Roland Bless > Subject: Re: [v6ops] IPv6 Diagnostic Option > To: v6ops@ietf.org > Cc: ipv6@ietf.org > Date: Thursday, July 21, 2011, 10:41 PM > Hi, > > On 22.07.2011 06:38, nalini.elkins@insidethestack.com > wrote: > > Would love to get feedback on an Internet Draft we > have submitted. > > > The issue we are addressing is that the IP > Identification field which > > was available with IPv4 in the main header is > available with IPv6 > > only in the Fragment Header. > > I don't think that your proposed solution is necessary, > since > IPv6 has the Flow Label, that - if set by the source - may > be > very well suited for your purpose (tracking flows along a > path). > Please see http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/ > for more details. > > Kind regards, > Roland > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From gert@space.net Fri Jul 22 09:35:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628AD21F8B34 for ; Fri, 22 Jul 2011 09:35:47 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lNskNazvNfZ for ; Fri, 22 Jul 2011 09:35:47 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7938E21F8B32 for ; Fri, 22 Jul 2011 09:35:45 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 9F044F8551 for ; Fri, 22 Jul 2011 18:35:44 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 83336F854D for ; Fri, 22 Jul 2011 18:35:44 +0200 (CEST) Received: (qmail 52447 invoked by uid 1007); 22 Jul 2011 18:35:44 +0200 Date: Fri, 22 Jul 2011 18:35:44 +0200 From: Gert Doering To: Fred Baker Message-ID: <20110722163544.GA2304@Space.Net> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3FmRlnZT3MJ0iQxE" Content-Disposition: inline In-Reply-To: <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker , "John R. Levine" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 16:35:47 -0000 --3FmRlnZT3MJ0iQxE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jul 22, 2011 at 08:59:27AM -0700, Fred Baker wrote: > My initial comment to Michael, when he pointed the draft out to me, was= =20 > that email seems like the poster child of an easy application to add IPv6= =20 > to, as the applications (SMTP, POP, and IMAP) mostly support it already= =20 > and the current OS's support IPv6.=20 Seconded. Plus, if mail gets delayed by a few minutes due to IPv6 breakage, it helps *noticing* problems without impacting user experience in a very massive way (like for IPv6 HTTP running into timeouts). > The primary thing preventing mail/IPv6 is network IPv6 deployment, which= =20 > is in progress. Yes. And mail/IPv6 can help network IPv6 deployment by showing folks that there indeed is IPv6 packets to be seen, monitored, and cared for :-) 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 (89) 32356-444 USt-IdNr.: DE813185279 --3FmRlnZT3MJ0iQxE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTimm4KkuBuNlUUl1AQJpIwP/QckjO3hRUSZCH8EedRn7jnF82TB7givm JIbKT9O7OdtQoaZ1fOBR5EZqVRgD89gsLTOAoVnOM8PCCA3tWcbK+X0Cl0x3Mszd OX0xqM4Lt2k4WR6LQ0pX1O54Ruv0bu8XykNI6W6CNNn6v6qnU+Dm4dQJhx0RbXbz 8k2Q0zjJf0A= =0JgA -----END PGP SIGNATURE----- --3FmRlnZT3MJ0iQxE-- From wesley.george@twcable.com Fri Jul 22 09:55:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F0E21F8B37 for ; Fri, 22 Jul 2011 09:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.067 X-Spam-Level: X-Spam-Status: No, score=0.067 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqmvDz9F7UB8 for ; Fri, 22 Jul 2011 09:55:19 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A975C21F8B32 for ; Fri, 22 Jul 2011 09:55:18 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,248,1309752000"; d="scan'208,217";a="238578781" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Jul 2011 12:53:21 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Fri, 22 Jul 2011 12:55:17 -0400 From: "George, Wesley" To: "Livingood, Jason" , "O'Reirdan, Michael" , "v6ops@ietf.org" Date: Fri, 22 Jul 2011 12:55:14 -0400 Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AQHMR9MX48R+MKwtbkO0KgAdYLlAe5T3LzCAgAE9apA= Message-ID: <34E4F50CAFA10349A41E0756550084FB0BBE7152@PRVPEXVS04.corp.twcable.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_34E4F50CAFA10349A41E0756550084FB0BBE7152PRVPEXVS04corpt_" MIME-Version: 1.0 Cc: "John R. Levine" , Joe St Sauveur , "barryleiba@computer.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 16:55:22 -0000 --_000_34E4F50CAFA10349A41E0756550084FB0BBE7152PRVPEXVS04corpt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While I agree that there are some things that need to be addressed when con= sidering use of IPv6 transport for email, I think that there's probably two= drafts necessary here. One would be focused exclusively on IPv6 transition for email, including ti= meframes/phases as appropriate and some BCP for enabling IPv6 on mail serve= rs, both for server to server and server to client communication, includin= g issues and considerations not directly related to abuse. The other would = be focused on abuse considerations for using IPv6 for mail. The reason that I think we need a separate draft on abuse considerations is= that I think it will be significant all by itself, it will likely have a d= ifferent group of folks both interested in working on it and as an audience= , and there's a timing consideration. What I mean by timing is that a draft that serves as a call to arms to enab= le IPv6 on mail servers and gives recommendations and considerations on how= to do so is widely applicable, and many folks can benefit from that immedi= ately, especially if they are not as concerned about the impacts of spam wh= en enabling IPv6. So we'd do well to rapidly get it to a state where it's u= seful to folks considering their IPv6 deployment steps. Then, this gives us= the opportunity to really consider the abuse problems and identify some ga= ps that we need IETF to come up with better solutions for, as you allude to= in your current security considerations text. In other words, we need a th= orough gap analysis on mail Abuse with a specific focus on IPv6 so that we = can identify what can be done today, as well as work that needs to be farme= d out to either existing WGs or possibly even a new WG dedicated to protoco= l changes necessary to solve the identified problems. It should probably ha= ve significant input from MAAWG, since they probably know a thing or two ab= out this ;-) Regarding the current draft section 11, I realize that this is an early dra= ft, but I think that you need a significant amount of explanation/justifica= tion/rationale to support those recommendations if indeed they are to becom= e requirements (even if requirements in a BCP/Informational draft are a lit= tle more like suggestions anyway). Based on feedback I've gotten from some = of our mail/systems folks, expecting to require DKIM across the board is no= t realistic due to the costs to implement it at scale. I view whitelists as= problematic to scale unless you're talking about a very small number of se= rvers that you exchange email with, or you are proposing some sort of semi-= automated whitelist that is updated like todays spam blacklists. Perhaps it= 's just unclear where you're suggesting that they be used, and if so I'll w= ait for a revision before saying much else. Thanks, Wes George From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of L= ivingood, Jason Sent: Thursday, July 21, 2011 3:50 PM To: O'Reirdan, Michael; v6ops@ietf.org Cc: John R. Levine; Joe St Sauveur; Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice= providers and other communities Thanks for submitting the -00, Mike. A few notes for reviewers: - This is a very early first draft (and is from some folks new to the IETF)= , so be gentle and give lots of good feedback - It seems we need to sort out the appearance of some RFC 2119 language in = here and whether it may be better to be less focused on 'recommendations fo= r...' and more 'suggested phases of the transition of mail services to IPv6= ' (a slight tonal shift) I also suggest that the dates don't apply, since every mail provider is at = a different stage of readiness. As a result, sections 5, 6, and 7 probably = should not have dates and may instead be Phase 1, 2 and 3 or something like= that. Jason On 7/21/11 2:21 PM, "O'Reirdan, Michael" > wrote: Chaps I would like to bring to your attention and solicit comments on the followi= ng draft. http://tools.ietf.org/html//draft-oreirdan-rosenwald-ipv6mail-transition-00= Thanks Mike O'Reirdan _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_34E4F50CAFA10349A41E0756550084FB0BBE7152PRVPEXVS04corpt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While I agree that there = are some things that need to be addressed when considering use of IPv6 tran= sport for email, I think that there’s probably two drafts necessary here.

One would be focused excl= usively on IPv6 transition for email, including timeframes/phases as approp= riate and some BCP for enabling IPv6 on mail servers,  both for server to server and server to client communication, including issues = and considerations not directly related to abuse. The other would be focuse= d on abuse considerations for using IPv6 for mail.

 <= /p>

The reason that I think w= e need a separate draft on abuse considerations is that I think it will be = significant all by itself, it will likely have a different group of folks both interested in working on it and as an audience, and th= ere’s a timing consideration.

What I mean by timing is = that a draft that serves as a call to arms to enable IPv6 on mail servers a= nd gives recommendations and considerations on how to do so is widely applicable, and many folks can benefit from that immediately,= especially if they are not as concerned about the impacts of spam when ena= bling IPv6. So we’d do well to rapidly get it to a state where itR= 17;s useful to folks considering their IPv6 deployment steps. Then, this gives us the opportunity to really consider t= he abuse problems and identify some gaps that we need IETF to come up with = better solutions for, as you allude to in your current security considerati= ons text. In other words, we need a thorough gap analysis on mail Abuse with a specific focus on IPv6 so tha= t we can identify what can be done today, as well as work that needs to be = farmed out to either existing WGs or possibly even a new WG dedicated to pr= otocol changes necessary to solve the identified problems. It should probably have significant input from MA= AWG, since they probably know a thing or two about this ;-)

 <= /p>

Regarding the current dra= ft section 11, I realize that this is an early draft, but I think that you = need a significant amount of explanation/justification/rationale to support those recommendations if indeed they are to become requirements= (even if requirements in a BCP/Informational draft are a little more like = suggestions anyway). Based on feedback I’ve gotten from some of our m= ail/systems folks, expecting to require DKIM across the board is not realistic due to the costs to implement it at= scale. I view whitelists as problematic to scale unless you’re talki= ng about a very small number of servers that you exchange email with, or yo= u are proposing some sort of semi-automated whitelist that is updated like todays spam blacklists. Perhaps it’s = just unclear where you’re suggesting that they be used, and if so I&#= 8217;ll wait for a revision before saying much else.

 <= /p>

Thanks,=

 <= /p>

Wes George

 <= /p>

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Livingood, Jason
Sent: Thursday, July 21, 2011 3:50 PM
To: O'Reirdan, Michael; v6ops@ietf.org
Cc: John R. Levine; Joe St Sauveur; Dave Crocker
Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for= sevice providers and other communities

 

Thanks for submitting the –00, Mike. A= few notes for reviewers:

- This is a very early first draft (and is f= rom some folks new to the IETF), so be gentle and give lots of good feedbac= k

- It seems we need to sort out the appearanc= e of some RFC 2119 language in here and whether it may be better to be less= focused on 'recommendations for…' and more 'suggested phases of the transition of mail services to IPv6' (a slight tonal shift)

 

I also suggest that the dates don't apply, s= ince every mail provider is at a different stage of readiness. As a result,= sections 5, 6, and 7 probably should not have dates and may instead be Phase 1, 2 and 3 or something like that.<= /p>

 

Jason

 

 

On 7/21/11 2:21 PM, "O'Reirdan, Michael= " <Michael_OR= eirdan@Cable.Comcast.com> wrote:

 

Chaps 

 

I would like to bring to yo= ur attention and solicit comments on the following draft.=

 

 

Thanks

 

Mike O'Reirdan

 

 

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


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_34E4F50CAFA10349A41E0756550084FB0BBE7152PRVPEXVS04corpt_-- From moore@network-heretics.com Fri Jul 22 10:27:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A3F21F8639 for ; Fri, 22 Jul 2011 10:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H0hhXzM7XGU for ; Fri, 22 Jul 2011 10:27:41 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0876821F85F7 for ; Fri, 22 Jul 2011 10:27:41 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 9ED8320E9C; Fri, 22 Jul 2011 13:27:40 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 22 Jul 2011 13:27:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=cQ9f7R/zoNiFas0G/pqRmEJR7hQ=; b=CE W4XTtR0GOC1JDpacvIN/bDN9LQp33xYoE7TOszTT7J7SljKyQ3qgeTtkWeKrwW+B acQwUOYZaZKxln2/WPutTNN0BIMIlxmEdHFwyjxxTDqWxhf5uea40x3Bg5mzVprI +ZtxAoyOSLx4O5H+6t62oYuxDvA2Qxp2qQX17gbKI= X-Sasl-enc: iPwBEECJeEIVn5WXKAkRvkbItE64jvpCzIXbF7e4HmOe 1311355660 Received: from [149.48.166.192] (unknown [149.48.166.192]) by mail.messagingengine.com (Postfix) with ESMTPA id 56D2145214C; Fri, 22 Jul 2011 13:27:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110722152052.GX2304@Space.Net> Date: Fri, 22 Jul 2011 13:27:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1084) Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 17:27:43 -0000 On Jul 22, 2011, at 11:20 AM, Gert Doering wrote: > You don't need universal availability on the last DSL line to have > IPv6 *on servers*. Which are usually not located behind consumer > products. This might be true for your customers. But it's not an appropriate = assumption to make for all mail servers on the Internet. Keith From moore@network-heretics.com Fri Jul 22 10:28:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7211521F86C2 for ; Fri, 22 Jul 2011 10:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+sNt+qDFDyU for ; Fri, 22 Jul 2011 10:28:54 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id DD72721F865E for ; Fri, 22 Jul 2011 10:28:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 9653E20EB0; Fri, 22 Jul 2011 13:28:53 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 22 Jul 2011 13:28:53 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=r1MNZnSP1z2cVUoMdr+oEAGrRq0=; b=kU LGPJWA8sSJ3nFPDh29LvFAuUDvGCIYEI3uqdi8/vq8QafstbdTluULrq5OE5D0oR blwouMGZ+6IwjhUkxHwIHWMJ3bIK7f36cRCZBrtbzFRitWiJfq/e/gpuddKOnqUe 3TLiYrRXPF6kgGZrGvcVAr2bSp55IcMyLA7GTxGaU= X-Sasl-enc: lnKXvS/K5IKe1kbm+Lsiarf+Zv0um8w1ZHM/m6Vt5y8D 1311355733 Received: from [149.48.166.192] (unknown [149.48.166.192]) by mail.messagingengine.com (Postfix) with ESMTPA id 51CA344747E; Fri, 22 Jul 2011 13:28:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Fri, 22 Jul 2011 13:28:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 17:28:54 -0000 On Jul 22, 2011, at 11:34 AM, Philip Homburg wrote: > In your letter dated Fri, 22 Jul 2011 11:01:19 -0400 you wrote: >> On Jul 22, 2011, at 10:48 AM, Gert Doering wrote: >>> Recent studies show that about 50% of the ISPs connected to the 3 = largest >>> exchange points in Europe already have native IPv6. Many of them = not >>> "all the way to the end customers", but sufficient to enable IPv6 to >>> mail servers. >>=20 >> Only for the ISPs' mail servers. Not for their customers' mail = servers. It' >> s the "all the way to end customers" bit that matters, and universal = availabil >> ity there is years away. >=20 > I don't see why it's the 'all the way to end customers' bit that = matters.=20 > Huge amounts of e-mail go to and from big players.=20 If the document wants to make clear that it only applies to "big = players", that might be okay. Though I worry about recommendations = coming from IETF that threaten to further marginalize small players. Keith From moore@network-heretics.com Fri Jul 22 10:33:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8C321F8A1A for ; Fri, 22 Jul 2011 10:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFcaWj7d99Tp for ; Fri, 22 Jul 2011 10:33:00 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id B474821F89CC for ; Fri, 22 Jul 2011 10:33:00 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 6606420E39; Fri, 22 Jul 2011 13:33:00 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 22 Jul 2011 13:33:00 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=WkiBCYq8ztdZzz47933nC1ua8as=; b=dW 1Wzm5F7X8YsKKw4H3qMKji1LVizIEN7oGoXOqwjgsuxTzSXlYIZKNRSCLLYEL0kG +IMu1fYfQ/4Zx+FEtSuUNvuIkgb+0caJRfsAjf1VD/8vhGSNVpx34OYdqVWRGRY4 p/CbgaABHQ34IbkS+DAEAs7l1xJLE5NNQwKg6Z2eE= X-Sasl-enc: 4ehDkWH9ymJvhyF/qN1RVef71Hgr5oIcZgutX+9a7c25 1311355980 Received: from [149.48.166.192] (unknown [149.48.166.192]) by mail.messagingengine.com (Postfix) with ESMTPA id 175F644E971; Fri, 22 Jul 2011 13:33:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> Date: Fri, 22 Jul 2011 13:32:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5C15E073-2764-4BFF-ADB0-E8939D58917F@network-heretics.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 17:33:01 -0000 On Jul 22, 2011, at 11:59 AM, Fred Baker wrote: > On Jul 22, 2011, at 8:20 AM, Gert Doering wrote: >=20 >> You don't need universal availability on the last DSL line to have = IPv6 *on servers*.=20 >=20 > and by the way, the entire series of MUA/MTA and MTA/MTA links don't = have to have IPv6 for it to be used on some of them. If one end user is = IPv6-only, the other is IPv4-only, and at least one MTA in between is = dual, nobody should notice an issue. >=20 > My initial comment to Michael, when he pointed the draft out to me, = was that email seems like the poster child of an easy application to add = IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support it = already and the current OS's support IPv6. The primary thing preventing = mail/IPv6 is network IPv6 deployment, which is in progress. I guess my view is sort of the opposite - there's really little point to = upgrading mail to use IPv6 until most of the net has IPv6 access. Of course it's a good idea for operators to gain experience with use of = SMTP over IPv6, and ramp up usage of it, especially because things like = source-address based reputation services are going to have to work = differently. But that's not the same thing as universally rolling it = out on a fixed timetable. I'm not sure how much value there is in having a "poster child" for = IPv6, as opposed to actual use of IPv6 to do things that you can't = really do well in IPv4. Maybe it matters. But that's a marketing = question, and I'm an engineer. Keith From moore@network-heretics.com Fri Jul 22 10:42:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0821F8B1C for ; Fri, 22 Jul 2011 10:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC5Bf3LSuQwR for ; Fri, 22 Jul 2011 10:42:57 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3B821F8B1E for ; Fri, 22 Jul 2011 10:42:57 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 235962080C; Fri, 22 Jul 2011 13:42:57 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 22 Jul 2011 13:42:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=qkxEA2GCdURlBndXETCunu0Mefc=; b=MG v7X9q35XLw3vwxnCvyywEsk3P21Lx0rSURZpysMDozs1CoODtgv1wjjx44Ydzl8k wMOfM4RCQP6xtF3iC3JaTWrL1kAcQKyJsDWGx3mwJ42Wktli09XidV4Z1LsiZZaL 4tsogzGtnft6/EpYpsT6BRXA96NSbcS0RRFVif4Ho= X-Sasl-enc: Y1I7NqvM9jhk57UA3d+vgR7q9B7cl/2Nwk4NkNgFMF/K 1311356576 Received: from [149.48.166.192] (unknown [149.48.166.192]) by mail.messagingengine.com (Postfix) with ESMTPA id A8467453065; Fri, 22 Jul 2011 13:42:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <11072209372672_B93@oregon.uoregon.edu> Date: Fri, 22 Jul 2011 13:42:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11072209372672_B93@oregon.uoregon.edu> To: "Joe St Sauver" X-Mailer: Apple Mail (2.1084) Cc: johnl@iecc.com, v6ops@ietf.org, dcrocker@bbiw.net Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 17:42:58 -0000 On Jul 22, 2011, at 12:37 PM, Joe St Sauver wrote: > I think it's great for providers to add support for IPv6 for: >=20 > -- web email > -- Authenticated secure IMAP > -- Authenticated secure POP > -- Authenticated secure message submission >=20 > In all of those cases, because users *are* authenticating, you know = who=20 > your users are, regardless of how or from where they connect. If they > begin to spew, you'll know who it is and you can deal with them/their=20= > compromised machine. >=20 > At this point, though, I'd be wary of fielding Internet-accessible=20 > IPv6-enabled SMTP servers. >=20 > Why? Spam management solutions simply aren't yet where they need to = be... One of the things that I've been wondering is whether IPv6 provides a = good excuse/lever to have all email that crosses administrative domain = boundaries over IPv6, use TLS and AUTH EXTERNAL and authenticate to SMTP = servers using client certificates. Ideally it would use DNSSEC to = authenticate the client certs instead of relying on trusted CAs. But I = think all of the protocol work should be defined, it just needs to be = profiled. This seems like it might be an opportunity to raise the = level of email security in general and also raise the bar for spammers. Keith From joe@oregon.uoregon.edu Fri Jul 22 09:59:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A5721F8B34 for ; Fri, 22 Jul 2011 09:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHUNWuPQFGYO for ; Fri, 22 Jul 2011 09:59:38 -0700 (PDT) Received: from grey.uoregon.edu (grey.uoregon.edu [128.223.214.89]) by ietfa.amsl.com (Postfix) with SMTP id B9A4021F8B18 for ; Fri, 22 Jul 2011 09:59:38 -0700 (PDT) Date: Fri, 22 Jul 2011 09:37:26 -0700 (PDT) Message-Id: <11072209372672_B93@oregon.uoregon.edu> From: "Joe St Sauver" To: gert@space.net X-VMS-To: SMTP%"gert@space.net" X-VMS-Cc: SMTP%"fred@cisco.com", SMTP%"gert@space.net", SMTP%"moore@network-heretics.com", SMTP%"joe@oregon.uoregon.edu", SMTP%"v6ops@ietf.org", SMTP%"dcrocker@bbiw.net", SMTP%"johnl@iecc.com" X-Mailman-Approved-At: Fri, 22 Jul 2011 11:04:26 -0700 Cc: joe@oregon.uoregon.edu, v6ops@ietf.org, moore@network-heretics.com, dcrocker@bbiw.net, johnl@iecc.com Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 16:59:39 -0000 Gert commented: #On Fri, Jul 22, 2011 at 08:59:27AM -0700, Fred Baker wrote: #> My initial comment to Michael, when he pointed the draft out to me, was #> that email seems like the poster child of an easy application to add IPv6 #> to, as the applications (SMTP, POP, and IMAP) mostly support it already #> and the current OS's support IPv6. # #Seconded. Plus, if mail gets delayed by a few minutes due to IPv6 breakage, #it helps *noticing* problems without impacting user experience in a very #massive way (like for IPv6 HTTP running into timeouts). Let me just jump in for a second on this. I think it's great for providers to add support for IPv6 for: -- web email -- Authenticated secure IMAP -- Authenticated secure POP -- Authenticated secure message submission In all of those cases, because users *are* authenticating, you know who your users are, regardless of how or from where they connect. If they begin to spew, you'll know who it is and you can deal with them/their compromised machine. At this point, though, I'd be wary of fielding Internet-accessible IPv6-enabled SMTP servers. Why? Spam management solutions simply aren't yet where they need to be... Yeah, if you're lucky, maybe you won't see any spam via IPv6 connections, or maybe you can clean it up with a purely content-oriented anti-spam solution (such as SpamAssassin or a Baeysian approach), but if you want to use traditional blocklists or you want to use some of the major commercial anti-spam appliances, what you'd want is simply not available. Regards, Joe From wesley.george@twcable.com Fri Jul 22 11:09:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D2B21F8891 for ; Fri, 22 Jul 2011 11:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.23 X-Spam-Level: X-Spam-Status: No, score=-0.23 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67g3chgioTfM for ; Fri, 22 Jul 2011 11:09:13 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id DB21821F8880 for ; Fri, 22 Jul 2011 11:09:06 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,248,1309752000"; d="scan'208";a="252803702" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Jul 2011 14:07:18 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Fri, 22 Jul 2011 14:09:06 -0400 From: "George, Wesley" To: Victor Kuarsingh , "Rajiv Asati (rajiva)" , Brian E Carpenter , IPv6 Operations Date: Fri, 22 Jul 2011 14:09:05 -0400 Thread-Topic: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt Thread-Index: AcxIKwl3urOBvdGrS06AxCztPQGqzgAaoRjA Message-ID: <34E4F50CAFA10349A41E0756550084FB0BBE71FD@PRVPEXVS04.corp.twcable.com> References: <067E6CE33034954AAC05C9EC85E2577C0575FDC5@XMB-RCD-111.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 18:09:14 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of V= ictor Kuarsingh Sent: Friday, July 22, 2011 12:51 AM To: Rajiv Asati (rajiva); Brian E Carpenter; IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-= 00.txt > One additional option that was noted to me offline was NAT64. I think > NAT64 poses challenges in the near to mid term future (in Wireline > Networks) since there is way too much IPv4-only equipment in customer pre= m > today. I am hesitant to promote options which are based on eliminating > variables I don't control - consumer controlled and operated equipment. > Therefore assumed Dual Stack home for the foreseeable future (the realist > in me). On the NAT64 note, I do think it is usable in some environments > (like some Wireless services), but I stuck with common Wireline > environments for now. Victor - this is a useful consideration around NAT64. You should add some c= omments to this effect in your draft. I understand the rationale, but it's = better to include it and explain like you did here than to simply omit it. Also, I think that there is an opportunity for a little shameless plug in s= ection 3.3, especially the 3rd paragraph - IETF needs feedback from operato= rs as they discover new issues and problems during their implementation pha= se :-) You also may want to discuss the option of moving some things in the operat= or's infrastructure which can support it to IPv6-only fairly early in the p= rocess in order to free up IPv4 resources for use in support of legacy appl= ications and devices which cannot. You mention it in the context of DS-Lite= in 5.5, but I think it's more generally applicable. For that matter, there= is probably room for some discussion about phasing with regards to infrast= ructure (such as management of devices, back office, etc) vs customer facin= g services and when those all get enabled for IPv6, since "all at once" is= rarely practical. 5.1.2 may want to discuss considerations about OSPFv3 vs ISIS as an IGP (or= reference an existing document that does, if exist) 5.2 may also want to include discussion of 6PE as a means to bridge gaps wh= ere IPv6 cannot be supported in the network infrastructure. Nits: 4.3 : %s/defiantly/definitely 5.1.1: %s/vial/vital 5.2: %s/Na=EFve/Native Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From joelja@bogus.com Fri Jul 22 11:25:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2856421F8AEA for ; Fri, 22 Jul 2011 11:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOlP1QJDpado for ; Fri, 22 Jul 2011 11:25:15 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 844EB21F8AD8 for ; Fri, 22 Jul 2011 11:25:15 -0700 (PDT) Received: from [10.104.74.150] ([75.98.19.132]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6MIP0dd046191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jul 2011 18:25:02 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <11072209372672_B93@oregon.uoregon.edu> Date: Fri, 22 Jul 2011 11:24:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9A599E25-B603-4EDB-9449-4A0B67938AFD@bogus.com> References: <11072209372672_B93@oregon.uoregon.edu> To: "Joe St Sauver" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 22 Jul 2011 18:25:04 +0000 (UTC) Cc: johnl@iecc.com, v6ops@ietf.org, dcrocker@bbiw.net, moore@network-heretics.com Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 18:25:16 -0000 On Jul 22, 2011, at 9:37 AM, Joe St Sauver wrote: > Gert commented: >=20 > #On Fri, Jul 22, 2011 at 08:59:27AM -0700, Fred Baker wrote: > #> My initial comment to Michael, when he pointed the draft out to me, = was > #> that email seems like the poster child of an easy application to = add IPv6 > #> to, as the applications (SMTP, POP, and IMAP) mostly support it = already > #> and the current OS's support IPv6. > # > #Seconded. Plus, if mail gets delayed by a few minutes due to IPv6 = breakage, > #it helps *noticing* problems without impacting user experience in a = very > #massive way (like for IPv6 HTTP running into timeouts). >=20 > Let me just jump in for a second on this. >=20 > I think it's great for providers to add support for IPv6 for: >=20 > -- web email > -- Authenticated secure IMAP > -- Authenticated secure POP > -- Authenticated secure message submission >=20 > In all of those cases, because users *are* authenticating, you know = who=20 > your users are, regardless of how or from where they connect. If they > begin to spew, you'll know who it is and you can deal with them/their=20= > compromised machine. >=20 > At this point, though, I'd be wary of fielding Internet-accessible=20 > IPv6-enabled SMTP servers. >=20 > Why? Spam management solutions simply aren't yet where they need to = be... Well, there's the other observation to make. which is you and I have = been running ipv6 enabled mailservers since sometime in 2001 and yes we = receive spam from over ipv6 but the world pretty much hasn't ended = either. now in neither case we we dependent on some rock in a box spam = appliance that we forgot to renew the annual maintenance on, but at the = same time we're not running that much that isn't off the shelf software. > Yeah, if you're lucky, maybe you won't see any spam via IPv6 = connections, > or maybe you can clean it up with a purely content-oriented anti-spam=20= > solution (such as SpamAssassin or a Baeysian approach), but if you = want=20 > to use traditional blocklists or you want to use some of the major=20 > commercial anti-spam appliances, what you'd want is simply not = available. > Regards, >=20 > Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nick@inex.ie Fri Jul 22 11:28:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED8F21F8A30 for ; Fri, 22 Jul 2011 11:28:21 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzbKp0oaPH1E for ; Fri, 22 Jul 2011 11:28:21 -0700 (PDT) Received: from prometheus.inex.ie (prometheus.inex.ie [IPv6:2001:7f8:18:2::148]) by ietfa.amsl.com (Postfix) with ESMTP id B40CC21F8AB8 for ; Fri, 22 Jul 2011 11:28:20 -0700 (PDT) Received: from prometheus.inex.ie (localhost [127.0.0.1]) by prometheus.inex.ie (Postfix) with ESMTP id 06F7728421 for ; Fri, 22 Jul 2011 19:28:20 +0100 (IST) X-Virus-Scanned: amavisd-new at inex.ie Received: from prometheus.inex.ie ([127.0.0.1]) by prometheus.inex.ie (prometheus.inex.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge+ahaY5-Ioh for ; Fri, 22 Jul 2011 19:28:18 +0100 (IST) Received: from crumpet.foobar.org (unknown [IPv6:2001:4d68:2002:100:55d:1386:3c8e:21dd]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: operations) by prometheus.inex.ie (Postfix) with ESMTPSA id 6656C28419 for ; Fri, 22 Jul 2011 19:28:18 +0100 (IST) Message-ID: <4E29C141.6000307@inex.ie> Date: Fri, 22 Jul 2011 19:28:17 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <11072209372672_B93@oregon.uoregon.edu> In-Reply-To: X-Enigmail-Version: 1.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 18:28:22 -0000 On 22/07/2011 18:42, Keith Moore wrote: > One of the things that I've been wondering is whether IPv6 provides a > good excuse/lever to have all email that crosses administrative domain > boundaries over IPv6, use TLS and AUTH EXTERNAL and authenticate to SMTP > servers using client certificates. Ideally it would use DNSSEC to > authenticate the client certs instead of relying on trusted CAs. Keith, Summarising this and previous emails, you're suggesting that: 1. the authors should add a quickie paragraph to mandate that all interdomain ipv6 SMTP be authenticated via PKI, 2. provider MTA/MSA services are being held up by lack of automatic tunnelling, 2.1 ... implying that it's even remotely appropriate to host production services on service provider networks using ipv6 transition mechanisms, 3. this document "threatens to marginalize small players", 4. the time-frames mentioned in this document are "completely disconnected from reality", 5. that this document can or should attempt to deal with the tiny proportion of users on the internet who host mail servers on the last mile, and 6. "There's really little point to upgrading mail to use IPv6 until most of the net has IPv6 access". Speaking as an operator, I do not see any credible basis for any of these positions. Nick From joe@oregon.uoregon.edu Fri Jul 22 11:33:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C1221F8B3F for ; Fri, 22 Jul 2011 11:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC4JXV-t8U81 for ; Fri, 22 Jul 2011 11:33:22 -0700 (PDT) Received: from grey.uoregon.edu (grey.uoregon.edu [128.223.214.89]) by ietfa.amsl.com (Postfix) with SMTP id 375FF21F8B51 for ; Fri, 22 Jul 2011 11:33:22 -0700 (PDT) Date: Fri, 22 Jul 2011 10:54:22 -0700 (PDT) Message-Id: <11072210542268_B93@oregon.uoregon.edu> From: "Joe St Sauver" To: moore@network-heretics.com X-VMS-To: SMTP%"moore@network-heretics.com" X-VMS-Cc: SMTP%"joe@oregon.uoregon.edu", SMTP%"gert@space.net", SMTP%"fred@cisco.com", SMTP%"v6ops@ietf.org", SMTP%"dcrocker@bbiw.net", SMTP%"johnl@iecc.com" Cc: joe@oregon.uoregon.edu, v6ops@ietf.org, dcrocker@bbiw.net, johnl@iecc.com Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 18:33:23 -0000 Keith commented: #One of the things that I've been wondering is whether IPv6 provides a good #excuse/lever to have all email that crosses administrative domain boundaries #over IPv6, use TLS and AUTH EXTERNAL and authenticate to SMTP servers using #client certificates. Ideally it would use DNSSEC to authenticate the client #certs instead of relying on trusted CAs. But I think all of the protocol work #should be defined, it just needs to be profiled. This seems like it might be #an opportunity to raise the level of email security in general and also raise #the bar for spammers. Just a couple of quick points: -- I'm a huge fan of opportunistic TLS wherever it can be deployed, including for SMTP (whether that SMTP server uses IPv4 or IPv6 transport or both). -- Because (as of July 2011) I've taken on additional duties as the certificate program manager for the Internet2/InCommon Certificate Service (http://www.incommon.org/cert/) in addition to my continuing responsibilities as Internet2's security program manager under contract through UO, to avoid any potential perception of a COI when it comes to promoting use of certificates, I'll simply say that: -- I'd agree that there are *many* potential security-enhancing ways that one can potentially employ server and personal certificates, and -- My support for both traditional well-trusted CAs *and* for the IETF DANE work leveraging DNSSEC for key trust management is a matter of record (for example, I co-presented with Leif from SUNET/NORDUNet as part of the DANE session at the April 2011 Internet2 Memeber Meeting in Arlington). I don't view one model as precluding the other, and ideally speaking, I'd like to see sites embrace both. Regards, Joe From msk@cloudmark.com Fri Jul 22 11:39:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6963221F85A7 for ; Fri, 22 Jul 2011 11:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.535 X-Spam-Level: X-Spam-Status: No, score=-103.535 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+nsQr8fk0lU for ; Fri, 22 Jul 2011 11:39:04 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id EFF7621F858C for ; Fri, 22 Jul 2011 11:39:03 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 22 Jul 2011 11:39:03 -0700 From: "Murray S. Kucherawy" To: Gert Doering , Fred Baker Date: Fri, 22 Jul 2011 11:39:02 -0700 Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AcxIjXMUIkm7ooIaTt+Zw9REJoxGzAAEQTSA Message-ID: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <20110722163544.GA2304@Space.Net> In-Reply-To: <20110722163544.GA2304@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 18:39:04 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Gert Doering > Sent: Friday, July 22, 2011 9:36 AM > To: Fred Baker > Cc: Joe St Sauveur; v6ops@ietf.org; Keith Moore; Dave Crocker; John R. Le= vine > Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevi= ce providers and other communities >=20 > On Fri, Jul 22, 2011 at 08:59:27AM -0700, Fred Baker wrote: > > My initial comment to Michael, when he pointed the draft out to me, > > was that email seems like the poster child of an easy application to > > add IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support > > it already and the current OS's support IPv6. >=20 > Seconded. Plus, if mail gets delayed by a few minutes due to IPv6 > breakage, it helps *noticing* problems without impacting user > experience in a very massive way (like for IPv6 HTTP running into > timeouts). Since the word "applications" appeared twice in there, I wonder if this mig= ht be better suited to be developed inside APPSAWG instead of, or perhaps i= n conjunction with, V6OPS. From moore@network-heretics.com Fri Jul 22 12:24:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871B721F8AB9 for ; Fri, 22 Jul 2011 12:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.766 X-Spam-Level: X-Spam-Status: No, score=-3.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCb3lW2pDJjX for ; Fri, 22 Jul 2011 12:24:28 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0C43C21F8AAC for ; Fri, 22 Jul 2011 12:24:28 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id A9F0F20D95; Fri, 22 Jul 2011 15:24:27 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 22 Jul 2011 15:24:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=3dlZMmFd7cgXZLy3Hz01o05nS0Q=; b=lv vVyVrDHk4P9M4mhj9x0lDcf4/mgUBpuyFyOG4+DR6pvU4Dq1zuk99XnFmtMI8HdE Bkd/NibTn3u7qRYZjkdRw5foQ0NFk1F5/Xx7h33ZKRLf42rRGWYlH+ogGkX3toQZ 2Sm6c/34Bi3lI0qKe0hRk4laD+QHnIaos53ElxQyg= X-Sasl-enc: 87ngLz2NdKg5AafUCgYFEmQOxniNikemzHW+XFYlsoWX 1311362667 Received: from [149.48.166.192] (unknown [149.48.166.192]) by mail.messagingengine.com (Postfix) with ESMTPA id 4241C451ED0; Fri, 22 Jul 2011 15:24:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <11072210542268_B93@oregon.uoregon.edu> Date: Fri, 22 Jul 2011 15:24:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <138BA1C7-FCE5-425F-95D1-0B6ED3BCF189@network-heretics.com> References: <11072210542268_B93@oregon.uoregon.edu> To: Joe St Sauver X-Mailer: Apple Mail (2.1084) Cc: johnl@iecc.com, v6ops@ietf.org, dcrocker@bbiw.net Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 19:24:28 -0000 On Jul 22, 2011, at 1:54 PM, Joe St Sauver wrote: > Keith commented: >=20 > #One of the things that I've been wondering is whether IPv6 provides a = good > #excuse/lever to have all email that crosses administrative domain = boundaries > #over IPv6, use TLS and AUTH EXTERNAL and authenticate to SMTP servers = using > #client certificates. Ideally it would use DNSSEC to authenticate = the client > #certs instead of relying on trusted CAs. But I think all of the = protocol work > #should be defined, it just needs to be profiled. This seems like it = might be=20 > #an opportunity to raise the level of email security in general and = also raise > #the bar for spammers.=20 >=20 > Just a couple of quick points: >=20 > -- I'm a huge fan of opportunistic TLS wherever it can be deployed, = including=20 > for SMTP (whether that SMTP server uses IPv4 or IPv6 transport or = both). I'm actually proposing something slightly more ambitious than = opportunistic TLS here. I'm proposing that the normal profile for = relaying IPv6 mail over SMTP be defined to use STARTTLS, AUTH EXTERNAL, = and client certificates authenticated via DNSSEC. (or maybe, via = either DNSSEC or a trusted CA...that would make it a tad easier.) Keith From moore@network-heretics.com Fri Jul 22 12:25:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A1521F8AE6 for ; Fri, 22 Jul 2011 12:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhT58h767LkN for ; Fri, 22 Jul 2011 12:25:17 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id E787F21F8ABC for ; Fri, 22 Jul 2011 12:25:16 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 99E2C20D88; Fri, 22 Jul 2011 15:25:16 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute5.internal (MEProxy); Fri, 22 Jul 2011 15:25:16 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=7jy MsdZZ8Qoab6vguuPQkOwyePQ=; b=A0CVVLbUNyPrfbeASxsun36DUZJfcr8UFNM cpK920VKt9uE0fGilYgZWjNPcl1PNlQ7zNrSqBqmVRa9ej9mWc9wlvAN/NSnA0G+ E9+tpfxKaJ79dqSZ5zh0I2PQLm4NZ2cOzDEfcs7yJUUytTb/3eee5mPzFBjk+62w esdy2Si8= X-Sasl-enc: MVWYh5J1hvNF7gfAcMnb+yuhQG1q5IUZOmpn+EwCJg06 1311362716 Received: from [149.48.166.192] (unknown [149.48.166.192]) by mail.messagingengine.com (Postfix) with ESMTPA id 42942446065; Fri, 22 Jul 2011 15:25:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-31-195550701 From: Keith Moore In-Reply-To: Date: Fri, 22 Jul 2011 15:25:15 -0400 Message-Id: <8427BB6D-C84A-400E-9CDE-0E79A25EAA58@network-heretics.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <20110722163544.GA2304@Space.Net> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1084) Cc: Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker , "John R. Levine" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 19:25:17 -0000 --Apple-Mail-31-195550701 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 22, 2011, at 2:39 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Gert Doering >> Sent: Friday, July 22, 2011 9:36 AM >> To: Fred Baker >> Cc: Joe St Sauveur; v6ops@ietf.org; Keith Moore; Dave Crocker; John = R. Levine >> Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for = sevice providers and other communities >>=20 >> On Fri, Jul 22, 2011 at 08:59:27AM -0700, Fred Baker wrote: >>> My initial comment to Michael, when he pointed the draft out to me, >>> was that email seems like the poster child of an easy application to >>> add IPv6 to, as the applications (SMTP, POP, and IMAP) mostly = support >>> it already and the current OS's support IPv6. >>=20 >> Seconded. Plus, if mail gets delayed by a few minutes due to IPv6 >> breakage, it helps *noticing* problems without impacting user >> experience in a very massive way (like for IPv6 HTTP running into >> timeouts). >=20 > Since the word "applications" appeared twice in there, I wonder if = this might be better suited to be developed inside APPSAWG instead of, = or perhaps in conjunction with, V6OPS. My suggestion to the authors was that they run it by ietf-smtp@imc.org, = which is the old IETF smtpext WG mailing list. Keith --Apple-Mail-31-195550701 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
-----Original = Message-----
From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert = Doering
Sent: Friday, July 22, = 2011 9:36 AM
To: Fred = Baker
Cc: Joe St Sauveur; v6ops@ietf.org; Keith Moore; Dave = Crocker; John R. Levine
Subject:= Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice = providers and other communities

On Fri, Jul 22, = 2011 at 08:59:27AM -0700, Fred Baker wrote:
My initial comment to Michael, = when he pointed the draft out to = me,
was that email seems like the poster child of an easy = application to
add IPv6 to, as the applications = (SMTP, POP, and IMAP) mostly = support
it already and the current OS's support = IPv6.

Seconded. =  Plus, if mail gets delayed by a few minutes due to = IPv6
breakage, it helps = *noticing* problems without impacting user
experience in a very massive way (like for IPv6 HTTP = running into
timeouts).

Since the word = "applications" appeared twice in there, I wonder if this might be better = suited to be developed inside APPSAWG instead of, or perhaps in = conjunction with, V6OPS.

My = suggestion to the authors was that they run it by ietf-smtp@imc.org, which is the = old IETF smtpext WG mailing = list.

Keith

= --Apple-Mail-31-195550701-- From joelja@bogus.com Fri Jul 22 12:34:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904A521F886C for ; Fri, 22 Jul 2011 12:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2pQ0l2PwoJ6 for ; Fri, 22 Jul 2011 12:34:41 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id DD29C21F87D9 for ; Fri, 22 Jul 2011 12:34:40 -0700 (PDT) Received: from [10.104.74.150] ([75.98.19.132]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6MJYRO4051009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jul 2011 19:34:29 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <138BA1C7-FCE5-425F-95D1-0B6ED3BCF189@network-heretics.com> Date: Fri, 22 Jul 2011 12:34:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44286070-785E-4E2E-B8B9-8BE496BFE3BD@bogus.com> References: <11072210542268_B93@oregon.uoregon.edu> <138BA1C7-FCE5-425F-95D1-0B6ED3BCF189@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 22 Jul 2011 19:34:31 +0000 (UTC) Cc: johnl@iecc.com, Joe St Sauver , v6ops@ietf.org, dcrocker@bbiw.net Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 19:34:41 -0000 On Jul 22, 2011, at 12:24 PM, Keith Moore wrote: > On Jul 22, 2011, at 1:54 PM, Joe St Sauver wrote: >=20 >> Keith commented: >>=20 >> #One of the things that I've been wondering is whether IPv6 provides = a good >> #excuse/lever to have all email that crosses administrative domain = boundaries >> #over IPv6, use TLS and AUTH EXTERNAL and authenticate to SMTP = servers using >> #client certificates. Ideally it would use DNSSEC to authenticate = the client >> #certs instead of relying on trusted CAs. But I think all of the = protocol work >> #should be defined, it just needs to be profiled. This seems like = it might be=20 >> #an opportunity to raise the level of email security in general and = also raise >> #the bar for spammers.=20 >>=20 >> Just a couple of quick points: >>=20 >> -- I'm a huge fan of opportunistic TLS wherever it can be deployed, = including=20 >> for SMTP (whether that SMTP server uses IPv4 or IPv6 transport or = both). >=20 > I'm actually proposing something slightly more ambitious than = opportunistic TLS here. I'm proposing that the normal profile for = relaying IPv6 mail over SMTP be defined to use STARTTLS, AUTH EXTERNAL, = and client certificates authenticated via DNSSEC. (or maybe, via = either DNSSEC or a trusted CA...that would make it a tad easier.) This is your solution to you claim that ipv6 blocklist management won't = scale? > Keith >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From moore@network-heretics.com Fri Jul 22 12:47:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64EC21F869C for ; Fri, 22 Jul 2011 12:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NziQJO-PjXJp for ; Fri, 22 Jul 2011 12:47:28 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 18CA921F8556 for ; Fri, 22 Jul 2011 12:47:28 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id C2B2820E9F; Fri, 22 Jul 2011 15:47:27 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute5.internal (MEProxy); Fri, 22 Jul 2011 15:47:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=e3Y+7cM0WfAzTsT5fjvTUP9nnEY=; b=HG pQrXkFRFwkG9Ah2EmLo2hsx85+rCdoghGH/Bj06ZKk190fqDoGUET2z2EBaEnFqR jOxjMYw8aWRgr0Pd1ddwkv3KgvN8/mxYuuTec9Nsf5YCynzjviXUo0FcgsCboonP de/c5k+aiY5D9OlUnj/Vs7WXANFMqDdEtIK3ecMXg= X-Sasl-enc: 7R7RaA6o8bxakaJgN/0GxREJVNukredGay8UIQefVDCn 1311364047 Received: from [149.48.166.192] (unknown [149.48.166.192]) by mail.messagingengine.com (Postfix) with ESMTPA id 82F9C452293; Fri, 22 Jul 2011 15:47:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E29C141.6000307@inex.ie> Date: Fri, 22 Jul 2011 15:47:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11072209372672_B93@oregon.uoregon.edu> <4E29C141.6000307@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 19:47:29 -0000 On Jul 22, 2011, at 2:28 PM, Nick Hilliard wrote: > On 22/07/2011 18:42, Keith Moore wrote: >> One of the things that I've been wondering is whether IPv6 provides a >> good excuse/lever to have all email that crosses administrative = domain >> boundaries over IPv6, use TLS and AUTH EXTERNAL and authenticate to = SMTP >> servers using client certificates. Ideally it would use DNSSEC to >> authenticate the client certs instead of relying on trusted CAs. >=20 > Keith, >=20 > Summarising this and previous emails, you're suggesting that: >=20 > 1. the authors should add a quickie paragraph to mandate that all > interdomain ipv6 SMTP be authenticated via PKI, I don't think it's a "quickie paragraph", but I do think it's the same = general topic and might should be part of the discussion. I don't think = this is something that should be decided quickly, and certainly not = entirely in v6ops. > 2. provider MTA/MSA services are being held up by lack of automatic = tunnelling, Not "provider" services. But if you want to write a document that = specifies how to do email over IPv6, it's important to not marginalize = those who don't have IPv6 yet. > 2.1 ... implying that it's even remotely appropriate to host = production > services on service provider networks using ipv6 transition = mechanisms, No, I implied the opposite... at least when using current transition = mechanisms. > 3. this document "threatens to marginalize small players", The idea, expressed here, that email services shouldn't be run in = enterprise networks on the edge, does threaten to marginalize small = players, where "players" include enterprises running their own mail.=20 > 4. the time-frames mentioned in this document are "completely = disconnected > from reality", ..unless you somehow limit who is expected to follow those guidelines to = "major players" > 5. that this document can or should attempt to deal with the tiny > proportion of users on the internet who host mail servers on the last = mile, and ...or maybe, the document just needs to be clearer about its scope. > 6. "There's really little point to upgrading mail to use IPv6 until = most of > the net has IPv6 access". There's a point if you want to gain experience with SMTP over IPv6 and = spam countermeasures in that world. But there's no functionality to be = gained by doing so. The basis for interoperability of email is going = to continue to be IPv4 for a long time, *unless* large operators somehow = manage to marginalize small ones. And that's not desirable from my POV, = nor appropriate for IETF to encourage. > Speaking as an operator, I do not see any credible basis for any of = these > positions. That's probably because you're an operator, and therefore have a = different view of the world. Keith From moore@network-heretics.com Fri Jul 22 12:53:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838A321F89BA for ; Fri, 22 Jul 2011 12:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.643 X-Spam-Level: X-Spam-Status: No, score=-3.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRy+4EOQyN5z for ; Fri, 22 Jul 2011 12:53:41 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id C46B421F899D for ; Fri, 22 Jul 2011 12:53:41 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 6B93B211DA; Fri, 22 Jul 2011 15:53:41 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 22 Jul 2011 15:53:41 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=ENenCPkYcOYRNoZ43LJ7k7X6OEg=; b=Q4 cxJm5D7TMeXeD1QWGjWWnoo5HAxpjlQOqZZxQJ7Lp9LxAfzfIIt6lgV0QtR+HKW7 5LW0hQZDhw4DYkZPXA/oQSrTn+0WLqrl81BfMo81lFKY6ICO6fepd9SOy68gyZnR x+4sDg9dlH04ofnVPp3um1s554/feo4BiwJLbG848= X-Sasl-enc: 24dhbep19248uEo1u3yHNMz3PEz7UgiKzGR1RKKUeXfO 1311364421 Received: from [149.48.166.192] (unknown [149.48.166.192]) by mail.messagingengine.com (Postfix) with ESMTPA id 0838745332D; Fri, 22 Jul 2011 15:53:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <44286070-785E-4E2E-B8B9-8BE496BFE3BD@bogus.com> Date: Fri, 22 Jul 2011 15:53:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <81AA9637-52DE-4F1C-B9BE-9DC470B8B55A@network-heretics.com> References: <11072210542268_B93@oregon.uoregon.edu> <138BA1C7-FCE5-425F-95D1-0B6ED3BCF189@network-heretics.com> <44286070-785E-4E2E-B8B9-8BE496BFE3BD@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1084) Cc: johnl@iecc.com, Joe St Sauver , v6ops@ietf.org, dcrocker@bbiw.net Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 19:53:42 -0000 On Jul 22, 2011, at 3:34 PM, Joel Jaeggli wrote: > On Jul 22, 2011, at 12:24 PM, Keith Moore wrote: >=20 >> On Jul 22, 2011, at 1:54 PM, Joe St Sauver wrote: >>=20 >>> Keith commented: >>>=20 >>> #One of the things that I've been wondering is whether IPv6 provides = a good >>> #excuse/lever to have all email that crosses administrative domain = boundaries >>> #over IPv6, use TLS and AUTH EXTERNAL and authenticate to SMTP = servers using >>> #client certificates. Ideally it would use DNSSEC to authenticate = the client >>> #certs instead of relying on trusted CAs. But I think all of the = protocol work >>> #should be defined, it just needs to be profiled. This seems like = it might be=20 >>> #an opportunity to raise the level of email security in general and = also raise >>> #the bar for spammers.=20 >>>=20 >>> Just a couple of quick points: >>>=20 >>> -- I'm a huge fan of opportunistic TLS wherever it can be deployed, = including=20 >>> for SMTP (whether that SMTP server uses IPv4 or IPv6 transport or = both). >>=20 >> I'm actually proposing something slightly more ambitious than = opportunistic TLS here. I'm proposing that the normal profile for = relaying IPv6 mail over SMTP be defined to use STARTTLS, AUTH EXTERNAL, = and client certificates authenticated via DNSSEC. (or maybe, via = either DNSSEC or a trusted CA...that would make it a tad easier.) >=20 > This is your solution to you claim that ipv6 blocklist management = won't scale? There's more than one kind of scaling. The problem with basing = reputation on IPv6 source addresses is that IPv6 source addresses are = even less meaningful than IPv4 addresses in this regard, and IPv4 = addresses are already of pretty marginal value. The consequence of = basing reputation on a meaningless value is that more innocent peoples' = mail gets blacklisted. Whether you think of this as a scaling problem = depends on your POV. Keith From Ted.Lemon@nominum.com Fri Jul 22 13:10:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA1821F87A4 for ; Fri, 22 Jul 2011 13:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nduzox97-SOq for ; Fri, 22 Jul 2011 13:10:13 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAF521F86E6 for ; Fri, 22 Jul 2011 13:10:12 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTinZHzMzhFHjo4ZyeQs/GL6Pp1tkj8VP@postini.com; Fri, 22 Jul 2011 13:10:13 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8EA3B1B81AD for ; Fri, 22 Jul 2011 13:10:05 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 79B6919006B; Fri, 22 Jul 2011 13:10:05 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Fri, 22 Jul 2011 13:10:05 -0700 From: Ted Lemon To: Joel Jaeggli Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AQHMSI2j6Jk8HHzgmkCy3qniqcKe15T5HYsAgAAdYYA= Date: Fri, 22 Jul 2011 20:10:04 +0000 Message-ID: References: <11072209372672_B93@oregon.uoregon.edu> <9A599E25-B603-4EDB-9449-4A0B67938AFD@bogus.com> In-Reply-To: <9A599E25-B603-4EDB-9449-4A0B67938AFD@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.89.227.148] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Joe St Sauver , "" , "" , "" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 20:10:14 -0000 On Jul 22, 2011, at 2:24 PM, Joel Jaeggli wrote: > Well, there's the other observation to make. which is you and I have been= running ipv6 enabled mailservers since sometime in 2001 and yes we receive= spam from over ipv6 but the world pretty much hasn't ended either. now in = neither case we we dependent on some rock in a box spam appliance that we f= orgot to renew the annual maintenance on, but at the same time we're not ru= nning that much that isn't off the shelf software. I have a v6-only SMTP server for a domain that I don't need to depend on, a= nd it has not received a single item of spam since I set it up. Of course= , if all the mail servers out there worked with IPv6, that would change. I think that it might be worth differentiating between listening on IPv6 an= d sending on IPv6. Listening on IPv6 requires that you have an answer for= spam. Sending on IPv6 does not. Sending on IPv6 would make it possible= to deliver to sites that can originate IPv4 SMTP connections over a NAT li= nk, don't have a globally-routable IPv4 address, but do have a globally-rou= teable IPv6 address. Consequently, I'd really like to see people enable t= ransmission of mail over IPv6, even if they don't enable reception. From gert@space.net Fri Jul 22 14:15:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E2A21F8B2D for ; Fri, 22 Jul 2011 14:15:04 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9-rJB22du2d for ; Fri, 22 Jul 2011 14:15:04 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id F2DFF21F8B3F for ; Fri, 22 Jul 2011 14:15:02 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id B27EBF855E for ; Fri, 22 Jul 2011 23:15:01 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8572EF854E for ; Fri, 22 Jul 2011 23:15:01 +0200 (CEST) Received: (qmail 68970 invoked by uid 1007); 22 Jul 2011 23:15:01 +0200 Date: Fri, 22 Jul 2011 23:15:01 +0200 From: Gert Doering To: Joe St Sauver Message-ID: <20110722211501.GC2304@Space.Net> References: <11072209372672_B93@oregon.uoregon.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5O9P/emuN/u5cQ6a" Content-Disposition: inline In-Reply-To: <11072209372672_B93@oregon.uoregon.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, moore@network-heretics.com, dcrocker@bbiw.net, johnl@iecc.com Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:15:05 -0000 --5O9P/emuN/u5cQ6a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jul 22, 2011 at 09:37:26AM -0700, Joe St Sauver wrote: > At this point, though, I'd be wary of fielding Internet-accessible=20 > IPv6-enabled SMTP servers. >=20 > Why? Spam management solutions simply aren't yet where they need to be... =2E.. in which case, gratuitous amounts of pressure needs to be applied to anti-spam vendors that are not there yet. We use an anti-spam appliance from one of the big vendors that make videos how important IPv6 is, but that still doesn't have IPv6 yet - so we had to setup a parallel IPv6-only MX that will wash the e-mail in a different way. Ugly as hell, but all this stalling "we can't do IPv6 because *this* is missing and *they* are not there either" is really something that needs to go away. Quickly. > Yeah, if you're lucky, maybe you won't see any spam via IPv6 connections, > or maybe you can clean it up with a purely content-oriented anti-spam=20 > solution (such as SpamAssassin or a Baeysian approach), but if you want= =20 > to use traditional blocklists or you want to use some of the major=20 > commercial anti-spam appliances, what you'd want is simply not available. I won't go into the details of the various anti-spam options - but there's enough that operate on the sender's IPv* address and handle v6 fine. Others, like SpamAssassin, use the IP address only for scoring among other algorithms, and also handle IPv6 just fine. BTDT, since way too many years to not get impatient over time. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --5O9P/emuN/u5cQ6a Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTinoVakuBuNlUUl1AQIkoQP/YCPP2rYYFP5GTuOvcCnQYo1QrgbeMrLd 6eOBHkX2fEMzg211PeShxuX/uTPjw9f8vZFqjLUpM3ak48WRtog9fukSzuWlr8vT SLUxsl8f4d3PSKMUl7hwcl2iiHo6r5QOfMQ2/xcJxyZFh4nj/lM+KNIRgt2SjUWT 5ao5EFJ99rk= =D6oW -----END PGP SIGNATURE----- --5O9P/emuN/u5cQ6a-- From gert@space.net Fri Jul 22 14:15:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2251321F8B4F for ; Fri, 22 Jul 2011 14:15:48 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukKg4fPKMK12 for ; Fri, 22 Jul 2011 14:15:47 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8348521F8B68 for ; Fri, 22 Jul 2011 14:15:47 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id C4E83F855D for ; Fri, 22 Jul 2011 23:15:46 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id AAD8BF854A for ; Fri, 22 Jul 2011 23:15:46 +0200 (CEST) Received: (qmail 69155 invoked by uid 1007); 22 Jul 2011 23:15:46 +0200 Date: Fri, 22 Jul 2011 23:15:46 +0200 From: Gert Doering To: Keith Moore Message-ID: <20110722211546.GD2304@Space.Net> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w5H9inKjI0oWCkP3" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker , "John R. Levine" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:15:48 -0000 --w5H9inKjI0oWCkP3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jul 22, 2011 at 01:27:40PM -0400, Keith Moore wrote: > On Jul 22, 2011, at 11:20 AM, Gert Doering wrote: >=20 > > You don't need universal availability on the last DSL line to have > > IPv6 *on servers*. Which are usually not located behind consumer > > products. >=20 > This might be true for your customers. But it's not an appropriate assum= ption to make for all mail servers on the Internet. Neither is your assumption that there is no IPv6. So what? 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 (89) 32356-444 USt-IdNr.: DE813185279 --w5H9inKjI0oWCkP3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTinogqkuBuNlUUl1AQL+pgQAjBBQUfUiZ84NnPJQejLvkyxp0ojL9VhF WY02Q+vdN1vlemD4654ODy8NKMDhrEV8Fs0MeqBL6sWngBbr4DxLdp4+xpaupqCY DmUMe6jFTetCUnAUfb543+fGRqTWOwlHqJaqw1A651KbDOZVemTeydcFqxbiJ/an sMCvvDmRcUM= =NQj0 -----END PGP SIGNATURE----- --w5H9inKjI0oWCkP3-- From nick@inex.ie Fri Jul 22 14:26:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9B121F87C6 for ; Fri, 22 Jul 2011 14:26:47 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stVmQqsv1ihw for ; Fri, 22 Jul 2011 14:26:46 -0700 (PDT) Received: from prometheus.inex.ie (prometheus.inex.ie [IPv6:2001:7f8:18:2::148]) by ietfa.amsl.com (Postfix) with ESMTP id 42E9B21F87BC for ; Fri, 22 Jul 2011 14:26:45 -0700 (PDT) Received: from prometheus.inex.ie (localhost [127.0.0.1]) by prometheus.inex.ie (Postfix) with ESMTP id 87DE228423; Fri, 22 Jul 2011 22:26:44 +0100 (IST) X-Virus-Scanned: amavisd-new at inex.ie Received: from prometheus.inex.ie ([127.0.0.1]) by prometheus.inex.ie (prometheus.inex.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS5VTYFpAgkJ; Fri, 22 Jul 2011 22:26:43 +0100 (IST) Received: from crumpet.foobar.org (unknown [IPv6:2001:4d68:2002:100:55d:1386:3c8e:21dd]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: operations) by prometheus.inex.ie (Postfix) with ESMTPSA id E9EB728419; Fri, 22 Jul 2011 22:26:42 +0100 (IST) Message-ID: <4E29EB12.4080605@inex.ie> Date: Fri, 22 Jul 2011 22:26:42 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Keith Moore References: <11072209372672_B93@oregon.uoregon.edu> <4E29C141.6000307@inex.ie> In-Reply-To: X-Enigmail-Version: 1.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:26:47 -0000 On 22/07/2011 20:47, Keith Moore wrote: > [lots of stuff] I was going to reply to this email point by point, but decided against as there appears to be little or no common ground between us. Continuing the conversation would just end up in a shouting match, with little chance of meaningful discussion. And it would do nothing but distract attention from the substantial issues in the draft. Nick From johnl@iecc.com Fri Jul 22 14:48:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE4B21F881C for ; Fri, 22 Jul 2011 14:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5T36twOFbBm0 for ; Fri, 22 Jul 2011 14:48:34 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 02DDF21F880C for ; Fri, 22 Jul 2011 14:48:33 -0700 (PDT) Received: (qmail 50686 invoked from network); 22 Jul 2011 21:48:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=c5fd.4e29f030.k1107; bh=aK/cNANHn+Xw51CPS3DANhjkTfnWlFc3N3uEh5EY2gY=; b=pq5haw6vLE+3eFz78+ty+n/uxvJNywPxgA5AUSHgcFIfF6D0blPczetYkkO8OWbbbegheSe0MWwDngXaEH4Vno8O0jrChICXhwd/c1vyP3TDpS0IC45UZjpV3F5ynHPM8I7Ttr4ZlT+sYk1WUEzIO21Lt6qjz0vOTofgfD4Mw3s= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Jul 2011 21:48:10 -0000 Date: 22 Jul 2011 23:48:28 +0200 Message-ID: From: "John R. Levine" To: "Fred Baker" In-Reply-To: <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 22 Jul 2011 14:54:54 -0700 Cc: Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker , Keith Moore Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:48:34 -0000 > My initial comment to Michael, when he pointed the draft out to me, was that email seems like the poster child of an easy application to add IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support it already and the current OS's support IPv6. The primary thing preventing mail/IPv6 is network IPv6 deployment, which is in progress. Setting up an IPv6 mail server is easy. The problem is that the vast majority of incoming mail is hostile, and IPv4 mail filtering techniques don't migrate well to IPv6. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From msk@cloudmark.com Fri Jul 22 14:57:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F10221F8B2F for ; Fri, 22 Jul 2011 14:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.027 X-Spam-Level: X-Spam-Status: No, score=-103.027 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV+sYG95oAS4 for ; Fri, 22 Jul 2011 14:57:49 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id BA0E421F8B1C for ; Fri, 22 Jul 2011 14:57:49 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 22 Jul 2011 14:57:49 -0700 From: "Murray S. Kucherawy" To: Keith Moore Date: Fri, 22 Jul 2011 14:57:48 -0700 Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AcxIpRpGdghV6/UCQnSEOaVmYqRkvAAFTuAw Message-ID: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <20110722163544.GA2304@Space.Net> <8427BB6D-C84A-400E-9CDE-0E79A25EAA58@network-heretics.com> In-Reply-To: <8427BB6D-C84A-400E-9CDE-0E79A25EAA58@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DF3D5EXCHC2corpclo_" MIME-Version: 1.0 Cc: Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker , "John R. Levine" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:57:51 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DF3D5EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, though any transition will involve things outside of SMTP's scope as = well. From: Keith Moore [mailto:moore@network-heretics.com] Sent: Friday, July 22, 2011 12:25 PM To: Murray S. Kucherawy Cc: Gert Doering; Fred Baker; Joe St Sauveur; v6ops@ietf.org; Dave Crocker;= John R. Levine Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice= providers and other communities On Jul 22, 2011, at 2:39 PM, Murray S. Kucherawy wrote: -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Gert Doering Sent: Friday, July 22, 2011 9:36 AM To: Fred Baker Cc: Joe St Sauveur; v6ops@ietf.org; Keith Moore; Dav= e Crocker; John R. Levine Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice= providers and other communities On Fri, Jul 22, 2011 at 08:59:27AM -0700, Fred Baker wrote: My initial comment to Michael, when he pointed the draft out to me, was that email seems like the poster child of an easy application to add IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support it already and the current OS's support IPv6. Seconded. Plus, if mail gets delayed by a few minutes due to IPv6 breakage, it helps *noticing* problems without impacting user experience in a very massive way (like for IPv6 HTTP running into timeouts). Since the word "applications" appeared twice in there, I wonder if this mig= ht be better suited to be developed inside APPSAWG instead of, or perhaps i= n conjunction with, V6OPS. My suggestion to the authors was that they run it by ietf-smtp@imc.org, which is the old IETF smtpext WG mailing list. Keith --_000_F5833273385BB34F99288B3648C4F06F13512DF3D5EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure, though any transition will involve things outside of SMTP&= #8217;s scope as well.

 

From:<= /b> Keit= h Moore [mailto:moore@network-heretics.com]
Sent: Friday, July 2= 2, 2011 12:25 PM
To: Murray S. Kucherawy
Cc: Gert Doeri= ng; Fred Baker; Joe St Sauveur; v6ops@ietf.org; Dave Crocker; John R. Levin= e
Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv= 4 for sevice providers and other communities

 

On Jul 22, 2011, at 2:39 PM, Murray S. Kucherawy wrote:



-----Original Messa= ge-----

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Gert Doering

Sent: Friday, July 2= 2, 2011 9:36 AM

To: Fred Baker

<= p class=3DMsoNormal>Cc: Joe St Sauveur; v= 6ops@ietf.org; Keith Moore; Dave Crocker; John R. Levine

=

Subject: Re: [v6ops] Draft on email transition to IPv6 fr= om IPv4 for sevice providers and other communities

 

On Fri, Jul 22, 2011 at 08:5= 9:27AM -0700, Fred Baker wrote:

My initial comment to Micha= el, when he pointed the draft out to me,

was t= hat email seems like the poster child of an easy application to<= /p>

add IPv6 to, as the applications (SMTP, POP, and IMAP) mo= stly support

it already and the current OS's s= upport IPv6.

 =

Seconded.  Plus, if mail gets delayed by a few m= inutes due to IPv6

breakage, it helps *noti= cing* problems without impacting user

exper= ience in a very massive way (like for IPv6 HTTP running into

=

timeouts).


Since the word "applications" appeared twice in there, I wo= nder if this might be better suited to be developed inside APPSAWG instead = of, or perhaps in conjunction with, V6OPS.

 

My suggestion= to the authors was that they run it by ietf-smtp@imc.org, which is the old IETF smtpext WG mailing list.

 

=

Keith

 

= --_000_F5833273385BB34F99288B3648C4F06F13512DF3D5EXCHC2corpclo_-- From bigbadbob0@gmail.com Fri Jul 22 15:01:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D30121F8512 for ; Fri, 22 Jul 2011 15:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2a1x1ZpAV44 for ; Fri, 22 Jul 2011 15:01:31 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9842921F8510 for ; Fri, 22 Jul 2011 15:01:30 -0700 (PDT) Received: by qwc23 with SMTP id 23so2122593qwc.31 for ; Fri, 22 Jul 2011 15:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Zyl0/MqDCNvWH4OHE4zvh+7c3XxzO7kJR/BNN+7uNrQ=; b=QiKkiv9MNYwy4aOSxs2APQeaYjidazIXllrHaaQbOwtuYP4ffiBj5vgkKm2vbvuPg2 iS+4Kjh3Ui2G8/p80d21hxttiG/XUaoEcLu9v719hcKm0fJ8TGE13w8NwRAf0ivPN/RU 84Ht6RFQlSf0sx/rRMv6ztVCIx8n5URFzmh+0= MIME-Version: 1.0 Received: by 10.229.2.131 with SMTP id 3mr1634580qcj.156.1311372089894; Fri, 22 Jul 2011 15:01:29 -0700 (PDT) Sender: bigbadbob0@gmail.com Received: by 10.229.187.136 with HTTP; Fri, 22 Jul 2011 15:01:29 -0700 (PDT) In-Reply-To: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> Date: Fri, 22 Jul 2011 15:01:29 -0700 X-Google-Sender-Auth: 1wpbyUbvYpID_TJsM2DdTugL0aE Message-ID: From: Bob Van Zant To: "John R. Levine" Content-Type: text/plain; charset=ISO-8859-1 Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 22:01:32 -0000 On Fri, Jul 22, 2011 at 2:48 PM, John R. Levine wrote: > The problem is that the vast majority of incoming mail is hostile, and > IPv4 mail filtering techniques don't migrate well to IPv6. This statement simply doesn't hold true for IPv6 email. Gert's saying it. I'm saying it. Someone else on this thread said it. We're all speaking from experience. We sit on this list and occasionally criticize the networking gear vendors for dragging their feet (and we should). Who's dragging their feet now? -Bob From ocl@gih.com Fri Jul 22 15:06:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100EE21F8B82 for ; Fri, 22 Jul 2011 15:06:07 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DFvyK3hbDvX for ; Fri, 22 Jul 2011 15:06:06 -0700 (PDT) Received: from waikiki.gih.co.uk (salsa.gih.co.uk [IPv6:2a00:19e8:10:5::b]) by ietfa.amsl.com (Postfix) with ESMTP id E5BB621F8531 for ; Fri, 22 Jul 2011 15:06:05 -0700 (PDT) Received: from waikiki.gih.co.uk (localhost6.localdomain6 [IPv6:::1]) by waikiki.gih.co.uk (Postfix) with ESMTP id CEB3918F3AF; Fri, 22 Jul 2011 23:06:03 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mahalo1; bh=ggiNWfPt+ 7uQCujXDuxFKRzL550=; b=X9PvVxfoP8muNiK0LQCCbMBpFiR97S+JF0cCN1thg 5LYB2x2LGZYw/8vkNDKtLP3Hx3aG7JgUcBHh056794hWXy8iaVeZfLSp1s7k5Uhs Ipyp6La6BY6wsF/VqITlMZn+l+4qpIUJDn5n4Y6G6F+y1ZSLqesvnSuS7F2r6EuJ Cg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gih.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mahalo1; b=g38 aFpvpyUNeaYaooAf7f4b0FhqVZS7hPgXrAZRjQACUPcgsGpoKYhkn8f/rmAdDvq3 xdghGVAcxfAJTfXCxfHO1p4WvlSOg9yaUkSsSEMu0WQpbG0HhjRfCMXRwh1QZmfz ri8aQeGH4kB8MxQee3DWp3G06nltTY6/fHWVcGNM= Received: from [192.168.1.45] (ANice-552-1-25-165.w109-210.abo.wanadoo.fr [109.210.192.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by waikiki.gih.co.uk (Postfix) with ESMTPSA id DFD4918F3AC; Fri, 22 Jul 2011 23:06:02 +0100 (BST) Message-ID: <4E29F45C.4050101@gih.com> Date: Sat, 23 Jul 2011 00:06:20 +0200 From: Olivier MJ Crepin-Leblond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "John R. Levine" References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 22:06:07 -0000 On 22/07/2011 23:48, John R. Levine wrote : >> My initial comment to Michael, when he pointed the draft out to me, >> was that email seems like the poster child of an easy application to >> add IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support >> it already and the current OS's support IPv6. The primary thing >> preventing mail/IPv6 is network IPv6 deployment, which is in progress. > > Setting up an IPv6 mail server is easy. The problem is that the vast > majority of incoming mail is hostile, and IPv4 mail filtering > techniques don't migrate well to IPv6. > I keep on hearing here that people don't run IPv6 on their mailers because of spam coming over IPv6. Does anyone actually have real figures from their gateways for: 1. the percentage of spam using IPv6 vs. IPv4 2. the percentage of spam in their mail incoming via IPv6 Thanks, Olivier --=20 Olivier MJ Cr=E9pin-Leblond, PhD http://www.gih.com/ocl.html From wmaton@ryouko.imsb.nrc.ca Fri Jul 22 15:27:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C5E21F876A for ; Fri, 22 Jul 2011 15:27:35 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zZrA8I9dkyo for ; Fri, 22 Jul 2011 15:27:35 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2604:8400:0:127::10]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4DE21F8761 for ; Fri, 22 Jul 2011 15:27:35 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.4/8.14.4) with ESMTP id p6MMREZv004172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2011 18:27:19 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.4/8.14.4/Submit) with ESMTP id p6MMRDiO004149; Fri, 22 Jul 2011 18:27:14 -0400 Date: Fri, 22 Jul 2011 18:27:13 -0400 (EDT) From: "William F. Maton Sotomayor" To: "John R. Levine" In-Reply-To: Message-ID: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 22:27:35 -0000 On Fri, 22 Jul 2011, John R. Levine wrote: >> My initial comment to Michael, when he pointed the draft out to me, was >> that email seems like the poster child of an easy application to add IPv6 >> to, as the applications (SMTP, POP, and IMAP) mostly support it already and >> the current OS's support IPv6. The primary thing preventing mail/IPv6 is >> network IPv6 deployment, which is in progress. > > Setting up an IPv6 mail server is easy. The problem is that the vast > majority of incoming mail is hostile, and IPv4 mail filtering techniques > don't migrate well to IPv6. What I've done in the past is have a dual-stack exchanger receive email from anywhere, then funnel that to an IPv4 mail server to do the work of filtering. Yes, that may seem to be blasphemy, but it worked at that time despite the hoops I had to jump through. wfms From johnl@iecc.com Fri Jul 22 15:04:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C92B21F8531 for ; Fri, 22 Jul 2011 15:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUCdMUp7SXjQ for ; Fri, 22 Jul 2011 15:04:11 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CF40F21F8B80 for ; Fri, 22 Jul 2011 15:04:07 -0700 (PDT) Received: (qmail 50830 invoked from network); 22 Jul 2011 22:04:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=c68d.4e29f3d6.k1107; bh=DWpDdIHRo4lDxET+dNSH4JiVWbPp1xuqUlIeY2+WDZ0=; b=ymuxjln/acgWtir4/MqGLUzNXTSho1ADOkkJry9oCrSlPJaFWydRTxzw7zZpajP1NcGqbiQd+DJNFnDWsAdV265PfOY1HkpseEM8Vrming0LAJFlf5ATQ0Do98ifJREoMgDgjck68dIihX8K3z8bixlJun6B+EmBMtWFUZoGTFI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Jul 2011 22:03:44 -0000 Date: 23 Jul 2011 00:04:03 +0200 Message-ID: From: "John R. Levine" To: "Joel Jaeggli" In-Reply-To: <9A599E25-B603-4EDB-9449-4A0B67938AFD@bogus.com> References: <11072209372672_B93@oregon.uoregon.edu> <9A599E25-B603-4EDB-9449-4A0B67938AFD@bogus.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 22 Jul 2011 15:27:40 -0700 Cc: Joe St Sauver , v6ops@ietf.org, Dave Crocker , moore@network-heretics.com Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 22:04:12 -0000 > Well, there's the other observation to make. which is you and I have > been running ipv6 enabled mailservers since sometime in 2001 and yes we > receive spam from over ipv6 but the world pretty much hasn't ended either. I've been running an IPv6 listener for a while, and the only spam I see is stuff from compromised web servers and stuff that leaks through 6to4. Botnets do not send spam to IPv6 yet. When they do, expect a lot of v6 mail servers to fall over, since for a variety of reasons I can explain if you're not familiar with them, IPv4 filtering techniques don't work in IPv6. In v4, DNSBLs catch 80-90% of bot spam, and it will be really bad if v6 servers have to handle 5x to 10x the load of spam to body filter. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Fri Jul 22 15:15:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BA521F8B69 for ; Fri, 22 Jul 2011 15:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYBJYZeVvEF6 for ; Fri, 22 Jul 2011 15:15:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A7E6A21F8B67 for ; Fri, 22 Jul 2011 15:15:32 -0700 (PDT) Received: (qmail 50936 invoked from network); 22 Jul 2011 22:15:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=c6f7.4e29f683.k1107; bh=yavekx64TBI75bKz4k+jvSDFl6m5yxCNQ36kmHnFBcc=; b=Ulbpv/S+rqPkgmbwoPImxyN6RYRpYB44UpvfBY10zH9k1Z03zHExHGe+EkQ8nBGAlUbGkDIvRTS4k7R2QH/L/54UWLSJkhLcuKPA9ETr5CDdYbUULV/vGm83HakQvEZMGVd2o+Bz0AZIOFyHnPVaP9k8AaueL+mRmXQemFfawWI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Jul 2011 22:15:09 -0000 Date: 23 Jul 2011 00:15:28 +0200 Message-ID: From: "John R. Levine" To: "Gert Doering" In-Reply-To: <20110722211501.GC2304@Space.Net> References: <11072209372672_B93@oregon.uoregon.edu> <20110722211501.GC2304@Space.Net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 22 Jul 2011 15:27:40 -0700 Cc: Joe St Sauver , v6ops@ietf.org, dcrocker@bbiw.net, moore@network-heretics.com Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 22:15:33 -0000 >> Why? Spam management solutions simply aren't yet where they need to be... > > ... in which case, gratuitous amounts of pressure needs to be applied > to anti-spam vendors that are not there yet. That is a phenomenally naive and unhelpful suggestion. The vast size of the IPv6 address space means that a lot of stuff that worked in IPv4 simply doesn't work in IPv6. Most notably, we have to assume that bad guys (or even misguided good guys) will use a different IP address for every single messge. This means that any per-message DNS lookup, even an rDNS lookup, can make your DNS cache explode. The abuse management community has been thinking about this for quite a while. If you think there are easy solutions, that means you don't understand the problem. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Fri Jul 22 15:19:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C77821F8B7B for ; Fri, 22 Jul 2011 15:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPrmU40cyySI for ; Fri, 22 Jul 2011 15:19:00 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A4D3F21F8B79 for ; Fri, 22 Jul 2011 15:19:00 -0700 (PDT) Received: (qmail 50992 invoked from network); 22 Jul 2011 22:18:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=c72f.4e29f753.k1107; bh=akJ4R1vTv6NYr6GTGHLE/vy66TkaSpGLF5ocoFcyYoo=; b=OCTe+VKlIrqD4eBQWnL3tnzYtcefp2Q+dZfIJcD1fvQUp+BqCvIxN/um7V2ZaCU5g1zIbZqrtN3mAwkiAD2eq/c1stVOmYfId+Qhw5h7+lN15TEVFQo0EDvoYoxU5NIaq5TzMa7amik/eYvAhUhoOYPW3Umi+exSY6eqKf6aJmk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Jul 2011 22:18:37 -0000 Date: 23 Jul 2011 00:18:56 +0200 Message-ID: From: "John R. Levine" To: "Bob Van Zant" In-Reply-To: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 22 Jul 2011 15:27:40 -0700 Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 22:19:01 -0000 >> The problem is that the vast majority of incoming mail is hostile, and >> IPv4 mail filtering techniques don't migrate well to IPv6. > > This statement simply doesn't hold true for IPv6 email. Gert's saying > it. I'm saying it. Someone else on this thread said it. We're all > speaking from experience. I'm also speaking from experience. The current amount of IPv6 mail is a tiny trickle compared to IPv4 mail. Any half assed approach will work for a trickle, but that says nothing about how it would work for real production mail. > We sit on this list and occasionally criticize the networking gear > vendors for dragging their feet (and we should). Who's dragging their > feet now? Nobody. As I've said several times, if you're saying that managing IPv6 mail is easy, you've self-identified as not understanding the problem. R's, John From johnl@iecc.com Fri Jul 22 15:20:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE0421F8B87 for ; Fri, 22 Jul 2011 15:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIrfMjqoDDz4 for ; Fri, 22 Jul 2011 15:20:21 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 31BA221F8B79 for ; Fri, 22 Jul 2011 15:20:21 -0700 (PDT) Received: (qmail 51010 invoked from network); 22 Jul 2011 22:20:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=c741.4e29f7a4.k1107; bh=18Lf/sP/B66stOpDHL/tAMb2uRuMqz2LymTmVHDHRc8=; b=o+mTby6NNK+c1S+fKhvPH4paKOSf+yuLLP9Skl5/Hc24L+8LNroxn6as6h12cy6JSIMW6AZx28GvS5aFTKvGo9bnKygf72oYeihqgtyaL91FesRh6oNxt2x1uvJcJ4Lw2CxcMHrQWfNtLFXBvUMX5CtADhBJVPwVpbB2Fs7pTGg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Jul 2011 22:19:58 -0000 Date: 23 Jul 2011 00:20:17 +0200 Message-ID: From: "John R. Levine" To: "Olivier MJ Crepin-Leblond" In-Reply-To: <4E29F45C.4050101@gih.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <4E29F45C.4050101@gih.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 22 Jul 2011 15:27:40 -0700 Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 22:20:22 -0000 > Does anyone actually have real figures from their gateways for: > 1. the percentage of spam using IPv6 vs. IPv4 > 2. the percentage of spam in their mail incoming via IPv6 On my system, both of those numbers are close enough to zero as not to matter. I get so little spam over v6 that I can look at each one individually. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From bigbadbob0@gmail.com Fri Jul 22 15:31:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32E921F899D for ; Fri, 22 Jul 2011 15:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLneB1qmMFWZ for ; Fri, 22 Jul 2011 15:31:44 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA3721F84D5 for ; Fri, 22 Jul 2011 15:31:07 -0700 (PDT) Received: by qyk29 with SMTP id 29so1924434qyk.10 for ; Fri, 22 Jul 2011 15:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FLw1qnL0Q2Ou/R+9RLS0JrmUkQpaWFhljwKRgoNkeCc=; b=nuQE76qsO8939WdRcU/cD0lCbkzH+ato5BdqdKaG27SzJufuwpUt/q9T2JXHiioLIk 0clsFJ9ExSF9V0rfjeW3yib5bmp/Ocj6hoaKu0d9LGlyFIbLVM3+x7SWsir9UMaa7ATp ISaiPB0d7aPGrxo41Gu5o7Gk2W0wUAUQ4GHEo= MIME-Version: 1.0 Received: by 10.229.2.131 with SMTP id 3mr1651006qcj.156.1311373866367; Fri, 22 Jul 2011 15:31:06 -0700 (PDT) Sender: bigbadbob0@gmail.com Received: by 10.229.187.136 with HTTP; Fri, 22 Jul 2011 15:31:06 -0700 (PDT) In-Reply-To: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> Date: Fri, 22 Jul 2011 15:31:06 -0700 X-Google-Sender-Auth: VMmqEA2qV2yNRhjcscDP8AnoFBQ Message-ID: From: Bob Van Zant To: "John R. Levine" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 22:31:44 -0000 On Fri, Jul 22, 2011 at 3:18 PM, John R. Levine wrote: >>> The problem is that the vast majority of incoming mail is hostile, and >>> IPv4 mail filtering techniques don't migrate well to IPv6. >> >> This statement simply doesn't hold true for IPv6 email. Gert's saying >> it. I'm saying it. Someone else on this thread said it. We're all >> speaking from experience. > > I'm also speaking from experience. > > The current amount of IPv6 mail is a tiny trickle compared to IPv4 mail. = Any > half assed approach will work for a trickle, but that says nothing about = how > it would work for real production mail. Why would you waste time solving a problem you don't have? We all want to solve the IPv6 spam problem. What IPv6 spam problem? We want to create IPv6 blacklists in the context of email. Why? Who would you put on that blacklist? A company I used to work for told customers that we had a chicken and egg problem here. Without seeing real IPv6 email we can't tell you who the bad guys are. Without knowing who the bad guys are we can't give you an IPv6 email solution that is on par with our IPv4 offerings. > >> We sit on this list and occasionally criticize the networking gear >> vendors for dragging their feet (and we should). Who's dragging their >> feet now? > > Nobody. =A0As I've said several times, if you're saying that managing IPv= 6 > mail is easy, you've self-identified as not understanding the problem. What problem? I've read about a lot of problems that people are predicting we'll eventually have. Is there a real IPv6 mail problem *today*? From johnl@iecc.com Fri Jul 22 15:32:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB9221F8B79 for ; Fri, 22 Jul 2011 15:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jegaF8MQ2XDJ for ; Fri, 22 Jul 2011 15:32:16 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0A221F8B6E for ; Fri, 22 Jul 2011 15:32:16 -0700 (PDT) Received: (qmail 51090 invoked from network); 22 Jul 2011 22:32:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=c791.4e29fa6d.k1107; bh=ZlbzVKuU/RZTC42zt/MlGG7BVMjLNMKhAWCV8ti9WpE=; b=yq4FOhckDQzMuKfZ7z947nGWB//bewX2O36DLi2XLCTqPh+3Os8Pmqj4HtP+5pDR4PnzREyBlaF/VGIb1RK051ktqeowQS3FfRrDKgH9Q2DH10ia9cbDjAD//6kvOaNWSete5UDAEB3fYyFG3hoA5sPMFWePE87gcxVNBYlH9uQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Jul 2011 22:31:51 -0000 Date: 23 Jul 2011 00:32:10 +0200 Message-ID: From: "John R. Levine" To: "William F. Maton Sotomayor" In-Reply-To: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 22:32:17 -0000 > What I've done in the past is have a dual-stack exchanger receive email from > anywhere, then funnel that to an IPv4 mail server to do the work of > filtering. Yes, that may seem to be blasphemy, but it worked at that time > despite the hoops I had to jump through. That's what I do, too, but the DNSBLs that catch 90% of the v4 spam don't do anything when mail is coming from the v4 address of my v6 gateway. For the umpteenth time, the current trickle of v6 mail tells us nothing useful about what we'll need to do to handle v6 mail at the scale we're handling v4 mail. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Fri Jul 22 15:35:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172E421F8BB2 for ; Fri, 22 Jul 2011 15:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89V0X1pvkL2U for ; Fri, 22 Jul 2011 15:35:50 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6766A21F8B80 for ; Fri, 22 Jul 2011 15:35:50 -0700 (PDT) Received: (qmail 51154 invoked from network); 22 Jul 2011 22:35:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=c7d1.4e29fb45.k1107; bh=hl+64ECRm6YdV6UX32SJES8xdx0fqqnP/G2eIZVHfqc=; b=htql7fy8mVmjvmxZn8SpfGy7yP/VOwNEzGDzq6KlxXOr7NlnwuFkWkgbczqA0bKnyXfqee6dmkRbgyZAEjTUYpvpEQIJSsjfzdl0IQ0KYbJnf35NXNnQa45qTqXzOuFjj4kDfMqbjaWwQ0xF+1iZtO6CAKwMiSVCrH+gdQUYzC4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Jul 2011 22:35:27 -0000 Date: 23 Jul 2011 00:35:45 +0200 Message-ID: From: "John R. Levine" To: "Bob Van Zant" In-Reply-To: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 22:35:51 -0000 >> The current amount of IPv6 mail is a tiny trickle compared to IPv4 mail. Any >> half assed approach will work for a trickle, but that says nothing about how >> it would work for real production mail. > > Why would you waste time solving a problem you don't have? We all want > to solve the IPv6 spam problem. What IPv6 spam problem? We want to > create IPv6 blacklists in the context of email. Why? Who would you put > on that blacklist? Sorry, I have no idea what your point is. If you're saying that moving mail to v6 is so hard that it will all stay on v4, I wouldn't disagree with you, but that does run counter to IETF dogma. > A company I used to work for told customers that we had a chicken and > egg problem here. Without seeing real IPv6 email we can't tell you who > the bad guys are. Without knowing who the bad guys are we can't give > you an IPv6 email solution that is on par with our IPv4 offerings. Right. So it appears that you are proposing to set up IPv6 mail servers that will fall over and die if the bad guys ever point their botnets at IPv6 addresses. That seems, ah, short sighted. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From Ted.Lemon@nominum.com Fri Jul 22 16:04:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEE721F8B08 for ; Fri, 22 Jul 2011 16:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgoZ42rZeJdg for ; Fri, 22 Jul 2011 16:04:00 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id A387721F8AFD for ; Fri, 22 Jul 2011 16:04:00 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTioB35eVJ6HVHmn8kSdqwX0AB0/cdq3X@postini.com; Fri, 22 Jul 2011 16:04:00 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A223A1B81AE for ; Fri, 22 Jul 2011 16:03:59 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 67E7119006B; Fri, 22 Jul 2011 16:03:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0289.001; Fri, 22 Jul 2011 16:03:47 -0700 From: Ted Lemon To: "John R. Levine" Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AQHMSLoQalI5I8L3pke3J0CpCBEN6ZT5YOaAgAABYgCAAAjUAA== Date: Fri, 22 Jul 2011 23:03:46 +0000 Message-ID: <9573A8DA-DCD5-4468-B901-1FE450DCBE73@nominum.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_9573A8DADCD54468B9011FE450DCBE73nominumcom_" MIME-Version: 1.0 Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:04:01 -0000 --_000_9573A8DADCD54468B9011FE450DCBE73nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Jul 22, 2011, at 6:32 PM, John R. Levine wrote: That's what I do, too, but the DNSBLs that catch 90% of the v4 spam don't d= o anything when mail is coming from the v4 address of my v6 gateway. How would that ever happen? If the SMTP connection is to your SMTP server= , which has an IPv6 address, it will be an IPv6 connection, not an IPv4 con= nection. If your gateway is doing protocol translation, and your SMTP ser= ver doesn't have an IPv6 address, that's out of scope=97we're talking about= v6 connections here, not protocol translators. --_000_9573A8DADCD54468B9011FE450DCBE73nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 22, 2011, at 6:32 PM, John R. Levine wrote:
That's what I do, too, but the DNSBLs that catch 90% of the v4 spam don't do anyt= hing when mail is coming from the v4 address of my v6 gateway.

How would that ever happen?   If the SMTP connection is to your S= MTP server, which has an IPv6 address, it will be an IPv6 connection, not a= n IPv4 connection.   If your gateway is doing protocol translation, an= d your SMTP server doesn't have an IPv6 address, that's out of scope=97we're talking about v6 connections here, not protoco= l translators.

--_000_9573A8DADCD54468B9011FE450DCBE73nominumcom_-- From Ted.Lemon@nominum.com Fri Jul 22 16:05:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BFC21F8B9E for ; Fri, 22 Jul 2011 16:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUdcoLMacgP7 for ; Fri, 22 Jul 2011 16:05:56 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 0B69B21F8B9D for ; Fri, 22 Jul 2011 16:05:55 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTioCU9qUiNXPdfRPgGnCSkriz0Yk8S7M@postini.com; Fri, 22 Jul 2011 16:05:56 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0DC0E1B81AD for ; Fri, 22 Jul 2011 16:05:55 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id F3FD319006B; Fri, 22 Jul 2011 16:05:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0289.001; Fri, 22 Jul 2011 16:05:55 -0700 From: Ted Lemon To: "John R. Levine" Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AQHMSLoQalI5I8L3pke3J0CpCBEN6ZT5WbWAgAAE4ACAAANnAIAAAUyAgAAIbIA= Date: Fri, 22 Jul 2011 23:05:53 +0000 Message-ID: <8639AABE-0D4A-483D-9F81-E80003B4EA51@nominum.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_8639AABE0D4A483D9F81E80003B4EA51nominumcom_" MIME-Version: 1.0 Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:05:56 -0000 --_000_8639AABE0D4A483D9F81E80003B4EA51nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 22, 2011, at 6:35 PM, John R. Levine wrote: Right. So it appears that you are proposing to set up IPv6 mail servers th= at will fall over and die if the bad guys ever point their botnets at IPv6 = addresses. That seems, ah, short sighted. The problem with spam is not that your SMTP server falls over and dies. I= t's that you have to filter through a bunch of crap. If someone wants to = point their botnet at you, it's going to suck, and no RBL in the world is g= oing to make it not suck. --_000_8639AABE0D4A483D9F81E80003B4EA51nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <074AB8B37F052B4882B19ED9CD0AEC04@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 22, 2011, at 6:35 PM, John R. Levine wrote:
Right.  So it appears that you are proposing to set up IPv6 mail servers tha= t will fall over and die if the bad guys ever point their botnets at IPv6 a= ddresses.  That seems, ah, short sighted.

The problem with spam is not that your SMTP server falls over and dies= .   It's that you have to filter through a bunch of crap.   If so= meone wants to point their botnet at you, it's going to suck, and no RBL in= the world is going to make it not suck.

--_000_8639AABE0D4A483D9F81E80003B4EA51nominumcom_-- From bigbadbob0@gmail.com Fri Jul 22 16:06:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF2021F874E for ; Fri, 22 Jul 2011 16:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGi6h3rrYK6D for ; Fri, 22 Jul 2011 16:06:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 896C721F8678 for ; Fri, 22 Jul 2011 16:06:27 -0700 (PDT) Received: by qwc23 with SMTP id 23so2146200qwc.31 for ; Fri, 22 Jul 2011 16:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ekHB61JHl6/5VYaWnzZ2a4m3NUbzdH5ffAOs5EPVsiQ=; b=Ei5k2i3q5Yjh+F5QY7VTSRIAX7HDbTG4r8YXPT9WkInXD+RUxvtZ8wfnGObvMXrguc hZNP9YeoL1sYBFaG7CV3G2mvQDAddYEhF5iJErsueUcumcOtvYfC/2v431XSFcWc4fiJ VtHtDdHJ3q8G//qffNQHLN1UeWuJ7SDL44HMg= MIME-Version: 1.0 Received: by 10.224.204.194 with SMTP id fn2mr1813991qab.121.1311375986959; Fri, 22 Jul 2011 16:06:26 -0700 (PDT) Sender: bigbadbob0@gmail.com Received: by 10.229.187.136 with HTTP; Fri, 22 Jul 2011 16:06:26 -0700 (PDT) In-Reply-To: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> Date: Fri, 22 Jul 2011 16:06:26 -0700 X-Google-Sender-Auth: RBee0zc-CMM9PKpUY8K30Ww5S5M Message-ID: From: Bob Van Zant To: "John R. Levine" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:06:39 -0000 On Fri, Jul 22, 2011 at 3:35 PM, John R. Levine wrote: >> >> Why would you waste time solving a problem you don't have? We all want >> to solve the IPv6 spam problem. What IPv6 spam problem? We want to >> create IPv6 blacklists in the context of email. Why? Who would you put >> on that blacklist? > > Sorry, I have no idea what your point is. You're yapping to this list that IPv6 email is so hard. You're calling people naive if they don't agree with you (I think there's a word for this). My point is that there is no IPv6 email abuse problem right now and people should quit saying that a lack of an IPv6 blacklist or reputation system is a legitimate reason to avoid deploying SMTP over IPv6. > Right. =A0So it appears that you are proposing to set up IPv6 mail server= s > that will fall over and die if the bad guys ever point their botnets at I= Pv6 > addresses. =A0That seems, ah, short sighted. You're not being helpful. Why don't you just sit quietly on the sidelines until the rest of us make SMTP over IPv6 safe enough for you. From bigbadbob0@gmail.com Fri Jul 22 16:08:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E139421F8BC2 for ; Fri, 22 Jul 2011 16:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0t2S5E4XYu8 for ; Fri, 22 Jul 2011 16:08:52 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 43B7221F8B67 for ; Fri, 22 Jul 2011 16:08:52 -0700 (PDT) Received: by qyk29 with SMTP id 29so1937006qyk.10 for ; Fri, 22 Jul 2011 16:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x+D7czJtUgIwGnqsL3D9HK6exg2kzB6SqWaQDsVfIi0=; b=wXAXbNfx3694RxCzkw5g0TUCEYZ7faYpHvvn/+m+hmDoWopjMSPG9rwkJKblPGzbH4 abbz4gZPdmI85ujmwMCpptPX/eoo3eXp5YMvPNCiw9dvW8OgJKzoBoiBZ+P6xdBaW5Rd UruXdoP0OwQQKm6tBKA0KLCo+g0A27PG3gu+Y= MIME-Version: 1.0 Received: by 10.229.229.195 with SMTP id jj3mr1636556qcb.232.1311376131745; Fri, 22 Jul 2011 16:08:51 -0700 (PDT) Sender: bigbadbob0@gmail.com Received: by 10.229.187.136 with HTTP; Fri, 22 Jul 2011 16:08:51 -0700 (PDT) In-Reply-To: <8639AABE-0D4A-483D-9F81-E80003B4EA51@nominum.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <8639AABE-0D4A-483D-9F81-E80003B4EA51@nominum.com> Date: Fri, 22 Jul 2011 16:08:51 -0700 X-Google-Sender-Auth: CAImJQfw1Z6GZJTKxy7AXtG0irE Message-ID: From: Bob Van Zant To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:08:53 -0000 On Fri, Jul 22, 2011 at 4:05 PM, Ted Lemon wrote: > On Jul 22, 2011, at 6:35 PM, John R. Levine wrote: > > Right. =A0So it appears that you are proposing to set up IPv6 mail server= s > that will fall over and die if the bad guys ever point their botnets at I= Pv6 > addresses. =A0That seems, ah, short sighted. > > The problem with spam is not that your SMTP server falls over and dies. > It's that you have to filter through a bunch of crap. =A0 If someone want= s to > point their botnet at you, it's going to suck, and no RBL in the world is > going to make it not suck. > A big botnet with clean IPs directed straight at a single domain can impose a world of hurt. This is the problem that John is trying to scare us all with. The great news for all of us today is that there's no such thing as an IPv6 botnet. Though, any mail system worth its weight can do IP-based throttling; even for IPv6. From denghui02@gmail.com Fri Jul 22 16:14:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6231D21F8B87 for ; Fri, 22 Jul 2011 16:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.504 X-Spam-Level: X-Spam-Status: No, score=-103.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36EmGBIQVRh1 for ; Fri, 22 Jul 2011 16:14:05 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B32F721F8B78 for ; Fri, 22 Jul 2011 16:14:04 -0700 (PDT) Received: by wyj26 with SMTP id 26so2042083wyj.31 for ; Fri, 22 Jul 2011 16:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Gn8rIWTVe9hhPtx4vNbtq6W86QxBC93tNKe1LcLzlq4=; b=NMZuawis/FfdoaqyAuDcb6v64MCrJ2pYTuV/hgmjOFMRqfgb4cVNoUVYqJMzU8TpjZ aDsM3uGUZDd4j84mEyn1V9Gkzf9Bh8P4CtLRgoVa03wu+nNU7f9c3E+UzcFbCotuB0Dx 2bDn+o8PHvYCyflFfeC+bJ7liqoAurzhclHpw= MIME-Version: 1.0 Received: by 10.216.8.80 with SMTP id 58mr1586172weq.0.1311376443765; Fri, 22 Jul 2011 16:14:03 -0700 (PDT) Received: by 10.216.73.17 with HTTP; Fri, 22 Jul 2011 16:14:03 -0700 (PDT) Date: Sat, 23 Jul 2011 07:14:03 +0800 Message-ID: From: Hui Deng To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=0016364c7bc918f3d004a8b09fbe Subject: [v6ops] Comments for draft-keranen-ipv6day-measurements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:14:05 -0000 --0016364c7bc918f3d004a8b09fbe Content-Type: text/plain; charset=ISO-8859-1 Hello authors This work has gathered the useful information, appreciate the work. Several comments below: 1) Have you done the delay test for the case host which doesn't have IPv6 connection, have to fall back to IPv4 connection? does this prove dual stack website not feasible during the IPv6 transition stage? 2) could you predict how many website sitting behind of NAT64? 3) Does the measure tool is a open source for download? 4) There are 13 top 100 support AAAA which is less than 14 before IPv6 day, who is that website? Best regards, -Hui --0016364c7bc918f3d004a8b09fbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello authors

This work has gathered the useful information, appreciate the work.
S= everal comments below:
1) Have you done the delay test for the case host= which doesn't have IPv6 connection, have to fall back
to IPv4 conn= ection? does this prove dual stack website not feasible during the IPv6 tra= nsition stage?

2) could you predict how many website sitting behind of NAT64?

3) Does the measure tool is a open source for download?

4) There are 13 top 100 support AAAA which is less than 14 before IPv6 d= ay, who is that website?

Best regards,

-Hui

--0016364c7bc918f3d004a8b09fbe-- From denghui02@gmail.com Fri Jul 22 16:14:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596DA21F8BD6 for ; Fri, 22 Jul 2011 16:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1tW3ahprtQ9 for ; Fri, 22 Jul 2011 16:14:32 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E60F21F8BCF for ; Fri, 22 Jul 2011 16:14:31 -0700 (PDT) Received: by mail-wy0-f172.google.com with SMTP id 26so2042083wyj.31 for ; Fri, 22 Jul 2011 16:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=3OaMNmw3T/wPkmF94jx0hpTxO0pnQgxGS2eWOSs9tdE=; b=ZI4S5GWiQzDh2EIPyjO5WWLDBKjg9qiDrEdVCc3mX2uIUMkW4NMVx5ZpIC0K7QDhgv JW31a4PFRV2NgY/mTR02K/xmkcesJXBG2xQGXzSbG+RfpMQqexPKvoDLjdBbrCeL2vkx I/vHZ9Eahj+OzNZuPzHW4Ko0WEG33jP0T3tlw= MIME-Version: 1.0 Received: by 10.217.7.66 with SMTP id z44mr1604896wes.100.1311376471235; Fri, 22 Jul 2011 16:14:31 -0700 (PDT) Received: by 10.216.73.17 with HTTP; Fri, 22 Jul 2011 16:14:31 -0700 (PDT) Date: Sat, 23 Jul 2011 07:14:31 +0800 Message-ID: From: Hui Deng To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=20cf30266edcbc1d1e04a8b0a023 Subject: [v6ops] 1 comment on draft-jjmb-v6ops-comcast-ipv6-experiences-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:14:32 -0000 --20cf30266edcbc1d1e04a8b0a023 Content-Type: text/plain; charset=ISO-8859-1 Hello authors This work is a good reference for the operator, thanks for writing this draft, has gathered the useful information, appreciate the work. Just one clarification, the reason of recommdating dual stack is because Comcast is mainly providing CDN based IPTV like service? Best regards, -Hui --20cf30266edcbc1d1e04a8b0a023 Content-Type: text/html; charset=ISO-8859-1

Hello authors

This work is a good reference for the operator, thanks for writing this draft,
has gathered the useful information, appreciate the work.

Just one clarification, the reason of recommdating dual stack is because Comcast is mainly providing CDN based IPTV like service?

Best regards,

-Hui

--20cf30266edcbc1d1e04a8b0a023-- From dcp@dcptech.com Fri Jul 22 16:17:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFB721F8B88 for ; Fri, 22 Jul 2011 16:17:38 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezJ6VOLLt+Sn for ; Fri, 22 Jul 2011 16:17:37 -0700 (PDT) Received: from ironport.dcptech.com (ironport.dcptech.com [66.92.168.157]) by ietfa.amsl.com (Postfix) with SMTP id 9686A21F8B82 for ; Fri, 22 Jul 2011 16:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcptech.com; i=dcp@dcptech.com; q=dns/txt; s=ironport; t=1311376657; x=1342912657; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; z=From:=20"David=20Prall"=20|To:=20"'Oliv ier=20MJ=20Crepin-Leblond'"=20,=0D=0A=20=20 =20=20=20=20=20=20"'John=20R.=20Levine'"=20|Cc:=20"'Joe=20St=20Sauveur'"=20,=20,=0D=0A=20=20=20=20=20=20=20=20"'Kei th=20Moore'"=20,=0D=0A=20=20 =20=20=20=20=20=20"'Dave=20Crocker'"=20|References:=20=09=09<20110722134844.GP2304@Space.Net>=09=09<201107 22141726.GS2304@Space.Net>=09<9DDB62C5-E0E3-4336-BA2E-A43 C48763793@network-heretics.com>=09<20110722144843.GV2304@ Space.Net>=09<4A84C1DA-B34D-46F3-875E-243D737F1CDE@networ k-heretics.com>=09<20110722152052.GX2304@Space.Net>=09<60 232E31-E780-4CD8-A562-39761A73520C@cisco.com>=09=20<4E29F45C.4050101 @gih.com>|In-Reply-To:=20<4E29F45C.4050101@gih.com> |Subject:=20RE:=20[v6ops]=20Draft=20on=20email=20transiti on=20to=20IPv6=20from=20IPv4=20for=20sevice=20providers =20and=20other=20communities|Date:=20Fri,=2022=20Jul=2020 11=2019:17:22=20-0400|Message-ID:=20<007a01cc48c5$836da56 0$8a48f020$@com>|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit; bh=eXb9D+gD8PvavGZyX1aZ4Ss6+SKUGkTTRKQmulmvBcY=; b=Haiw59RxOeD+NB0uULhmmCg7i8IMxkSEt1oRR977Rf6zDxtre4LGKBll 9nmOtsa+p342tsjTgwkczV7vEPUU7bsN3Imq2VvwNhM52rzFn4zZAmGYZ So1o+DbIhPkAAmc+SxAw/LLF4L8s++aogX/m2z78J0g4FYFTlMz7Ex8+q g=; X-IronPort-AV: E=Sophos;i="4.67,249,1309752000"; d="scan'208";a="248336" Received: from server6e0.mobile.dcptech.com (HELO server.mobile.dcptech.com) ([IPv6:2001:4830:1650::e0:6400]) by ironport.dcptech.com with ESMTP; 22 Jul 2011 19:17:24 -0400 Received: from dprallwxp02 ([IPv6:2001:4978:1c0:151:fd48:d21a:ea8b:3374]) (authenticated bits=0) by server.mobile.dcptech.com (8.14.3/8.13.8) with ESMTP id p6MNHMd4017146 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 22 Jul 2011 19:17:23 -0400 From: "David Prall" To: "'Olivier MJ Crepin-Leblond'" , "'John R. Levine'" References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <4E29F45C.4050101@gih.com> In-Reply-To: <4E29F45C.4050101@gih.com> Date: Fri, 22 Jul 2011 19:17:22 -0400 Organization: DCP Technologies Message-ID: <007a01cc48c5$836da560$8a48f020$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxIu6DBksbOSAdVRKah+4rAZH6gwQABZUvw Content-Language: en-us X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (server.mobile.dcptech.com [IPv6:2001:4978:1c0::e3:6400]); Fri, 22 Jul 2011 19:17:23 -0400 (EDT) Cc: 'Joe St Sauveur' , v6ops@ietf.org, 'Keith Moore' , 'Dave Crocker' Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:17:38 -0000 > From: Olivier MJ Crepin-Leblond > > On 22/07/2011 23:48, John R. Levine wrote : > >> My initial comment to Michael, when he pointed the draft out to me, > >> was that email seems like the poster child of an easy application to > >> add IPv6 to, as the applications (SMTP, POP, and IMAP) mostly > support > >> it already and the current OS's support IPv6. The primary thing > >> preventing mail/IPv6 is network IPv6 deployment, which is in > progress. > > > > Setting up an IPv6 mail server is easy. The problem is that the vast > > majority of incoming mail is hostile, and IPv4 mail filtering > > techniques don't migrate well to IPv6. > > > > I keep on hearing here that people don't run IPv6 on their mailers > because of spam coming over IPv6. > > Does anyone actually have real figures from their gateways for: > 1. the percentage of spam using IPv6 vs. IPv4 > 2. the percentage of spam in their mail incoming via IPv6 > > Thanks, > > Olivier > My dual-stack Ironport at home doesn't send out reports detailing what was received via IPv4 or IPv6, although it does tell me daily what happened, yesterday 12,345 (96.9%) messages received were stopped by reputation filter, 88 (0.7%) were spam, 299 (2.3%) were clean. I'm hoping that the 88 messages that were determined to be spam locally are helping to build an IPv6 reputation database. Nope all the spam via IPv4. I've seen a number of discussions about DNSBL's for IPv6. Do we start with a single address, add a second, then ramp up to a /64, then to a /48. We'll probably break a few things, just as what has happened along the way with IPv4 and spam. David -- http://dcp.dcptech.com From moore@network-heretics.com Fri Jul 22 16:17:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4529E21F8BB3 for ; Fri, 22 Jul 2011 16:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyZD0HNCeH+C for ; Fri, 22 Jul 2011 16:17:46 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9234621F8BA3 for ; Fri, 22 Jul 2011 16:17:46 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 28BD820E69; Fri, 22 Jul 2011 19:17:46 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 22 Jul 2011 19:17:46 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=N06KEyoz3cbRCGVVVOvmVZ3Xkps=; b=hK DDswbRbnulaNaU5YXR91uBvn7P4tgjfX03XTGnAq1w7Mo7MiQJlQIQ3gP1h/2sdT EGBVQSZpQBR4zuDbYe8nX5v70RLs55mGMKnTeel/fR/qpXEatj3qeBwf1fHddAnF ccHOmjF4EWijUFGJmRTZlQ2wL7V7MR6Dp91V52SZE= X-Sasl-enc: f+Ci+k9svMlzaws9GMmW4atk7/r862hMomFrvGSEAyWa 1311376665 Received: from [10.59.1.76] (static-71-166-174-114.washdc.east.verizon.net [71.166.174.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 1FBE7412735; Fri, 22 Jul 2011 19:17:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <20110722211546.GD2304@Space.Net> Date: Fri, 22 Jul 2011 19:17:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1DC51AC4-EB7C-47B6-8CB5-B95D9BFDAEB1@network-heretics.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <20110722211546.GD2304@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1084) Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:17:47 -0000 On Jul 22, 2011, at 5:15 PM, Gert Doering wrote: > Hi, >=20 > On Fri, Jul 22, 2011 at 01:27:40PM -0400, Keith Moore wrote: >> On Jul 22, 2011, at 11:20 AM, Gert Doering wrote: >>=20 >>> You don't need universal availability on the last DSL line to have >>> IPv6 *on servers*. Which are usually not located behind consumer >>> products. >>=20 >> This might be true for your customers. But it's not an appropriate = assumption to make for all mail servers on the Internet. >=20 > Neither is your assumption that there is no IPv6. So what? I haven't made any such assumption. Keith From moore@network-heretics.com Fri Jul 22 16:19:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F4E21F8BE8 for ; Fri, 22 Jul 2011 16:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7cdv6Wpl3jw for ; Fri, 22 Jul 2011 16:19:23 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 48B8521F8BE6 for ; Fri, 22 Jul 2011 16:19:23 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 005CA20EA4; Fri, 22 Jul 2011 19:19:22 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 22 Jul 2011 19:19:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=0WWgbB+sQ6VHPGF/pq1TPmW6uC8=; b=El MRn7+OD+G/iHvG823mlcqb49yt8toz9Wogf9mkSE9knr2zZK6evXT0NncgJqSxrN JLz2DpJ0/FJM3JdvTCfkjkgCd/1jToXUFmXCFih7EIpYKhc7+hMPWph47rxUo2N+ ftmdOqF3F0X5a/ZCNrR0Zsjm4iQpCUfQRiIzYhzhk= X-Sasl-enc: Iph0f73mFft5AE08glJug9cjj9bpaeb7EqMD+OGtG9T6 1311376762 Received: from [10.59.1.76] (static-71-166-174-114.washdc.east.verizon.net [71.166.174.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 90F9B41277A; Fri, 22 Jul 2011 19:19:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4E29EB12.4080605@inex.ie> Date: Fri, 22 Jul 2011 19:19:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <48225CE8-836F-496D-B45A-FF3A4921CE73@network-heretics.com> References: <11072209372672_B93@oregon.uoregon.edu> <4E29C141.6000307@inex.ie> <4E29EB12.4080605@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:19:24 -0000 On Jul 22, 2011, at 5:26 PM, Nick Hilliard wrote: > On 22/07/2011 20:47, Keith Moore wrote: >> [lots of stuff] >=20 > I was going to reply to this email point by point, but decided against = as > there appears to be little or no common ground between us. Continuing = the > conversation would just end up in a shouting match, with little chance = of > meaningful discussion. And it would do nothing but distract attention = from > the substantial issues in the draft. I certainly agree that there's a large disconnect, and there's no point = in repeatedly talking past each other. =20 I don't know how to get people to see things from a perspective other = than their own, when they're apparently hostile to such input. Keith From sander@steffann.nl Fri Jul 22 16:21:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651EF21F8B1A for ; Fri, 22 Jul 2011 16:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDV-HsVBsiVl for ; Fri, 22 Jul 2011 16:21:53 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id D524121F8560 for ; Fri, 22 Jul 2011 16:21:46 -0700 (PDT) Received: from [172.18.1.100] (095-097-083-091.static.chello.nl [95.97.83.91]) by mail.sintact.nl (Postfix) with ESMTP id BF9EE201E; Sat, 23 Jul 2011 01:16:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: Date: Sat, 23 Jul 2011 01:16:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BCFF711-9B1C-4C11-B178-89DC9B0BFFBF@steffann.nl> References: <11072209372672_B93@oregon.uoregon.edu> <9A599E25-B603-4EDB-9449-4A0B67938AFD@bogus.com> To: Ted Lemon X-Mailer: Apple Mail (2.1244.3) Cc: IPv6 Operations Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:21:54 -0000 Hi Ted, > I think that it might be worth differentiating between listening on = IPv6 and sending on IPv6. Listening on IPv6 requires that you have an = answer for spam. Sending on IPv6 does not. Sending on IPv6 would = make it possible to deliver to sites that can originate IPv4 SMTP = connections over a NAT link, don't have a globally-routable IPv4 = address, but do have a globally-routeable IPv6 address. Consequently, = I'd really like to see people enable transmission of mail over IPv6, = even if they don't enable reception. +1 I think this is very good advise. Sander From moore@network-heretics.com Fri Jul 22 16:24:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8917321F8C03 for ; Fri, 22 Jul 2011 16:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwuu8hxtYR77 for ; Fri, 22 Jul 2011 16:24:36 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB4F21F8C02 for ; Fri, 22 Jul 2011 16:24:36 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id A9F6C20EAE; Fri, 22 Jul 2011 19:24:35 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 22 Jul 2011 19:24:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=GHrsQsfLGpUCU5qsuQoSwOdPOpY=; b=lg ahAEF1W0wTWfno8FqczP4svx+EysjEsCRS7j7Z7eWjWzar07zgunShgTDAXhxtu7 yuMew5xZ1mEmLG/i8n3WCzh7zrNOudnBFyDSpsQAl+SgTRPK6adp7JT8NxsMmmqq XJX4shHHprL14EZVnmhNfK6jReMg3yWloeHxz2zA0= X-Sasl-enc: g7S9NaPcNpV+HbEvP1iGArUVE2S0ZdoRQJSjvsFhA6e4 1311377075 Received: from [10.59.1.76] (static-71-166-174-114.washdc.east.verizon.net [71.166.174.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 0129741277A; Fri, 22 Jul 2011 19:24:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Fri, 22 Jul 2011 19:24:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <22303AD9-08B5-4768-B4BC-F7721DB76ED9@network-heretics.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> To: Bob Van Zant X-Mailer: Apple Mail (2.1084) Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:24:36 -0000 On Jul 22, 2011, at 6:01 PM, Bob Van Zant wrote: > On Fri, Jul 22, 2011 at 2:48 PM, John R. Levine = wrote: >> The problem is that the vast majority of incoming mail is hostile, = and >> IPv4 mail filtering techniques don't migrate well to IPv6. >=20 > This statement simply doesn't hold true for IPv6 email. Gert's saying > it. I'm saying it. Someone else on this thread said it. We're all > speaking from experience. It's not true for IPv6 email _now_. But as soon as major providers = start accepting mail via IPv6 SMTP, it's fairly predictable that = spammers will start sending spam than way. Then what? IPv6 and IPv4 are different enough that it's a bit difficult to = anticipate which source-address-based countermeasures will be effective = in IPv6. So it seems a bit silly to say that countermeasure X must be = in place before anyone should accept IPv6 SMTP mail. Of course, = countermeasures based on content analysis should work about as well for = IPv6 as IPv4. Maybe that's all that can reasonably be said about the subject at the = moment. Keith From wmaton@ryouko.imsb.nrc.ca Fri Jul 22 16:27:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DD021F8BCB for ; Fri, 22 Jul 2011 16:27:17 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOgejKS6MlEa for ; Fri, 22 Jul 2011 16:27:17 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2604:8400:0:127::10]) by ietfa.amsl.com (Postfix) with ESMTP id 124EC21F8BC4 for ; Fri, 22 Jul 2011 16:27:16 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.4/8.14.4) with ESMTP id p6MNR0uk024150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2011 19:27:05 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.4/8.14.4/Submit) with ESMTP id p6MNR0Ev024147; Fri, 22 Jul 2011 19:27:00 -0400 Date: Fri, 22 Jul 2011 19:27:00 -0400 (EDT) From: "William F. Maton Sotomayor" To: "John R. Levine" In-Reply-To: Message-ID: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:27:17 -0000 On Fri, 23 Jul 2011, John R. Levine wrote: >> What I've done in the past is have a dual-stack exchanger receive email >> from anywhere, then funnel that to an IPv4 mail server to do the work of >> filtering. Yes, that may seem to be blasphemy, but it worked at that time >> despite the hoops I had to jump through. > > That's what I do, too, but the DNSBLs that catch 90% of the v4 spam don't do > anything when mail is coming from the v4 address of my v6 gateway. I still have fond (yes, fond!) memories of getting my very first spam through a mail server in Germany that was dual-stacked onto my own workstation. That was in 2002. I proudly showed my boss that IPv6 does indeed work. :-) > For the umpteenth time, the current trickle of v6 mail tells us nothing > useful about what we'll need to do to handle v6 mail at the scale we're > handling v4 mail. Right. wfms From sander@steffann.nl Fri Jul 22 16:27:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B815B21F8BDE for ; Fri, 22 Jul 2011 16:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XB4A1meBU68c for ; Fri, 22 Jul 2011 16:27:29 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id 0F59A21F8BCD for ; Fri, 22 Jul 2011 16:27:29 -0700 (PDT) Received: from [172.18.1.100] (095-097-083-091.static.chello.nl [95.97.83.91]) by mail.sintact.nl (Postfix) with ESMTP id 85F48201E; Sat, 23 Jul 2011 01:22:27 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: Date: Sat, 23 Jul 2011 01:22:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <04D6BDFF-FD99-4D3C-A861-0197620504E7@steffann.nl> References: <11072209372672_B93@oregon.uoregon.edu> <20110722211501.GC2304@Space.Net> To: John R. Levine X-Mailer: Apple Mail (2.1244.3) Cc: IPv6 Operations Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:27:29 -0000 Hi, >>> Why? Spam management solutions simply aren't yet where they need to = be... >>=20 >> ... in which case, gratuitous amounts of pressure needs to be applied >> to anti-spam vendors that are not there yet. >=20 > That is a phenomenally naive and unhelpful suggestion. >=20 > The vast size of the IPv6 address space means that a lot of stuff that = worked in IPv4 simply doesn't work in IPv6. Most notably, we have to = assume that bad guys (or even misguided good guys) will use a different = IP address for every single messge. This means that any per-message DNS = lookup, even an rDNS lookup, can make your DNS cache explode. >=20 > The abuse management community has been thinking about this for quite = a while. If you think there are easy solutions, that means you don't = understand the problem. The solutions don't have to be easy. Gert made a comment about anti-spam = *vendors*. They make money by providing anti-spam solutions. It's their = job to work on this. That is what we pay them for... They need to = understand that products without IPv6 support will not sell very well. If it was easy I would do it myself ;) - Sander From wwwrun@rfc-editor.org Fri Jul 22 16:40:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5476721F8C19; Fri, 22 Jul 2011 16:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIL7bPDldTmY; Fri, 22 Jul 2011 16:40:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id BB6F821F8C08; Fri, 22 Jul 2011 16:40:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AEC0798C50F; Fri, 22 Jul 2011 16:40:21 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110722234021.AEC0798C50F@rfc-editor.org> Date: Fri, 22 Jul 2011 16:40:21 -0700 (PDT) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6312 on Mobile Networks Considerations for IPv6 Deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:40:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6312 Title: Mobile Networks Considerations for IPv6 Deployment Author: R. Koodli Status: Informational Stream: IETF Date: July 2011 Mailbox: rkoodli@cisco.com Pages: 17 Characters: 45988 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-v6-in-mobile-networks-05.txt URL: http://www.rfc-editor.org/rfc/rfc6312.txt Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From sander@steffann.nl Fri Jul 22 16:55:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B73A21F8BE5 for ; Fri, 22 Jul 2011 16:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxlRNUqVqElk for ; Fri, 22 Jul 2011 16:55:10 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67121F8BE1 for ; Fri, 22 Jul 2011 16:55:10 -0700 (PDT) Received: from [172.18.1.100] (095-097-083-091.static.chello.nl [95.97.83.91]) by mail.sintact.nl (Postfix) with ESMTP id 2B4A82021; Sat, 23 Jul 2011 01:50:08 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Sander Steffann In-Reply-To: <4E29F45C.4050101@gih.com> Date: Sat, 23 Jul 2011 01:50:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <294FF5D8-0283-42EC-8A55-F3408BDEC9AE@steffann.nl> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <4E29F45C.4050101@gih.com> To: Olivier MJ Crepin-Leblond X-Mailer: Apple Mail (2.1244.3) Cc: IPv6 Operations Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 23:55:10 -0000 Hi, > I keep on hearing here that people don't run IPv6 on their mailers > because of spam coming over IPv6. >=20 > Does anyone actually have real figures from their gateways for: > 1. the percentage of spam using IPv6 vs. IPv4 > 2. the percentage of spam in their mail incoming via IPv6 Some numbers from a tiny mail server: - Total number of incoming messages: 23425 - Over IPv4: 23229 - After blacklists: 7752 - Spam: 928 - Over IPv6: 192 - Spam: 3 70.6% of incoming IPv4 mail was spam. 1.6% of incoming IPv6 mail was spam. These numbers are so small that statistically they are not reliable, but = they might give an indication=85 Sander From Ted.Lemon@nominum.com Fri Jul 22 17:08:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05C621F8BAF for ; Fri, 22 Jul 2011 17:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLuJVtprVUMW for ; Fri, 22 Jul 2011 17:08:19 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 2518321F8BAA for ; Fri, 22 Jul 2011 17:08:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTioQ8oK3D0cT+kbs01ABbKvEw3l7nbHk@postini.com; Fri, 22 Jul 2011 17:08:19 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 56F411B81B0 for ; Fri, 22 Jul 2011 17:08:17 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1BF0719006B; Fri, 22 Jul 2011 17:08:17 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Fri, 22 Jul 2011 17:08:10 -0700 From: Ted Lemon To: "" Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AQHMSLoQalI5I8L3pke3J0CpCBEN6ZT5YOaAgAABYgCAAA9SAIAAC3+A Date: Sat, 23 Jul 2011 00:08:10 +0000 Message-ID: <9DFD3506-08D3-497B-A4E6-641345CE35EE@nominum.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.89.227.148] Content-Type: text/plain; charset="us-ascii" Content-ID: <8748DDCFD0DBED4E8444346517DFB601@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 00:08:19 -0000 On Jul 22, 2011, at 7:27 PM, William F. Maton Sotomayor wrote: > I still have fond (yes, fond!) memories of getting my very first spam thr= ough a mail server in Germany that was dual-stacked onto my own workstation= . That was in 2002. I proudly showed my boss that IPv6 does indeed work. = :-) I bet it came through an open relay. :) From cb.list6@gmail.com Fri Jul 22 17:10:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6DC21F8C45 for ; Fri, 22 Jul 2011 17:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLkdGIBZWoH6 for ; Fri, 22 Jul 2011 17:10:13 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 593F621F8C42 for ; Fri, 22 Jul 2011 17:10:13 -0700 (PDT) Received: by wwe5 with SMTP id 5so1800005wwe.13 for ; Fri, 22 Jul 2011 17:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SdLFViXXaaEM8mTZm/TlkK9pfCNg8bVtpYghwK5CBa4=; b=APWbt5jiz29yoFuYlE/CadCnq0Ikk7sbhs3nHqMein/rUb69SmwHaYmtJ/smCHS3bu EzxwoAwKwrZqu5ANO6DWPPtpwT/3fry4ZgzrSCUSka4lfAP0CcKzUU1NgO6QtC92Rn6j Zt8nfnk5imeFAp4y+26x1gfTAvXCBXKjvOjLM= MIME-Version: 1.0 Received: by 10.216.232.222 with SMTP id n72mr1697595weq.62.1311379795561; Fri, 22 Jul 2011 17:09:55 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Fri, 22 Jul 2011 17:09:54 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Fri, 22 Jul 2011 17:09:54 -0700 (PDT) In-Reply-To: <294FF5D8-0283-42EC-8A55-F3408BDEC9AE@steffann.nl> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <4E29F45C.4050101@gih.com> <294FF5D8-0283-42EC-8A55-F3408BDEC9AE@steffann.nl> Date: Fri, 22 Jul 2011 17:09:54 -0700 Message-ID: From: Cameron Byrne To: Sander Steffann Content-Type: multipart/alternative; boundary=000e0cd47e46e14ea704a8b16605 Cc: IPv6 Operations Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 00:10:14 -0000 --000e0cd47e46e14ea704a8b16605 Content-Type: text/plain; charset=ISO-8859-1 Ipv6 dnsbl do exist http://virbl.bit.nl More to come in the future I am sure. --000e0cd47e46e14ea704a8b16605 Content-Type: text/html; charset=ISO-8859-1

Ipv6 dnsbl do exist http://virbl.bit.nl

More to come in the future I am sure.

--000e0cd47e46e14ea704a8b16605-- From johnl@iecc.com Fri Jul 22 22:49:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E5721F87C2 for ; Fri, 22 Jul 2011 22:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.613 X-Spam-Level: X-Spam-Status: No, score=-102.613 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kExQwoNFx8KK for ; Fri, 22 Jul 2011 22:49:22 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB6121F87BC for ; Fri, 22 Jul 2011 22:49:21 -0700 (PDT) Received: (qmail 54158 invoked from network); 23 Jul 2011 05:49:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=d38d.4e2a60e0.k1107; bh=uTVBBcpELJYoaHjfR/5PtDuSyJgoV0Ie6bmnZjk1U+E=; b=UIhTub0aKN09UNVd/8w/z8oP8CHPdJeAnrGYL/lz506obrQEOx6mqjRsi16u7EdAwDCGcaGzmCalEz/bD1XY+EAm+WvgYpbcWolPKaywREekWlD2lAElRZ2MnsIgxCTkeXTY2NQXDS8q1yN2SZppLZa/EFXbHj/0bpI07t3uqXI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Jul 2011 05:48:57 -0000 Date: 23 Jul 2011 07:49:16 +0200 Message-ID: From: "John R. Levine" To: "Ted Lemon" In-Reply-To: <8639AABE-0D4A-483D-9F81-E80003B4EA51@nominum.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <8639AABE-0D4A-483D-9F81-E80003B4EA51@nominum.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 05:49:23 -0000 > Right. So it appears that you are proposing to set up IPv6 mail servers that will fall over and die if the bad guys ever point their botnets at IPv6 addresses. That seems, ah, short sighted. > > The problem with spam is not that your SMTP server falls over and dies. It's that you have to filter through a bunch of crap. If someone wants to point their botnet at you, it's going to suck, and no RBL in the world is going to make it not suck. I gather that you don't know anyone whose mail servers get a billion connections per day, over 90% of which is spam. I do. It's hard to avoid the impression that few people in this discussion are familiar with the operation of large mail systems. If your system gets 100K connections per day, any half-assed design will do. If it gets 100M connections per day, you have to know what you're doing. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Fri Jul 22 22:50:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C312921F8829 for ; Fri, 22 Jul 2011 22:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.613 X-Spam-Level: X-Spam-Status: No, score=-102.613 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I1lyHpeWtHr for ; Fri, 22 Jul 2011 22:50:22 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D05F821F87C5 for ; Fri, 22 Jul 2011 22:50:21 -0700 (PDT) Received: (qmail 54173 invoked from network); 23 Jul 2011 05:50:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=d39c.4e2a611d.k1107; bh=GS8bk60WlmGXRIOzn0hozv5aIutHeX+pnEMUHNcqPfQ=; b=l7qMKL1eWABresrjBqmrK40sDVkD2uzLjMwiUTjwa5ojQargV3ee7Tg7GqNw5UAdBOdEvpiIooRBSIg6EKz3/Qn4uGMvVrv19RebnXu6br/woK0+5/dIJmTTsTuzIYgWNv6I+sgetsKAyjiB+tZfATVS8MDh7W7DowEFUZZ5xsA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Jul 2011 05:49:58 -0000 Date: 23 Jul 2011 07:50:18 +0200 Message-ID: From: "John R. Levine" To: "Bob Van Zant" In-Reply-To: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 05:50:23 -0000 Ah, I see this isn't the discussion we thought we were having. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Fri Jul 22 22:52:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B2621F887C for ; Fri, 22 Jul 2011 22:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.613 X-Spam-Level: X-Spam-Status: No, score=-102.613 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmWLrp4aAQUw for ; Fri, 22 Jul 2011 22:52:49 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B258821F886A for ; Fri, 22 Jul 2011 22:52:48 -0700 (PDT) Received: (qmail 54183 invoked from network); 23 Jul 2011 05:52:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=d3a6.4e2a61af.k1107; bh=7m5jlHRtgvju19jIBLF9ZPHJSq6LyKePnsaygQ0hZIY=; b=h9w/vAxQMu/lCluP3OVxyibm6HjTbjXmLTLyhOoZRotcgjf4lL3UFUVDPSlcy00dYuGaGJvds/3M0oFiKdKRbHcfAu1fdz5en4qydFqvwrvxFneTmis+IAeYsRWIkpXEEC9eGNZxFCjdcnA12RUDJL/FwqfUTH5T2ylk/z17/z8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Jul 2011 05:52:25 -0000 Date: 23 Jul 2011 07:52:44 +0200 Message-ID: From: "John R. Levine" To: "Bob Van Zant" In-Reply-To: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <8639AABE-0D4A-483D-9F81-E80003B4EA51@nominum.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker , Keith Moore Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 05:52:49 -0000 > Though, any mail system worth its weight can do IP-based throttling; > even for IPv6. Big botnets don't send a million spams from each of a thousand IPs, they send a dozen spams from each of a million IPs. IP based throttling is mostly useful to choke back over-eager ESPs, who are not a big volume problem in the first place. I'm sorry if I hurt your feelings when I say that you don't understand the issues of large mail systems, but it's painfully obvious. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From dwing@cisco.com Sat Jul 23 00:56:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2E921F84E1 for ; Sat, 23 Jul 2011 00:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.048 X-Spam-Level: X-Spam-Status: No, score=-104.048 tagged_above=-999 required=5 tests=[AWL=-2.623, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwXKu3i43CTM for ; Sat, 23 Jul 2011 00:56:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 24F6821F84DF for ; Sat, 23 Jul 2011 00:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3164; q=dns/txt; s=iport; t=1311407768; x=1312617368; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=IxvPZR7Hqf53MOuVf9Hl0qs8UIi3YhoyE8ugmLkZH/8=; b=eXf/IQZV0rb5G6VcJ2tXhiZ4f2YsLObhO8WhZVqrQuPdfSPicaCaIjQv 0Gac5z7xEImGUtebnrxYRF1XrT5soM/Tkk0h2OIyJm7wWCr6zhhrk2fIN PnfqIkU4lwdiQ8z7/J0Y8GBzCh3uUauL2b1g14kLBh7COGL0tsvpdu6XG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgHAGp9Kk6rRDoJ/2dsb2JhbAA1AQEBAQIBAQIFDAEbEFIGGVcGExUkAQUmGJgkgSeNZXeIfASeYIEjnX+GPwSHVYkPkww X-IronPort-AV: E=Sophos;i="4.67,252,1309737600"; d="scan'208";a="5721678" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-4.cisco.com with ESMTP; 23 Jul 2011 07:56:07 +0000 Received: from dwingWS ([10.32.240.196]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6N7u7HN007617 for ; Sat, 23 Jul 2011 07:56:07 GMT From: "Dan Wing" To: Date: Sat, 23 Jul 2011 00:56:06 -0700 Message-ID: <025b01cc490d$fa73b030$ef5b1090$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxJDfotbwsqfGrMR1iZBRQMRXlHTQ== Content-Language: en-us Subject: [v6ops] OSX Lion IPv6 changes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 07:56:08 -0000 http://lists.apple.com/archives/Ipv6-dev/2011/Jul/msg00009.html > Has anyone played around with IPv6 since installing Lion. > Any interesting observations? There are some significant changes in Lion. Results from getaddrinfo are now sorted using routing statistics (destination with the lowest min round trip time wins). If the statistics can not determine which destination is better, an implementation of RFC3484 is used. The default RFC3484 policy is read only. CF and NS layer frameworks that use CFSocketStream do not use getaddrinfo. Those APIs use something similar to happy eyeballs. The A and AAAA queries are started at the same time but the responses are handled as they are received. When an answer is received, it is sorted in to a list of destination addresses. If there are no more addresses coming in (this was the last answer in the DNS packet or mDNSResponder has no more answers in the cache), a connection is started to the first destination on the sorted list. The DNS resolve operation is left running and more answers are processed as they arrive. A timer is setup for a period of time in which we would expect the connection to complete, based on the routing statistics. If the timer fires before the connection is established, a connection to the next best address will be started while the existing connection continues to try and make progress. A similar timer is setup and the process repeats until a connection is established or we run out of addresses to try. The code keeps track of whether or not it has received both A and AAAA response (whether the answer was a list of addresses or no address). If the connection is established before both A and AAAA responses come back, the resolve is kept open for up to a second to allow mDNSResponder to receive a slow response and store it in the cache. This way, subsequent connections to the same host in a short period of time will have all answers in the cache. Most users that aren't on this list don't care if they connect over IPv4 or IPv6. They just care that they connect. The code in CF and NS aims to make sure the user always gets a connection quickly. The code above also addresses issues where a AAAA response is never received (doesn't hold up connecting to IPv4) and issues where the user has some busted equipment that sends routing advertisements for a prefix even though the equipment has no way to route IPv6 traffic. The trade off is that it may be hard to predict whether a connection will occur over IPv6 or IPv4. If an option were added to prefer one address family over the other, it would need to indicate how much longer the user was willing to wait to get the address family of their choice. You can use the command line tool "nettop -n -m route" to dump a live view of the routing statistics. You can use "nettop -n" to dump a live view of all TCP and UDP sockets on the system. -josh -d From v6ops@globis.net Sat Jul 23 01:44:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0FB21F8757 for ; Sat, 23 Jul 2011 01:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwczQl45Kxvn for ; Sat, 23 Jul 2011 01:44:34 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6849421F8754 for ; Sat, 23 Jul 2011 01:44:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1F9708700F0; Sat, 23 Jul 2011 10:44:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zle0n0efwHVf; Sat, 23 Jul 2011 10:44:25 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 50C658700EE; Sat, 23 Jul 2011 10:44:25 +0200 (CEST) Message-ID: <4E2A89E9.5060209@globis.net> Date: Sat, 23 Jul 2011 10:44:25 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "v6ops@ietf.org WG" , "John R. Levine" Content-Type: multipart/alternative; boundary="------------040906000203060809000108" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 08:44:35 -0000 This is a multi-part message in MIME format. --------------040906000203060809000108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > Subject: > Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice > providers and other communities > From: > "John R. Levine" > Date: > 23 Jul 2011 07:49:16 +0200 > > To: > "Ted Lemon" > CC: > Joe St Sauveur , "v6ops@ietf.org" > , Keith Moore , Dave > Crocker > > Precedence: > list > MIME-Version: > 1.0 > References: > > > <20110722134844.GP2304@Space.Net> > > <20110722141726.GS2304@Space.Net> > <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> > <20110722144843.GV2304@Space.Net> > <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> > <20110722152052.GX2304@Space.Net> > <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> > > > > > > <8639AABE-0D4A-483D-9F81-E80003B4EA51@nominum.com> > In-Reply-To: > <8639AABE-0D4A-483D-9F81-E80003B4EA51@nominum.com> > Message-ID: > > Content-Type: > TEXT/PLAIN; charset=US-ASCII; format=flowed > Message: > 5 > > > > I gather that you don't know anyone whose mail servers get a billion > connections per day, over 90% of which is spam. I do. > > It's hard to avoid the impression that few people in this discussion > are familiar with the operation of large mail systems. If your system > gets 100K connections per day, any half-assed design will do. If it > gets 100M connections per day, you have to know what you're doing. > > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. http://jl.ly With all due respect, people operating mega MTA's will probably learn little from any draft produced by v6ops. If anything, shouldn't they be contributing to it? Rather than a "mine's bigger than yours" discussion, aren't the following questions things we should be asking on v6ops: Why is there any need for such mega MTA's? Did X400 have it right in the first place, and email is so difficult to do well that it's best left to a few large Telco/ISP providers? Is it because these millions of email users have some requirement in common and thus cannot run their own distributed MTA's? Or is it the fact that it's just so hard and time-consuming for the average IT savvy end-user to run their own MTA today, due to all sorts of barriers, and that this will only get worse with IPv6? If it is the last option, isn't this exactly why the email transition draft should be a v6ops WG item to provide useful information or BCP, and that the target reader should be the average IT-savvy IPv4 MTA operator? [Disclaimer: this email comes from someone who runs their own ipv6 capable MTA on the Internet, but who is apparently disqualified from contributing because the volume is so low] regards, RayH --------------040906000203060809000108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Subject:
Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities
From:
"John R. Levine" <johnl@iecc.com>
Date:
23 Jul 2011 07:49:16 +0200
To:
"Ted Lemon" <Ted.Lemon@nominum.com>
CC:
Joe St Sauveur <joe@oregon.uoregon.edu>, "v6ops@ietf.org" <v6ops@ietf.org>, Keith Moore <moore@network-heretics.com>, Dave Crocker <dcrocker@bbiw.net>
Precedence:
list
MIME-Version:
1.0
References:
<CA4DE67E.2620D%Michael_OReirdan@Cable.Comcast.com> <CA4DF9C6.30655%jason_livingood@cable.comcast.com> <20110722134844.GP2304@Space.Net> <E417AF87-8D7A-4F59-BCF9-7BB8A605D6D7@network-heretics.com> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <alpine.BSF.2.00.1107222347450.3739@joyce.lan> <CADrOfLJ2btpu6jjXHibGPp8RRaxqMJqC8AJ4ZQyV0zZd-gt5DA@mail.gmail.com> <alpine.BSF.2.00.1107230016360.3739@joyce.lan> <CADrOfL+fb5UMihx6=rU9qruph7Zk3ruJ6puRLV_TLX4OKAZRnQ@mail.gmail.com> <alpine.BSF.2.00.1107230032310.3739@joyce.lan> <8639AABE-0D4A-483D-9F81-E80003B4EA51@nominum.com>
In-Reply-To:
<8639AABE-0D4A-483D-9F81-E80003B4EA51@nominum.com>
Message-ID:
<alpine.BSF.2.00.1107230747130.36031@joyce.lan>
Content-Type:
TEXT/PLAIN; charset=US-ASCII; format=flowed
Message:
5


I gather that you don't know anyone whose mail servers get a billion connections per day, over 90% of which is spam.  I do.

It's hard to avoid the impression that few people in this discussion are familiar with the operation of large mail systems.  If your system gets 100K connections per day, any half-assed design will do.  If it gets 100M connections per day, you have to know what you're doing.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

With all due respect, people operating mega MTA's will probably learn little from any draft produced by v6ops.
If anything, shouldn't they be contributing to it?

Rather than a "mine's bigger than yours" discussion, aren't the following questions things we should be asking on v6ops:

Why is there any need for such mega MTA's?

Did X400 have it right in the first place, and email is so difficult to do well that it's best left to a few large Telco/ISP providers?

Is it because these millions of email users have some requirement in common and thus cannot run their own distributed MTA's?

Or is it the fact that it's just so hard and time-consuming for the average IT savvy end-user to run their own MTA today, due to all sorts of barriers, and that this will only get worse with IPv6?

If it is the last option, isn't this exactly why the email transition draft should be a v6ops WG item to provide useful information or BCP, and that the target reader should be the average IT-savvy IPv4 MTA operator?

[Disclaimer: this email comes from someone who runs their own ipv6 capable MTA on the Internet, but who is apparently disqualified from contributing because the volume is so low]

regards,
RayH
--------------040906000203060809000108-- From gert@space.net Sat Jul 23 01:51:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B111621F844F for ; Sat, 23 Jul 2011 01:51:07 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcoLarl-C1ap for ; Sat, 23 Jul 2011 01:51:06 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2005F21F86A2 for ; Sat, 23 Jul 2011 01:51:05 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id C66F8F854E for ; Sat, 23 Jul 2011 10:51:03 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A108AF855C for ; Sat, 23 Jul 2011 10:51:03 +0200 (CEST) Received: (qmail 84029 invoked by uid 1007); 23 Jul 2011 10:51:03 +0200 Date: Sat, 23 Jul 2011 10:51:03 +0200 From: Gert Doering To: "John R. Levine" Message-ID: <20110723085103.GA72014@Space.Net> References: <11072209372672_B93@oregon.uoregon.edu> <20110722211501.GC2304@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Joe St Sauver , v6ops@ietf.org, moore@network-heretics.com, dcrocker@bbiw.net Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 08:51:07 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Jul 23, 2011 at 12:15:28AM +0200, John R. Levine wrote: > you don't understand the problem. You've made that abundantly clear, and thanks for that enlightenment. Indeed I've never run one of the 100 biggest mail servers in the world, and there are people much better qualified than I that are doing that. And those tell me "it can be done" - strato.de and t-online.de are two of the top 10 mail providers in germany, and both feel confident that their anti-spam solutions can handle spammers using IPv6. So why should I believe otherwise? Regarding DNSBLs and "spammers will use a different source address=20 per connection and kill your DNS cache" - well, indeed, it will not work by applying IPv4 techniques 1:1 and not adjusting the mechanics for IPv6. So new concepts need to be thought out and tested - and if it turns out that they don't work, then turn off IPv6 on the MX for=20 a month and come up with new ideas in the mean time. (Which is mostly what the draft is saying - "trial now, be ready next year") *Not* deploying IPv6 "just because it might not work" is not going to help solving the problem either. Feel free to tell me a few more times that I don't understand your=20 problem. 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 (89) 32356-444 USt-IdNr.: DE813185279 --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTiqLd6kuBuNlUUl1AQJPywP+MTGF0qg1htEWzqjUPWmfH5XG/Stk2xOK I47VMjXW4Iv+7wMpxc9kOTz9doM3sGXY7xnCF6S7cKCWsIpWRw5MfSLlZQoP2xKR V5EfQ7hORQYBMP9okc/4jf5LjdMkkWQH1cDr0qcj3zASQLavY1C9EHseO7Iq/iEg CTG9lauq57w= =eHJn -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2-- From pch-b2B3A6689@u-1.phicoh.com Sat Jul 23 01:52:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EF121F8781 for ; Sat, 23 Jul 2011 01:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.269 X-Spam-Level: X-Spam-Status: No, score=-4.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyikdPCn7WD8 for ; Sat, 23 Jul 2011 01:52:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (unknown [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 463CE21F876F for ; Sat, 23 Jul 2011 01:52:12 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QkXwP-0001mnC; Sat, 23 Jul 2011 10:52:09 +0200 Message-Id: To: "John R. Levine" From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <11072209372672_B93@oregon.uoregon.edu> <20110722211501.GC2304@Space.Net> In-reply-to: Your message of "23 Jul 2011 00:15:28 +0200 ." Date: Sat, 23 Jul 2011 10:51:50 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 08:52:14 -0000 In your letter dated 23 Jul 2011 00:15:28 +0200 you wrote: >The vast size of the IPv6 address space means that a lot of stuff that >worked in IPv4 simply doesn't work in IPv6. Most notably, we have to >assume that bad guys (or even misguided good guys) will use a different IP >address for every single messge. This means that any per-message DNS >lookup, even an rDNS lookup, can make your DNS cache explode. > >The abuse management community has been thinking about this for quite a >while. If you think there are easy solutions, that means you don't >understand the problem. Of course there are easy solutions. Thinking for just 5 minutes about this problem gives you a couple of easy solutions. But, v6ops is in my opinion not the right place to discuss anti-spam measures. So, I will leave at at that. From pch-b2B3A6689@u-1.phicoh.com Sat Jul 23 03:53:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6FA21F86E6 for ; Sat, 23 Jul 2011 03:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.213 X-Spam-Level: X-Spam-Status: No, score=-8.213 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQWi6W4oQbTX for ; Sat, 23 Jul 2011 03:53:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2D321F86E0 for ; Sat, 23 Jul 2011 03:53:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QkZfd-0001ZpC; Sat, 23 Jul 2011 12:42:57 +0200 Message-Id: To: Ray Hunter From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Sat, 23 Jul 2011 10:44:25 +0200 ." <4E2A89E9.5060209@globis.net> Date: Sat, 23 Jul 2011 12:42:39 +0200 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 10:53:28 -0000 In your letter dated Sat, 23 Jul 2011 10:44:25 +0200 you wrote: >Why is there any need for such mega MTA's? > >Did X400 have it right in the first place, and email is so difficult to >do well that it's best left to a few large Telco/ISP providers? > >Is it because these millions of email users have some requirement in >common and thus cannot run their own distributed MTA's? > >Or is it the fact that it's just so hard and time-consuming for the >average IT savvy end-user to run their own MTA today, due to all sorts >of barriers, and that this will only get worse with IPv6? > >[Disclaimer: this email comes from someone who runs their own ipv6 >capable MTA on the Internet, but who is apparently disqualified from >contributing because the volume is so low] I guess you and I are in the easy part of the MTA spectrum. At the very low end, consumers can only run their own mail server is it is just a single button click to turn it on. That's a hard problem. Then we get to the small scale mail servers. That is easy. Somebody who knows a little bit about DNS, configuring software, etc. can easily set up a mailserver. Then you get to bigger organization, thousands of users. There you need qualified people who know about scaling. Many of those organizations got rid of everybody who actually knows how stuff works and replaced them with consultants who are better at billing then actually making things work. So, both individuals who want to be independent of their ISPs and bigger organizations outsource their e-mail to big e-mail providers. From ietfc@btconnect.com Sat Jul 23 04:27:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B49021F86DE for ; Sat, 23 Jul 2011 04:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5YoEF8ORdQj for ; Sat, 23 Jul 2011 04:27:48 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFB221F86DC for ; Sat, 23 Jul 2011 04:27:47 -0700 (PDT) Received: from host86-174-254-236.range86-174.btcentralplus.com (HELO pc6) ([86.174.254.236]) by c2bthomr07.btconnect.com with SMTP id DWZ40018; Sat, 23 Jul 2011 12:27:44 +0100 (BST) Message-ID: <013201cc4922$bf2e4ca0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Fred Baker" References: <20110722134844.GP2304@Space.Net><20110722141726.GS2304@Space.Net><9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com><20110722144843.GV2304@Space.Net><4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com><20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> Date: Sat, 23 Jul 2011 12:24:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4E2AB030.005E, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.7.19.51514:17:7.586, ip=86.174.254.236, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __CP_NAME_BODY, BODY_SIZE_1500_1599, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020B.4E2AB031.001E,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: v6ops@ietf.org Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for seviceproviders and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 11:27:49 -0000 ----- Original Message ----- From: "Fred Baker" To: "Gert Doering" Cc: "John R. Levine" ; "Joe St Sauveur" ; ; "Keith Moore" ; "Dave Crocker" Sent: Friday, July 22, 2011 5:59 PM > > On Jul 22, 2011, at 8:20 AM, Gert Doering wrote: > > > You don't need universal availability on the last DSL line to have IPv6 *on servers*. > > and by the way, the entire series of MUA/MTA and MTA/MTA links don't have to have IPv6 for it to be used on some of them. If one end user is IPv6-only, the other is IPv4-only, and at least one MTA in between is dual, nobody should notice an issue. Not quite true. If there is an IPv6 MTA somewhere in the chain, then an MTA/MUA will likely see an IPv6 address in the header, in the 'Received: from' so any software, perhaps those concerned with detecting and analysing possible 'spam', that looks at those fields will be affected. Tom Petch > > My initial comment to Michael, when he pointed the draft out to me, was that email seems like the poster child of an easy application to add IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support it already and the current OS's support IPv6. The primary thing preventing mail/IPv6 is network IPv6 deployment, which is in progress. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ietfc@btconnect.com Sat Jul 23 04:32:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0AF21F872F for ; Sat, 23 Jul 2011 04:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R27sEipI5GJA for ; Sat, 23 Jul 2011 04:32:27 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9876321F86DC for ; Sat, 23 Jul 2011 04:32:26 -0700 (PDT) Received: from host86-174-254-236.range86-174.btcentralplus.com (HELO pc6) ([86.174.254.236]) by c2bthomr09.btconnect.com with SMTP id DUL98087; Sat, 23 Jul 2011 12:32:21 +0100 (BST) Message-ID: <013c01cc4923$643ffd60$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Sander Steffann" , "John R. Levine" References: <11072209372672_B93@oregon.uoregon.edu><20110722211501.GC2304@Space.Net> <04D6BDFF-FD99-4D3C-A861-0197620504E7@steffann.nl> Date: Sat, 23 Jul 2011 12:29:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4E2AB145.000F, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.7.23.102715:17:7.586, ip=86.174.254.236, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4E2AB146.000C,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: IPv6 Operations Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for seviceproviders and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 11:32:27 -0000 ----- Original Message ----- From: "Sander Steffann" To: "John R. Levine" Cc: "IPv6 Operations" Sent: Saturday, July 23, 2011 1:22 AM > Hi, > > >>> Why? Spam management solutions simply aren't yet where they need to be... > >> > >> ... in which case, gratuitous amounts of pressure needs to be applied > >> to anti-spam vendors that are not there yet. > > > > That is a phenomenally naive and unhelpful suggestion. > > > > The vast size of the IPv6 address space means that a lot of stuff that worked in IPv4 simply doesn't work in IPv6. Most notably, we have to assume that bad guys (or even misguided good guys) will use a different IP address for every single messge. This means that any per-message DNS lookup, even an rDNS lookup, can make your DNS cache explode. > > > > The abuse management community has been thinking about this for quite a while. If you think there are easy solutions, that means you don't understand the problem. > > The solutions don't have to be easy. Gert made a comment about anti-spam *vendors*. They make money by providing anti-spam solutions. It's their job to work on this. That is what we pay them for... They need to understand that products without IPv6 support will not sell very well. I think that you have just argued for the abolition of the IETF and IRTF. Having vendor-independent standards has, on occasions, helped the development of the Internet. On this particular topic, the asrg has been wrestling with this issue for a long time, and, as John says, there are no easy solutions. And any figures about current IPv6 usage are irrelevant. Spammers follow the traffic and as - if? - and when IPv6 has substantial traffic, then we will see the 90+% levels of spam that we currently see reported on IPv4 Tom Petch > > If it was easy I would do it myself ;) > - Sander > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sander@steffann.nl Sat Jul 23 05:06:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFE321F8665 for ; Sat, 23 Jul 2011 05:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npn2alYpIP7I for ; Sat, 23 Jul 2011 05:06:40 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [83.137.17.90]) by ietfa.amsl.com (Postfix) with ESMTP id A63C521F85A3 for ; Sat, 23 Jul 2011 05:06:40 -0700 (PDT) Received: from [IPv6:2001:610:6ce:1:3c85:8dd1:2530:2d5d] (unknown [IPv6:2001:610:6ce:1:3c85:8dd1:2530:2d5d]) by mail.sintact.nl (Postfix) with ESMTP id CBE372012; Sat, 23 Jul 2011 14:01:37 +0200 (CEST) References: <11072209372672_B93@oregon.uoregon.edu> <20110722211501.GC2304@Space.Net> <04D6BDFF-FD99-4D3C-A861-0197620504E7@steffann.nl> <013c01cc4923$643ffd60$4001a8c0@gateway.2wire.net> In-Reply-To: <013c01cc4923$643ffd60$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 (iPhone Mail 8K2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9C3EEC81-9DAF-4D61-BE77-FA91E146F201@steffann.nl> X-Mailer: iPhone Mail (8K2) From: Sander Steffann Date: Sat, 23 Jul 2011 14:01:35 +0200 To: "t.petch" Cc: "John R. Levine" , IPv6 Operations Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for seviceproviders and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 12:06:41 -0000 Hi, >=20 > I think that you have just argued for the abolition of the IETF and IRTF. No I didn't :) > Having vendor-independent standards has, on occasions, helped the developm= ent of > the Internet. On this particular topic, the asrg has been wrestling with t= his > issue for a long time, and, as John says, there are no easy solutions. I didn't say that the anti-spam vendors should work outside the IETF. Althou= gh I don't see a big problem as long as they speak SMTP on the outside :) >=20 - Sander From joelja@bogus.com Sat Jul 23 06:14:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10E021F85C0 for ; Sat, 23 Jul 2011 06:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mr2nYXpEhr5 for ; Sat, 23 Jul 2011 06:14:36 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3172E21F8585 for ; Sat, 23 Jul 2011 06:14:36 -0700 (PDT) Received: from [130.129.87.16] (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6NDESI1021456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 23 Jul 2011 13:14:31 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli X-Priority: 3 In-Reply-To: <013201cc4922$bf2e4ca0$4001a8c0@gateway.2wire.net> Date: Sat, 23 Jul 2011 06:14:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110722134844.GP2304@Space.Net><20110722141726.GS2304@Space.Net><9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com><20110722144843.GV2304@Space.Net><4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com><20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <013201cc4922$bf2e4ca0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 23 Jul 2011 13:14:32 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for seviceproviders and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 13:14:37 -0000 On Jul 23, 2011, at 3:24 AM, t.petch wrote: > ----- Original Message ----- > From: "Fred Baker" > To: "Gert Doering" > Cc: "John R. Levine" ; "Joe St Sauveur" > ; ; "Keith Moore" > ; "Dave Crocker" > Sent: Friday, July 22, 2011 5:59 PM >=20 >>=20 >> On Jul 22, 2011, at 8:20 AM, Gert Doering wrote: >>=20 >>> You don't need universal availability on the last DSL line to have = IPv6 *on > servers*. >>=20 >> and by the way, the entire series of MUA/MTA and MTA/MTA links don't = have to > have IPv6 for it to be used on some of them. If one end user is = IPv6-only, the > other is IPv4-only, and at least one MTA in between is dual, nobody = should > notice an issue. >=20 > Not quite true. If there is an IPv6 MTA somewhere in the chain, then = an MTA/MUA > will likely see an IPv6 address in the header, in the 'Received: from' = so any > software, perhaps those concerned with detecting and analysing = possible 'spam', > that looks at those fields will be affected. This happens today, on this mailing list no less. It's happened for more = than a decade now. From Ted.Lemon@nominum.com Sat Jul 23 06:52:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2308F21F865E for ; Sat, 23 Jul 2011 06:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDFscbqls5Rj for ; Sat, 23 Jul 2011 06:52:55 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 691FF21F863C for ; Sat, 23 Jul 2011 06:52:55 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTirSNuhGWrgMj6KLkPUIEUYU/FqXJmtp@postini.com; Sat, 23 Jul 2011 06:52:55 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 692C01B81B9 for ; Sat, 23 Jul 2011 06:52:54 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4B3EE190060; Sat, 23 Jul 2011 06:52:54 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0289.001; Sat, 23 Jul 2011 06:52:48 -0700 From: Ted Lemon To: Ray Hunter Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AQHMSRS5alI5I8L3pke3J0CpCBEN6ZT6YssA Date: Sat, 23 Jul 2011 13:52:48 +0000 Message-ID: References: <4E2A89E9.5060209@globis.net> In-Reply-To: <4E2A89E9.5060209@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_B37234DD6F1244A7A85ABE9586BC828Fnominumcom_" MIME-Version: 1.0 Cc: "John R. Levine" , "v6ops@ietf.org WG" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 13:52:56 -0000 --_000_B37234DD6F1244A7A85ABE9586BC828Fnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Jul 23, 2011, at 4:44 AM, Ray Hunter wrote: Or is it the fact that it's just so hard and time-consuming for the average= IT savvy end-user to run their own MTA today, due to all sorts of barriers= , and that this will only get worse with IPv6? If it is the last option, isn't this exactly why the email transition draft= should be a v6ops WG item to provide useful information or BCP, and that t= he target reader should be the average IT-savvy IPv4 MTA operator? One of the reasons I'm keen on seeing MTAs at least *deliver* to IPv6 addre= sses is that I think in principle IPv6 ought to make it possible for people= to move away from the million-plus-user MTA model. However, I think it's= a big leap from it being possible to it happening. Right now I'm just in= terested in it being possible. --_000_B37234DD6F1244A7A85ABE9586BC828Fnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7B3994CD7DBD484296E3E8115A78CA24@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 23, 2011, at 4:44 AM, Ray Hunter wrote:
Or is it the fact that it's just so hard and time-consuming for the average I= T savvy end-user to run their own MTA today, due to all sorts of barriers, = and that this will only get worse with IPv6?

If it is the last option, isn't this exactly why the email transition draft= should be a v6ops WG item to provide useful information or BCP, and that t= he target reader should be the average IT-savvy IPv4 MTA operator?

One of the reasons I'm keen on seeing MTAs at least *deliver* to IPv6 = addresses is that I think in principle IPv6 ought to make it possible for p= eople to move away from the million-plus-user MTA model.   However, I = think it's a big leap from it being possible to it happening.   Right now I'm just interested in it being possible= .

--_000_B37234DD6F1244A7A85ABE9586BC828Fnominumcom_-- From pch-b2B3A6689@u-1.phicoh.com Sat Jul 23 07:05:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093C421F877F for ; Sat, 23 Jul 2011 07:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqSZnJnV0Hyp for ; Sat, 23 Jul 2011 07:05:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 1417321F86EE for ; Sat, 23 Jul 2011 07:05:36 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1Qkcpi-0001gzC; Sat, 23 Jul 2011 16:05:34 +0200 Message-Id: To: Ted Lemon From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <4E2A89E9.5060209@globis.net> In-reply-to: Your message of "Sat, 23 Jul 2011 13:52:48 +0000 ." Date: Sat, 23 Jul 2011 16:05:23 +0200 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 14:05:37 -0000 In your letter dated Sat, 23 Jul 2011 13:52:48 +0000 you wrote: >One of the reasons I'm keen on seeing MTAs at least *deliver* to IPv6 addre= >sses is that I think in principle IPv6 ought to make it possible for people= > to move away from the million-plus-user MTA model. However, I think it's= > a big leap from it being possible to it happening. Right now I'm just in= >terested in it being possible. One thing to make this possible would a 'secondary MX' service that accepts mail over IPv4, spam filters it and then delivers it over IPv6 to the customer. From joelja@bogus.com Sat Jul 23 07:15:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0007421F8797 for ; Sat, 23 Jul 2011 07:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktfxHrTv2hhc for ; Sat, 23 Jul 2011 07:15:49 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5A15D21F8743 for ; Sat, 23 Jul 2011 07:15:49 -0700 (PDT) Received: from [130.129.87.16] (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6NEFhtp025626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 23 Jul 2011 14:15:45 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Sat, 23 Jul 2011 07:15:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hui Deng X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 23 Jul 2011 14:15:46 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] 1 comment on draft-jjmb-v6ops-comcast-ipv6-experiences-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 14:15:50 -0000 On Jul 22, 2011, at 4:14 PM, Hui Deng wrote: > Hello authors >=20 > This work is a good reference for the operator, thanks for writing = this draft, > has gathered the useful information, appreciate the work. >=20 > Just one clarification, the reason of recommdating dual stack is = because Comcast is mainly providing CDN based IPTV like service? The question seems really odd? Why wouldn't native deployment be the = preferable model? joel > Best regards, >=20 > -Hui >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From moore@network-heretics.com Sat Jul 23 07:20:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B612E21F853A for ; Sat, 23 Jul 2011 07:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c16VRgTlGKOh for ; Sat, 23 Jul 2011 07:20:56 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5E27021F8877 for ; Sat, 23 Jul 2011 07:20:56 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 75C6F20368; Sat, 23 Jul 2011 10:20:55 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Sat, 23 Jul 2011 10:20:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=+SB U46ssMjKL48U9y8BgLkAVDOs=; b=qWQO0acuLY9rKGtphiZ4/KK0IYt75PZynqf CTX+wQXdbidRKbEALdV/Sab2wZN8uQ4gDh0YlAruBoOUXbLtW4rd0PlXfh7loUGS FySHouqIRxA5NVsfJDIBfrWAFoPqA1Q/XNhm8bNt6tb4poRx6yIunBLDlMhE53Pa FwzDoCTw= X-Sasl-enc: sAwTYwpo0GTbHPUVr6wZT+IngtyNWHHcowc3MzbihxYg 1311430855 Received: from [10.164.210.65] (unknown [149.48.225.2]) by mail.messagingengine.com (Postfix) with ESMTPA id 38527453955; Sat, 23 Jul 2011 10:20:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-32-263689681 From: Keith Moore In-Reply-To: Date: Sat, 23 Jul 2011 10:20:54 -0400 Message-Id: <68ADF2C9-7B23-42D3-BA8B-8394825F9279@network-heretics.com> References: <4E2A89E9.5060209@globis.net> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "John R. Levine" , Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 14:20:58 -0000 --Apple-Mail-32-263689681 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 23, 2011, at 9:52 AM, Ted Lemon wrote: > On Jul 23, 2011, at 4:44 AM, Ray Hunter wrote: >> Or is it the fact that it's just so hard and time-consuming for the = average IT savvy end-user to run their own MTA today, due to all sorts = of barriers, and that this will only get worse with IPv6? >>=20 >> If it is the last option, isn't this exactly why the email transition = draft should be a v6ops WG item to provide useful information or BCP, = and that the target reader should be the average IT-savvy IPv4 MTA = operator? >=20 > One of the reasons I'm keen on seeing MTAs at least *deliver* to IPv6 = addresses is that I think in principle IPv6 ought to make it possible = for people to move away from the million-plus-user MTA model. However, = I think it's a big leap from it being possible to it happening. Right = now I'm just interested in it being possible. Me too. But as far as I can tell, the biggest barrier to running your = own MTA, or a small enterprise running its own MTA, is spam filtering. = I've advised several small business clients to migrate their own in = house mail services to a large commercial provider, because there's no = way that a small enterprise can mange an effective, locally-run spam = filtering operation anywhere nearly as cheaply as a large MSP can = provide an equivalent service. =20 (YMMV, in fact it almost certainly does vary. People's experience of = spam varies widely. But my clients were getting a fair amount of spam = and it was interfering with their ability to do billable work.) Keith --Apple-Mail-32-263689681 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 23, 2011, at 9:52 AM, Ted Lemon wrote:

On Jul 23, 2011, at 4:44 AM, Ray Hunter wrote:
Or is it the fact that it's just so hard and time-consuming for the average IT savvy end-user to run their own MTA today, due to all sorts of barriers, and that this will only get worse with IPv6?

If it is the last option, isn't this exactly why the email transition draft should be a v6ops WG item to provide useful information or BCP, and that the target reader should be the average IT-savvy IPv4 MTA operator?

One of the reasons I'm keen on seeing MTAs at least *deliver* to IPv6 addresses is that I think in principle IPv6 ought to make it possible for people to move away from the million-plus-user MTA model.   However, I think it's a big leap from it being possible to it happening.   Right now I'm just interested in it being possible.

Me too.  But as far as I can tell, the biggest barrier to running your own MTA, or a small enterprise running its own MTA, is spam filtering.  I've advised several small business clients to migrate their own in house mail services to a large commercial provider, because there's no way that a small enterprise can mange an effective, locally-run spam filtering operation anywhere nearly as cheaply as a large MSP can provide an equivalent service.  

(YMMV, in fact it almost certainly does vary.   People's experience of spam varies widely.  But my clients were getting a fair amount of spam and it was interfering with their ability to do billable work.)

Keith

--Apple-Mail-32-263689681-- From john_brzozowski@cable.comcast.com Sat Jul 23 08:11:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0614521F84F5 for ; Sat, 23 Jul 2011 08:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHPoOvhktgrd for ; Sat, 23 Jul 2011 08:11:27 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5E55321F84F3 for ; Sat, 23 Jul 2011 08:11:27 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.45885838; Sat, 23 Jul 2011 09:16:00 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Sat, 23 Jul 2011 11:11:20 -0400 From: "Brzozowski, John" To: Hui Deng , "v6ops@ietf.org" Thread-Topic: [v6ops] 1 comment on draft-jjmb-v6ops-comcast-ipv6-experiences-01 Thread-Index: AQHMSMVC6o/V6E+VLEihriLA2xkRzJT6BAAA Date: Sat, 23 Jul 2011 15:11:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <0050C2DB028E9648A29898806C9AE8DF@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] 1 comment on draft-jjmb-v6ops-comcast-ipv6-experiences-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 15:11:28 -0000 Hui, At this time native dual stack reference mostly pertains to broadband Internet. We did enable some of our content (web sites) using a variety of techniques including native dual stack. There is no reference to IPTV in the document. HTH, John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 7/22/11 7:14 PM, "Hui Deng" wrote: >Hello authors >This work is a good reference for the operator, thanks for writing this >draft, >has gathered the useful information, appreciate the work. >Just one clarification, the reason of recommdating dual stack is because >Comcast is mainly providing CDN based IPTV like service? >Best regards, >-Hui >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From Ted.Lemon@nominum.com Sat Jul 23 09:20:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90C221F8A4D for ; Sat, 23 Jul 2011 09:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTR3TsvoQ4ai for ; Sat, 23 Jul 2011 09:20:53 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2906521F8987 for ; Sat, 23 Jul 2011 09:20:52 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTir04z/Ncym/qFRBs4Oq1TzmxAh1Br6F@postini.com; Sat, 23 Jul 2011 09:20:53 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 63F401B81BB for ; Sat, 23 Jul 2011 09:20:51 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 37466190060; Sat, 23 Jul 2011 09:20:51 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0289.001; Sat, 23 Jul 2011 09:20:51 -0700 From: Ted Lemon To: Keith Moore Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AQHMSRS5alI5I8L3pke3J0CpCBEN6ZT6YssAgAAH2gCAACGEgA== Date: Sat, 23 Jul 2011 16:20:50 +0000 Message-ID: <100C1765-EFFE-40E9-9C22-32FCD48BB6C1@nominum.com> References: <4E2A89E9.5060209@globis.net> <68ADF2C9-7B23-42D3-BA8B-8394825F9279@network-heretics.com> In-Reply-To: <68ADF2C9-7B23-42D3-BA8B-8394825F9279@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_100C1765EFFE40E99C2232FCD48BB6C1nominumcom_" MIME-Version: 1.0 Cc: "John R. Levine" , Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 16:20:54 -0000 --_000_100C1765EFFE40E99C2232FCD48BB6C1nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 23, 2011, at 10:20 AM, Keith Moore wrote: Me too. But as far as I can tell, the biggest barrier to running your own = MTA, or a small enterprise running its own MTA, is spam filtering. I've ad= vised several small business clients to migrate their own in house mail ser= vices to a large commercial provider, because there's no way that a small e= nterprise can mange an effective, locally-run spam filtering operation anyw= here nearly as cheaply as a large MSP can provide an equivalent service. Sad, but true. I get some mileage out of free RBLs, but it's still pretty= bad. Needs further work. --_000_100C1765EFFE40E99C2232FCD48BB6C1nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0F0E6CBFFC812349A48406FC4A0C6AFD@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 23, 2011, at 10:20 AM, Keith Moore wrote:
Me too.  But as far as I can tell, the biggest barrier to running your o= wn MTA, or a small enterprise running its own MTA, is spam filtering.  = ;I've advised several small business clients to migrate their own in house = mail services to a large commercial provider, because there's no way that a small enterprise can mange an effective, loc= ally-run spam filtering operation anywhere nearly as cheaply as a large MSP= can provide an equivalent service.  

Sad, but true.   I get some mileage out of free RBLs, but it's st= ill pretty bad.   Needs further work.

--_000_100C1765EFFE40E99C2232FCD48BB6C1nominumcom_-- From johnl@iecc.com Sat Jul 23 09:41:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCB121F8560 for ; Sat, 23 Jul 2011 09:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.155 X-Spam-Level: X-Spam-Status: No, score=-102.155 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMfRipZ84+5H for ; Sat, 23 Jul 2011 09:41:28 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9873C21F84EB for ; Sat, 23 Jul 2011 09:41:28 -0700 (PDT) Received: (qmail 58856 invoked from network); 23 Jul 2011 16:41:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=e5e7.4e2af9b6.k1107; bh=CJtt1Zxi5305FxqSp89ohmWleqsb8X7DB9ddqn0oWoA=; b=IjQkRfJDPQjh9+0lQBMTcbFDYsV0aT3+rRwKkt6qPu2h2wRcsLhPllXVMNuk/R2nowHjzVRAEKZmt0OHqGUjMuNVQeaSk+gzDfKuo31qafrPTKvnHBYBnKRCM2HbjkH1sW0h7adOQLXz+Di5dw/B42oyY4pAqHAB2ec/J455zHk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Jul 2011 16:41:03 -0000 Date: 23 Jul 2011 18:41:23 +0200 Message-ID: From: "John R. Levine" To: "Ray Hunter" In-Reply-To: <4E2A89E9.5060209@globis.net> References: <4E2A89E9.5060209@globis.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 16:41:29 -0000 > With all due respect, people operating mega MTA's will probably learn little > from any draft produced by v6ops. > If anything, shouldn't they be contributing to it? You might be interested in draft-oreirdan-rosenwald-ipv6mail-transition-00 which is written by two tech guys at Comcast. > Why is there any need for such mega MTA's? I don't understand this question. If you are Hotmail or Comcast, with millions of users, you need a mail system that can handle your users' mail. If you're arguing that mail systems shouldn't have that many users, we're definiting out of scope. > Is it because these millions of email users have some requirement in common > and thus cannot run their own distributed MTA's? Based on my experience (you might want to ask Google about the books I've written), the vast majority of users have no interest whatsoever in running any mail software at all. They don't want to run an MUA, much less an MTA. That's why web mail is so popular. > [Disclaimer: this email comes from someone who runs their own ipv6 capable > MTA on the Internet, but who is apparently disqualified from contributing > because the volume is so low] In case it's not clear, my mail system isn't very big either, with maybe 100K connections on a normal day and 400K on a busy one. I'm not saying that people shouldn't contribute, but I am saying that it is not useful to assume that what works on our toy systems will work on the kinds of large systems that the majority of Internet users use. There's plenty of room for systems of all sizes, but if we're going to offer advice for running them, we really need to understand what the issues are at different scales, and have a reasonable understanding of what the issues are likely to be, most notably, the ways that spammers, who are totally anti-social, are likely to attack whatever is built. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Sat Jul 23 09:47:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B375221F8B12 for ; Sat, 23 Jul 2011 09:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQ8fhQ-+wiQO for ; Sat, 23 Jul 2011 09:47:15 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D57D421F86AF for ; Sat, 23 Jul 2011 09:47:14 -0700 (PDT) Received: (qmail 58916 invoked from network); 23 Jul 2011 16:47:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=e623.4e2afb12.k1107; bh=WpaVyvRJadWnCPfgasocRkVMY4co1BvDMVHPv/3Cngo=; b=PlYUVkPpLtM2BGtyC/3RJHdw3EcSUfpCQLFWBYKoayxRcwC/9jSJRygwcqsYVtNB1MJnfmh3pVMQcbdFaxvogfE9hTtbCXyhyifAhAt5KEcGSQR/z5C8ffkvayD3JZHdV5A9hulG3iJzW2VEWSb3JCuNIplil/kkx52EfwdlT3M= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Jul 2011 16:46:51 -0000 Date: 23 Jul 2011 18:47:11 +0200 Message-ID: From: "John R. Levine" To: "Gert Doering" In-Reply-To: <20110723085103.GA72014@Space.Net> References: <11072209372672_B93@oregon.uoregon.edu> <20110722211501.GC2304@Space.Net> <20110723085103.GA72014@Space.Net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Joe St Sauver , v6ops@ietf.org, dcrocker@bbiw.net, moore@network-heretics.com Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 16:47:15 -0000 > And those tell me "it can be done" - strato.de and t-online.de are two > of the top 10 mail providers in germany, and both feel confident that > their anti-spam solutions can handle spammers using IPv6. > > So why should I believe otherwise? I know other mail systems at least as large who are much less optimistic. > Regarding DNSBLs and "spammers will use a different source address > per connection and kill your DNS cache" - well, indeed, it will not > work by applying IPv4 techniques 1:1 and not adjusting the mechanics > for IPv6. So new concepts need to be thought out and tested - and if > it turns out that they don't work, then turn off IPv6 on the MX for > a month and come up with new ideas in the mean time. (Which is mostly > what the draft is saying - "trial now, be ready next year") Um, has anyone read draft-levine-iprangepub? It's a different way to do DNSBLs that I've been experimenting with since December. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From johnl@iecc.com Sat Jul 23 10:05:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915E721F8AFB for ; Sat, 23 Jul 2011 10:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdYVzS5X59i3 for ; Sat, 23 Jul 2011 10:05:43 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B0B4521F8AFE for ; Sat, 23 Jul 2011 10:05:41 -0700 (PDT) Received: (qmail 59084 invoked from network); 23 Jul 2011 17:05:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=e6cb.4e2aff64.k1107; bh=p0vqas/Ii/kJEzPdkAwOpL0n7uKND6fzk6TrgtXOj2o=; b=P61wvvKFuyRhzuyxbi8OLL75LSi+e7tUZDc/WZyy5HujhAk6e6igNb7OQe4PEU65xX1Jt8I3EArkggObZ6rJIBJ1PtOCmbnAklG/rXve17Kx+o+gdxw8TJnbNaX1zeidtzeflqbg63P88Co5q8D9rswkTj8V0245DiYPR0GY4/w= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Jul 2011 17:05:18 -0000 Date: 23 Jul 2011 19:05:38 +0200 Message-ID: From: "John R. Levine" To: "Ted Lemon" In-Reply-To: <100C1765-EFFE-40E9-9C22-32FCD48BB6C1@nominum.com> References: <4E2A89E9.5060209@globis.net> <68ADF2C9-7B23-42D3-BA8B-8394825F9279@network-heretics.com> <100C1765-EFFE-40E9-9C22-32FCD48BB6C1@nominum.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ray Hunter , "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] outsourced spam filtering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 17:05:43 -0000 > Me too. But as far as I can tell, the biggest barrier to running your > own MTA, or a small enterprise running its own MTA, is spam filtering. Quite right. If an enterprise wants to run its own mail service (which in my experience is relatively rare, not because it's so hard, but because it's one more damned thing not directly related to their actual business), you can outsource it to companies like Messagelabs or MX Logic who run filtering proxies in front of your MTA. There are also on-site filtering proxies like Barracuda, but I've never seen one I would recommend. Obv6: Some of these companies are thinking about inbound v6 but I don't know any who are offering it yet. Perhaps someone interested in v6 mail could poke around their web sites and see what they're currently saying. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From gert@space.net Sat Jul 23 11:32:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224BB21F865B for ; Sat, 23 Jul 2011 11:32:52 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwnGezVU1fzC for ; Sat, 23 Jul 2011 11:32:51 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 09D1621F863E for ; Sat, 23 Jul 2011 11:32:49 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 8954CF855A for ; Sat, 23 Jul 2011 20:32:48 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 6AD89F8561 for ; Sat, 23 Jul 2011 20:32:48 +0200 (CEST) Received: (qmail 57996 invoked by uid 1007); 23 Jul 2011 20:32:48 +0200 Date: Sat, 23 Jul 2011 20:32:48 +0200 From: Gert Doering To: "John R. Levine" Message-ID: <20110723183248.GC72014@Space.Net> References: <11072209372672_B93@oregon.uoregon.edu> <20110722211501.GC2304@Space.Net> <20110723085103.GA72014@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iFRdW5/EC4oqxDHL" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Joe St Sauver , v6ops@ietf.org, moore@network-heretics.com, dcrocker@bbiw.net Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 18:32:52 -0000 --iFRdW5/EC4oqxDHL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Jul 23, 2011 at 06:47:11PM +0200, John R. Levine wrote: > > And those tell me "it can be done" - strato.de and t-online.de are two > > of the top 10 mail providers in germany, and both feel confident that > > their anti-spam solutions can handle spammers using IPv6. > > > > So why should I believe otherwise? >=20 > I know other mail systems at least as large who are much less optimistic. I've observed IPv6 non-deployment for about 14 years now, mostly because people were "less optimistic". There's a great saying about those that don't believe something can be done not standing in the way of those that are busy *doing* it... > > Regarding DNSBLs and "spammers will use a different source address > > per connection and kill your DNS cache" - well, indeed, it will not > > work by applying IPv4 techniques 1:1 and not adjusting the mechanics > > for IPv6. So new concepts need to be thought out and tested - and if > > it turns out that they don't work, then turn off IPv6 on the MX for > > a month and come up with new ideas in the mean time. (Which is mostly > > what the draft is saying - "trial now, be ready next year") >=20 > Um, has anyone read draft-levine-iprangepub? It's a different way to do= =20 > DNSBLs that I've been experimenting with since December. Thanks for bringing forward new ideas. So maybe you could explain your point again why people cannot do IPv6 deployment on their MXes, not even for trials? Indeed I do not understand. 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 (89) 32356-444 USt-IdNr.: DE813185279 --iFRdW5/EC4oqxDHL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTisT0KkuBuNlUUl1AQL+rAQAvNSyc2OVk2rnKSWUfsQJ3p4AydLF6YLR ZSd73OTZm2p4mqQg+NHSQ8Hn3QZyJ7o9fgwEuxx3iOzTfaPjO2qEisGlyUTEKkqX ABTu4K1/vUxIplhWVUliV9QharJZ7EZKfvkbI8JjvAVONBx0J1lnACAg1SBUXhw3 RuRgmYWXlBM= =vyg4 -----END PGP SIGNATURE----- --iFRdW5/EC4oqxDHL-- From Ted.Lemon@nominum.com Sat Jul 23 12:03:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5E021F853B for ; Sat, 23 Jul 2011 12:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.223 X-Spam-Level: X-Spam-Status: No, score=-106.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwo8pozw9aby for ; Sat, 23 Jul 2011 12:03:25 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 821B521F8698 for ; Sat, 23 Jul 2011 12:03:25 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTisa+lXiwhhs1UwkCtoREShwyGJLu3oL@postini.com; Sat, 23 Jul 2011 12:03:25 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 383E71B81BB for ; Sat, 23 Jul 2011 12:03:22 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1FCDC190060; Sat, 23 Jul 2011 12:03:22 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0289.001; Sat, 23 Jul 2011 12:03:16 -0700 From: Ted Lemon To: t.petch Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for seviceproviders and other communities Thread-Index: AQHMSSNhZyycff6oPkatqugrZnjvA5T6uWoA Date: Sat, 23 Jul 2011 19:03:15 +0000 Message-ID: <9C0DCA20-9B0C-46A5-A99F-B63FDEF41421@nominum.com> References: <11072209372672_B93@oregon.uoregon.edu><20110722211501.GC2304@Space.Net> <04D6BDFF-FD99-4D3C-A861-0197620504E7@steffann.nl> <013c01cc4923$643ffd60$4001a8c0@gateway.2wire.net> In-Reply-To: <013c01cc4923$643ffd60$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_9C0DCA209B0C46A5A99FB63FDEF41421nominumcom_" MIME-Version: 1.0 Cc: "John R. Levine" , IPv6 Operations Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for seviceproviders and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 19:03:26 -0000 --_000_9C0DCA209B0C46A5A99FB63FDEF41421nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 23, 2011, at 6:29 AM, t.petch wrote: I think that you have just argued for the abolition of the IETF and IRTF. Having vendor-independent standards has, on occasions, helped the developme= nt of the Internet. On this particular topic, the asrg has been wrestling with t= his issue for a long time, and, as John says, there are no easy solutions. No. The IETF is not in the business of tactical responses to abuse. We = are to some degree in the business of strategic responses, in the sense tha= t if we can design our protocols so that they are hard to abuse, then tacti= cal responses will be less necessary. SMTP is a cat already out of the ba= g, however. For the purposes of the current discussion, it is entirely fa= ir to say that anti-spam vendors will deal with the hard aspects of the fil= tering problem, and for us then to simply talk about the actual problems of= deployment. We can acknowledge that a spam solution is needed, without r= atholing endlessly on what that solution might be. --_000_9C0DCA209B0C46A5A99FB63FDEF41421nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 23, 2011, at 6:29 AM, t.petch wrote:
I think that you have just argued for the abolition of the IETF and IRTF. Having vendor-independent standards has, on occasions, helped the developme= nt of
the Internet.  On this particular topic, the asrg has been wrestling w= ith this
issue for a long time, and, as John says, there are no easy solutions.

No.   The IETF is not in the business of tactical responses to ab= use.   We are to some degree in the business of strategic responses, i= n the sense that if we can design our protocols so that they are hard to ab= use, then tactical responses will be less necessary.   SMTP is a cat already out of the bag, however.   Fo= r the purposes of the current discussion, it is entirely fair to say that a= nti-spam vendors will deal with the hard aspects of the filtering problem, = and for us then to simply talk about the actual problems of deployment.   We can acknowledge that a spam solution is = needed, without ratholing endlessly on what that solution might be.

--_000_9C0DCA209B0C46A5A99FB63FDEF41421nominumcom_-- From joelja@bogus.com Sat Jul 23 13:11:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB04421F8AE6 for ; Sat, 23 Jul 2011 13:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaVMTJoSWzwi for ; Sat, 23 Jul 2011 13:11:08 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6F68D21F846A for ; Sat, 23 Jul 2011 13:11:07 -0700 (PDT) Received: from [130.129.87.16] (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6NKAp56049289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 23 Jul 2011 20:10:54 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6-284686271 From: Joel Jaeggli In-Reply-To: Date: Sat, 23 Jul 2011 16:10:51 -0400 Message-Id: <0B61ECDC-FFD2-4919-88BA-38FB35283A36@bogus.com> References: To: "O'Reirdan, Michael" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 23 Jul 2011 20:10:55 +0000 (UTC) Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 20:11:09 -0000 --Apple-Mail-6-284686271 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Apologies I hake been reading that thread backwards to forwards. these are my own thoughts. headings 5 6 7 are actually subheadings of 4 not new sections in their = own right. The timeline specified seems effectively arbitrary, deployments are in = various stages there are a small number for example that crossed the = threshold 7 (modula the part about turning ipv4 off more than 10 years = ago. likewise even in scenario where the majority of internet connected = mailservers support ipv6 it seems likely that mailservers operate at = scale will maintain A records until the percentage traffic received on = them drops to a negligible percentage. A timeline therefore whether = measured in years or not is only locally significant except perhaps on = very long timescales. The document couples ipv6 email service, with customer ipv6 transport = deployment when really they're fairly decoupled, e.g. from my vantage = point I use the same mailservers regardless of which network to which I = am presently attached and to the extent that some them have AAAA records = for IMAP, MX and submission services I expect those even when my client = is not presently in a location that can use them. likewise I expect = comcast t-mobile google and apples mail services timelines to be = uncoupled from from t-mobile or comcast offering v6 transport to by = devices. On Jul 21, 2011, at 11:21 AM, O'Reirdan, Michael wrote: > Chaps=20 >=20 > I would like to bring to your attention and solicit comments on the = following draft. >=20 > = http://tools.ietf.org/html//draft-oreirdan-rosenwald-ipv6mail-transition-0= 0 >=20 > Thanks >=20 > Mike O'Reirdan >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-6-284686271 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Chaps 

I would like to bring to your attention and solicit comments on the = following draft.


Thanks

Mike O'Reirdan


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

= --Apple-Mail-6-284686271-- From joelja@bogus.com Sat Jul 23 16:25:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C61621F8BFA for ; Sat, 23 Jul 2011 16:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wulek9plSkOe for ; Sat, 23 Jul 2011 16:25:37 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C3EF721F8BEE for ; Sat, 23 Jul 2011 16:25:36 -0700 (PDT) Received: from dhcp-47c2.meeting.ietf.org (dhcp-47c2.meeting.ietf.org [130.129.71.194]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6NNPXUP062100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 23 Jul 2011 23:25:34 GMT (envelope-from joelja@bogus.com) From: Joel Jaeggli Content-Type: multipart/alternative; boundary=Apple-Mail-7-296365894 Date: Sat, 23 Jul 2011 19:25:31 -0400 Message-Id: <9F2D77E9-35B2-417A-9E3C-9AD394E6F07A@bogus.com> To: "v6ops@ietf.org Operations" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 23 Jul 2011 23:25:34 +0000 (UTC) Subject: [v6ops] minute taker and jabber scribe X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 23:25:37 -0000 --Apple-Mail-7-296365894 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii v6ops chairs could use volunteers to supplement either the jabber scribe = or notetaking roles in the . It's your opportunity to contribute to the = overall quality of the meeting materials. See you on Tuesday at 0900 EDT and again on Thursday at 1320 EDT in RM = 205 ABC tuesday and thursday meetings will be streamed here: http://ietf81streaming.dnsalias.net/ietf/ietf803.m3u and the jabber chatroom is: v6ops@jabber.ietf.org/ --Apple-Mail-7-296365894 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii v6ops = chairs could use volunteers to supplement either the jabber scribe or = notetaking roles in the . It's your opportunity to contribute to the = overall quality of the meeting materials.

See you on = Tuesday at 0900 EDT and again on Thursday at 1320 EDT in RM 205 = ABC

tuesday and thursday meetings will be = streamed here:


and = the jabber chatroom is:


=




<= /html>= --Apple-Mail-7-296365894-- From fred@cisco.com Sat Jul 23 20:41:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF67121F8BD2 for ; Sat, 23 Jul 2011 20:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.392 X-Spam-Level: X-Spam-Status: No, score=-103.392 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvxRNHiETpe3 for ; Sat, 23 Jul 2011 20:41:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 29D3521F8BD1 for ; Sat, 23 Jul 2011 20:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1723; q=dns/txt; s=iport; t=1311478865; x=1312688465; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=nrouHfv2xo8Jk1k12ok9DcmYkZdH/gH6V1JVni6KndA=; b=Vz3cE5MT7ErUrsYhAlQ2cPUtSOGYbqUb3LTytCUDvJPT9P00u4SpZtdL u0cxO3nf2OBfHnPlsgRtbIwGwa7WlY9v0YJtNxBc8a5QPoBSM404ndYKg pAzGgFCj8x1JUFogqyS5zzGXB2H9pmTlZYMU7nOS1vRw/8jpsLXcfVNvE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucFACeTK06rRDoH/2dsb2JhbAA1AQEBAQIBFAErPQgFDAxSFD4BEgc3Bw+nI3eIfJ9UnROFYF8EknCFB4t1 X-IronPort-AV: E=Sophos;i="4.67,254,1309737600"; d="scan'208";a="5832482" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-8.cisco.com with ESMTP; 24 Jul 2011 03:41:04 +0000 Received: from Freds-Computer.local (sjc-vpn6-1055.cisco.com [10.21.124.31]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6O3exxR002555; Sun, 24 Jul 2011 03:41:03 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sat, 23 Jul 2011 23:41:03 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Sat, 23 Jul 2011 23:41:03 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <22303AD9-08B5-4768-B4BC-F7721DB76ED9@network-heretics.com> Date: Sat, 23 Jul 2011 19:13:33 -0400 Message-Id: <33289A0F-C202-4AB0-9D36-2D50955ADE4E@cisco.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <22303AD9-08B5-4768-B4BC-F7721DB76ED9@network-heretics.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "John R. Levine" , "v6ops@ietf.org" , Dave Crocker , Joe St Sauveur Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 03:41:05 -0000 On Jul 22, 2011, at 4:24 PM, Keith Moore wrote: > IPv6 and IPv4 are different enough that it's a bit difficult to = anticipate which source-address-based countermeasures will be effective = in IPv6. So it seems a bit silly to say that countermeasure X must be = in place before anyone should accept IPv6 SMTP mail. Of course, = countermeasures based on content analysis should work about as well for = IPv6 as IPv4. The best countermeasures, to my knowledge, are a combination of = reputation (spam tends to come from bots, and bots tend to not be in = one's business-partner's networks) and Bayesian or Bayesian-style = filters (e.g., content-based). The latter, as you note, doesn't need to = depend on source address (although in reality it probably does figure = in); the former does. Of course, spammers will enjoy nesting in places = that use privacy addresses, which for better or worse at the moment = means that Windows machines will be a botmaster target, and is an = argument for MAC-address or DHCP-based schemes. But you and I both know = the obvious solution there; subnets develop reputations, not EIDs. I'll argue that we probably know pretty well how to defend IPv6 = networks. We may not have collected the reputation data for addresses or = prefixes yet, but we know how to do that. We already have the Bayesian = data, modulo the source address. It's largely - as with many things in = IPv6 - a matter of turning things on. As near as I can tell, delaying the start of that process is - as with = anything in which one arbitrarily delays - a matter of delay. The work = has to get done eventually, and delay mostly puts off the beginning - = the work is the same.= From wesley.george@twcable.com Sat Jul 23 21:03:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5BC21F8C0B for ; Sat, 23 Jul 2011 21:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.059 X-Spam-Level: X-Spam-Status: No, score=0.059 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArDvxTduCqbz for ; Sat, 23 Jul 2011 21:03:39 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id C3BF721F8C0A for ; Sat, 23 Jul 2011 21:03:39 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,254,1309752000"; d="scan'208";a="253159834" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 Jul 2011 00:01:48 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Sun, 24 Jul 2011 00:03:39 -0400 From: "George, Wesley" To: Philip Homburg , "John R. Levine" Date: Sun, 24 Jul 2011 00:03:37 -0400 Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AcxJFdrR907YSBJbRruW//GR8KsMmQAnx2Nw Message-ID: <34E4F50CAFA10349A41E0756550084FB0BBE739F@PRVPEXVS04.corp.twcable.com> References: <11072209372672_B93@oregon.uoregon.edu> <20110722211501.GC2304@Space.Net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 04:03:40 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of P= hilip Homburg Sent: Saturday, July 23, 2011 4:52 AM To: John R. Levine Cc: v6ops@ietf.org Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice= providers and other communities >But, v6ops is in my opinion not the right place to discuss anti-spam measu= res. >So, I will leave at at that. Which is sorta why I suggested in my last message (lost in the noise) that = the draft be broken up to deal with the abuse problem as a completely separ= ate issue, because it's clearly clouding the discussion as a single draft. The argument this thread has come to represent demonstrates admirably that = there are plenty of folks who don't see IPv6 email spam/abuse as a big prob= lem and therefore (I think) see value in a draft that covers the other cons= iderations and transition steps to enable IPv6 on a mail server for client = to server and server to server communications over IPv6 transport. It also = demonstrates that there are folks who believe that there is a looming IPv6 = mail abuse/scaling problem that the IETF needs to be considering protocol a= ction to address (and that hopefully some of them will want to help solve i= t). The latter likely does not belong in v6ops, other than some sort of a gap a= nalysis, and even that I'm not totally certain belongs here. The former lik= ely does. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From moore@network-heretics.com Sat Jul 23 21:08:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01ED021F8BDC for ; Sat, 23 Jul 2011 21:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGfE1d9rzMTa for ; Sat, 23 Jul 2011 21:08:51 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6036E21F8BD9 for ; Sat, 23 Jul 2011 21:08:51 -0700 (PDT) Received: from [71.166.174.114] (helo=[10.59.1.76]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Qkpzk-0002Gs-3P; Sun, 24 Jul 2011 00:08:48 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <33289A0F-C202-4AB0-9D36-2D50955ADE4E@cisco.com> Date: Sun, 24 Jul 2011 00:08:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <22303AD9-08B5-4768-B4BC-F7721DB76ED9@network-heretics.com> <33289A0F-C202-4AB0-9D36-2D50955ADE4E@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940e875d797b1f35906a241f0f5ac633d49350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.166.174.114 Cc: "John R. Levine" , "v6ops@ietf.org" , Dave Crocker , Joe St Sauveur Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 04:08:52 -0000 On Jul 23, 2011, at 7:13 PM, Fred Baker wrote: > On Jul 22, 2011, at 4:24 PM, Keith Moore wrote: >=20 >> IPv6 and IPv4 are different enough that it's a bit difficult to = anticipate which source-address-based countermeasures will be effective = in IPv6. So it seems a bit silly to say that countermeasure X must be = in place before anyone should accept IPv6 SMTP mail. Of course, = countermeasures based on content analysis should work about as well for = IPv6 as IPv4. >=20 > The best countermeasures, to my knowledge, are a combination of = reputation (spam tends to come from bots, and bots tend to not be in = one's business-partner's networks) and Bayesian or Bayesian-style = filters (e.g., content-based). The latter, as you note, doesn't need to = depend on source address (although in reality it probably does figure = in); the former does. Of course, spammers will enjoy nesting in places = that use privacy addresses, which for better or worse at the moment = means that Windows machines will be a botmaster target, and is an = argument for MAC-address or DHCP-based schemes. But you and I both know = the obvious solution there; subnets develop reputations, not EIDs. >=20 > I'll argue that we probably know pretty well how to defend IPv6 = networks. We may not have collected the reputation data for addresses or = prefixes yet, but we know how to do that. We already have the Bayesian = data, modulo the source address. It's largely - as with many things in = IPv6 - a matter of turning things on. >=20 > As near as I can tell, delaying the start of that process is - as with = anything in which one arbitrarily delays - a matter of delay. The work = has to get done eventually, and delay mostly puts off the beginning - = the work is the same. I think we disagree about the effectiveness of address-based reputation, = but there's no reason to argue about it. As for delay, I think that network providers that also provide mail = service should think in terms of rolling out IPv6-based mail service in = the same timeframe as they're rolling out their IPv6-based, publicly = accessible, datagram routing service. But they'd probably be wise to = rate-limit the IPv6 email traffic somehow and ramp it up gradually as = they fine-tune their spam filters. The reason I think the dates in the draft are unrealistic is that I = don't see most access providers providing native IPv6 access anywhere = nearly that soon. I'd love to be proven wrong about that, though. Keith From johnl@iecc.com Sat Jul 23 22:49:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A16C21F8B1A for ; Sat, 23 Jul 2011 22:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.982 X-Spam-Level: X-Spam-Status: No, score=-101.982 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s167EJkjFU1C for ; Sat, 23 Jul 2011 22:49:56 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B2B1E21F8B14 for ; Sat, 23 Jul 2011 22:49:55 -0700 (PDT) Received: (qmail 64024 invoked from network); 24 Jul 2011 05:49:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=fa17.4e2bb282.k1107; bh=XllH8Z/OYeWqjQF5HhI5QBVO1C1RhIoMOZp8EY/1LcI=; b=GrVHNfIssEeVzvyr0hp3D0zZIcaNKn54RhpyyMu+CAczIVk1BQEp3nhrXFl1ZjtdvBI3/3RU2CjyC5rDp2Y37cCsXY67gNedHnSTzPsdKB9E6ubhLmElxsBpeY0IWECi6j372IsK6Sl1bHiBUaOsXbgCnGtoLV/qZ4PKsdhGs9Q= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Jul 2011 05:49:32 -0000 Date: 24 Jul 2011 07:49:51 +0200 Message-ID: From: "John R. Levine" To: "Fred Baker" In-Reply-To: <33289A0F-C202-4AB0-9D36-2D50955ADE4E@cisco.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <22303AD9-08B5-4768-B4BC-F7721DB76ED9@network-heretics.com> <33289A0F-C202-4AB0-9D36-2D50955ADE4E@cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Joe St Sauveur , "v6ops@ietf.org" , Keith Moore , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 05:49:56 -0000 > I'll argue that we probably know pretty well how to defend IPv6 networks. Conceptually, sure. But the details are surprisingly difficult once you get into them. As you note, body filtering won't change much, if at all, but using an IP reputation check as a first pass is so much faster that it has to work. That's where the scaling issues come in. The IPv4 address space is small enough that it's practical to keep a reputation database of each address, but in v6 that's hopeless. Even if you aggregate everything to /64, which is a bad idea for various reasons, it's still hopeless. You can aggregate at varying sizes, but now there's the questions both of how the DNSBL decides what sizes to use, and how clients do queries without blowing out DNS caches, a problem I failed to anticipate in RFC 5782. You can ask networks to publish assertions about the way they manage their address space, but you have to be prepared for their answers to be lies if they find that in their short term self-interest, or if they're just incompetent. Many people have noted that the total number of hosts in the world that send any mail that anyone wants is only about 100,000, so it'd be a whole lot more efficient to whitelist those and body filter their mail rather than blacklisting the rest, if there were some way to manage whitelists that won't degenerate into a pay-to-mail shakedown. These scaling and management issues are somewhat similar to the IPv6 rDNS problem which was discussed by some guys from big ISPs last year in draft-howard-isp-ip6rdns-04.txt. All these problems are clearly soluble, but at this point we really have no idea what IPv6 traffic will look like once there's enough of it to matter, and the amount of traffic will spike painfully when one or two botnets start sending to v6. So probably the best thing to say about mail traffic management is to put in a placeholder and note that anyone who runs a mail system MUST be prepared to update and adapt what they do as the world figures it out. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From moore@network-heretics.com Sat Jul 23 23:01:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F10A21F84F7 for ; Sat, 23 Jul 2011 23:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2r8-EH+hbBD for ; Sat, 23 Jul 2011 23:01:06 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8649A21F86EA for ; Sat, 23 Jul 2011 23:01:06 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 6C54E20A18; Sun, 24 Jul 2011 02:01:05 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 24 Jul 2011 02:01:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=9Fe j5L/RQjEWOjcW72jfbLKT7Oc=; b=pz7e2rK4HM3gpUx8N5TFIb/7Ay5SUl1bsCc hmhGGNWGTTwp1byAGeo2Cjrex6ySdiXvUSHxdNydC2Sfgl/oRc9VeHWYa3bZoLb6 WOZC3Y0N+GGQQMKwrqW/tZBA2DEcSiNn+HTW1NTE2T58TRivx2wfMuBgFEwSQdwA 15AFuZTU= X-Sasl-enc: TVF1OJ71vhho9oisJ2ULvgQZ459RwT0XoAyHnOjrPFNG 1311487263 Received: from [10.59.1.76] (static-71-166-174-114.washdc.east.verizon.net [71.166.174.114]) by mail.messagingengine.com (Postfix) with ESMTPSA id D9359453BF5; Sun, 24 Jul 2011 02:01:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6-320096407 From: Keith Moore In-Reply-To: Date: Sun, 24 Jul 2011 02:01:01 -0400 Message-Id: <81E99EA4-F09A-40BB-8104-38ADA22741F7@network-heretics.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <22303AD9-08B5-4768-B4BC-F7721DB76ED9@network-heretics.com> <33289A0F-C202-4AB0-9D36-2D50955ADE4E@cisco.com> To: "John R. Levine" X-Mailer: Apple Mail (2.1084) Cc: Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 06:01:07 -0000 --Apple-Mail-6-320096407 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 24, 2011, at 1:49 AM, John R. Levine wrote: >=20 > All these problems are clearly soluble, but at this point we really = have no idea what IPv6 traffic will look like once there's enough of it = to matter, and the amount of traffic will spike painfully when one or = two botnets start sending to v6. So probably the best thing to say = about mail traffic management is to put in a placeholder and note that = anyone who runs a mail system MUST be prepared to update and adapt what = they do as the world figures it out. Sounds pretty vague to me. Is it even worth saying that? Does it = provide any useful instruction to the reader? The only thing that seems clear at this point is that having a sudden = flood of IPv6 mail isn't in anyone's interest except perhaps the = spammers'. Mail service operators need to start dealing with = SMTP-over-IPv6 soon so that they'll have experience with it, but they = also need to be able to throttle the flow of IPv6 mail so that, even if = there is a flood, there's time to learn what works well and what = doesn't. =20 I'm not sure what the best way to do this is - maybe have DNS servers = randomly return MX records with v6 addresses (or not) with a = configurable probability? Everything else seems like it would have the = undesirable side-effect of delaying IPv4 mail traffic. Keith --Apple-Mail-6-320096407 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

All these = problems are clearly soluble, but at this point we really have no idea = what IPv6 traffic will look like once there's enough of it to matter, = and the amount of traffic will spike painfully when one or two botnets = start sending to v6.  So probably the best thing to say about mail = traffic management is to put in a placeholder and note that anyone who = runs a mail system MUST be prepared to update and adapt what they do as = the world figures it out.

Sounds = pretty vague to me.  Is it even worth saying that?  Does it = provide any useful instruction to the = reader?

The only thing that seems clear at this = point is that having a sudden flood of IPv6 mail isn't in anyone's = interest except perhaps the spammers'.   Mail service operators = need to start dealing with SMTP-over-IPv6 soon so that they'll have = experience with it, but they also need to be able to throttle the flow = of IPv6 mail so that, even if there is a flood, there's time to learn = what works well and what doesn't.   =  

I'm not sure what the best way to do = this is - maybe have DNS servers randomly return MX records with v6 = addresses (or not) with a configurable probability?   Everything = else seems like it would have the undesirable side-effect of delaying = IPv4 mail = traffic.

Keith

= --Apple-Mail-6-320096407-- From denghui02@gmail.com Sun Jul 24 01:25:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4D321F8B3D for ; Sun, 24 Jul 2011 01:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.244 X-Spam-Level: X-Spam-Status: No, score=-103.244 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2-rXGKAthYx for ; Sun, 24 Jul 2011 01:25:57 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 059AD21F84E1 for ; Sun, 24 Jul 2011 01:25:56 -0700 (PDT) Received: by wwe5 with SMTP id 5so2208719wwe.13 for ; Sun, 24 Jul 2011 01:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hm5uQrKyjHefnlDiVhmdVCvWZb6zSxaI4mDdtM90rTg=; b=m7bCtkGZbONRouGN+0G6cF9+DfToJDvNIGixZupi8Gipdfn69oabN9oommYNlsJIGQ ycosYJtEUSmxqyh9uOM1NEyHGuEJHvR2G3EXdj2mRWbmOMCbwIBKny7K21Mh9yz8Nsdd 2E/wPZ7quH57Ux/i1X6YrBuVpYGPZNoX+tjXI= MIME-Version: 1.0 Received: by 10.216.140.141 with SMTP id e13mr2602006wej.85.1311495954459; Sun, 24 Jul 2011 01:25:54 -0700 (PDT) Received: by 10.216.73.17 with HTTP; Sun, 24 Jul 2011 01:25:54 -0700 (PDT) In-Reply-To: References: Date: Sun, 24 Jul 2011 04:25:54 -0400 Message-ID: From: Hui Deng To: Joel Jaeggli Content-Type: multipart/alternative; boundary=0016e6dab3497d6b2b04a8cc7285 Cc: v6ops@ietf.org Subject: Re: [v6ops] 1 comment on draft-jjmb-v6ops-comcast-ipv6-experiences-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 08:25:58 -0000 --0016e6dab3497d6b2b04a8cc7285 Content-Type: text/plain; charset=ISO-8859-1 Joel, If operator provide the complex service to the user, normally it need multiple options for different things, but if you are providing simple service, dual stack is quite straightforward. -Hui 2011/7/23 Joel Jaeggli > > On Jul 22, 2011, at 4:14 PM, Hui Deng wrote: > > > Hello authors > > > > This work is a good reference for the operator, thanks for writing this > draft, > > has gathered the useful information, appreciate the work. > > > > Just one clarification, the reason of recommdating dual stack is because > Comcast is mainly providing CDN based IPTV like service? > > The question seems really odd? Why wouldn't native deployment be the > preferable model? > > joel > > > Best regards, > > > > -Hui > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > --0016e6dab3497d6b2b04a8cc7285 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joel,
=A0
If operator provide the complex service to the user, normally it need = multiple options for different things, but if you are providing simple serv= ice, dual stack is quite straightforward.
=A0
-Hui
=A0


=A0
2011/7/23 Joel Jaeggli <joelja@bogus.com>

On Jul 22, 2011, at 4:14 PM, Hui Deng wrote:

&= gt; Hello authors
>
> This work is a good reference for the ope= rator, thanks for writing this draft,
> has gathered the useful infor= mation, appreciate the work.
>
> Just one clarification, the reason of recommdating dual stack = is because Comcast is mainly providing CDN based IPTV like service?

=
The question seems really odd? Why wouldn't native deployme= nt be the preferable model?

joel

> Best regards,
>
> -Hui
>
> ___= ____________________________________________
> v6ops mailing list
= > v6ops@ietf.org
> https://= www.ietf.org/mailman/listinfo/v6ops


--0016e6dab3497d6b2b04a8cc7285-- From denghui02@gmail.com Sun Jul 24 01:30:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF1921F8B49 for ; Sun, 24 Jul 2011 01:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2AoCpQeQ501 for ; Sun, 24 Jul 2011 01:30:37 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 15D7821F8B48 for ; Sun, 24 Jul 2011 01:30:36 -0700 (PDT) Received: by wyj26 with SMTP id 26so2552936wyj.31 for ; Sun, 24 Jul 2011 01:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+QmJvt/htlPBQDuCBfv+++3BiychX5Jghvn+DPqopJ0=; b=KggwFGqPnJS2CestpfVyeOZV8xUia0nLfyQqKf/a/eBikiPXuCjG8ciVA/MthUP9Ag IQEJ7RbKhk2WbGTHh+vpqaH8mruxr+scgCdEoP/gmiwfZvLQjs9R8q07R3uYE4OhO4Z6 mH2LawBrwbU4CYHCD2NiZyVhG4aB+/cBHFKXs= MIME-Version: 1.0 Received: by 10.216.162.203 with SMTP id y53mr682539wek.70.1311496235940; Sun, 24 Jul 2011 01:30:35 -0700 (PDT) Received: by 10.216.73.17 with HTTP; Sun, 24 Jul 2011 01:30:35 -0700 (PDT) In-Reply-To: References: Date: Sun, 24 Jul 2011 04:30:35 -0400 Message-ID: From: Hui Deng To: "Brzozowski, John" Content-Type: multipart/alternative; boundary=001636416d55447bef04a8cc83db Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 1 comment on draft-jjmb-v6ops-comcast-ipv6-experiences-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 08:30:38 -0000 --001636416d55447bef04a8cc83db Content-Type: text/plain; charset=ISO-8859-1 John, Thanks for your clarification. If so, I guess that you have sufficient public IPv4 addresses for broadband access? Best regards, -Hui 2011/7/23 Brzozowski, John > Hui, > > At this time native dual stack reference mostly pertains to broadband > Internet. We did enable some of our content (web sites) using a variety > of techniques including native dual stack. > > There is no reference to IPTV in the document. > > HTH, > > John > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski@cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > > > > > On 7/22/11 7:14 PM, "Hui Deng" wrote: > > >Hello authors > >This work is a good reference for the operator, thanks for writing this > >draft, > >has gathered the useful information, appreciate the work. > >Just one clarification, the reason of recommdating dual stack is because > >Comcast is mainly providing CDN based IPTV like service? > >Best regards, > >-Hui > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops > > --001636416d55447bef04a8cc83db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
John,
=A0
Thanks for your clarification.
If so, I guess that you have sufficient public IPv4 addresses for broa= dband access?
=A0
Best regards,
=A0
-Hui

2011/7/23 Brzozowski, John <= ;John_Brzozowski@cable= .comcast.com>
Hui,

At this time native = dual stack reference mostly pertains to broadband
Internet. =A0We did en= able some of our content (web sites) using a variety
of techniques including native dual stack.

There is no reference to = IPTV in the document.

HTH,

John
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
e) ma= ilto:john_brzozowski@c= able.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D




On 7/22/11 7:14 PM, "Hui Deng" = <denghui02@gmail.com> wrot= e:

>Hello authors
>This work is a good reference for the op= erator, thanks for writing this
>draft,
>has gathered the useful information, appreciate the work.=
>Just one clarification, the reason of recommdating dual stack is be= cause
>Comcast is mainly providing CDN based IPTV like service?
>Best regards,
>-Hui
>_______________________________________________
&g= t;v6ops mailing list
>v6ops@ietf.or= g
>https://www.ietf.org/mailman/listinfo/v6ops


--001636416d55447bef04a8cc83db-- From pch-b2B3A6689@u-1.phicoh.com Sun Jul 24 03:00:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F53E21F8B18 for ; Sun, 24 Jul 2011 03:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.535 X-Spam-Level: X-Spam-Status: No, score=-4.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVp7son6xYXL for ; Sun, 24 Jul 2011 03:00:51 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED8F21F8B16 for ; Sun, 24 Jul 2011 03:00:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QkvUI-0001hwC; Sun, 24 Jul 2011 12:00:42 +0200 Message-Id: To: "Dan Wing" From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: Your message of "Mon, 11 Jul 2011 09:15:03 -0700 ." <20110711161503.10931.6058.idtracker@ietfa.amsl.com> <04fc01cc4815$753cbe50$5fb63af0$@com> In-reply-to: Your message of "Thu, 21 Jul 2011 19:17:08 -0700 ." <04fc01cc4815$753cbe50$5fb63af0$@com> Date: Sun, 24 Jul 2011 12:00:38 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 10:00:52 -0000 In your letter dated Thu, 21 Jul 2011 19:17:08 -0700 you wrote: >> Section 4.1 >> >> In my opinion the MUST is too strong. I think a SHOULD is more than >> enough. >> But more importantly, Section 4.2 qualifies that MUST. I think that >> either >> 4.1 should contain a description of when MUST can be violated or it >> should >> explicitly forward reference 4.2. In my opinion it is important that >> requirements are as self-contained as possible. > >You're referring to: > > Happy Eyeballs implementations MUST follow the host's address > preference policy or, if that policy is unknown, implementations MUST > prefer IPv6 over IPv4. > > Justification: This reduces load on stateful IPv4 middleboxes > (NAT and firewalls) and reduces IPv4 address sharing contention. > >and I guess you're referring to that first MUST ("MUST follow the host's >address preference policy"). Yes. >As for MUST versus SHOULD, how is this: > > A Happy Eyeballs implementations MUST follow the host's > address preference policy, unless the conditions > in Section 4.2 apply). If the host's policy is unknown or > not attainable, implementations MUST prefer IPv6 over IPv4. > >I clarified 4.2 to better describe the implementation as stateful >(that is, the implementation notices that IPv6 is always failing). Yes, that is fine. >> Section 4.2 >> >> In think that Section 4.2 should explain what 'failed' means. > >Is this sufficient? > > After making a connection attempt on the preferred address > family (e.g., IPv6), and failing to establish a connection > within a certain time period, a Happy Eyeballs implementation > will decide to initiate a second connection attempt using the > other address family (e.g., IPv4). In that case, I think you need some text about what 'a certain time period' is. For example, that an implementation may have a static value, or that it may determine this value dynamically by observing IPv4 and IPv6 connect times. >> Obviously, >> if a protocol doesn't work at all, it should be considered failed. But >> I think >> that in many cases, a tunnel that always adds 200 ms latency can be >> considered >> as failing as well. >> >> (my own algorithm just connects to whatever works best, without trying >> to declare something as failed). > >I would classify the Chrome and Firefox algorithms as also connecting >to what 'works best', giving IPv6 a ~200ms head start. I don't think this particular algorithm connects to what works best. It just limits the damage that can be done by a failing IPv6 link to 200ms of additional latency. >> Section 5.5 >> >> I quickly read the (by now expired) draft on Same Origin Policy and I >> didn't >> find anything that directly deal with IP addresses. > >The Wiki page is a little better, and explains that there is no >canonical definition of Same Origin Policy. A better reference >might be "to avoid DNS rebinding attacks", which is what really >encourages web browsers to sandbox their traffic to the same IP >address without regard to DNS TTLs or anything else. But, I >imagine that could be considered part of the "same origin policy". > >I'm not a browser person, so guidance for a better citation is >certainly welcome. I'd say that unless there is a standard that defines the Same Origin Policy, Happy Eyeballs should not have an normative text regarding it. Of course, it doesn't do any harm to point out to readers that Happy Eyeballs may conclict with this policy. I guess that in practice, if you already know which address to are going to connect to (because the policy only allows you to connect to the same address as before) there will be no need for HE anyhow. >> 1) >> >> Playing with my own HE implementation I arrived a the following >> prototype for >> the library function that provides it: >> >> int tcp_connect_to_name(char *hostname, char *portname, int *gai_errp, >> struct timeval *tv); >> >> I think application portability will be enhanced if HE implementations >> provide >> similar features. There is also no need for OS implementors to all >> reinvent >> the wheel. > >Mark Andrews had a different prototype. I don't have any preference, >of course. But I want to finish this I-D. Easy way forward is to list both for the time being and try to get people to express a preference. I don't care so much which one gets picked, as long as we do what we can to get one function standardized across platforms. >> 2) >> >> In practice, a DNS RR set may contain more than just one IPv4 and one >> IPv6 >> address. It may be a good idea to add some discussion about this. > >
>It is possible that an DNS query for an A or AAAA resource >record will return more than one A or AAAA address. When this >occurs, it is RECOMMENDED that a Happy Eyeballs implementation >order the responses following the host's address preference >policy and then try the first address. If that fails after >a certain time, the next address SHOULD be the IPv4 address. > >This means that a Happy Eyeballs implementation will not >try other IPv6 addresses that are returned; effecitively, the >Happy Eyeballs implementation will behave as if only one >address was returned. >
This is not good. Eventually, a host has to try all addresses in a RR set. So after the first IPv6 address and the first IPv4 address it has to try all other addresses, the order doesn't really matter, so the order returned by getaddrinfo is probably best. >> 3) >> >> In practice, local IPv6 connections may still work while the link to >> the >> outside world is broken. What does 'failed' mean in this context? > > If connections using the preferred address family are successful, >the > preferred address family SHOULD be used for subsequent > connections. I guess that if an implementation notices that some (local) connections succeed but others don't, it can violate the SHOULD. >> 4) >> >> What happens if I take the same algorithm as Google used in Chrome but >> I >> set the timer to 30 ms instead of 300? Is that considered an acceptable >> HE >> implementation according to this draft? > > >Yes. The normative text does not define the duration of the delay >between trying IPv6 and trying IPv4. In fact, you could try them both >at the same time -- so long as the IPv6 one is "preferred" (by some >definition of preferred), and the network is not thrashed with >simultaneous connections. Complex algorithms, such as what we >had earlier in draft-ietf-v6ops-happy-eyeballs, achieve this. As >do simple algorithms such as what is in Chrome and Firefox. I don't think it would good idea if a popular product would start with IPv6 and then connects to IPv4 10ms later. That effectively double the connect load on content, keep a huge load on any kind of CGN, and would effectively make it impossible to phase out IPv4 because there will all be a huge number of connects over IPv4. So I think that ideally, the document should give some performance requirements. I.e. a HE implementation should connect to just one address in over xx% of the cases, with xx close to 100. That may not be feasable. So some text that the implementor of HE should ensure that the parameters used are conservative enough that in most cases only one address is connected to. Or something like that. >> 5) >> >> This draft sometimes talks about an entire address family (for example >> Section 4.2) but in other places (Section 4) it's about addresses for >> an >> individual host. I think this should be make more clear in Sections 4.1 >> and 4.2. > >I don't know how to best fix all of that, especially if we consider >that a host could have an IPv4-mapped IPv6 address in DNS (ugly, but >it happens) as well as a real IPv4 address. That is, I don't know >if it's best to talk about "address family" or "address" throughout >the document. Ultimately, the connect happens over IPv4 or IPv6. So given the level of detail in the draft, address family (or maybe protocol) would be best, except where you talk about individual addresses returned by getaddrinfo, there it would an address that belong to a certain address family. From gert@space.net Sun Jul 24 05:19:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6A321F8B01 for ; Sun, 24 Jul 2011 05:19:36 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7ilwqOmeS07 for ; Sun, 24 Jul 2011 05:19:36 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD5221F8AFF for ; Sun, 24 Jul 2011 05:19:29 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id B2CD9F8535 for ; Sun, 24 Jul 2011 14:19:28 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8AD69F8562 for ; Sun, 24 Jul 2011 14:19:28 +0200 (CEST) Received: (qmail 18113 invoked by uid 1007); 24 Jul 2011 14:19:28 +0200 Date: Sun, 24 Jul 2011 14:19:28 +0200 From: Gert Doering To: Keith Moore Message-ID: <20110724121928.GF72014@Space.Net> References: <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <22303AD9-08B5-4768-B4BC-F7721DB76ED9@network-heretics.com> <33289A0F-C202-4AB0-9D36-2D50955ADE4E@cisco.com> <81E99EA4-F09A-40BB-8104-38ADA22741F7@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81E99EA4-F09A-40BB-8104-38ADA22741F7@network-heretics.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "John R. Levine" , Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 12:19:36 -0000 Hi, On Sun, Jul 24, 2011 at 02:01:01AM -0400, Keith Moore wrote: > I'm not sure what the best way to do this is - maybe have DNS > servers randomly return MX records with v6 addresses (or not) with > a configurable probability? Everything else seems like it would > have the undesirable side-effect of delaying IPv4 mail traffic. Please explain why returning a MX records with v6+v4 address will delay IPv4 mail traffic. 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 (89) 32356-444 USt-IdNr.: DE813185279 From moore@network-heretics.com Sun Jul 24 05:42:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD4021F86D0 for ; Sun, 24 Jul 2011 05:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2C8stEnIaBM for ; Sun, 24 Jul 2011 05:42:26 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id A4EDC21F8698 for ; Sun, 24 Jul 2011 05:42:26 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 4556620D61; Sun, 24 Jul 2011 08:42:26 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 24 Jul 2011 08:42:26 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:message-id:from:to:cc :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=GTzCOUFvck5H92O7fFMm+94AaEE=; b=k6rdULGzrGtygD6jkyb/TWyIr1a5 9RXWOERKV9FGjZKYlM3VX7SXlslDElF53kVjWhYXndnGUJieNJNMsRKCB7v3nDL3 rMNn0t7gMBlyLA3yMAIHSmZsjyezjR5rYuW+1+Cb0WLjtnvUBmVx3zUPWsz8Gyed CKV/WJw1+aaDc0I= X-Sasl-enc: HLIWz6/XXP2iZXDIfUvJSP63LaRxp75jaXsd4EVwEhkh 1311511345 Received: from 10.205.128.25 (unknown [209.226.201.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 6DDC1412EE9; Sun, 24 Jul 2011 08:42:25 -0400 (EDT) Date: Sun, 24 Jul 2011 08:42:22 -0400 Message-ID: From: Keith Moore To: Gert Doering MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: "John R. Levine" , Joe St Sauveur , v6ops@ietf.org, Dave Crocker Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 12:42:27 -0000 SWYgeW91J3JlIHJhdGUgbGltaXRpbmcgSVB2NiBtYWlsIGF0IHRoZSBTTVRQIGxldmVsLCBwcmVz dW1hYmx5IHlvdSdyZSBnb2luZyB0byByZWplY3Qgc29tZSBJUHY2IFNNVFAgY29ubmVjdGlvbnMg c28gdGhhdCB0aGV5J2xsIGZhaWwgb3ZlciB0byBhbiBNWCB0aGF0IG9ubHkgYWNjZXB0cyBJUHY0 LiAgVGhhdCBpbnRyb2R1Y2VzIGEgZGVsYXkgdGhhdCBpc24ndCB1bmRlciBjb250cm9sIG9mIHRo ZSBzZXJ2ZXIuICBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgeW91IGxpbWl0IGhvdyBvZnRlbiB5b3Ug cmV0dXJuIE1YIHJlY29yZHMgdGhhdCBoYXZlIGRvbWFpbnMgdGhhdCBoYXZlIEFBQUEgcmVjb3Jk cywgdGhhdCBkb2Vzbid0IGRlbGF5IElQdjQgbWFpbCBhdCBhbGwuCgpHZXJ0IERvZXJpbmcgPGdl cnRAc3BhY2UubmV0PiB3cm90ZToKCj5IaSwKPgo+T24gU3VuLCBKdWwgMjQsIDIwMTEgYXQgMDI6 MDE6MDFBTSAtMDQwMCwgS2VpdGggTW9vcmUgd3JvdGU6Cj4+IEknbSBub3Qgc3VyZSB3aGF0IHRo ZSBiZXN0IHdheSB0byBkbyB0aGlzIGlzIC0gbWF5YmUgaGF2ZSBETlMKPj4gc2VydmVycyByYW5k b21seSByZXR1cm4gTVggcmVjb3JkcyB3aXRoIHY2IGFkZHJlc3NlcyAob3Igbm90KSB3aXRoCj4+ IGEgY29uZmlndXJhYmxlIHByb2JhYmlsaXR5PyAgIEV2ZXJ5dGhpbmcgZWxzZSBzZWVtcyBsaWtl IGl0IHdvdWxkCj4+IGhhdmUgdGhlIHVuZGVzaXJhYmxlIHNpZGUtZWZmZWN0IG9mIGRlbGF5aW5n IElQdjQgbWFpbCB0cmFmZmljLgo+Cj5QbGVhc2UgZXhwbGFpbiB3aHkgcmV0dXJuaW5nIGEgTVgg cmVjb3JkcyB3aXRoIHY2K3Y0IGFkZHJlc3Mgd2lsbAo+ZGVsYXkgSVB2NCBtYWlsIHRyYWZmaWMu Cj4KPkdlcnQgRG9lcmluZwo+ICAgICAgICAtLSBOZXRNYXN0ZXIKPi0tIAo+aGF2ZSB5b3UgZW5h YmxlZCBJUHY2IG9uIHNvbWV0aGluZyB0b2RheS4uLj8KPgo+U3BhY2VOZXQgQUcgICAgICAgICAg ICAgICAgICAgICAgICBWb3JzdGFuZDogU2ViYXN0aWFuIHYuIEJvbWhhcmQKPkpvc2VwaC1Eb2xs aW5nZXItQm9nZW4gMTQgICAgICAgICAgQXVmc2ljaHRzcmF0c3ZvcnMuOiBBLiBHcnVuZG5lci1D dWxlbWFubgo+RC04MDgwNyBNdWVuY2hlbiAgICAgICAgICAgICAgICAgICBIUkI6IDEzNjA1NSAo QUcgTXVlbmNoZW4pCj5UZWw6ICs0OSAoODkpIDMyMzU2LTQ0NCAgICAgICAgICAgIFVTdC1JZE5y LjogREU4MTMxODUyNzkK From joelja@bogus.com Sun Jul 24 06:45:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F7521F8AB8 for ; Sun, 24 Jul 2011 06:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0ZhzRwLFaHS for ; Sun, 24 Jul 2011 06:45:37 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6934D21F8A97 for ; Sun, 24 Jul 2011 06:45:37 -0700 (PDT) Received: from [130.129.87.16] (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6ODjUJ4018936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 24 Jul 2011 13:45:33 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-9-347964931 From: Joel Jaeggli In-Reply-To: Date: Sun, 24 Jul 2011 09:45:30 -0400 Message-Id: <949A590F-44E2-4418-B216-4E580EC16C64@bogus.com> References: To: Hui Deng X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 24 Jul 2011 13:45:33 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] 1 comment on draft-jjmb-v6ops-comcast-ipv6-experiences-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 13:45:38 -0000 --Apple-Mail-9-347964931 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 24, 2011, at 4:25 AM, Hui Deng wrote: > Joel, > =20 > If operator provide the complex service to the user, normally it need = multiple options for different things, but if you are providing simple = service, dual stack is quite straightforward. I still don't understand. you seem to think that native ipv6 service is = somehow problematic. If that is is case case, Why, and what do you = recommend as the most appropriate model? > =20 > -Hui > =20 >=20 >=20 > =20 > 2011/7/23 Joel Jaeggli >=20 > On Jul 22, 2011, at 4:14 PM, Hui Deng wrote: >=20 > > Hello authors > > > > This work is a good reference for the operator, thanks for writing = this draft, > > has gathered the useful information, appreciate the work. > > > > Just one clarification, the reason of recommdating dual stack is = because Comcast is mainly providing CDN based IPTV like service? >=20 > The question seems really odd? Why wouldn't native deployment be the = preferable model? >=20 > joel >=20 > > Best regards, > > > > -Hui > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 --Apple-Mail-9-347964931 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 24, 2011, at 4:25 AM, Hui Deng wrote:

Joel,
 
If operator provide the complex service to the user, normally it need multiple options for different things, but if you are providing simple service, dual stack is quite straightforward.

I still don't understand. you seem to think that native ipv6 service is somehow problematic. If that is is case case, Why, and what do you recommend as the most appropriate model?


 
-Hui
 


 
2011/7/23 Joel Jaeggli <joelja@bogus.com>

On Jul 22, 2011, at 4:14 PM, Hui Deng wrote:

> Hello authors
>
> This work is a good reference for the operator, thanks for writing this draft,
> has gathered the useful information, appreciate the work.
>
> Just one clarification, the reason of recommdating dual stack is because Comcast is mainly providing CDN based IPTV like service?

The question seems really odd? Why wouldn't native deployment be the preferable model?

joel

> Best regards,
>
> -Hui
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



--Apple-Mail-9-347964931-- From joelja@bogus.com Sun Jul 24 06:47:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B28421F84F0 for ; Sun, 24 Jul 2011 06:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.507 X-Spam-Level: X-Spam-Status: No, score=-101.507 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96Llbcd9GdmA for ; Sun, 24 Jul 2011 06:46:59 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3013421F8567 for ; Sun, 24 Jul 2011 06:46:40 -0700 (PDT) Received: from [130.129.87.16] (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6ODjUJ5018936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 24 Jul 2011 13:46:29 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Sun, 24 Jul 2011 09:46:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D479183-2D7D-4B6B-A24E-BA76F9C64EC1@bogus.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <22303AD9-08B5-4768-B4BC-F7721DB76ED9@network-heretics.com> <33289A0F-C202-4AB0-9D36-2D50955ADE4E@cisco.com> To: "John R. Levine" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 24 Jul 2011 13:46:30 +0000 (UTC) Cc: Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker , Keith Moore Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 13:47:00 -0000 On Jul 24, 2011, at 1:49 AM, John R. Levine wrote: >> I'll argue that we probably know pretty well how to defend IPv6 = networks. >=20 > Conceptually, sure. But the details are surprisingly difficult once = you get into them. As you note, body filtering won't change much, if at = all, but using an IP reputation check as a first pass is so much faster = that it has to work. That's where the scaling issues come in. The IPv4 = address space is small enough that it's practical to keep a reputation = database of each address, but in v6 that's hopeless. Even if you = aggregate everything to /64, which is a bad idea for various reasons, = it's still hopeless. You can aggregate at varying sizes, but now there's = the questions both of how the DNSBL decides what sizes to use, and how = clients do queries without blowing out DNS caches, a problem I failed to = anticipate in RFC 5782. You can ask networks to publish assertions = about the way they manage their address space, but you have to be = prepared for their answers to be lies if they find that in their short = term self-interest, or if they're just incompetent. I've been using milter greylist with ipv6 support for a couple of years, = autowhitelisting is fairly effective for capturing the ipv6 sources that = I expect to receive mail from (just as it does in ipv4) and I don't = expect that to change much, if a sender uses a different source address = for each connection they're never going to get whitelisted. > Many people have noted that the total number of hosts in the world = that send any mail that anyone wants is only about 100,000, so it'd be a = whole lot more efficient to whitelist those and body filter their mail = rather than blacklisting the rest, if there were some way to manage = whitelists that won't degenerate into a pay-to-mail shakedown. >=20 > These scaling and management issues are somewhat similar to the IPv6 = rDNS problem which was discussed by some guys from big ISPs last year in = draft-howard-isp-ip6rdns-04.txt. >=20 > All these problems are clearly soluble, but at this point we really = have no idea what IPv6 traffic will look like once there's enough of it = to matter, and the amount of traffic will spike painfully when one or = two botnets start sending to v6. So probably the best thing to say = about mail traffic management is to put in a placeholder and note that = anyone who runs a mail system MUST be prepared to update and adapt what = they do as the world figures it out. >=20 > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for = Dummies", > Please consider the environment before reading this e-mail. = http://jl.ly > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From johnl@iecc.com Sun Jul 24 14:23:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E4F21F85B2 for ; Sun, 24 Jul 2011 14:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al2AFXUEsH8X for ; Sun, 24 Jul 2011 14:23:49 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA5F21F8559 for ; Sun, 24 Jul 2011 14:23:48 -0700 (PDT) Received: (qmail 70232 invoked from network); 24 Jul 2011 21:23:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=11257.4e2c8d63.k1107; bh=fR8Ll1nvGK38+RU2Tg6Pt9lOOE88z/B0ZI52UXX/LKs=; b=rPmNw29VNANe0rG0K0W6ALQEkXW6tG8araupxd+HDOLCtu1KrzVqhf6MBtnrXIi51DyqbtCM5WfdWbyTf440xa7H//1ufG2aFyTtE/EFPNMSTQeVLcfvDse89h4Bh8hptME6alvut1hr8C+6VIvLMy3l3T6PrE0ZdZPknyk3KXc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Jul 2011 21:23:25 -0000 Date: 24 Jul 2011 23:23:44 +0200 Message-ID: From: "John R. Levine" To: "Joel Jaeggli" In-Reply-To: <8D479183-2D7D-4B6B-A24E-BA76F9C64EC1@bogus.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <22303AD9-08B5-4768-B4BC-F7721DB76ED9@network-heretics.com> <33289A0F-C202-4AB0-9D36-2D50955ADE4E@cisco.com> <8D479183-2D7D-4B6B-A24E-BA76F9C64EC1@bogus.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Joe St Sauveur , "v6ops@ietf.org" , Dave Crocker , Keith Moore Subject: Re: [v6ops] v6 mail management techniques X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 21:23:49 -0000 > I've been using milter greylist with ipv6 support for a couple of years, autowhitelisting is fairly effective for capturing the ipv6 sources that I expect to receive mail from (just as it does in ipv4) and I don't expect that to change much, if a sender uses a different source address for each connection they're never going to get whitelisted. I haven't updated my greylister to do v6 yet (not enough traffic to bother) but that doesn't surprise me a bit. Greylisting remains a remarkably efficient way to make v4 botnet traffic go away, even though the bad guys could easily defeat it if they wanted to. I was thinking about shared v6 client lists, though, so each little host doesn't have to go through the same slow learning process. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From newbery@gmail.com Sun Jul 24 21:05:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4425211E8081 for ; Sun, 24 Jul 2011 21:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoYiAo7Ig+fC for ; Sun, 24 Jul 2011 21:05:49 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8041011E8080 for ; Sun, 24 Jul 2011 21:05:49 -0700 (PDT) Received: by vws12 with SMTP id 12so3402724vws.31 for ; Sun, 24 Jul 2011 21:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=50GTOkq4xdj1ly28syNOkp7MO4IbhfSoj9qaZLO0AjA=; b=lLfmW/u+ONYOoQtrV6tA2/ynLb3aUshobrf7+nS/nj218Aw6iLnrNaSn/Jp5nCj6C4 JXQZpsFntO+QvMse1QPF/S9kXBBNblFQeqg802i4b9wrl6FID52t5BAdO7APe22wLU+G KHthGGYx7tEq9gy4pnBLOKdqgLC9xyXY8MzIQ= Received: by 10.52.182.195 with SMTP id eg3mr3466626vdc.527.1311566443249; Sun, 24 Jul 2011 21:00:43 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id dh9sm2472273vdc.34.2011.07.24.21.00.40 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jul 2011 21:00:42 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1-399267425; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 25 Jul 2011 16:00:26 +1200 In-Reply-To: <5C15E073-2764-4BFF-ADB0-E8939D58917F@network-heretics.com> To: "v6ops@ietf.org WG" References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <5C15E073-2764-4BFF-ADB0-E8939D58917F@network-heretics.com> Message-Id: X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 04:05:50 -0000 --Apple-Mail-1-399267425 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23/07/2011, at 5:32 AM, Keith Moore wrote: > On Jul 22, 2011, at 11:59 AM, Fred Baker wrote: >=20 >> On Jul 22, 2011, at 8:20 AM, Gert Doering wrote: >>=20 >>> You don't need universal availability on the last DSL line to have = IPv6 *on servers*.=20 >>=20 >> and by the way, the entire series of MUA/MTA and MTA/MTA links don't = have to have IPv6 for it to be used on some of them. If one end user is = IPv6-only, the other is IPv4-only, and at least one MTA in between is = dual, nobody should notice an issue. >>=20 >> My initial comment to Michael, when he pointed the draft out to me, = was that email seems like the poster child of an easy application to add = IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support it = already and the current OS's support IPv6. The primary thing preventing = mail/IPv6 is network IPv6 deployment, which is in progress. >=20 > I guess my view is sort of the opposite - there's really little point = to upgrading mail to use IPv6 until most of the net has IPv6 access. [ignoring for the moment the ongoing discussion on spam and *-lists] You need up upgrade mail to use IPv6 as soon as * you have customers that only have IPv6 transport * there is any significant amount of traffic that is IPv6 only It isn't that day far in the future when most of the world is IPv6 that = matters; it's that day that is almost upon us now, when there is stuff = you are missing because OTHER parts of the Internet can't---or = won't---speak IPv4.= --Apple-Mail-1-399267425 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwp7azANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTA3MTkwNzM5MjBaFw0x MjAxMTUwNzM5MjBaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQB4spEELcawjbe7Gw1LBh6peFMP+zJCoUXvFnFX3ph/VQmap7tqf/Rv 8OJJ2jRHeMz/AsICEVw/nswf4zsipYISyqG1AA+jygWLz7Lo3IZKTVd+xielXrLkFDsk4dQWB9M3 HP8u5j/xnMj1wpQX8jsEfx21Q2/Q9eojMX+hWvjz8hZC7UxClGGDgAZNQBcIDMJBPXokQYtu04eu sGZAxM8LRuuAFyhH/zlwM7+Kqx/8zXGIqKkQUTreez2hTxkv6HF1kCK5GpEFkoQ2rLGWxZIegSFQ ETG4x6+km3XXyH1A050MZThS1jW09Er3dSrIyjPP6Zh1CYYS3ezNKZPaoSntxio1s4KGIFuV1WnE A2uL0FwyAPLKgWsnQB6I7lCyvxwbHQnoRic2XACvp0hOBzGALeEb7C/7fsty02JHW+T9qlt1fZ6r CYp2ykM3Rs7eopqHp0u/G9d2OGZrzGneWzgHcbYfCACeUDBIVH69E2a6q8z/af63ctMHmouRxvm8 x1HI//Aj87oczRoxaaY71rFlAFogRXE1x0T4BP6JQmavZTiWrQzOEMASIQVnU4yfM8/fSnpQdPKi DZmVF/fq/9xcTpWcsoR1OY818TkvKoTiK/kBxp1z7XtYhTpYvJtqSVblEBScPZoi6+xfKDItWqTC 148zyS/wO4Djbm1JKRrAJzGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKe2swCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNzI1MDQwMDMz WjAjBgkqhkiG9w0BCQQxFgQU6NuBn4a7Ea94Hg+wCApgA9CIwCAwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCntrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCntrMA0GCSqG SIb3DQEBAQUABIIBAAUNDHyvTDsgzaOnr89ujKt73bQL3Y4AWVwlccOqKYtUurMUOho6dCv70vED EYCWgm8x0ThruJBWhKeDhynIZ4goLS+TPnH0zwE9XNt6tPmYFXGkE6efCOBSLpb3GnZegQY+d6Rq J15S/Su/Mup6h8bJAM8op/tQ8CjwOM4RUqr6ZxP/vCEKzPX/tmvqROEYmHwMw46mIyert7gY0Cmk 454GW5tpeR1jOBe1fgrTS1VXbrRYkl8ZCV5udmYqFJDD7b3eUv9YfCKwSGRrqIMF8HMo8ZbwuGBE EWYgmn/9YJ1Tfs7gnwDZw3Utw5mPpkwntE8WCDo/rICWczzghPdQn+4AAAAAAAA= --Apple-Mail-1-399267425-- From moore@network-heretics.com Sun Jul 24 21:35:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0315E8003 for ; Sun, 24 Jul 2011 21:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFJX0LIQl9L5 for ; Sun, 24 Jul 2011 21:35:53 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2304621F86AF for ; Sun, 24 Jul 2011 21:35:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 92E1620CA9; Mon, 25 Jul 2011 00:35:52 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 25 Jul 2011 00:35:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=ruihjklG3r9AErVl40shW0JTqws=; b=qG PuodZHccs4j4ONSCEhDLNfvZXrvbV8Zgs8uiOYo/igIiXYnKtbzxfDkiXXRXAHxh RuEqwLXuOQlCFvDrhknoJzyPWJM3whF5hhXMIAJdaheBrkVAROK+Yv8zhSkUQNYc GN88XBLnHqBvEH+eeSbayXfJdHixkUKVcTIk8N7+s= X-Sasl-enc: yQR5sq6be1X+SFWNVPSmHwmmMGzm3EjGMh46fK24HlPy 1311568552 Received: from [192.168.200.118] (modemcable114.145-70-69.static.videotron.ca [69.70.145.114]) by mail.messagingengine.com (Postfix) with ESMTPSA id 30777453EDB; Mon, 25 Jul 2011 00:35:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Mon, 25 Jul 2011 00:35:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4EBC029E-A4B1-4F37-9467-BCBB7CCA310D@network-heretics.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <5C15E073-2764-4BFF-ADB0-E8939D58917F@network-heretics.com> To: Michael Newbery X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 04:35:54 -0000 On Jul 25, 2011, at 12:00 AM, Michael Newbery wrote: >=20 > On 23/07/2011, at 5:32 AM, Keith Moore wrote: >=20 >> On Jul 22, 2011, at 11:59 AM, Fred Baker wrote: >>=20 >>> On Jul 22, 2011, at 8:20 AM, Gert Doering wrote: >>>=20 >>>> You don't need universal availability on the last DSL line to have = IPv6 *on servers*.=20 >>>=20 >>> and by the way, the entire series of MUA/MTA and MTA/MTA links don't = have to have IPv6 for it to be used on some of them. If one end user is = IPv6-only, the other is IPv4-only, and at least one MTA in between is = dual, nobody should notice an issue. >>>=20 >>> My initial comment to Michael, when he pointed the draft out to me, = was that email seems like the poster child of an easy application to add = IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support it = already and the current OS's support IPv6. The primary thing preventing = mail/IPv6 is network IPv6 deployment, which is in progress. >>=20 >> I guess my view is sort of the opposite - there's really little point = to upgrading mail to use IPv6 until most of the net has IPv6 access. I probably should say at the outset that my position on this has shifted = a bit. I now do think that there's some point to rolling out IPv6 email = if for no other reason than to gain experience with it (and especially = spam filtering in the IPv6 environment) before the deluge hits. = Because there will come a point at which IPv4 will be abandoned on a = massive scale, and at that point everyone who has been relying on IPv4 = to send mail will suddenly start using IPv6. > [ignoring for the moment the ongoing discussion on spam and *-lists] >=20 > You need up upgrade mail to use IPv6 as soon as > * you have customers that only have IPv6 transport > * there is any significant amount of traffic that is IPv6 only I don't disagree with the above. However: - Is anyone really planning on offering _only_ IPv6 transport anytime = soon, as opposed to IPv6 with some sort of NATed IPv4 access, perhaps = tunneled over IPv6? I have a difficult time believing that anyone wants = to offer customers a service that won't let them access 99.9% of the = current Internet. At the very least I think the provider would give = them a web proxy to let them access v4 only content, an SMTP forwarder = to let them send mail to domains that only have v4 MXes, and an SMTP = server that can act as a backup MX, relaying incoming IPv4 mail to the = customer's v6-only SMTP server.=20 - Similarly, at least in the near future, anyone who wants their mail to = be delivered is going to have to be able to send to IPv4 MXes, so I = don't think that there will be a significant amount of SMTP traffic that = cannot fall back to IPv4 anytime soon. As I've said for years, I think email and the web will be the last = applications to fully migrate to IPv6. It's not that I doubt the = access providers' resolve to migrate their email services. It's that I = think that all of those enterprises out there that are running their own = mail systems will be slow to upgrade, and it will still be necessary to = accept mail from them and deliver it to them. But I think it's a good idea to encourage operators (not just access, = but enterprise also) to start rolling out SMTP over v6 so that they can = get experience with it.=20 Keith From newbery@gmail.com Sun Jul 24 22:34:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DEE21F85B8 for ; Sun, 24 Jul 2011 22:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4YPU7J8idzF for ; Sun, 24 Jul 2011 22:34:16 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id AED5811E807E for ; Sun, 24 Jul 2011 22:34:16 -0700 (PDT) Received: by pzk6 with SMTP id 6so7539581pzk.26 for ; Sun, 24 Jul 2011 22:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=VE3/gTI0MDgMAgqqkagMv4cTGL+Ws1sHhRhBWX0eJ+o=; b=Yk6fE1Kj0T/mxJjL3RWKP3Gd60zRO+jFT09SsKwvu7b4/lhcftA1op5Jc3fMam7B79 tjYPgEzXGiA6vVmnJWdBuUecYWj/dBmxcFbE+GTCoccIHJ6XCK5CB4O5BzFwLp8YArz4 SO5o4Ub7kFrTn/yyLuDOxblR/bBds1mI1MyU8= Received: by 10.68.44.129 with SMTP id e1mr7015085pbm.113.1311572051470; Sun, 24 Jul 2011 22:34:11 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id i9sm4264372pbk.36.2011.07.24.22.34.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jul 2011 22:34:10 -0700 (PDT) From: Michael Newbery Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-2-404880383; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 25 Jul 2011 17:34:00 +1200 In-Reply-To: <4EBC029E-A4B1-4F37-9467-BCBB7CCA310D@network-heretics.com> To: "v6ops@ietf.org WG" References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <5C15E073-2764-4BFF-ADB0-E8939D58917F@network-heretics.com> <4EBC029E-A4B1-4F37-9467-BCBB7CCA310D@network-heretics.com> Message-Id: <126E47C5-3945-4242-AF8C-8B855345355E@gmail.com> X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 05:34:17 -0000 --Apple-Mail-2-404880383 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25/07/2011, at 4:35 PM, Keith Moore wrote: >=20 > On Jul 25, 2011, at 12:00 AM, Michael Newbery wrote: >=20 >>=20 >> On 23/07/2011, at 5:32 AM, Keith Moore wrote: >>=20 >>> I guess my view is sort of the opposite - there's really little = point to upgrading mail to use IPv6 until most of the net has IPv6 = access. >=20 > I probably should say at the outset that my position on this has = shifted a bit. I now do think that there's some point to rolling out = IPv6 email if for no other reason than to gain experience with it (and = especially spam filtering in the IPv6 environment) before the deluge = hits. Because there will come a point at which IPv4 will be abandoned = on a massive scale, and at that point everyone who has been relying on = IPv4 to send mail will suddenly start using IPv6. Yes. I suspect that time may come sooner than many are expecting. >=20 >> [ignoring for the moment the ongoing discussion on spam and *-lists] >>=20 >> You need up upgrade mail to use IPv6 as soon as >> * you have customers that only have IPv6 transport >> * there is any significant amount of traffic that is IPv6 only >=20 > I don't disagree with the above. However: >=20 > - Is anyone really planning on offering _only_ IPv6 transport anytime = soon, as opposed to IPv6 with some sort of NATed IPv4 access, perhaps = tunneled over IPv6? I have a difficult time believing that anyone wants = to offer customers a service that won't let them access 99.9% of the = current Internet. At the very least I think the provider would give = them a web proxy to let them access v4 only content, an SMTP forwarder = to let them send mail to domains that only have v4 MXes, and an SMTP = server that can act as a backup MX, relaying incoming IPv4 mail to the = customer's v6-only SMTP server.=20 On the inside, customer facing side? Yes. In that, an ISP may very well = have customers with IPv6 only transport. LTE for instance. Such an ISP = would then want to listen to SMTP from its customers using IPv6. Now, such an ISP might very well offer NAT64, but I struggle to see the = sense in having an ISP NAT64 its *own* customers so its SMTP server = doesn't have to speak IPv4. Surely it's simpler to support native IPv6 = transport? >=20 > - Similarly, at least in the near future, anyone who wants their mail = to be delivered is going to have to be able to send to IPv4 MXes, so I = don't think that there will be a significant amount of SMTP traffic that = cannot fall back to IPv4 anytime soon. I agree of course. I doubt any ISP of any size won't be able to find an = IPv4 address for its mail servers anytime soon. But, not all mall comes = from the ISP's servers.=20= --Apple-Mail-2-404880383 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwp7azANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTA3MTkwNzM5MjBaFw0x MjAxMTUwNzM5MjBaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQB4spEELcawjbe7Gw1LBh6peFMP+zJCoUXvFnFX3ph/VQmap7tqf/Rv 8OJJ2jRHeMz/AsICEVw/nswf4zsipYISyqG1AA+jygWLz7Lo3IZKTVd+xielXrLkFDsk4dQWB9M3 HP8u5j/xnMj1wpQX8jsEfx21Q2/Q9eojMX+hWvjz8hZC7UxClGGDgAZNQBcIDMJBPXokQYtu04eu sGZAxM8LRuuAFyhH/zlwM7+Kqx/8zXGIqKkQUTreez2hTxkv6HF1kCK5GpEFkoQ2rLGWxZIegSFQ ETG4x6+km3XXyH1A050MZThS1jW09Er3dSrIyjPP6Zh1CYYS3ezNKZPaoSntxio1s4KGIFuV1WnE A2uL0FwyAPLKgWsnQB6I7lCyvxwbHQnoRic2XACvp0hOBzGALeEb7C/7fsty02JHW+T9qlt1fZ6r CYp2ykM3Rs7eopqHp0u/G9d2OGZrzGneWzgHcbYfCACeUDBIVH69E2a6q8z/af63ctMHmouRxvm8 x1HI//Aj87oczRoxaaY71rFlAFogRXE1x0T4BP6JQmavZTiWrQzOEMASIQVnU4yfM8/fSnpQdPKi DZmVF/fq/9xcTpWcsoR1OY818TkvKoTiK/kBxp1z7XtYhTpYvJtqSVblEBScPZoi6+xfKDItWqTC 148zyS/wO4Djbm1JKRrAJzGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMKe2swCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNzI1MDUzNDA2 WjAjBgkqhkiG9w0BCQQxFgQUoQ7TlYwMirayN3vd4vcSN3wOt4owgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCntrMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCntrMA0GCSqG SIb3DQEBAQUABIIBAC5TEM9RqjyDMZBi7lQRZTaHdkhHUL4tqrY0LMMyWFpLTGqlczJnrCvK9jbU q2dQwWk+dGsOhVUCuPEG4fM1vJPZSExyb3DEBd9xCsT0c8lLqgLQl7HFvN24ewxqGVO9zFTCgCBl uWWpS60aE/532JYRmbPlU2i/4qS3aD9IKLl4UfsF/lNhTEAVlndvwxKYuu0+xMaJFRQH+NnM28eR zPyDnTo9WjdeKW1FolsoAX5l7GZPs6BBQcOhdJfcJNJ8O6KxwV8/TsyOOyYgk4FnNX8gm5ifrGAR /+ZFuzv/s4ICI0Kq0QRSlWa0lNWLqC7v7GlVzevXgJ9aCuuJz7mqjpQAAAAAAAA= --Apple-Mail-2-404880383-- From farmer@umn.edu Sun Jul 24 22:59:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4AE21F89A1 for ; Sun, 24 Jul 2011 22:59:15 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvzbYM+k2L74 for ; Sun, 24 Jul 2011 22:59:14 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBF221F85DA for ; Sun, 24 Jul 2011 22:59:14 -0700 (PDT) Received: from mail-yw0-f43.google.com (mail-yw0-f43.google.com [209.85.213.43]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 25 Jul 2011 00:59:08 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-yw0-f43.google.com [209.85.213.43] #+LO+TR X-Umn-Classification: local Received: by ywt2 with SMTP id 2so2777329ywt.16 for ; Sun, 24 Jul 2011 22:59:08 -0700 (PDT) Received: by 10.236.193.7 with SMTP id j7mr5135164yhn.465.1311573547966; Sun, 24 Jul 2011 22:59:07 -0700 (PDT) Received: from oit200959392.local ([2001:470:1f11:821:225:ff:fe43:6145]) by mx.google.com with ESMTPS id g5sm4071624yhn.65.2011.07.24.22.59.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jul 2011 22:59:06 -0700 (PDT) Message-ID: <4E2D05F5.2060506@umn.edu> Date: Mon, 25 Jul 2011 00:58:13 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe St Sauver References: <11072209372672_B93@oregon.uoregon.edu> In-Reply-To: <11072209372672_B93@oregon.uoregon.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, moore@network-heretics.com, dcrocker@bbiw.net, johnl@iecc.com Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 05:59:15 -0000 On 7/22/11 11:37 CDT, Joe St Sauver wrote: > Gert commented: > > #On Fri, Jul 22, 2011 at 08:59:27AM -0700, Fred Baker wrote: > #> My initial comment to Michael, when he pointed the draft out to me, was > #> that email seems like the poster child of an easy application to add IPv6 > #> to, as the applications (SMTP, POP, and IMAP) mostly support it already > #> and the current OS's support IPv6. > # > #Seconded. Plus, if mail gets delayed by a few minutes due to IPv6 breakage, > #it helps *noticing* problems without impacting user experience in a very > #massive way (like for IPv6 HTTP running into timeouts). > > Let me just jump in for a second on this. > > I think it's great for providers to add support for IPv6 for: > > -- web email > -- Authenticated secure IMAP > -- Authenticated secure POP > -- Authenticated secure message submission > > In all of those cases, because users *are* authenticating, you know who > your users are, regardless of how or from where they connect. If they > begin to spew, you'll know who it is and you can deal with them/their > compromised machine. Yep these should be fairly easy and safe to do IPv6 for and everyone should start working on these. And these are the services that an IPv6 only user agent will need. > At this point, though, I'd be wary of fielding Internet-accessible > IPv6-enabled SMTP servers. > > Why? Spam management solutions simply aren't yet where they need to be... > > Yeah, if you're lucky, maybe you won't see any spam via IPv6 connections, > or maybe you can clean it up with a purely content-oriented anti-spam > solution (such as SpamAssassin or a Baeysian approach), but if you want > to use traditional blocklists or you want to use some of the major > commercial anti-spam appliances, what you'd want is simply not available. I'm defiantly wary of doing IPv6 MTA to MTA email transport, and any one who understand anything about the issue should be wary. However, the word wary doesn't and shouldn't mean don't do it at all. Nor, should it mean dive in head first. It should mean find ways to proceed forward carefully and cautiously. I think that is what the draft is all about, moving forward with IPv6 email carefully and cautiously. A little context, I don't actually run email servers, I'm an Internet plumber, not an Internet postman. And, the University is migrating most of its email users to Google, but that is a whole other discussion. However, since only most and not all email users will be migrated to Google, the University will continue to run its own MXes. As I read the draft, the primary objective is not the transition of transport for most email to IPv6. But, preparing for the day when IPv6 only MTAs start to become necessary in the Post-Transition Phase it describes. It accomplishes this by calling for current MTAs to implement Dual-Stack to ensure reachability to and from these IPv6 only MTAs when they become necessary. While I support this objective and believe it is necessary to enable Dual-Stack on all current MTAs. Realistically, it will also be necessary for service providers to provide their IPv6 only customers that want/need to run their own MTAs access to an authenticated Dual-Stack Relay and Dual-Stack MX services in order to reach and be reached by lagging IPv4 only MTAs. But back to the Draft, If the intent is to allow for IPv6 only MTAs and not necessarily transition email transport to IPv6 then maybe we should be thinking about how to enable IPv6 but still prefer IPv4 for email transport. Therefore, I would like to see the draft discuss the interactions of MX priority, AAAA records, Address Selection based on RFC3484-bis, and maybe prioritizing IPv4 over IPv6. Also, probably discussing interactions with, and Dual-Stack variations of, techniques like Nolisting and Greylisting to push traffic to prefer IPv4 over IPv6, basically use IPv6 as a last resort for email transport. So, I'm thinking of talking to our email guys about going to two tiers of MXes that are Dual-Stacked. With the first tier only having SMTP bound to IPv4 and explicitly denying SMTP over IPv6, proving a kind of IPv6 Nolisting and pushing email traffic to IPv4 even if the remote server is Dual-Stack enabled. Then the second tier doing the opposite, SMTP bound to IPv6, denying IPv4, and doing IPv6 Greylisting with other purely content-oriented anti-spam solutions (such as SpamAssassin or a Baeysian approach). Also if IPv6 reputation based solutions emerge they can be used in the second tier too. Also, our email guys require reverse DNS for IPv4 email servers, this causes a few false positives, but catches a bunch of spam before it makes on to DNSBLs. That solution should adapt well to IPv6 if legitimate IPv6 email servers provide reverse DNS for IPv6. We also provide a bounce back allowing a real user to request access with individualized white-listing for each users email box. Additionally, It should be possible to adapt the current IPv4 reputation based solutions for some of the IPv6 transition technologies as well. With 6to4, Teredo, and ISATAP the IPv4 address that is embedded in the IPv6 address can be extracted and used as an IPv4 address to be looked-up in DNSBLs. 6to4 is trivial; 2002:[IPv4 Address]:: Teredo is a little trickier; 2001:0:[Teredo Server IPv4 Address]:[16 bit Flag field]:[16bit External UDP Port hash]:[Obfuscated External IPv4 Address]. The Teredo Server's IPv4 Address is irrelevant, the Obfuscated External IPv4 Address is what you want. But you will need to reverse the obfuscation, which should be easily accomplished by XORing it with 0xFFFFFFFF. ISATSAP again is fairly trivial; [IPv6 /64 Prefix]:200:5EFE:[Public IPv4 address] [IPv6 /64 Prefix]:0:5EFE:[Private IPv4 address] The ISATAP IPv6 address is only useful if it contains a Public IPv4 address, that is probably not going to be that common. But its probably still worth doing if someone gives you a Public IPv4 address. I don't know how useful this would really be, but it probably wouldn't hut anything more than the current IPv4 reputation based solutions do already. Finally, I agree it is time to get moving on IPv6 email, and this discussion has gotten me thinking about how to get it rolling in my organization and hopefully this draft will do the same for others. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From pch-b2B3A6689@u-1.phicoh.com Mon Jul 25 00:10:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B7821F8B00 for ; Mon, 25 Jul 2011 00:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.379 X-Spam-Level: X-Spam-Status: No, score=-8.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pabxGF7VbTfX for ; Mon, 25 Jul 2011 00:10:24 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 41B5121F8AFF for ; Mon, 25 Jul 2011 00:10:22 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QlFIy-0001hOC; Mon, 25 Jul 2011 09:10:20 +0200 Message-Id: To: Keith Moore From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <5C15E073-2764-4BFF-ADB0-E8939D58917F@network-heretics.com> <4EBC029E-A4B1-4F37-9467-BCBB7CCA310D@network-heretics.com> In-reply-to: Your message of "Mon, 25 Jul 2011 00:35:51 -0400 ." <4EBC029E-A4B1-4F37-9467-BCBB7CCA310D@network-heretics.com> Date: Mon, 25 Jul 2011 09:10:08 +0200 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 07:10:25 -0000 In your letter dated Mon, 25 Jul 2011 00:35:51 -0400 you wrote: >- Is anyone really planning on offering _only_ IPv6 transport anytime soon, as > opposed to IPv6 with some sort of NATed IPv4 access, perhaps tunneled over IP >v6? I have a difficult time believing that anyone wants to offer customers a >service that won't let them access 99.9% of the current Internet. At the ver >y least I think the provider would give them a web proxy to let them access v4 > only content, an SMTP forwarder to let them send mail to domains that only ha >ve v4 MXes, and an SMTP server that can act as a backup MX, relaying incoming >IPv4 mail to the customer's v6-only SMTP server. > >- Similarly, at least in the near future, anyone who wants their mail to be de >livered is going to have to be able to send to IPv4 MXes, so I don't think tha >t there will be a significant amount of SMTP traffic that cannot fall back to >IPv4 anytime soon. So for outbound: - Say you are behind a CGN together with a couple of thousand other customers and you have DNSBLs that track reputation at a per IPv4 address granularity, what do you think would happen if any of those other customers gets infected and starts sending spam? If we want make e-mail something that can be done only be a few big parties then there is no need to support IPv6. If we want small parties to be able to do their own e-mail, then accepting mail over IPv6 is very important. Inbound: - A site that is behind a CGN can only accept inbound SMTP on IPv6. So there is a need for big secondaries that accept mail over IPv4 and forward it over IPv6. This is potentially destroys all the good parts about running your own MX. If most of the e-mail arrives over IPv6 then having to live with a secondary for legacy IPv4 may be acceptable. If most mail continue to flow over IPv4 then it is pointless. So, think that everybody who is dual stack today, should start sending and accepting mail over IPv6 as soon as possible. From fred@cisco.com Mon Jul 25 00:10:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD26411E808C for ; Mon, 25 Jul 2011 00:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.284 X-Spam-Level: X-Spam-Status: No, score=-103.284 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBZOwIHXabM6 for ; Mon, 25 Jul 2011 00:10:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 31FBF11E8086 for ; Mon, 25 Jul 2011 00:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=741; q=dns/txt; s=iport; t=1311577840; x=1312787440; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=1AODlXwlAD9lJmhQBlVPeANiaH7ZYzaOtM08gcY/A3s=; b=cE/k+X8ti439S+7JHT16Rn603z52IiUVIG7Wx/+1rEUBTIJgGJ+cnr/Y sfYUxlv/5DV+J8QfBoQXhlxJlAf2gJ7CtGZZrAo4cQ2RUi6htNmz9ou+Q lomDqQlps6fS8Jb/oFkx0GK0N9F4Yh8o1OaH1IhNIFQoW6HOwUAu2UL4m 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANQVLU6rRDoJ/2dsb2JhbAA0AQEBAxUBK0opAwECKiVJDxcnpy93iHygfYEjnVWFYF8EknCFB4t1 X-IronPort-AV: E=Sophos;i="4.67,259,1309737600"; d="scan'208";a="6023425" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-5.cisco.com with ESMTP; 25 Jul 2011 07:10:39 +0000 Received: from Freds-Computer.local (sjc-vpn6-153.cisco.com [10.21.120.153]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6P7AcQe019539 for ; Mon, 25 Jul 2011 07:10:38 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 25 Jul 2011 03:10:38 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 25 Jul 2011 03:10:38 -0400 From: Fred Baker Date: Mon, 25 Jul 2011 03:10:29 -0400 Message-Id: <813C2207-C251-48EA-84EF-A6B64D46B880@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Meeting Friday, Office Hours Monday X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 07:10:41 -0000 The Secretariat has given us a meeting slot after lunch on Friday - a = third two hour slot. This means that we have time for 6-8 more = discussions. Folks who didn't make the cut on the agenda and would like = to make use of that time should visit the chairs during the "Office = Hours" Monday (2:00-3:00, Room 301a) > From: Fred Baker > Date: July 18, 2011 11:43:41 AM EDT > To: IPv6 Operations > Subject: [v6ops] WG Chair Office Hours >=20 > As we did at IETF-80, Joel and I will be holding office hours at = IETF-81. We invite anyone who would like to talk with the chairs on any = v6ops-relevant topic to join us. >=20 > We will be in room 301A from 14:00-15:00 EDT on Monday 25 July. From joelja@bogus.com Mon Jul 25 04:54:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377DB21F8A6C for ; Mon, 25 Jul 2011 04:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.034 X-Spam-Level: X-Spam-Status: No, score=-102.034 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FUI-Ko5c-cG for ; Mon, 25 Jul 2011 04:54:12 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 998E221F8B9B for ; Mon, 25 Jul 2011 03:44:06 -0700 (PDT) Received: from dhcp-47c2.meeting.ietf.org (dhcp-47c2.meeting.ietf.org [130.129.71.194]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6PAhseR003967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 25 Jul 2011 10:43:55 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <4E2D05F5.2060506@umn.edu> Date: Mon, 25 Jul 2011 06:43:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <16B4EC40-4960-4AD6-9B84-0820C3C13ABA@bogus.com> References: <11072209372672_B93@oregon.uoregon.edu> <4E2D05F5.2060506@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 25 Jul 2011 10:43:57 +0000 (UTC) Cc: johnl@iecc.com, Joe St Sauver , v6ops@ietf.org, moore@network-heretics.com, dcrocker@bbiw.net Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 11:54:13 -0000 =20 On Jul 25, 2011, at 1:58 AM, David Farmer wrote: >=20 > Additionally, It should be possible to adapt the current IPv4 = reputation based solutions for some of the IPv6 transition technologies = as well. With 6to4, Teredo, and ISATAP the IPv4 address that is embedded = in the IPv6 address can be extracted and used as an IPv4 address to be = looked-up in DNSBLs. I am rather unclear on the advisability and for some reason really wary = of using transition technologies in the addressing of servers. > 6to4 is trivial; > 2002:[IPv4 Address]:: >=20 > Teredo is a little trickier; > 2001:0:[Teredo Server IPv4 Address]:[16 bit Flag field]:[16bit = External UDP Port hash]:[Obfuscated External IPv4 Address]. >=20 > The Teredo Server's IPv4 Address is irrelevant, the Obfuscated = External IPv4 Address is what you want. But you will need to reverse = the obfuscation, which should be easily accomplished by XORing it with = 0xFFFFFFFF. >=20 > ISATSAP again is fairly trivial; > [IPv6 /64 Prefix]:200:5EFE:[Public IPv4 address] > [IPv6 /64 Prefix]:0:5EFE:[Private IPv4 address] >=20 > The ISATAP IPv6 address is only useful if it contains a Public IPv4 = address, that is probably not going to be that common. But its probably = still worth doing if someone gives you a Public IPv4 address. >=20 > I don't know how useful this would really be, but it probably wouldn't = hut anything more than the current IPv4 reputation based solutions do = already. >=20 > Finally, I agree it is time to get moving on IPv6 email, and this = discussion has gotten me thinking about how to get it rolling in my = organization and hopefully this draft will do the same for others. >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > David Farmer Email:farmer@umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota=09 > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From moore@network-heretics.com Mon Jul 25 04:54:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E5321F8B17 for ; Mon, 25 Jul 2011 04:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x3n1DRFcEjK for ; Mon, 25 Jul 2011 04:54:38 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id F26C321F8AF1 for ; Mon, 25 Jul 2011 03:57:40 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 2D16220DA8; Mon, 25 Jul 2011 06:57:40 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 25 Jul 2011 06:57:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=KtdYrfFrMq9DAVUxh2gEQmiWY0A=; b=Ia BW9uuix3Mp9HxKLSVfiy14Puz5OqpLlDkZ1NbPS5IVSk6ZIcgCArWrH0zT4ysVnM zrZYHKuAoDmkDz6MRmNDHOvdTe7OegjF2EMAFfFmtDoqfbI+J8TVjBxiSCbEWS1B N8FkJSjqP1r6ZAQwqGXfbLi2JAVp1TmNg45lDMmjE= X-Sasl-enc: x2gT5xnzI74I420t8PUqswdcugVWZHP+rUWsMunx98K7 1311591459 Received: from [192.168.210.124] (modemcable114.145-70-69.static.videotron.ca [69.70.145.114]) by mail.messagingengine.com (Postfix) with ESMTPSA id B4C3C413462; Mon, 25 Jul 2011 06:57:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Mon, 25 Jul 2011 06:57:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5EFC7E43-4247-423F-9754-4001C2EFCA47@network-heretics.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <5C15E073-2764-4BFF-ADB0-E8939D58917F@network-heretics.com> <4EBC029E-A4B1-4F37-9467-BCBB7CCA310D@network-heretics.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" , Keith Moore Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 11:54:39 -0000 On Jul 25, 2011, at 3:10 AM, Philip Homburg wrote: > So for outbound:=20 > - Say you are behind a CGN together with a couple of thousand other = customers > and you have DNSBLs that track reputation at a per IPv4 address = granularity, > what do you think would happen if any of those other customers gets = infected > and starts sending spam? >=20 > If we want make e-mail something that can be done only be a few big = parties > then there is no need to support IPv6. If we want small parties to be = able > to do their own e-mail, then accepting mail over IPv6 is very = important. interesting point. I'd like to believe that the DNSBLs will be discredited when this = happens, but my experience with those in general is that people already = have too much misplaced faith in them, so I don't suppose this will = change much. > Inbound: > - A site that is behind a CGN can only accept inbound SMTP on IPv6. So = there > is a need for big secondaries that accept mail over IPv4 and forward = it > over IPv6. This is potentially destroys all the good parts about = running > your own MX. >=20 > If most of the e-mail arrives over IPv6 then having to live with a=20 > secondary for legacy IPv4 may be acceptable. If most mail continue to = flow > over IPv4 then it is pointless. >=20 > So, think that everybody who is dual stack today, should start sending = and > accepting mail over IPv6 as soon as possible. another interesting point. thanks. Keith From Ted.Lemon@nominum.com Mon Jul 25 05:14:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A1321F8509 for ; Mon, 25 Jul 2011 05:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FistT7LG8m5p for ; Mon, 25 Jul 2011 05:14:49 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8D39321F84CA for ; Mon, 25 Jul 2011 05:14:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTi1eOBMXemx1Wb6abBv/bc4EvzH98lUD@postini.com; Mon, 25 Jul 2011 05:14:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4A4041B81CF for ; Mon, 25 Jul 2011 05:14:48 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 32D57190059; Mon, 25 Jul 2011 05:14:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Mon, 25 Jul 2011 05:14:48 -0700 From: Ted Lemon To: Keith Moore Thread-Topic: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities Thread-Index: AQHMSIhq6Jk8HHzgmkCy3qniqcKe15T5DxSAgAPT+ACAAAnmgIAAgDmA Date: Mon, 25 Jul 2011 12:14:47 +0000 Message-ID: <4396E096-8134-4C16-AE73-9FF4EA885C61@nominum.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <5C15E073-2764-4BFF-ADB0-E8939D58917F@network-heretics.com> <4EBC029E-A4B1-4F37-9467-BCBB7CCA310D@network-heretics.com> In-Reply-To: <4EBC029E-A4B1-4F37-9467-BCBB7CCA310D@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.66.66] Content-Type: multipart/alternative; boundary="_000_4396E09681344C16AE739FF4EA885C61nominumcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 12:14:50 -0000 --_000_4396E09681344C16AE739FF4EA885C61nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 25, 2011, at 12:35 AM, Keith Moore wrote: - Is anyone really planning on offering _only_ IPv6 transport anytime soon,= as opposed to IPv6 with some sort of NATed IPv4 access, perhaps tunneled o= ver IPv6? I have a difficult time believing that anyone wants to offer cus= tomers a service that won't let them access 99.9% of the current Internet. = At the very least I think the provider would give them a web proxy to let= them access v4 only content, an SMTP forwarder to let them send mail to do= mains that only have v4 MXes, and an SMTP server that can act as a backup M= X, relaying incoming IPv4 mail to the customer's v6-only SMTP server. - Similarly, at least in the near future, anyone who wants their mail to be= delivered is going to have to be able to send to IPv4 MXes, so I don't thi= nk that there will be a significant amount of SMTP traffic that cannot fall= back to IPv4 anytime soon. Most internet connections nowadays can be configured with a stable, globall= y-routable IPv6 address, but not with a globally-routable IPv4 address, or = at least not with a stable one. This means that you can't receive SMTP co= nnections. But you can still originate SMTP connections, as long as the o= ther end is willing to accept them. So I would say that the time when IPv6-only transport is necessary for cert= ain applications is already with us. I would expect there to be loud and = vociferous disputes as to whether or not the hoi polloi should be allowed t= o have such connections, but that's a separate matter: my point is that the= re is in fact an application _right now_ that can only be achieved if peopl= e turn up IPv6 for outgoing connections. --_000_4396E09681344C16AE739FF4EA885C61nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <25A1F2D197AE15428271EA040E8D7D17@nominum.com> Content-Transfer-Encoding: quoted-printable
On Jul 25, 2011, at 12:35 AM, Keith Moore wrote:
- Is anyone really planning on offering _only_ IPv6 transport anytime soon, = as opposed to IPv6 with some sort of NATed IPv4 access, perhaps tunneled ov= er IPv6?  I have a difficult time believing that anyone wants to offer= customers a service that won't let them access 99.9% of the current Internet.   At the very least I thin= k the provider would give them a web proxy to let them access v4 only conte= nt, an SMTP forwarder to let them send mail to domains that only have v4 MX= es, and an SMTP server that can act as a backup MX, relaying incoming IPv4 mail to the customer's v6-only SMTP server. 

- Similarly, at least in the near future, anyone who wants their mail to be= delivered is going to have to be able to send to IPv4 MXes, so I don't thi= nk that there will be a significant amount of SMTP traffic that cannot fall= back to IPv4 anytime soon.

Most internet connections nowadays can be configured with a stable, gl= obally-routable IPv6 address, but not with a globally-routable IPv4 address= , or at least not with a stable one.   This means that you can't recei= ve SMTP connections.   But you can still originate SMTP connections, as long as the other end is willing to accept = them.

So I would say that the time when IPv6-only transport is necessary for= certain applications is already with us.   I would expect there to be= loud and vociferous disputes as to whether or not the hoi polloi should be= allowed to have such connections, but that's a separate matter: my point is that there is in fact an application= _right now_ that can only be achieved if people turn up IPv6 for outgoing = connections.

--_000_4396E09681344C16AE739FF4EA885C61nominumcom_-- From fred@cisco.com Mon Jul 25 07:06:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D52A21F866A for ; Mon, 25 Jul 2011 07:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVaul5bT-6Yk for ; Mon, 25 Jul 2011 07:06:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9789C21F8B29 for ; Mon, 25 Jul 2011 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=127; q=dns/txt; s=iport; t=1311602101; x=1312811701; h=date:from:message-id:to:subject:cc; bh=mB1ftJvidiBPx1gIqr1GQFYJBq7AqxaE6ZUU9MUa8GM=; b=WKXJ+lMPwNXHFDSBW6oH3xNBHhqXsOElaQoA8TNJ4ET48k0tI5G5Ofyo YX6iA1dCW8k349d17Ayz/keCVjfUQSs2tUXjDIb23prqiSken8TVCpTW8 bDs3wDCYkgwP3dlIePES4HKs1fHAaTChpCDS1AY+4t5Hk5MjU8YYElpDT M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEIAJB1LU6rRDoJ/2dsb2JhbABPAXA+OQyBFpgdAQGPEneJAKJHnXeGPwSHVZwb X-IronPort-AV: E=Sophos;i="4.67,261,1309737600"; d="scan'208";a="6121554" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-9.cisco.com with ESMTP; 25 Jul 2011 13:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6PDt0P8008468; Mon, 25 Jul 2011 13:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p6PDt0Z23915; Mon, 25 Jul 2011 06:55:00 -0700 (PDT) Date: Mon, 25 Jul 2011 06:55:00 -0700 (PDT) From: Message-Id: <201107251355.p6PDt0Z23915@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-vanrein-v6ops-6bed4@tools.ietf.org Subject: [v6ops] new draft: draft-vanrein-v6ops-6bed4-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 14:06:34 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-vanrein-v6ops-6bed4. Please take a look at it and comment. From tjc@ecs.soton.ac.uk Mon Jul 25 09:09:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E7C21F8754 for ; Mon, 25 Jul 2011 09:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPoK7h-JaRIv for ; Mon, 25 Jul 2011 09:09:25 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5B021F877D for ; Mon, 25 Jul 2011 07:18:56 -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 p6PEIrB0020916 for ; Mon, 25 Jul 2011 15:18:53 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p6PEIrB0020916 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1311603534; bh=mFAChxLb0LRtheIVsabJ6+OF4ko=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=CUIWoUfk5aTaTmJMidwfGPJWcsMZpA+va+nuaJKV8MALq2dHLzCneDtzG62LU3NXN FjlLxPtKHoyPKPe0vVL/+4qP3a1brx4Ksefs/0ieyn2Ky23S5ew26eYuZY8yIex+nh HeO+NW7t8wJQ7YKyFQm09yA8wil8ZHfrNx6FGToY= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n6OFIr0366129444g8 ret-id none; Mon, 25 Jul 2011 15:18:54 +0100 Received: from [IPv6:2001:df8::112:50a9:cf12:628a:dbc5] ([IPv6:2001:df8:0:112:50a9:cf12:628a:dbc5]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p6PEIjoW022079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 25 Jul 2011 15:18:46 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Tim Chown In-Reply-To: <20110722134844.GP2304@Space.Net> Date: Mon, 25 Jul 2011 15:18:45 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20110722134844.GP2304@Space.Net> <2E40C785-C54E-4721-ACF5-AC69EE370049@ecs.soton.ac.uk> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1244.3) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n6OFIr036612944400; tid=n6OFIr0366129444g8; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p6PEIrB0020916 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:09:26 -0000 On 22 Jul 2011, at 14:48, Gert Doering wrote: >=20 > I think that the dates in there are actually the main contribution of > that draft. Create the necessary push for those that still have no > IPv6 on their mail systems to do it in a *timely* way. I agree; I think a 'push' is a good thing. There is now reason however why sites can't start supporting dual-stack = mail now. Many sites as Joel says have been doing this for years. Sure, = they're not the huge mail providers that John refers to, but a typical = enterprise (in my case campus/university) is a different beast. We have been running dual-stack relays for quite some time, using = MailScanner, which is open source. We are in the 100's of K's of = connections bracket, load-wise. We would not consider running IPv6-only = for the foreseeable future. In terms of IPv6 spam levels, it's about = 25%, compared to 90%+ for IPv4, but the bulk of that spam appears to be = from dual-stack list servers, in that it comes from manually-configured = IP addresses, rather than autoconfigured ones. There are some = dual-stack mail list servers that contribute a lot of it. That 25% is = somewhat higher than Sander's figure, but again it's a relatively small = sample, and IPv6 transport mail remains just under 1% of the IPv4 = transport volume. Compare that to about 5% of our external traffic = overall being IPv6. There have been some blips with having IPv6 support, e.g. when the IETF = ran with its secondary/backup mail servers for a test period, but hadn't = added reverse DNS for those MXes, so our mail servers rejected their = mail over IPv6 and surprisingly - to me at least - they didn't fall back = to IPv4 transport, so I dropped off some lists as a result of that. In some senses, it would be nice to be the target of an IPv6 SMTP = botnet, to learn from it... until we are, then we're following the 'run = dual-stack and adapt as necessary' suggestion. If we had to turn off = IPv6 on our MXes, it wouldn't take long to do and in practice we'd not = miss out on much, if any, external mail. Tim From tjc@ecs.soton.ac.uk Mon Jul 25 09:11:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F66711E8088 for ; Mon, 25 Jul 2011 09:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-rP2skzLf1Z for ; Mon, 25 Jul 2011 09:11:16 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 1979E21F8C24 for ; Mon, 25 Jul 2011 07:32:54 -0700 (PDT) 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 p6PEWm1b024151 for ; Mon, 25 Jul 2011 15:32:48 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p6PEWm1b024151 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1311604368; bh=31zDktczKGf5MjoxHhxRwHtSgCY=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=ncpEhH/EB5rI3Dg3468cDQhcNCsbyOb+Zw1hIhElG31dkIwolhtQFqrFltBcWYXvh Fny5zGcCkSFPdKNDgMi3ZLb9sQCtxrn1gIBTrGUPatkqCwBtBs3QCZAR2En19z0Onf 17mvFM5H0GAaVgwJ8HZ6pwTuTt1HtwZKXEmxlh9E= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n6OFWm036612956119 ret-id none; Mon, 25 Jul 2011 15:32:48 +0100 Received: from [IPv6:2001:df8::112:50a9:cf12:628a:dbc5] ([IPv6:2001:df8:0:112:50a9:cf12:628a:dbc5]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p6PEWdZA025736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 25 Jul 2011 15:32:40 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Tim Chown In-Reply-To: <16B4EC40-4960-4AD6-9B84-0820C3C13ABA@bogus.com> Date: Mon, 25 Jul 2011 15:32:39 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <11072209372672_B93@oregon.uoregon.edu> <4E2D05F5.2060506@umn.edu> <16B4EC40-4960-4AD6-9B84-0820C3C13ABA@bogus.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1244.3) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n6OFWm036612956100; tid=n6OFWm036612956119; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p6PEWm1b024151 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:11:17 -0000 On 25 Jul 2011, at 11:43, Joel Jaeggli wrote: >=20 > On Jul 25, 2011, at 1:58 AM, David Farmer wrote: >>=20 >> Additionally, It should be possible to adapt the current IPv4 = reputation based solutions for some of the IPv6 transition technologies = as well. With 6to4, Teredo, and ISATAP the IPv4 address that is embedded = in the IPv6 address can be extracted and used as an IPv4 address to be = looked-up in DNSBLs. >=20 > I am rather unclear on the advisability and for some reason really = wary of using transition technologies in the addressing of servers. I agree; I wouldn't expect to see any of ISATAP, Teredo or 6to4 to be = used for MXes, or indeed any of our internal enterprise infrastructure. While you can identify 6to4 and Teredo prefixes, you can't do so with = ISATAP, as we noted in 3484-bis. Tim= From rbonica@juniper.net Mon Jul 25 09:11:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569DC11E80AE for ; Mon, 25 Jul 2011 09:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYDAN4-QvcJg for ; Mon, 25 Jul 2011 09:11:21 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id C166A21F8C39 for ; Mon, 25 Jul 2011 07:34:54 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTi1/DqVfA6kQjWplrx360yO+yM7Chso6@postini.com; Mon, 25 Jul 2011 07:34:54 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 25 Jul 2011 07:34:06 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 25 Jul 2011 10:34:05 -0400 From: Ronald Bonica To: "v6ops@ietf.org" Date: Mon, 25 Jul 2011 10:34:04 -0400 Thread-Topic: draft-ietf-v6ops-6to4-to-historic (yet again) Thread-Index: AcxK13EXQuzfLCzMQFivvvTkow95TgAAEgkQ Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F431D13B@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] FW: draft-ietf-v6ops-6to4-to-historic (yet again) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:11:22 -0000 Folks, For those of you who don't follow the IETF list, I just posted the message = below. If you want to respond, please subscribe to the IETF mailing list an= d do so. Ron > -----Original Message----- > From: Ronald Bonica > Sent: Monday, July 25, 2011 10:31 AM > To: ietf@ietf.org > Subject: draft-ietf-v6ops-6to4-to-historic (yet again) >=20 > Folks, >=20 > After some discussion, the IESG is attempting to determine whether > there is IETF consensus to do the following: >=20 > - add a new section to draft-ietf-v6ops-6to4-to-historic > - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL >=20 > draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and > convert their status to HISTORIC. It will also contain a new section > describing what it means for RFCs 3056 and 3068 to be classified as > HISTORIC. The new section will say that: >=20 > - 6-to-4 should not be configured by default on any implementation > (hosts, cpe routers, other) > - vendors will decide whether/when 6-to-4 will be removed from > implementations. Likewise, operators will decide whether/when 6-to-4 > relays will be removed from their networks. The status of RFCs 3056 and > 3068 should not be interpreted as a recommendation to remove 6-to-4 at > any particular time. >=20 >=20 > draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it > clarifies the meaning of "HISTORIC" in this particular case, it does > not set a precedent for any future case. >=20 > Please post your views on this course of action by August 8, 2011. >=20 >=20 > Ron > Bonica >=20 > From cb.list6@gmail.com Mon Jul 25 09:12:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622AD11E81EB for ; Mon, 25 Jul 2011 09:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.942 X-Spam-Level: X-Spam-Status: No, score=-2.942 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8FFD64jpDbl for ; Mon, 25 Jul 2011 09:12:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EEA3F21F8D64 for ; Mon, 25 Jul 2011 08:05:40 -0700 (PDT) Received: by wyj26 with SMTP id 26so3264025wyj.31 for ; Mon, 25 Jul 2011 08:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rsNXVDRPGSOFSyp3gS1+SNK6RL5d4bagcUS+jpWXBnQ=; b=sGhwyMZeAs88xjJ8vF8RkvixNgoLkgt9Py8VgSpxHcxhywlANu/RJ+zjZnNSpWAvdQ o9SuDGHv1QpW/VyTfn02qsV2bTcHmyN6I2Rbr7asbx++x6R762eVXLf8ZBSIJyzw3hh9 /r+Lil9OfM/CicRa2NzdgH55++GvgIbtExtSo= MIME-Version: 1.0 Received: by 10.216.187.75 with SMTP id x53mr595296wem.92.1311606339909; Mon, 25 Jul 2011 08:05:39 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Mon, 25 Jul 2011 08:05:39 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Mon, 25 Jul 2011 08:05:39 -0700 (PDT) In-Reply-To: <4EBC029E-A4B1-4F37-9467-BCBB7CCA310D@network-heretics.com> References: <20110722134844.GP2304@Space.Net> <20110722141726.GS2304@Space.Net> <9DDB62C5-E0E3-4336-BA2E-A43C48763793@network-heretics.com> <20110722144843.GV2304@Space.Net> <4A84C1DA-B34D-46F3-875E-243D737F1CDE@network-heretics.com> <20110722152052.GX2304@Space.Net> <60232E31-E780-4CD8-A562-39761A73520C@cisco.com> <5C15E073-2764-4BFF-ADB0-E8939D58917F@network-heretics.com> <4EBC029E-A4B1-4F37-9467-BCBB7CCA310D@network-heretics.com> Date: Mon, 25 Jul 2011 08:05:39 -0700 Message-ID: From: Cameron Byrne To: Keith Moore Content-Type: multipart/alternative; boundary=001485f1d81ef9b87304a8e62561 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:12:54 -0000 --001485f1d81ef9b87304a8e62561 Content-Type: text/plain; charset=ISO-8859-1 On Jul 24, 2011 9:36 PM, "Keith Moore" wrote: > > > On Jul 25, 2011, at 12:00 AM, Michael Newbery wrote: > > > > > On 23/07/2011, at 5:32 AM, Keith Moore wrote: > > > >> On Jul 22, 2011, at 11:59 AM, Fred Baker wrote: > >> > >>> On Jul 22, 2011, at 8:20 AM, Gert Doering wrote: > >>> > >>>> You don't need universal availability on the last DSL line to have IPv6 *on servers*. > >>> > >>> and by the way, the entire series of MUA/MTA and MTA/MTA links don't have to have IPv6 for it to be used on some of them. If one end user is IPv6-only, the other is IPv4-only, and at least one MTA in between is dual, nobody should notice an issue. > >>> > >>> My initial comment to Michael, when he pointed the draft out to me, was that email seems like the poster child of an easy application to add IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support it already and the current OS's support IPv6. The primary thing preventing mail/IPv6 is network IPv6 deployment, which is in progress. > >> > >> I guess my view is sort of the opposite - there's really little point to upgrading mail to use IPv6 until most of the net has IPv6 access. > > I probably should say at the outset that my position on this has shifted a bit. I now do think that there's some point to rolling out IPv6 email if for no other reason than to gain experience with it (and especially spam filtering in the IPv6 environment) before the deluge hits. Because there will come a point at which IPv4 will be abandoned on a massive scale, and at that point everyone who has been relying on IPv4 to send mail will suddenly start using IPv6. > > > [ignoring for the moment the ongoing discussion on spam and *-lists] > > > > You need up upgrade mail to use IPv6 as soon as > > * you have customers that only have IPv6 transport > > * there is any significant amount of traffic that is IPv6 only > > I don't disagree with the above. However: > > - Is anyone really planning on offering _only_ IPv6 transport anytime soon, as opposed to IPv6 with some sort of NATed IPv4 access, perhaps tunneled over IPv6? I have a difficult time believing that anyone wants to offer customers a service that won't let them access 99.9% of the current Internet. At the very least I think the provider would give them a web proxy to let them access v4 only content, an SMTP forwarder to let them send mail to domains that only have v4 MXes, and an SMTP server that can act as a backup MX, relaying incoming IPv4 mail to the customer's v6-only SMTP server. > Yes, ipv6 only + nat64 is a real and tactical near term architecture documented in ietf, 3gpp, and gsma. This architecture is deployed in beta at t-mobile USA and will transition to production real soon now for wireless devices. I am just providing you a data point on why native v6, especially mobile clients and the services they access (email ...), is very important in the near term to avoid nat44 and nat64 on various access networks. Cb > - Similarly, at least in the near future, anyone who wants their mail to be delivered is going to have to be able to send to IPv4 MXes, so I don't think that there will be a significant amount of SMTP traffic that cannot fall back to IPv4 anytime soon. > > As I've said for years, I think email and the web will be the last applications to fully migrate to IPv6. It's not that I doubt the access providers' resolve to migrate their email services. It's that I think that all of those enterprises out there that are running their own mail systems will be slow to upgrade, and it will still be necessary to accept mail from them and deliver it to them. > > But I think it's a good idea to encourage operators (not just access, but enterprise also) to start rolling out SMTP over v6 so that they can get experience with it. > > Keith > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001485f1d81ef9b87304a8e62561 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 24, 2011 9:36 PM, "Keith Moore" <moore@network-heretics.com> wrote:
>
>
> On Jul 25, 2011, at 12:00 AM, Michael Newbery wrote:
>
> >
> > On 23/07/2011, at 5:32 AM, Keith Moore wrote:
> >
> >> On Jul 22, 2011, at 11:59 AM, Fred Baker wrote:
> >>
> >>> On Jul 22, 2011, at 8:20 AM, Gert Doering wrote:
> >>>
> >>>> You don't need universal availability on the last= DSL line to have IPv6 *on servers*.
> >>>
> >>> and by the way, the entire series of MUA/MTA and MTA/MTA = links don't have to have IPv6 for it to be used on some of them. If one= end user is IPv6-only, the other is IPv4-only, and at least one MTA in bet= ween is dual, nobody should notice an issue.
> >>>
> >>> My initial comment to Michael, when he pointed the draft = out to me, was that email seems like the poster child of an easy applicatio= n to add IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support = it already and the current OS's support IPv6. The primary thing prevent= ing mail/IPv6 is network IPv6 deployment, which is in progress.
> >>
> >> I guess my view is sort of the opposite - there's really = little point to upgrading mail to use IPv6 until most of the net has IPv6 a= ccess.
>
> I probably should say at the outset that my position on this has shift= ed a bit. =A0I now do think that there's some point to rolling out IPv6= email if for no other reason than to gain experience with it (and especial= ly spam filtering in the IPv6 environment) before the deluge hits. =A0 Beca= use there will come a point at which IPv4 will be abandoned on a massive sc= ale, and at that point everyone who has been relying on IPv4 to send mail w= ill suddenly start using IPv6.
>
> > [ignoring for the moment the ongoing discussion on spam and *-lis= ts]
> >
> > You need up upgrade mail to use IPv6 as soon as
> > * you have customers that only have IPv6 transport
> > * there is any significant amount of traffic that is IPv6 only >
> I don't disagree with the above. =A0However:
>
> - Is anyone really planning on offering _only_ IPv6 transport anytime = soon, as opposed to IPv6 with some sort of NATed IPv4 access, perhaps tunne= led over IPv6? =A0I have a difficult time believing that anyone wants to of= fer customers a service that won't let them access 99.9% of the current= Internet. =A0 At the very least I think the provider would give them a web= proxy to let them access v4 only content, an SMTP forwarder to let them se= nd mail to domains that only have v4 MXes, and an SMTP server that can act = as a backup MX, relaying incoming IPv4 mail to the customer's v6-only S= MTP server.
>

Yes, ipv6 only + nat64 is a real and tactical near term architecture doc= umented in ietf, 3gpp, and gsma. This architecture is deployed in beta at t= -mobile USA and will transition to production real soon now for wireless de= vices.

I am just providing you a data point on why native v6, especially mobile= clients and the services they access (email ...), is very important in the= near term to avoid nat44 and nat64 on various access networks.

Cb

> - Similarly, at least in the near future, anyone who wants their ma= il to be delivered is going to have to be able to send to IPv4 MXes, so I d= on't think that there will be a significant amount of SMTP traffic that= cannot fall back to IPv4 anytime soon.
>
> As I've said for years, I think email and the web will be the last= applications to fully migrate to IPv6. =A0 It's not that I doubt the a= ccess providers' resolve to migrate their email services. =A0It's t= hat I think that all of those enterprises out there that are running their = own mail systems will be slow to upgrade, and it will still be necessary to= accept mail from them and deliver it to them.
>
> But I think it's a good idea to encourage operators (not just acce= ss, but enterprise also) to start rolling out SMTP over v6 so that they can= get experience with it.
>
> Keith
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--001485f1d81ef9b87304a8e62561-- From pch-b2B3A6689@u-1.phicoh.com Mon Jul 25 09:35:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D0E21F8456 for ; Mon, 25 Jul 2011 09:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.404 X-Spam-Level: X-Spam-Status: No, score=-8.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcoAFxHI0lJW for ; Mon, 25 Jul 2011 09:35:26 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3D01421F8438 for ; Mon, 25 Jul 2011 09:35:23 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QlO7h-0001hNC; Mon, 25 Jul 2011 18:35:17 +0200 Message-Id: To: Joel Jaeggli From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <11072209372672_B93@oregon.uoregon.edu> <4E2D05F5.2060506@umn.edu> <16B4EC40-4960-4AD6-9B84-0820C3C13ABA@bogus.com> In-reply-to: Your message of "Mon, 25 Jul 2011 06:43:53 -0400 ." <16B4EC40-4960-4AD6-9B84-0820C3C13ABA@bogus.com> Date: Mon, 25 Jul 2011 18:35:07 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:35:27 -0000 In your letter dated Mon, 25 Jul 2011 06:43:53 -0400 you wrote: > >On Jul 25, 2011, at 1:58 AM, David Farmer wrote: >> >> Additionally, It should be possible to adapt the current IPv4 reputation bas >ed solutions for some of the IPv6 transition technologies as well. With 6to4, >Teredo, and ISATAP the IPv4 address that is embedded in the IPv6 address can b >e extracted and used as an IPv4 address to be looked-up in DNSBLs. > >I am rather unclear on the advisability and for some reason really wary of usi >ng transition technologies in the addressing of servers. > >> 6to4 is trivial; >> 2002:[IPv4 Address]:: >From the context I assumed this would be about blacklists. And in that case, spammers don't care whether we think it is advisable to use transition technologies for sending e-mail. From moore@network-heretics.com Mon Jul 25 10:21:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE89721F8545 for ; Mon, 25 Jul 2011 10:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIjeMPATyxEb for ; Mon, 25 Jul 2011 10:21:02 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFF221F85C7 for ; Mon, 25 Jul 2011 10:20:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id C3E9C20729; Mon, 25 Jul 2011 13:20:57 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 25 Jul 2011 13:20:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=pdP qu/Jbc8NFiNTSUpb80CNNNRc=; b=b1INZUtB6wtBHjmjf6nJ+kBXyVMv5mYiO25 kQ1lu3A6SAOt3JV6Mr+YIcmJhSmDChHHovk3UUm0/mPd40xMkl/3Mapq3dRdlxlC acnGEP9HZ1id5lAF85mJckKy9opziXbcZ0lKU4kaSRSABRObplYcjalYRL5ThYhf pf0R4+pE= X-Sasl-enc: H9tPUND0crpqavILQt4RrADglJpQfXGsJp6TIPoNIEwi 1311614457 Received: from dhcp-336e.meeting.ietf.org (dhcp-336e.meeting.ietf.org [130.129.51.110]) by mail.messagingengine.com (Postfix) with ESMTPSA id 8B4E94137C5; Mon, 25 Jul 2011 13:20:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8-447292158 From: Keith Moore In-Reply-To: Date: Mon, 25 Jul 2011 13:20:57 -0400 Message-Id: <17C1380A-741C-4BF5-8C8F-C4C4460D98EE@network-heretics.com> References: <11072209372672_B93@oregon.uoregon.edu> <4E2D05F5.2060506@umn.edu> <16B4EC40-4960-4AD6-9B84-0820C3C13ABA@bogus.com> To: Tim Chown X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG , Keith Moore Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:21:03 -0000 --Apple-Mail-8-447292158 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 25, 2011, at 10:32 AM, Tim Chown wrote: > On 25 Jul 2011, at 11:43, Joel Jaeggli wrote: >=20 >> On Jul 25, 2011, at 1:58 AM, David Farmer wrote: >>>=20 >>> Additionally, It should be possible to adapt the current IPv4 = reputation based solutions for some of the IPv6 transition technologies = as well. With 6to4, Teredo, and ISATAP the IPv4 address that is embedded = in the IPv6 address can be extracted and used as an IPv4 address to be = looked-up in DNSBLs. >>=20 >> I am rather unclear on the advisability and for some reason really = wary of using transition technologies in the addressing of servers. >=20 > I agree; I wouldn't expect to see any of ISATAP, Teredo or 6to4 to be = used for MXes, or indeed any of our internal enterprise infrastructure. For the purposes of this argument, it doesn't really matter whether = these addresses are used for inbound mail (MXes); what matters is = whether they're used for outbound mail. =20 I'm sure that a few people will want to source or sink mail using 6to4, = or Teredo. But I guess I'd be surprised if it became a common enough = practice that it was worth the trouble to try to leverage IPv4 address = reputation services to evaluate incoming IPv6 mail from those kinds of = addresses. Keith --Apple-Mail-8-447292158 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 25 Jul 2011, at 11:43, = Joel Jaeggli wrote:

On Jul 25, = 2011, at 1:58 AM, David Farmer wrote:

Additionally, It should be = possible to adapt the current IPv4 reputation based solutions for some = of the IPv6 transition technologies as well. With 6to4, Teredo, and = ISATAP the IPv4 address that is embedded in the IPv6 address can be = extracted and used as an IPv4 address to be looked-up in = DNSBLs.

I am rather = unclear on the advisability and for some reason really wary of using = transition technologies in the addressing of = servers.

I agree; I wouldn't expect to see any of = ISATAP, Teredo or 6to4 to be used for MXes, or indeed any of our = internal enterprise = infrastructure.

For the purposes of = this argument, it doesn't really matter whether these addresses are used = for inbound mail (MXes); what matters is whether they're used for = outbound mail.
 
I'm sure that a few people = will want to source or sink mail using 6to4, or Teredo.  But I = guess I'd be surprised if it became a common enough practice that it was = worth the trouble to try to leverage IPv4 address reputation services to = evaluate incoming IPv6 mail from those kinds of = addresses.

Keith


<= /html>= --Apple-Mail-8-447292158-- From tjc@ecs.soton.ac.uk Mon Jul 25 10:46:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C5021F88A6 for ; Mon, 25 Jul 2011 10:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yImxHbOxhyEa for ; Mon, 25 Jul 2011 10:46:48 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEEB21F8888 for ; Mon, 25 Jul 2011 10:46:47 -0700 (PDT) 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 p6PHkhl6001861 for ; Mon, 25 Jul 2011 18:46:43 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p6PHkhl6001861 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1311616003; bh=VWdkH/qbRiPgMJ4/kxPgYKTArgM=; h=From:Mime-Version:Subject:Date:In-Reply-To:To:References; b=TaAYaeHNWiPUBthsbLXLJx83l468y3n6FNuu3o8tXYrkiIvTDw9OBpy+Cdc8cPuu6 0+eL293qkUDNw+dNhrWPGfiWjj00deLUUcM8J9aDloBIv1EPIOLVDj5NLUbhTiHyUS 23AGUc5YBWmPBTaUEBuUeWgP+M190p4L/e4E5C5g= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n6OIkh0366130836F2 ret-id none; Mon, 25 Jul 2011 18:46:43 +0100 Received: from [IPv6:2001:df8::112:f067:81ef:d232:d3bb] ([IPv6:2001:df8:0:112:f067:81ef:d232:d3bb]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p6PHkX9I004688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 25 Jul 2011 18:46:34 +0100 From: Tim Chown Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_0705C81D-8BA8-4E40-B410-0F82116706B7" Date: Mon, 25 Jul 2011 18:46:31 +0100 In-Reply-To: <17C1380A-741C-4BF5-8C8F-C4C4460D98EE@network-heretics.com> To: IPv6 Ops WG References: <11072209372672_B93@oregon.uoregon.edu> <4E2D05F5.2060506@umn.edu> <16B4EC40-4960-4AD6-9B84-0820C3C13ABA@bogus.com> <17C1380A-741C-4BF5-8C8F-C4C4460D98EE@network-heretics.com> <22679673-7819-4E48-9C83-3C2294682605@ecs.soton.ac.uk> Message-ID: X-Mailer: Apple Mail (2.1244.3) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n6OIkh036613083600; tid=n6OIkh0366130836F2; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p6PHkhl6001861 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:46:49 -0000 --Apple-Mail=_0705C81D-8BA8-4E40-B410-0F82116706B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25 Jul 2011, at 18:20, Keith Moore wrote: > On Jul 25, 2011, at 10:32 AM, Tim Chown wrote: >=20 >> On 25 Jul 2011, at 11:43, Joel Jaeggli wrote: >>=20 >>> On Jul 25, 2011, at 1:58 AM, David Farmer wrote: >>>>=20 >>>> Additionally, It should be possible to adapt the current IPv4 = reputation based solutions for some of the IPv6 transition technologies = as well. With 6to4, Teredo, and ISATAP the IPv4 address that is embedded = in the IPv6 address can be extracted and used as an IPv4 address to be = looked-up in DNSBLs. >>>=20 >>> I am rather unclear on the advisability and for some reason really = wary of using transition technologies in the addressing of servers. >>=20 >> I agree; I wouldn't expect to see any of ISATAP, Teredo or 6to4 to be = used for MXes, or indeed any of our internal enterprise infrastructure. >=20 > For the purposes of this argument, it doesn't really matter whether = these addresses are used for inbound mail (MXes); what matters is = whether they're used for outbound mail. > =20 > I'm sure that a few people will want to source or sink mail using = 6to4, or Teredo. But I guess I'd be surprised if it became a common = enough practice that it was worth the trouble to try to leverage IPv4 = address reputation services to evaluate incoming IPv6 mail from those = kinds of addresses. I meant both inbound and outbound. Enterprises will tend to force SMTP = through its own relays regardless. Tim --Apple-Mail=_0705C81D-8BA8-4E40-B410-0F82116706B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jul 25, 2011, at = 10:32 AM, Tim Chown wrote:

On 25 = Jul 2011, at 11:43, Joel Jaeggli wrote:

On Jul 25, 2011, at 1:58 AM, David Farmer = wrote:

Additionally, It should be = possible to adapt the current IPv4 reputation based solutions for some = of the IPv6 transition technologies as well. With 6to4, Teredo, and = ISATAP the IPv4 address that is embedded in the IPv6 address can be = extracted and used as an IPv4 address to be looked-up in = DNSBLs.

I am rather = unclear on the advisability and for some reason really wary of using = transition technologies in the addressing of = servers.

I agree; I wouldn't expect to see any of = ISATAP, Teredo or 6to4 to be used for MXes, or indeed any of our = internal enterprise = infrastructure.

For the purposes of = this argument, it doesn't really matter whether these addresses are used = for inbound mail (MXes); what matters is whether they're used for = outbound mail.
 
I'm sure that a few people = will want to source or sink mail using 6to4, or Teredo.  But I = guess I'd be surprised if it became a common enough practice that it was = worth the trouble to try to leverage IPv4 address reputation services to = evaluate incoming IPv6 mail from those kinds of = addresses.

I meant both inbound = and outbound.  Enterprises will tend to force SMTP through its own = relays regardless.

Tim

= --Apple-Mail=_0705C81D-8BA8-4E40-B410-0F82116706B7-- From dwing@cisco.com Mon Jul 25 11:03:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FC721F87AF for ; Mon, 25 Jul 2011 11:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.395 X-Spam-Level: X-Spam-Status: No, score=-105.395 tagged_above=-999 required=5 tests=[AWL=-0.796, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBdQR82w3RAx for ; Mon, 25 Jul 2011 11:03:09 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1497721F8BEF for ; Mon, 25 Jul 2011 11:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=11435; q=dns/txt; s=iport; t=1311616989; x=1312826589; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=jRmY56nAbU3wc1dq529hBGNVnEvJKJUmrpNi4nffIe4=; b=EzJRHqEGmHjCw7BuiM26R3SlVooDDAautQufc0leaXkytX1JeydfYjl6 PB6WkkAedcj1wgM2aLAyND4gZqtf6YItmb80JKxBv1Shap5SxM3/qAPOn YaSbh9hRg7pNGYlwJCTBh1hQLTAw1f5VxneM5oaYYt2go3NPtkvAfsCd5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8AAJKvLU6rRDoH/2dsb2JhbAA0AQEBAQIBCAwBGxBFDAEEAgoOAQICAgEBATMHFAYoDQ4IAQEFFw0CGJdbgWuNbHeIfASheJ4chj8Eo2w X-IronPort-AV: E=Sophos;i="4.67,263,1309737600"; d="scan'208";a="6206853" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 25 Jul 2011 18:03:08 +0000 Received: from dwingWS (sjc-vpn5-1896.cisco.com [10.21.95.104]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6PI363Y020736; Mon, 25 Jul 2011 18:03:07 GMT From: "Dan Wing" To: "'Philip Homburg'" References: Your message of "Mon, 11 Jul 2011 09:15:03 -0700 ." <20110711161503.10931.6058.idtracker@ietfa.amsl.com> <04fc01cc4815$753cbe50$5fb63af0$@com> In-Reply-To: Date: Mon, 25 Jul 2011 14:03:04 -0400 Message-ID: <06e901cc4af5$1b365410$51a2fc30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxJ6JDz2diNG5iHTE2jeO0GD0xETwBCU2iQ Content-Language: en-us Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:03:10 -0000 > -----Original Message----- > From: pch-b2B3A6689@u-1.phicoh.com [mailto:pch-b2B3A6689@u- > 1.phicoh.com] On Behalf Of Philip Homburg > Sent: Sunday, July 24, 2011 6:01 AM > To: Dan Wing > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt > > In your letter dated Thu, 21 Jul 2011 19:17:08 -0700 you wrote: > >> Section 4.1 > >> > >> In my opinion the MUST is too strong. I think a SHOULD is more than > >> enough. > >> But more importantly, Section 4.2 qualifies that MUST. I think that > >> either > >> 4.1 should contain a description of when MUST can be violated or it > >> should > >> explicitly forward reference 4.2. In my opinion it is important that > >> requirements are as self-contained as possible. > > > >You're referring to: > > > > Happy Eyeballs implementations MUST follow the host's address > > preference policy or, if that policy is unknown, implementations > MUST > > prefer IPv6 over IPv4. > > > > Justification: This reduces load on stateful IPv4 middleboxes > > (NAT and firewalls) and reduces IPv4 address sharing contention. > > > >and I guess you're referring to that first MUST ("MUST follow the > host's > >address preference policy"). > > Yes. > > >As for MUST versus SHOULD, how is this: > > > > A Happy Eyeballs implementations MUST follow the host's > > address preference policy, unless the conditions > > in Section 4.2 apply). If the host's policy is unknown or > > not attainable, implementations MUST prefer IPv6 over IPv4. > > > >I clarified 4.2 to better describe the implementation as stateful > >(that is, the implementation notices that IPv6 is always failing). > > Yes, that is fine. > > >> Section 4.2 > >> > >> In think that Section 4.2 should explain what 'failed' means. > > > >Is this sufficient? > > > > After making a connection attempt on the preferred address > > family (e.g., IPv6), and failing to establish a connection > > within a certain time period, a Happy Eyeballs implementation > > will decide to initiate a second connection attempt using the > > other address family (e.g., IPv4). > > In that case, I think you need some text about what 'a certain time > period' > is. For example, that an implementation may have a static value, or > that > it may determine this value dynamically by observing IPv4 and IPv6 > connect > times. > > >> Obviously, > >> if a protocol doesn't work at all, it should be considered failed. > But > >> I think > >> that in many cases, a tunnel that always adds 200 ms latency can be > >> considered > >> as failing as well. > >> > >> (my own algorithm just connects to whatever works best, without > trying > >> to declare something as failed). > > > >I would classify the Chrome and Firefox algorithms as also connecting > >to what 'works best', giving IPv6 a ~200ms head start. > > I don't think this particular algorithm connects to what works best. It > just > limits the damage that can be done by a failing IPv6 link to 200ms of > additional latency. Agreed that some history ("state") of past success/failure would be helpful to predict future success/failure, which would achieve something closer to "what works best". > >> Section 5.5 > >> > >> I quickly read the (by now expired) draft on Same Origin Policy and > I > >> didn't > >> find anything that directly deal with IP addresses. > > > >The Wiki page is a little better, and explains that there is no > >canonical definition of Same Origin Policy. A better reference > >might be "to avoid DNS rebinding attacks", which is what really > >encourages web browsers to sandbox their traffic to the same IP > >address without regard to DNS TTLs or anything else. But, I > >imagine that could be considered part of the "same origin policy". > > > >I'm not a browser person, so guidance for a better citation is > >certainly welcome. > > I'd say that unless there is a standard that defines the Same Origin > Policy, > Happy Eyeballs should not have an normative text regarding it. > > Of course, it doesn't do any harm to point out to readers that Happy > Eyeballs > may conclict with this policy. > > I guess that in practice, if you already know which address to are > going to > connect to (because the policy only allows you to connect to the same > address > as before) there will be no need for HE anyhow. Sure, but Same Origin Policy only affects subsequent connections to a host -- not the first connection). Optimizing that first connection to a host is critical and what H.E. is primarily concerned with optimizing. > >> 1) > >> > >> Playing with my own HE implementation I arrived a the following > >> prototype for > >> the library function that provides it: > >> > >> int tcp_connect_to_name(char *hostname, char *portname, int > *gai_errp, > >> struct timeval *tv); > >> > >> I think application portability will be enhanced if HE > implementations > >> provide > >> similar features. There is also no need for OS implementors to all > >> reinvent > >> the wheel. > > > >Mark Andrews had a different prototype. I don't have any preference, > >of course. But I want to finish this I-D. > > Easy way forward is to list both for the time being and try to get > people to > express a preference. > > I don't care so much which one gets picked, as long as we do what we > can to get one function standardized across platforms. With the OSX Lion implementation, which affects both getaddrinfo() [to reorder responses based on speed of previous IPv6 / IPv4 connections] and the OSX-specific libraries, http://www.ietf.org/mail-archive/web/v6ops/current/msg09805.html, I am even more reluctant to try to document One Algorithm To Rule Them All. > >> 2) > >> > >> In practice, a DNS RR set may contain more than just one IPv4 and > one > >> IPv6 > >> address. It may be a good idea to add some discussion about this. > > > >
> >It is possible that an DNS query for an A or AAAA resource > >record will return more than one A or AAAA address. When this > >occurs, it is RECOMMENDED that a Happy Eyeballs implementation > >order the responses following the host's address preference > >policy and then try the first address. If that fails after > >a certain time, the next address SHOULD be the IPv4 address. > > > >This means that a Happy Eyeballs implementation will not > >try other IPv6 addresses that are returned; effecitively, the > >Happy Eyeballs implementation will behave as if only one > >address was returned. > >
> > This is not good. Eventually, a host has to try all addresses in a RR > set. > > So after the first IPv6 address and the first IPv4 address it has to > try > all other addresses, the order doesn't really matter, so the order > returned by > getaddrinfo is probably best. Thanks. Adjusted to read: If that fails to connect after a certain time (see ), a Happy Eyeballs implementation SHOULD try the other addresses returned; the order of these connection attempts is not important. > >> 3) > >> > >> In practice, local IPv6 connections may still work while the link to > >> the > >> outside world is broken. What does 'failed' mean in this context? > > > > If connections using the preferred address family are > successful, > >the > > preferred address family SHOULD be used for subsequent > > connections. > > I guess that if an implementation notices that some (local) connections > succeed but others don't, it can violate the SHOULD. Yes. I don't want to get into all the reasons to violate the SHOULD; that can become too restrictive (if we don't list all the reasons to violate the SHOULD). > >> 4) > >> > >> What happens if I take the same algorithm as Google used in Chrome > but > >> I > >> set the timer to 30 ms instead of 300? Is that considered an > acceptable > >> HE > >> implementation according to this draft? > > > > > >Yes. The normative text does not define the duration of the delay > >between trying IPv6 and trying IPv4. In fact, you could try them both > >at the same time -- so long as the IPv6 one is "preferred" (by some > >definition of preferred), and the network is not thrashed with > >simultaneous connections. Complex algorithms, such as what we > >had earlier in draft-ietf-v6ops-happy-eyeballs, achieve this. As > >do simple algorithms such as what is in Chrome and Firefox. > > I don't think it would good idea if a popular product would start with > IPv6 > and then connects to IPv4 10ms later. That effectively double the > connect > load on content, keep a huge load on any kind of CGN, and would > effectively > make it impossible to phase out IPv4 because there will all be a huge > number of > connects over IPv4. > > So I think that ideally, the document should give some performance > requirements. I.e. a HE implementation should connect to just one > address in > over xx% of the cases, with xx close to 100. > > That may not be feasable. So some text that the implementor of HE > should ensure > that the parameters used are conservative enough that in most cases > only one > address is connected to. Or something like that. How is this:
The primary purpose of Happy Eyeballs is to reduce the wait time for a dual stack connection to complete, especially when the IPv6 path is broken and IPv6 is preferred. Aggressive time outs (on the order of tens of milliseconds) achieve this goal, but at the cost of network traffic. This network traffic may be billable on certain networks, will create state on some middleboxes (e.g., firewalls, IDS, NAT), and will consume ports if IPv4 addresses are shared. For these reasons, it is RECOMMENDED that connection attempts be paced to give connections a chance to complete. It is RECOMMENDED that connections attempts be paced 150-250ms apart. Stateful algorithms are expected to be more aggressive (that is, make connection attempts closer together), as stateful algorithms maintain an estimate of the expected connection completion time.
> >> 5) > >> > >> This draft sometimes talks about an entire address family (for > example > >> Section 4.2) but in other places (Section 4) it's about addresses > for > >> an > >> individual host. I think this should be make more clear in Sections > 4.1 > >> and 4.2. > > > >I don't know how to best fix all of that, especially if we consider > >that a host could have an IPv4-mapped IPv6 address in DNS (ugly, but > >it happens) as well as a real IPv4 address. That is, I don't know > >if it's best to talk about "address family" or "address" throughout > >the document. > > Ultimately, the connect happens over IPv4 or IPv6. So given the level > of > detail in the draft, address family (or maybe protocol) would be best, > except where you talk about individual addresses returned by > getaddrinfo, > there it would an address that belong to a certain address family. Let's take that offline. -d From scott.brim@gmail.com Mon Jul 25 11:09:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563A021F8B0F for ; Mon, 25 Jul 2011 11:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMBiE3AQMM9l for ; Mon, 25 Jul 2011 11:09:38 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6C9921F8C0B for ; Mon, 25 Jul 2011 11:09:19 -0700 (PDT) Received: by yxp4 with SMTP id 4so2974502yxp.31 for ; Mon, 25 Jul 2011 11:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:from:date:message-id:subject:to :cc:content-type; bh=+neAa1L8I2qkuc9RPgCknfRh6LMcFOS+nvZeO8wzguU=; b=B3v1MTpDpQzt9xNvIOL1QIOaGRQUCbk76WlWjyBevi6FpVxYpOzo5Qbuz8cwNTPxKZ ubKvkJ6U00pdgE3JWcD7x5yr/vncg6dkz8B9lZ2CYwit78WotG6+dXJIK9ogVOi58Ztp yRiJaXAMslXmKZUTxpSOnXvCGIgM7B5m7EHV4= Received: by 10.231.91.16 with SMTP id k16mr4957996ibm.124.1311617359103; Mon, 25 Jul 2011 11:09:19 -0700 (PDT) References: <20110711161503.10931.6058.idtracker@ietfa.amsl.com> <04fc01cc4815$753cbe50$5fb63af0$@com> <06e901cc4af5$1b365410$51a2fc30$@com> In-Reply-To: <06e901cc4af5$1b365410$51a2fc30$@com> Mime-Version: 1.0 (iPad Mail 8J2) From: Scott Brim Date: Mon, 25 Jul 2011 14:09:45 -0400 Message-ID: <-4474388752195637481@unknownmsgid> To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:09:49 -0000 On Jul 25, 2011, at 14:03, "Dan Wing" wrote: > I don't want to get into all the reasons to violate the SHOULD; that > can become too restrictive (if we don't list all the reasons to violate > the SHOULD). Typically this is done by listing examples of _classes_ of issues, so that the implementor at least knows the kinds of situations where violation might be reasonable. It's good to justify SHOULDs because humans are such a varied lot. Some vendors ignore all SHOULDs and implement only MUSTs, while others implement all. Some customers take SHOULDs as MUSTs and insist that a vendor must implement them even if they can't use them, and so on. From dwing@cisco.com Mon Jul 25 11:43:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABAD11E8097 for ; Mon, 25 Jul 2011 11:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.357 X-Spam-Level: X-Spam-Status: No, score=-104.357 tagged_above=-999 required=5 tests=[AWL=-1.758, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da+-7jjnpZS1 for ; Mon, 25 Jul 2011 11:43:43 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0031611E8093 for ; Mon, 25 Jul 2011 11:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1449; q=dns/txt; s=iport; t=1311619423; x=1312829023; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=t+ADJeirCZ00mNc8P6wIAuSOHOCe0ynbioqjkVR3DAM=; b=FrowQW09AgRDdBulz3f4FIkB0+3fVOhbG7L3KO+MbADrr0peBqX9fSXg PTsEV7zHRsSyKH2ueqAeBlmbd/OI9kL2Q2Yu2pVdPcdhXqX0Ym8/SyhTD 2VuvaRah7iOxoRmFR5gjuV9Qu1uZi8vPZBV452/KB4XO6hiJRTioIhmh3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8AAE+4LU6rRDoI/2dsb2JhbAA0AQEBAQMIDAEbEEUMAQQCCg8CBAEBATMHFAYMHA0OCAEBBRcPGJdbgWuNbHeqbZ4khj8EnFmHEw X-IronPort-AV: E=Sophos;i="4.67,264,1309737600"; d="scan'208";a="6225054" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-7.cisco.com with ESMTP; 25 Jul 2011 18:43:42 +0000 Received: from dwingWS (sjc-vpn5-1896.cisco.com [10.21.95.104]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6PIhfmb001305; Mon, 25 Jul 2011 18:43:41 GMT From: "Dan Wing" To: "'Scott Brim'" References: <20110711161503.10931.6058.idtracker@ietfa.amsl.com> <04fc01cc4815$753cbe50$5fb63af0$@com> <06e901cc4af5$1b365410$51a2fc30$@com> <-4474388752195637481@unknownmsgid> In-Reply-To: <-4474388752195637481@unknownmsgid> Date: Mon, 25 Jul 2011 14:43:41 -0400 Message-ID: <071601cc4afa$c68de850$53a9b8f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxK9fl8iP5ctCYQQBuStQuqlQx4rwABLvYA Content-Language: en-us Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 18:43:43 -0000 > -----Original Message----- > From: Scott Brim [mailto:scott.brim@gmail.com] > Sent: Monday, July 25, 2011 2:10 PM > To: Dan Wing > Cc: Philip Homburg; v6ops@ietf.org > Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-happy-eyeballs-03.txt > > On Jul 25, 2011, at 14:03, "Dan Wing" wrote: > > I don't want to get into all the reasons to violate the SHOULD; that > > can become too restrictive (if we don't list all the reasons to > violate > > the SHOULD). > > Typically this is done by listing examples of _classes_ of issues, so > that the implementor at least knows the kinds of situations where > violation might be reasonable. > > It's good to justify SHOULDs because humans are such a varied lot. > Some vendors ignore all SHOULDs and implement only MUSTs, while others > implement all. Some customers take SHOULDs as MUSTs and insist that a > vendor must implement them even if they can't use them, and so on. Good point. How is this: If connections using the preferred address family are successful, the preferred address family SHOULD be used for subsequent connections. Because this implementation is stateful, it MAY track connection success (or failure) based on IPv6 or IPv4 prefix (e.g., connections to the same prefix assigned to the interface are successful whereas connections to other prefixes are failing). -d From farmer@umn.edu Mon Jul 25 16:34:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A55311E80D7 for ; Mon, 25 Jul 2011 16:34:01 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aattO7T7U7fF for ; Mon, 25 Jul 2011 16:34:00 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 685DA11E80B1 for ; Mon, 25 Jul 2011 16:34:00 -0700 (PDT) Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 25 Jul 2011 18:33:50 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-iy0-f171.google.com [209.85.210.171] #+LO+TR X-Umn-Classification: local Received: by iyi12 with SMTP id 12so8515478iyi.16 for ; Mon, 25 Jul 2011 16:33:50 -0700 (PDT) Received: by 10.231.114.29 with SMTP id c29mr5232808ibq.16.1311636830128; Mon, 25 Jul 2011 16:33:50 -0700 (PDT) Received: from x-128-101-235-186.uofm-secure.wireless.umn.edu (x-128-101-235-186.uofm-secure.wireless.umn.edu [128.101.235.186]) by mx.google.com with ESMTPS id b6sm3436482ibg.31.2011.07.25.16.33.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 16:33:48 -0700 (PDT) Message-ID: <4E2DFD59.5080707@umn.edu> Date: Mon, 25 Jul 2011 18:33:45 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: IPv6 Ops WG References: <11072209372672_B93@oregon.uoregon.edu> <4E2D05F5.2060506@umn.edu> <16B4EC40-4960-4AD6-9B84-0820C3C13ABA@bogus.com> <17C1380A-741C-4BF5-8C8F-C4C4460D98EE@network-heretics.com> <22679673-7819-4E48-9C83-3C2294682605@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Keith Moore Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 23:34:01 -0000 On 7/25/11 12:46 CDT, Tim Chown wrote: > > On 25 Jul 2011, at 18:20, Keith Moore wrote: > >> On Jul 25, 2011, at 10:32 AM, Tim Chown wrote: >> >>> On 25 Jul 2011, at 11:43, Joel Jaeggli wrote: >>> >>>> On Jul 25, 2011, at 1:58 AM, David Farmer wrote: >>>>> >>>>> Additionally, It should be possible to adapt the current IPv4 >>>>> reputation based solutions for some of the IPv6 transition >>>>> technologies as well. With 6to4, Teredo, and ISATAP the IPv4 >>>>> address that is embedded in the IPv6 address can be extracted and >>>>> used as an IPv4 address to be looked-up in DNSBLs. >>>> >>>> I am rather unclear on the advisability and for some reason really >>>> wary of using transition technologies in the addressing of servers. >>> >>> I agree; I wouldn't expect to see any of ISATAP, Teredo or 6to4 to be >>> used for MXes, or indeed any of our internal enterprise infrastructure. >> >> For the purposes of this argument, it doesn't really matter whether >> these addresses are used for inbound mail (MXes); what matters is >> whether they're used for outbound mail. >> I'm sure that a few people will want to source or sink mail using >> 6to4, or Teredo. But I guess I'd be surprised if it became a common >> enough practice that it was worth the trouble to try to leverage IPv4 >> address reputation services to evaluate incoming IPv6 mail from those >> kinds of addresses. > > I meant both inbound and outbound. Enterprises will tend to force SMTP > through its own relays regardless. I probably agree that it is not advisable to IPv6 transition technologies for email delivery, especially 6to4, Teredo, and ISATAP. However, the discussion of IPv6 transition technologies being used to deliver email is explicitly brought up in the draft, further 6to4, Teredo, and ISATAP are not explicitly excluded. So, If we really think it is NOT advisable to use IPv6 transition technologies in general, or that some are OK, like managed tunnels and 6rd, while others are not like 6to4, Teredo, and ISATAP. Then the draft should say that and not what it currently says; From Section 5; "IPv6-based email services MAY be provided via IPv6 transition mechanisms (such as those described in [RFC4213], for example) or via native IPv6 network service." From Section 6; "IPv6-based email service SHOULD be via native IPv6 network service but MAY be via IPv6 transition mechanisms if necessary" Additionally, if we really think it is not advisable to use specifically 6to4 and Teredo, since they use generic IPv6 prefixes. Then we should probably suggest blacklisting email from the 2002::/16 and 2001::/32 prefixes in the draft as well. Because, I have the suspicion that they are going to be especially problematic if you don't out and out blacklist them or at least use DNSBL on the associated IPv4 address as I discussed in my previous post. As was mentioned in another reply; On 7/25/11 11:35 CDT, Philip Homburg wrote: > From the context I assumed this would be about blacklists. And in that > case, spammers don't care whether we think it is advisable to use transition > technologies for sending e-mail. +1 to that. There was a suggestion to move the abuse issues out of this draft, I'm neutral on that one way or the other. However, even if the more general email abuse issues for IPv6 are move to another draft, I think the specific issue of IPv6 transition technologies, and possibly blacklisting the 6ro4 and Teredo prefixes should probably remain in this draft. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From moore@network-heretics.com Mon Jul 25 17:25:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7C921F86BB for ; Mon, 25 Jul 2011 17:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRcqwY2uoz5h for ; Mon, 25 Jul 2011 17:25:18 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id B8F6121F86AA for ; Mon, 25 Jul 2011 17:25:18 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 26AA520B42; Mon, 25 Jul 2011 20:25:18 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 25 Jul 2011 20:25:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=Diu AP+T78s8/lAkUFpkqzPIsms4=; b=dcGNif6guN7OEixbc0rIs+UYSRRrbLbsCH3 KvN3epVfqprtacGWMGXG00YdRktQBxKH1QWwC33JUUw18tOgemfO/1nBK4z49Gjq FFHptl1HcoET52ruLt2PIIuP+Eva3HvPZJZfzXQdMUdbzg6OVb2o6gAMC+esGGfg Xs1JkkY4= X-Sasl-enc: bHAs1HJoVDnorIwKy/2iHxsz8HGNT+Ok9zgNnk6bVE4Y 1311639917 Received: from [192.168.210.100] (modemcable114.145-70-69.static.videotron.ca [69.70.145.114]) by mail.messagingengine.com (Postfix) with ESMTPSA id 778EF4139E1; Mon, 25 Jul 2011 20:25:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-31-472751243 From: Keith Moore In-Reply-To: <4E2DFD59.5080707@umn.edu> Date: Mon, 25 Jul 2011 20:25:16 -0400 Message-Id: <1B0A5DCD-B5BE-4A52-977A-B28D9C9E54D0@network-heretics.com> References: <11072209372672_B93@oregon.uoregon.edu> <4E2D05F5.2060506@umn.edu> <16B4EC40-4960-4AD6-9B84-0820C3C13ABA@bogus.com> <17C1380A-741C-4BF5-8C8F-C4C4460D98EE@network-heretics.com> <22679673-7819-4E48-9C83-3C2294682605@ecs.soton.ac.uk> <4E2DFD59.5080707@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG , Keith Moore Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 00:25:19 -0000 --Apple-Mail-31-472751243 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 25, 2011, at 7:33 PM, David Farmer wrote: >=20 > I probably agree that it is not advisable to IPv6 transition = technologies for email delivery, especially 6to4, Teredo, and ISATAP. = However, the discussion of IPv6 transition technologies being used to = deliver email is explicitly brought up in the draft, further 6to4, = Teredo, and ISATAP are not explicitly excluded. So, If we really think = it is NOT advisable to use IPv6 transition technologies in general, or = that some are OK, like managed tunnels and 6rd, while others are not = like 6to4, Teredo, and ISATAP. Then the draft should say that and not = what it currently says; >=20 > =46rom Section 5; > "IPv6-based email services MAY be provided via IPv6 transition = mechanisms (such as those described in [RFC4213], for example) or via = native IPv6 network service." >=20 > =46rom Section 6; > "IPv6-based email service SHOULD be via native IPv6 network service = but MAY be via IPv6 transition mechanisms if necessary" >=20 > Additionally, if we really think it is not advisable to use = specifically 6to4 and Teredo, since they use generic IPv6 prefixes. = Then we should probably suggest blacklisting email from the 2002::/16 = and 2001::/32 prefixes in the draft as well. Because, I have the = suspicion that they are going to be especially problematic if you don't = out and out blacklist them or at least use DNSBL on the associated IPv4 = address as I discussed in my previous post. I suspect that a wiser course of action is for this document to say as = little as possible about transition technologies, because it's hard to = tell what course v6 deployment will follow. It is possible that at = some point there will be significant portions of the network that have = no effective IPv4 access and therefore must receive mail via IPv6, and = that this will occur at a time that significant portions of the network = still do not have IPv6 access. If and when that happens, it might make = sense for the IPv4-only portions to use IPv6 transition technologies to = send mail to IPv6-only mail exchangers, and perhaps, to use transition = technologies to receive mail from IPv6-only senders. The point is, don't overconstrain the solution space. Also realize that email is considerably more tolerant of delays and = transient connectivity failures than, say, a person sitting at a web = browser. =20 > There was a suggestion to move the abuse issues out of this draft, I'm = neutral on that one way or the other. However, even if the more general = email abuse issues for IPv6 are move to another draft, I think the = specific issue of IPv6 transition technologies, and possibly = blacklisting the 6ro4 and Teredo prefixes should probably remain in this = draft. Blacklisting 6to4 and Teredo is silly and inappropriate unless you have = good reason to believe that they're sources of abusive mail. Keith --Apple-Mail-31-472751243 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I probably agree = that it is not advisable to IPv6 transition technologies for email = delivery, especially  6to4, Teredo, and ISATAP. However, the = discussion of IPv6 transition technologies being used to deliver email = is explicitly brought up in the draft, further 6to4, Teredo, and ISATAP = are not explicitly excluded.  So, If we really think it is NOT = advisable to use IPv6 transition technologies in general, or that some = are OK, like managed tunnels and 6rd, while others are not like 6to4, = Teredo, and ISATAP.  Then the draft should say that and not what it = currently says;

=46rom Section 5;
"IPv6-based email services = MAY be provided via IPv6 transition mechanisms (such as those described = in [RFC4213], for example) or via native IPv6 network = service."

=46rom Section 6;
"IPv6-based email service SHOULD = be via native IPv6 network service but MAY be via IPv6 transition = mechanisms if necessary"

Additionally, if we really think it is = not advisable to use specifically 6to4 and Teredo, since they use = generic IPv6 prefixes.  Then we should probably suggest = blacklisting email from the 2002::/16 and 2001::/32 prefixes in the = draft as well.  Because, I have the suspicion that they are going = to be especially problematic if you don't out and out blacklist them or = at least use DNSBL on the associated IPv4 address as I discussed in my = previous post.

I suspect that a = wiser course of action is for this document to say as little as possible = about transition technologies, because it's hard to tell what course v6 = deployment will follow.   It is possible that at some point there = will be significant portions of the network that have no effective IPv4 = access and therefore must receive mail via IPv6, and that this will = occur at a time that significant portions of the network still do not = have IPv6 access.   If and when that happens, it might make sense = for the IPv4-only portions to use IPv6 transition technologies to send = mail to IPv6-only mail exchangers, and perhaps, to use transition = technologies to receive mail from IPv6-only = senders.

The point is, don't overconstrain the = solution space.

Also realize that email is = considerably more tolerant of delays and transient connectivity failures = than, say, a person sitting at a web browser. =  

There was a = suggestion to move the abuse issues out of this draft, I'm neutral on = that one way or the other.  However, even if the more general email = abuse issues for IPv6 are move to another draft, I think the specific = issue of IPv6 transition technologies, and possibly blacklisting the = 6ro4 and Teredo prefixes should probably remain in this = draft.

Blacklisting 6to4 and Teredo = is silly and inappropriate unless you have good reason to believe that = they're sources of abusive = mail.

Keith

= --Apple-Mail-31-472751243-- From washam.fan@gmail.com Mon Jul 25 23:29:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9941D11E807E for ; Mon, 25 Jul 2011 23:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCZPMa4D-DgM for ; Mon, 25 Jul 2011 23:29:49 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id ACA4711E807C for ; Mon, 25 Jul 2011 23:29:48 -0700 (PDT) Received: by wwg11 with SMTP id 11so1979648wwg.1 for ; Mon, 25 Jul 2011 23:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=KPiWhEB+EcYcqD7GSloVlkEa4oaKtX9xBVFvJvtc52M=; b=UXgAUgLa2iU0+4z+nZLRo/HHXX9Yv6L05VGIHb6i2n0DVGpAUTKlkZhr2jqp/u3KZl yhoFa4jwjEOAzFOtGfgEL6ijOG0sQ9oWej+ARbL/VVDiiJ1aekbCCb0BdjYMaFnujvIE egXucJFtIb2TZSvop0C5FU9g/Df8t2ha9UsIo= MIME-Version: 1.0 Received: by 10.216.63.68 with SMTP id z46mr1182583wec.82.1311661787503; Mon, 25 Jul 2011 23:29:47 -0700 (PDT) Received: by 10.216.71.138 with HTTP; Mon, 25 Jul 2011 23:29:47 -0700 (PDT) Date: Tue, 26 Jul 2011 14:29:47 +0800 Message-ID: From: Washam Fan To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] slight comments on draft-vanrein-v6ops-6bed4-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 06:29:49 -0000 Hi, For first glance, i have a rough impression this draft has some similarity with another draft written a while ago at least in terms of udp encapsulation of ipv6. please refer to http://tools.ietf.org/html/draft-lee-softwire-6rd-udp 1. fe80::/128 seems to me a subnet router anycast address according to section 2.6.1, rfc4291. so you should not consider it as a unicast address. although, i dont see any issues under the circumstances. 2. you use DiffServ field several times, do you actually mean TrafficClass field? please in line with rfc2460. 3. why don't you mention direct encapsulated ipv6 end embeded system to end embeded communication? is it not in your senario or anything else? 4. you seem omit MTU and fragment/reassembly discussion. Thanks, washam From pch-b2B3A6689@u-1.phicoh.com Tue Jul 26 01:14:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C541B21F8C0F for ; Tue, 26 Jul 2011 01:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.543 X-Spam-Level: X-Spam-Status: No, score=-4.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W951iGYgTyPy for ; Tue, 26 Jul 2011 01:14:59 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id CDA2F21F8C0E for ; Tue, 26 Jul 2011 01:14:58 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1Qlcn2-0001iGC; Tue, 26 Jul 2011 10:14:56 +0200 Message-Id: To: Keith Moore From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <11072209372672_B93@oregon.uoregon.edu> <4E2D05F5.2060506@umn.edu> <16B4EC40-4960-4AD6-9B84-0820C3C13ABA@bogus.com> <17C1380A-741C-4BF5-8C8F-C4C4460D98EE@network-heretics.com> <22679673-7819-4E48-9C83-3C2294682605@ecs.soton.ac.uk> <4E2DFD59.5080707@umn.edu> <1B0A5DCD-B5BE-4A52-977A-B28D9C9E54D0@network-heretics.com> In-reply-to: Your message of "Mon, 25 Jul 2011 20:25:16 -0400 ." <1B0A5DCD-B5BE-4A52-977A-B28D9C9E54D0@network-heretics.com> Date: Tue, 26 Jul 2011 10:14:45 +0200 Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 08:14:59 -0000 In your letter dated Mon, 25 Jul 2011 20:25:16 -0400 you wrote: >Blacklisting 6to4 and Teredo is silly and inappropriate unless you have = >good reason to believe that they're sources of abusive mail. I agree. If it really becomes a problem then somebody may just have to write a small dnsbl server that extracts the IPv4 address from a 6to4 or Teredo address and queries one or more IPv4 dnsbls for that address. Otherwise, focus on getting generic IPv6 spam filtering to work without making all kinds of exceptions. From joelja@bogus.com Tue Jul 26 05:15:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EB821F8698 for ; Tue, 26 Jul 2011 05:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeVvVuLxnIHV for ; Tue, 26 Jul 2011 05:15:32 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7E13F21F8696 for ; Tue, 26 Jul 2011 05:15:31 -0700 (PDT) Received: from [IPv6:2001:df8::80:129a:ddff:feb1:e750] ([IPv6:2001:df8:0:80:129a:ddff:feb1:e750]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6QCFSoL007818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 26 Jul 2011 12:15:29 GMT (envelope-from joelja@bogus.com) From: Joel Jaeggli Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 26 Jul 2011 08:15:28 -0400 Message-Id: <4BCD3D86-B85D-4517-8DBB-81934EE764EE@bogus.com> To: "v6ops@ietf.org Operations" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [IPv6:2001:418:1::81]); Tue, 26 Jul 2011 12:15:29 +0000 (UTC) Subject: [v6ops] v6ops meeting 0900 EDT 7/26 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 12:15:32 -0000 The audio stream is going to be here: http://ietf81streaming.dnsalias.net/ietf/ietf803.m3u The jabber room is going to be here: xmpp:v6ops@jabber.ietf.org?join additional note-takers or jabber scribes would still be greatly appreciated. From ari.keranen@nomadiclab.com Tue Jul 26 06:21:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D63921F8C1F for ; Tue, 26 Jul 2011 06:21:49 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0ToHZk-lYHc for ; Tue, 26 Jul 2011 06:21:48 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 142ED21F8C1A for ; Tue, 26 Jul 2011 06:21:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id AA3494E6DF for ; Tue, 26 Jul 2011 16:21:38 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3S7V5oyVeVeV for ; Tue, 26 Jul 2011 16:21:37 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id AFDE74E6D1 for ; Tue, 26 Jul 2011 16:21:36 +0300 (EEST) Message-ID: <4E2EBF60.50407@nomadiclab.com> Date: Tue, 26 Jul 2011 09:21:36 -0400 From: Ari Keranen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] Some World IPv6 Day Measurement Results draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 13:21:53 -0000 Here's the draft containing more information about our World IPv6 day measurements (that were just presented at v6ops): http://tools.ietf.org/html/draft-keranen-ipv6day-measurements-01 Cheers, Ari From fred@cisco.com Tue Jul 26 06:55:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7261021F8B3D for ; Tue, 26 Jul 2011 06:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPfGouRHi7fe for ; Tue, 26 Jul 2011 06:55:02 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C88DD21F8B16 for ; Tue, 26 Jul 2011 06:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=134; q=dns/txt; s=iport; t=1311688502; x=1312898102; h=date:from:message-id:to:subject:cc; bh=B526vgh/99WVijfQdUbw9arZG90XNa8nYME6TyqzB5g=; b=i5zPa/IJQ6OW52bJGiA89lySIKctB4oZtFHeGO+/wwHRqYE863Ri7SdK bOhNAnwq58E1j1nuhZZCfVG6VvrfsPge+/M+7a81Kk6MJ5PLfL7RQcqEd 7HvbbAQ51E71qrvKHhJJeGdSIjIho7Wr5/C/tA5W/hWxhfiIA/2JRZqxC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEHAGrGLk6rRDoG/2dsb2JhbABQAXA+OQyBFpgeAQGPFneJAKJ3nmOGQASHV5wb X-IronPort-AV: E=Sophos;i="4.67,269,1309737600"; d="scan'208";a="6488223" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jul 2011 13:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6QDt1SZ013323; Tue, 26 Jul 2011 13:55:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p6QDt1422976; Tue, 26 Jul 2011 06:55:01 -0700 (PDT) Date: Tue, 26 Jul 2011 06:55:01 -0700 (PDT) From: Message-Id: <201107261355.p6QDt1422976@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-xli-v6ops-ivi-icmp-address@tools.ietf.org Subject: [v6ops] new draft: draft-xli-v6ops-ivi-icmp-address-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 13:55:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-xli-v6ops-ivi-icmp-address. Please take a look at it and comment. From xing@cernet.edu.cn Tue Jul 26 07:36:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD3221F8AE9 for ; Tue, 26 Jul 2011 07:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.603 X-Spam-Level: X-Spam-Status: No, score=-99.603 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhZeZ-FgFcpy for ; Tue, 26 Jul 2011 07:36:40 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 1CF5321F8BC8 for ; Tue, 26 Jul 2011 07:36:39 -0700 (PDT) Received: from [127.0.0.1]([130.129.19.192]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb4e2f0e9f; Tue, 26 Jul 2011 22:36:38 +0800 Message-ID: <4E2ED0F0.1070301@cernet.edu.cn> Date: Tue, 26 Jul 2011 22:36:32 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: v6ops-chairs@tools.ietf.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: c90kil0B Cc: draft-xli-v6ops-ivi-icmp-address@tools.ietf.org, v6ops@ietf.org Subject: [v6ops] Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:36:41 -0000 Hi V6ops Chairs, The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption. The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4. The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list. regards, Xing Li From sowmini05@gmail.com Tue Jul 26 07:54:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8D311E80F9 for ; Tue, 26 Jul 2011 07:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0fr+DbOR60u for ; Tue, 26 Jul 2011 07:54:13 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26BE311E80ED for ; Tue, 26 Jul 2011 07:54:13 -0700 (PDT) Received: by yxp4 with SMTP id 4so395374yxp.31 for ; Tue, 26 Jul 2011 07:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UgvSrOJZMEdou+TbMYtKJ1P3fe+5WdAb+Sv6zLI6wE0=; b=Mo1x4eztD0fxU0aGo9PByS0pd/gZl62ooy35cgfW+DnTijiXt2en6YeXZm0T4Dm3JV WhMrwgx2/WTIeXqh+OSeMrJrHYYwanmfRcj9ypzkQnf/4xiAT8Vfg8l4t02GzkI6ehUe PJBbKLS0Rm314ViT8bKDq0XMwxbdcI7wLrALo= MIME-Version: 1.0 Received: by 10.231.42.5 with SMTP id q5mr5797263ibe.17.1311692049564; Tue, 26 Jul 2011 07:54:09 -0700 (PDT) Received: by 10.42.227.71 with HTTP; Tue, 26 Jul 2011 07:54:09 -0700 (PDT) In-Reply-To: <201107261355.p6QDt1422976@ftpeng-update.cisco.com> References: <201107261355.p6QDt1422976@ftpeng-update.cisco.com> Date: Tue, 26 Jul 2011 10:54:09 -0400 Message-ID: From: sowmini varadhan To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: rvaithia@cisco.com Subject: Re: [v6ops] new draft: draft-xli-v6ops-ivi-icmp-address-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 14:54:14 -0000 On Tue, Jul 26, 2011 at 9:55 AM, wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-xli-v6ops-ivi-icmp-address. > Please take a look at it and comment. > Section 5: what happens if the algorithm ends up generating a Martian source address (e.g., subnet broadcast)? Nit: " Last Octet of the /24 prefix " is ambiguous: is this the least-signficant byte of the address or the least-significant non-zero byte of the prefix? --Sowmini From joelja@bogus.com Tue Jul 26 09:12:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4B921F8B43 for ; Tue, 26 Jul 2011 09:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE1RAEIwZ2NC for ; Tue, 26 Jul 2011 09:12:31 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EDB5421F8997 for ; Tue, 26 Jul 2011 09:12:29 -0700 (PDT) Received: from dhcp-5710.meeting.ietf.org (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6QGBpo0024428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 26 Jul 2011 16:12:28 GMT (envelope-from joelja@bogus.com) From: Joel Jaeggli Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 26 Jul 2011 12:12:28 -0400 Message-Id: <5E7A7B2E-8306-4898-86D7-C9FAE7D2350A@bogus.com> To: "v6ops@ietf.org Operations" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 26 Jul 2011 16:12:29 +0000 (UTC) Subject: [v6ops] two phones were found in the meeting room. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 16:12:31 -0000 they have been sent to the secretariat From shemant@cisco.com Tue Jul 26 10:23:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7950F21F8B66 for ; Tue, 26 Jul 2011 10:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC4NAjZJf2KC for ; Tue, 26 Jul 2011 10:23:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 376FF21F8AE4 for ; Tue, 26 Jul 2011 10:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6171; q=dns/txt; s=iport; t=1311700986; x=1312910586; h=mime-version:subject:date:message-id:from:to:cc; bh=IiqDUv/r9gFosltu+pheA5l2SNIMjudRot6hsX5WFlg=; b=FRElr9pCDuEG0uSbaWHrg/gkJtwDx8GH+3PHE+BXvcCzo11AIaMAlDui dE3mtXLeTSyYnWa6U2jd0QljOwu+GsijF29GNYyDQFIHjG0p/sUayikZw ChiDs/acEYtOXbZNknJTN1IBD7b5vZm01pV7XaGF6IPnRHF6HKV/P1co1 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAO32Lk6tJV2a/2dsb2JhbAArDQEBAxQBDBIDTxMBKwYkBxNSAQUjG4I2pHp3iQCie55ohWFfBIJPhQiQK4tu X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="scan'208,217";a="6564744" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 26 Jul 2011 17:23:05 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6QHN5la032249; Tue, 26 Jul 2011 17:23:05 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 12:23:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4BB8.ADE94202" Date: Tue, 26 Jul 2011 12:23:03 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc Thread-Index: AcxLuKzKq0shWdzUS/uvVfJ9gcyG8g== From: "Hemant Singh (shemant)" To: "Ted Lemon" X-OriginalArrivalTime: 26 Jul 2011 17:23:05.0480 (UTC) FILETIME=[AE27A080:01CC4BB8] Cc: IPv6 Operations Subject: [v6ops] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:23:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4BB8.ADE94202 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ted, =20 In the latest version of the document which is =20 http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router-bis/?in clude_text=3D1 =20 Please note this new section which is something we'd like to socialize with the DHC folks. The idea is since DHC tries forever, if a client send the first SOLiCIT with say, two options, such as the IA_NA and the IA_PD options, then if the server replied to the first SOLICIT having served only a IA_NA IA_Address and error for the IA_PD (due to server mis-configuration), then if the client sends a SOLICIT at another time, the client should not just include the IA_PD but send both the options as in the first SOLiCIT. The reason is what if the server has changed provisioning for the IA_NA in the meantime.=20 =20 5.7. Additional DHCPv6 WAN Requirement =20 When the WAN interface sends a DHCPV6 SOLICIT message, the CE router SHOULD request all mandatory information (IA_NA and IA_PD options) in the SOLICIT regardless of whether any partial information was received in response to previous SOLICITs. =20 =20 Thanks, =20 Hemant =20 ------_=_NextPart_001_01CC4BB8.ADE94202 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ted,

 

In the latest version of the document which = is

 

http://datatracker.ietf.org/doc/draft-ietf-v6ops-i= pv6-cpe-router-bis/?include_text=3D1

 

Please note this new section which is something = we’d like to socialize with the DHC folks.   The idea is since DHC = tries forever, if a client send the first SOLiCIT with say, two options, such = as the IA_NA and the IA_PD options,  then if the server replied to the = first SOLICIT having served only a IA_NA IA_Address and error for the IA_PD = (due to server mis-configuration), then if the client sends a SOLICIT at another = time, the client should not just include the IA_PD but  send both the = options as in the first SOLiCIT.   The reason is what if the server has = changed provisioning for the IA_NA in the meantime.

 

5.7.  Additional DHCPv6 WAN = Requirement

 

   When the WAN interface sends a = DHCPV6 SOLICIT message, the CE router

   SHOULD request all mandatory information (IA_NA and IA_PD options) in

   the SOLICIT regardless of = whether any partial information was

   received in response to previous SOLICITs.

 

 

Thanks,

 

Hemant



 

------_=_NextPart_001_01CC4BB8.ADE94202-- From Ted.Lemon@nominum.com Tue Jul 26 10:28:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF1921F8BD7 for ; Tue, 26 Jul 2011 10:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RGvie-ChItM for ; Tue, 26 Jul 2011 10:28:03 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id DA43E21F8BD6 for ; Tue, 26 Jul 2011 10:28:02 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTi75IjF89q0+V/0itpfI4RvO7xezbe6S@postini.com; Tue, 26 Jul 2011 10:28:02 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C680BF8002 for ; Tue, 26 Jul 2011 10:28:01 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B24CC190059; Tue, 26 Jul 2011 10:28:01 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0289.001; Tue, 26 Jul 2011 10:28:01 -0700 From: Ted Lemon To: "Hemant Singh (shemant)" Thread-Topic: socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc Thread-Index: AcxLuKzKq0shWdzUS/uvVfJ9gcyG8gAO13iA Date: Tue, 26 Jul 2011 17:28:00 +0000 Message-ID: <3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.83.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 17:28:03 -0000 You should raise this on the DHCP mailing list. The questions I'd want to = see answered are why just waiting for the IA_NA to time out doesn't work, a= nd why Reconfigure doesn't work. From ari.keranen@nomadiclab.com Tue Jul 26 12:15:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63EB21F85AE for ; Tue, 26 Jul 2011 12:15:30 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlxuQa5l0GQ2 for ; Tue, 26 Jul 2011 12:15:30 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id BC28321F85AA for ; Tue, 26 Jul 2011 12:15:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 21FE44E6DF; Tue, 26 Jul 2011 22:15:28 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sijVGe7sRNV6; Tue, 26 Jul 2011 22:15:26 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 22E534E6D1; Tue, 26 Jul 2011 22:15:25 +0300 (EEST) Message-ID: <4E2F124D.1080706@nomadiclab.com> Date: Tue, 26 Jul 2011 15:15:25 -0400 From: Ari Keranen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Hui Deng References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments for draft-keranen-ipv6day-measurements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 19:15:31 -0000 Hi, On 22.7.2011 19:14, Hui Deng wrote: > This work has gathered the useful information, appreciate the work. Thanks! > Several comments below: > 1) Have you done the delay test for the case host which doesn't have > IPv6 connection, have to fall back > to IPv4 connection? does this prove dual stack website not feasible > during the IPv6 transition stage? Our tests did not include a fall back possibility. But I'd say a dual-stack websites is in fact desirable during the transition stage. > 2) could you predict how many website sitting behind of NAT64? Not from these tests, but I'd be a bit surprised if there were any in the top 10k web sites. > 3) Does the measure tool is a open source for download? Unfortunately not; having the tool open sourced would require going through a non-trivial amount of bureaucracy. If you're really interested, contact me off-list and I can see if we can work out something. > 4) There are 13 top 100 support AAAA which is less than 14 before IPv6 > day, who is that website? ipv6.baidu.com had an AAAA record until the 65th test run. Cheers, Ari From shemant@cisco.com Tue Jul 26 13:39:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27F311E8097; Tue, 26 Jul 2011 13:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9jeavjJLfjV; Tue, 26 Jul 2011 13:39:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFBF11E80AF; Tue, 26 Jul 2011 13:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1320; q=dns/txt; s=iport; t=1311712740; x=1312922340; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0WZFizF229JSrn5GU0sgfnQvLC3ACGyMyQzv1/tCuGw=; b=dbMcDctHoKMJ1lq7jPNCd9NgZn3WYg9M+tkg37MciY9MyZHfI7JUso02 n2YPgaHMaEM2I1PqQwZ1q3OPQ9j3THhmTzVVJv/UGV700vl1xAc/3lAkK UJi9cP1zsShX7y+pMo/5/no07OMGHXjIUrCyVX0K9OIXLEpi0d/dsrEZ4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAABIlL06tJV2c/2dsb2JhbAAqCwEBAQEDFAEhChAqCwwFAgEJEQQBAQsGIwEGARM7DggBAQUXDBuXTo9cd6wykF6Nd4VhXwSHV5Ari24 X-IronPort-AV: E=Sophos;i="4.67,271,1309737600"; d="scan'208";a="6639470" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jul 2011 20:39:00 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6QKcxm1027685; Tue, 26 Jul 2011 20:38:59 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 15:38:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 15:38:57 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C302589C62@XMB-RCD-109.cisco.com> In-Reply-To: <3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc Thread-Index: AcxLuKzKq0shWdzUS/uvVfJ9gcyG8gAO13iAAAiR8aA= References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com> <3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com> From: "Hemant Singh (shemant)" To: "Ted Lemon" X-OriginalArrivalTime: 26 Jul 2011 20:38:59.0049 (UTC) FILETIME=[0BD3ED90:01CC4BD4] Cc: dhcwg@ietf.org, IPv6 Operations Subject: Re: [v6ops] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:39:00 -0000 -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Tuesday, July 26, 2011 1:28 PM To: Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc >You should raise this on the DHCP mailing list. =20 Done - thanks. >The questions I'd want to see answered are why just waiting for the IA_NA to time out doesn't work, and why Reconfigure doesn't work. The IPv6 CE router DHC6 client sent its first SOLICIT with IA_NA and IA_PD options and the server replied back with a valid IA_NA but failure for the IA_PD (due to a mis-configured server for IA_PD). So if the client waits for the IA_NA to timeout before the client sends any subsequent SOLICIT for both IA_NA and IA_PD. The IA_NA IA_Address Valid Lifetime is one week and thus the home LAN has no PD assigned for a week. Note also that if a server is mis-configured for IA_PD, when the mis-configuration is fixed, the IA_NA is may change as well. Thus it makes sense to send both IA_NA and the IA_PD options is subsequent SOLICITs. Agreed, when the IA_NA changes a Reconfigure can be sent from the server to the client. But there is no automated means to detect the mis-configuration and when does the server send the Reconfigure? =20 Hemant=20 From rbonica@juniper.net Tue Jul 26 13:53:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DA721F8A4B; Tue, 26 Jul 2011 13:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.935 X-Spam-Level: X-Spam-Status: No, score=-105.935 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpBHzEBnR-dJ; Tue, 26 Jul 2011 13:53:19 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9E15E21F880C; Tue, 26 Jul 2011 13:53:17 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTi8pPHPAnYiDzeHEWPt2hMi9ltc+gjFz@postini.com; Tue, 26 Jul 2011 13:53:18 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 13:51:29 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 26 Jul 2011 16:51:29 -0400 From: Ronald Bonica To: t.petch , "ietf@ietf.org" , "v6ops@ietf.org" Date: Tue, 26 Jul 2011 16:51:27 -0400 Thread-Topic: draft-ietf-v6ops-6to4-to-historic (yet again) Thread-Index: AcxLy6igndDxYpSyTlCEDzUOzhsoVgACgrMg Message-ID: <13205C286662DE4387D9AF3AC30EF456D3F455A480@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <015a01cc4bc2$d8cc2d60$4001a8c0@gateway.2wire.net> In-Reply-To: <015a01cc4bc2$d8cc2d60$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic (yet again) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:53:19 -0000 Tom, Sorry. I meant to copy both lists. They are both copied now. Ron > -----Original Message----- > From: t.petch [mailto:daedulus@btconnect.com] > Sent: Tuesday, July 26, 2011 2:36 PM > To: Ronald Bonica; ietf@ietf.org > Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again) >=20 > It seems strange that this e-mail is not copied to the v6ops list. >=20 > I would have expected this first to have been hammered out on the v6ops > list > and, if and only if consensus was reached there, the new text be then > brought to > the > IETF list. >=20 > I realise that, as you spell out, you are seeking IETF consensus but > what is > that if the > WG is dead set against it? >=20 > Tom Petch >=20 >=20 > ----- Original Message ----- > From: "Ronald Bonica" > To: > Sent: Monday, July 25, 2011 4:30 PM >=20 > > After some discussion, the IESG is attempting to determine whether > there is > IETF consensus to do the following: > > > > - add a new section to draft-ietf-v6ops-6to4-to-historic > > - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL > > > > draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 > and convert > their status to HISTORIC. It will also contain a new section describing > what it > means for RFCs 3056 and 3068 to be classified as HISTORIC. The new > section will > say that: > > > > - 6-to-4 should not be configured by default on any implementation > (hosts, cpe > routers, other) > > - vendors will decide whether/when 6-to-4 will be removed from > implementations. Likewise, operators will decide whether/when 6-to-4 > relays will > be removed from their networks. The status of RFCs 3056 and 3068 should > not be > interpreted as a recommendation to remove 6-to-4 at any particular > time. > > > > > > draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it > clarifies > the meaning of "HISTORIC" in this particular case, it does not set a > precedent > for any future case. > > > > Please post your views on this course of action by August 8, 2011. > > > > > > > Ron Bonica > > > as OPS Area AD> > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf From xing@cernet.edu.cn Tue Jul 26 14:14:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A4221F887C for ; Tue, 26 Jul 2011 14:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.803 X-Spam-Level: X-Spam-Status: No, score=-99.803 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZywpgSqYXXW for ; Tue, 26 Jul 2011 14:14:57 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 6653521F8876 for ; Tue, 26 Jul 2011 14:14:56 -0700 (PDT) Received: from [127.0.0.1]([70.25.120.2]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04e2f6bf2; Wed, 27 Jul 2011 05:14:49 +0800 Message-ID: <4E2F2E41.3090701@cernet.edu.cn> Date: Wed, 27 Jul 2011 05:14:41 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: sowmini varadhan References: <201107261355.p6QDt1422976@ftpeng-update.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: c4lxol0B Cc: v6ops@ietf.org, rvaithia@cisco.com Subject: Re: [v6ops] new draft: draft-xli-v6ops-ivi-icmp-address-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:14:57 -0000 Hi, Sowmini, Thanks for your comments. 于 2011/7/26 22:54, sowmini varadhan 写道: > On Tue, Jul 26, 2011 at 9:55 AM, wrote: >> A new draft has been posted, at http://tools.ietf.org/html/draft-xli-v6ops-ivi-icmp-address. > > Please take a look at it and comment. > Section 5: what happens if the algorithm ends up generating a Martian source > address (e.g., subnet broadcast)? How about adding For this /24 prefix, the algorithm MUST not generate subnet identifier or broadcast addresses as the source address of the ICMP packets. > Nit: " Last Octet of the /24 prefix " is ambiguous: is this the > least-signficant byte > of the address or the least-significant non-zero byte of the prefix? Thanks, It is the least-signficant byte of the address. Regards, xing > --Sowmini > > From internet-drafts@ietf.org Tue Jul 26 14:32:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9626911E810F; Tue, 26 Jul 2011 14:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A8BreGs096w; Tue, 26 Jul 2011 14:32:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD6811E80BF; Tue, 26 Jul 2011 14:32:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.56 Message-ID: <20110726213257.24248.38990.idtracker@ietfa.amsl.com> Date: Tue, 26 Jul 2011 14:32:57 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-v4v6tran-framework-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 21:32:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Framework for IP Version Transition Scenarios Author(s) : Brian Carpenter Sheng Jiang Victor Kuarsingh Filename : draft-ietf-v6ops-v4v6tran-framework-02.txt Pages : 7 Date : 2011-07-26 This document sets out a framework agreed by the V6OPS WG for the presentation of scenarios and recommendations for a variety of approaches to the transition from IPv4 to IPv6, given the necessity for a long period of co-existence of the two protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v4v6tran-framework-02.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v4v6tran-framework-02.t= xt From gih@apnic.net Tue Jul 26 15:08:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571B821F86AF for ; Tue, 26 Jul 2011 15:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.819 X-Spam-Level: X-Spam-Status: No, score=-100.819 tagged_above=-999 required=5 tests=[AWL=1.780, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv1qN6OOriD1 for ; Tue, 26 Jul 2011 15:08:54 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 66C2A21F86C4 for ; Tue, 26 Jul 2011 15:08:54 -0700 (PDT) Received: from dhcp-4331.meeting.ietf.org (dhcp-4331.meeting.ietf.org [130.129.67.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D8D32B673D; Wed, 27 Jul 2011 08:08:47 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Wed, 27 Jul 2011 08:08:38 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201107261355.p6QDt1422976@ftpeng-update.cisco.com> To: sowmini varadhan X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, rvaithia@cisco.com Subject: Re: [v6ops] new draft: draft-xli-v6ops-ivi-icmp-address-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:08:55 -0000 On 27/07/2011, at 12:54 AM, sowmini varadhan wrote: > On Tue, Jul 26, 2011 at 9:55 AM, wrote: >>=20 >> A new draft has been posted, at = http://tools.ietf.org/html/draft-xli-v6ops-ivi-icmp-address. >> Please take a look at it and comment. >>=20 >=20 > Section 5: what happens if the algorithm ends up generating a Martian = source > address (e.g., subnet broadcast)? >=20 Nothing happens. There is no subnet here. As section 4 states: = "Addresses from the assigned address prefix are intended to be used as = source addresses and not as destination addresses" regards, Geoff From brian.e.carpenter@gmail.com Tue Jul 26 15:26:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDAD5E8008 for ; Tue, 26 Jul 2011 15:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.308 X-Spam-Level: X-Spam-Status: No, score=-103.308 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dru0ssU9q0G3 for ; Tue, 26 Jul 2011 15:26:21 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20F735E8005 for ; Tue, 26 Jul 2011 15:26:21 -0700 (PDT) Received: by iye7 with SMTP id 7so1220619iye.31 for ; Tue, 26 Jul 2011 15:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=YXc2DcnaTWQxcaT8hKDc/pQlXCRmDsGD60xmpfCozHE=; b=TxFi4mTD/zmQBEUf92/zqE16vzWVAhXjZYUj30IbqfMsY6s+V39pa36fmR9J2MY+R1 Snxm0uv/wrqgac+llXmFtfrKdwLQ9RMMVH8KKQJ3So1//rzJ3E5ZIrYJgT4yXuZ334FZ W8oxFdrjVIYLPmo6bCWz80vmcwgAzmSe5LxnM= Received: by 10.231.114.96 with SMTP id d32mr6301753ibq.118.1311719175337; Tue, 26 Jul 2011 15:26:15 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id e2sm610840ibb.23.2011.07.26.15.26.13 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 15:26:14 -0700 (PDT) Message-ID: <4E2F3F02.9030207@gmail.com> Date: Wed, 27 Jul 2011 10:26:10 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-v4v6tran-framework-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:26:21 -0000 This is just a small update to clarify the status of the draft and keep it alive for 6 months. Brian -------- Original Message -------- Subject: I-D Action: draft-ietf-v6ops-v4v6tran-framework-02.txt Date: Tue, 26 Jul 2011 14:32:57 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: v6ops@ietf.org 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 : Framework for IP Version Transition Scenarios Author(s) : Brian Carpenter Sheng Jiang Victor Kuarsingh Filename : draft-ietf-v6ops-v4v6tran-framework-02.txt Pages : 7 Date : 2011-07-26 This document sets out a framework agreed by the V6OPS WG for the presentation of scenarios and recommendations for a variety of approaches to the transition from IPv4 to IPv6, given the necessity for a long period of co-existence of the two protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v4v6tran-framework-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v4v6tran-framework-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From brian.e.carpenter@gmail.com Tue Jul 26 15:49:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A215E800F; Tue, 26 Jul 2011 15:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.602 X-Spam-Level: X-Spam-Status: No, score=-103.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnygh4xiYp+p; Tue, 26 Jul 2011 15:49:59 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA0F55E8008; Tue, 26 Jul 2011 15:49:58 -0700 (PDT) Received: by iye7 with SMTP id 7so1243384iye.31 for ; Tue, 26 Jul 2011 15:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GxQvPpBwJ09EeJvLhuKOTUJNaWNvRcG9pXNk+gThJOM=; b=SbgzHVXzyPXzf/QNunIDJ5BWQdftIiNqzNaWYvYn4ovM0PFcJzWZ+00t3V9xODJbkS oV2UKJGCH19zvOWCM9IQHkvLUqX5AKDiXOqaOTINammO0Luk35T1pwTHJDgSQ+pEtTFF DDYgPYoYxW/jkOt9BIeEZu6yv/80mNMlgsUlw= Received: by 10.43.134.74 with SMTP id ib10mr13646icc.485.1311720598099; Tue, 26 Jul 2011 15:49:58 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id a9sm1247351icy.6.2011.07.26.15.49.55 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 15:49:57 -0700 (PDT) Message-ID: <4E2F4491.30102@gmail.com> Date: Wed, 27 Jul 2011 10:49:53 +1200 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: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> In-Reply-To: <4E2EDF23.3060804@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:49:59 -0000 Alex, Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it? If you have a reason to install and enable 6to4, why would the nominal status of a couple of RFCs make you do anything different? Of course, if implementors choose to drop the code you might not be able to upgrade software versions - but hopefully by that time you will have native IPv6 service anyway. Regards Brian Carpenter On 2011-07-27 03:37, Alexandru Petrescu wrote: > I jump in the midle of discussion and lazy to dissect emails: >=20 > Is there a replacement for historic 6to4? What should I now install in= > the lab, without interaction to some admin or web page of some core ser= ver? >=20 > Thanks, >=20 > Alex >=20 >=20 > Le 26/07/2011 15:47, Ronald Bonica a =C3=A9crit : >> Brian, >> >> Does the following text work for you? >> >> Ron >> >> >> N. Meaning of HISTORIC >> >> For the purposes of this document, the term HISTORIC means: >> >> - 6-to-4 should not be configured by default on any implementation >> (host, cpe router, other) >> >> - Vendors will decide which future versions of their products will >> support 6-to-4. It is assumed that vendors will continue to support >> 6-to-4 until a) they are no longer economically incented to do so and >> b) they are economically incented to remove unused features from their= >> products. >> >> - Operators will decide when to decommission 6-to-4 relays, if ever. >> It is assumed that operators will continue to operate 6-to-4 relays as= >> long as they are economically incented to do so. When 6-to-4 traffic >> levels reach zero, operators will probably begin to consider >> decommissioning. >> >> The status of RFCs 3056 and 3068 should not be interpreted as a >> recommendation to remove 6-to-4 at any particular time. >> >> >>> -----Original Message----- >>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>> Sent: Monday, July 25, 2011 11:09 PM >>> To: Ronald Bonica >>> Cc: ietf@ietf.org >>> Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again) >>> >>> To be clear, I'd like to see exact proposed text before expressing >>> support for the proposal. The trick is to get 6to4 disabled by defaul= t >>> at the user end, without disabling it for users who are getting good >>> service from it. >>> >>> Regards >>> Brian >>> >>> On 2011-07-26 09:49, Brian E Carpenter wrote: >>>>> Likewise, operators will decide whether/when 6-to-4 relays will b= e >>> removed from their networks. >>>> >>>> This is, of course, an undeniable statement of fact (as it is for an= y >>> other feature >>>> of the Internet). However, it needs to be made clear that doing so >>> *prematurely* >>>> would penalise existing successful users of those relays, and >>> therefore it should >>>> only be done when there is no successful traffic through them. Which= >>> is when any >>>> operator would remove them anyway. >>>> >>>> Therefore, I don't see much value in this statement, and possible >>> harm to users. >>>> The ways to avoid such harm as far as possible are already in the RF= C >>> Editor >>>> queue. >>>> >>>> Regards >>>> Brian Carpenter >>>> >>>> On 2011-07-26 02:30, Ronald Bonica wrote: >>>>> Folks, >>>>> >>>>> After some discussion, the IESG is attempting to determine whether >>> there is IETF consensus to do the following: >>>>> >>>>> - add a new section to draft-ietf-v6ops-6to4-to-historic >>>>> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL >>>>> >>>>> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 >>> and convert their status to HISTORIC. It will also contain a new >>> section describing what it means for RFCs 3056 and 3068 to be >>> classified as HISTORIC. The new section will say that: >>>>> >>>>> - 6-to-4 should not be configured by default on any implementation >>> (hosts, cpe routers, other) >>>>> - vendors will decide whether/when 6-to-4 will be removed from >>> implementations. Likewise, operators will decide whether/when 6-to-4 >>> relays will be removed from their networks. The status of RFCs 3056 a= nd >>> 3068 should not be interpreted as a recommendation to remove 6-to-4 a= t >>> any particular time. >>>>> >>>>> >>>>> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While i= t >>> clarifies the meaning of "HISTORIC" in this particular case, it does >>> not set a precedent for any future case. >>>>> >>>>> Please post your views on this course of action by August 8, 2011. >>>>> >>>>> >>>>> >>> Ron Bonica >>>>> >>> >>>>> _______________________________________________ >>>>> Ietf mailing list >>>>> Ietf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf >>>>> >>>> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From brian.e.carpenter@gmail.com Tue Jul 26 15:57:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F55121F86D8; Tue, 26 Jul 2011 15:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.602 X-Spam-Level: X-Spam-Status: No, score=-103.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1K+XzdPvBUY; Tue, 26 Jul 2011 15:57:01 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id B114421F8586; Tue, 26 Jul 2011 15:57:00 -0700 (PDT) Received: by yie30 with SMTP id 30so803558yie.31 for ; Tue, 26 Jul 2011 15:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=582CK1HOgKZANKFQtTl4FUTHAhtESPdSFcl1iJHPfEY=; b=TJxuGCbcjiXRSGNVaiTxXwQBkMJE/uZQpElwxnzzkPvCvV2OQMARqA0fRwYEiblHY1 SzNi+QOyJcdukkTITVLa+CWoRBvBEEwPA9FWHq1EGd2a6Uf2/G/4IVUZxQPJIK4nTaiW SRFar3zVRl18jZDwvM6ssoSQ72QXZmth/u76g= Received: by 10.42.155.74 with SMTP id t10mr15500icw.527.1311721019761; Tue, 26 Jul 2011 15:56:59 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id h6sm1261152icy.1.2011.07.26.15.56.57 (version=SSLv3 cipher=OTHER); Tue, 26 Jul 2011 15:56:59 -0700 (PDT) Message-ID: <4E2F4637.3060409@gmail.com> Date: Wed, 27 Jul 2011 10:56:55 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ronald Bonica References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , "ietf@ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic (yet again) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:57:01 -0000 Ron, The normal typography is 6to4, not 6-to-4. I assume the draft will still refer to [I-D.ietf-v6ops-6to4-advisory]. Given that, I believe the draft should proceed. I definitely disagree with those who say this would be a misuse of "Historic"; the words in RFC 2026 certainly cover this case ("for any other reason considered to be obsolete"). Regards Brian Carpenter On 2011-07-27 01:47, Ronald Bonica wrote: > Brian, > > Does the following text work for you? > > Ron > > > N. Meaning of HISTORIC > > For the purposes of this document, the term HISTORIC means: > > - 6-to-4 should not be configured by default on any implementation (host, cpe router, other) > > - Vendors will decide which future versions of their products will support 6-to-4. It is assumed that vendors will continue to support 6-to-4 until a) they are no longer economically incented to do so and b) they are economically incented to remove unused features from their products. > > - Operators will decide when to decommission 6-to-4 relays, if ever. It is assumed that operators will continue to operate 6-to-4 relays as long as they are economically incented to do so. When 6-to-4 traffic levels reach zero, operators will probably begin to consider decommissioning. > > The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. > > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Monday, July 25, 2011 11:09 PM >> To: Ronald Bonica >> Cc: ietf@ietf.org >> Subject: Re: draft-ietf-v6ops-6to4-to-historic (yet again) >> >> To be clear, I'd like to see exact proposed text before expressing >> support for the proposal. The trick is to get 6to4 disabled by default >> at the user end, without disabling it for users who are getting good >> service from it. >> >> Regards >> Brian >> >> On 2011-07-26 09:49, Brian E Carpenter wrote: >>>> Likewise, operators will decide whether/when 6-to-4 relays will be >> removed from their networks. >>> This is, of course, an undeniable statement of fact (as it is for any >> other feature >>> of the Internet). However, it needs to be made clear that doing so >> *prematurely* >>> would penalise existing successful users of those relays, and >> therefore it should >>> only be done when there is no successful traffic through them. Which >> is when any >>> operator would remove them anyway. >>> >>> Therefore, I don't see much value in this statement, and possible >> harm to users. >>> The ways to avoid such harm as far as possible are already in the RFC >> Editor >>> queue. >>> >>> Regards >>> Brian Carpenter >>> >>> On 2011-07-26 02:30, Ronald Bonica wrote: >>>> Folks, >>>> >>>> After some discussion, the IESG is attempting to determine whether >> there is IETF consensus to do the following: >>>> - add a new section to draft-ietf-v6ops-6to4-to-historic >>>> - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL >>>> >>>> draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 >> and convert their status to HISTORIC. It will also contain a new >> section describing what it means for RFCs 3056 and 3068 to be >> classified as HISTORIC. The new section will say that: >>>> - 6-to-4 should not be configured by default on any implementation >> (hosts, cpe routers, other) >>>> - vendors will decide whether/when 6-to-4 will be removed from >> implementations. Likewise, operators will decide whether/when 6-to-4 >> relays will be removed from their networks. The status of RFCs 3056 and >> 3068 should not be interpreted as a recommendation to remove 6-to-4 at >> any particular time. >>>> >>>> draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it >> clarifies the meaning of "HISTORIC" in this particular case, it does >> not set a precedent for any future case. >>>> Please post your views on this course of action by August 8, 2011. >>>> >>>> >>>> >> Ron Bonica >> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>>> From sowmini05@gmail.com Tue Jul 26 17:54:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0887611E80D4 for ; Tue, 26 Jul 2011 17:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQoDPP1gS2Ri for ; Tue, 26 Jul 2011 17:54:37 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFB211E80C2 for ; Tue, 26 Jul 2011 17:54:37 -0700 (PDT) Received: by qyk9 with SMTP id 9so2105600qyk.10 for ; Tue, 26 Jul 2011 17:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Umq8qOKSYlWcY7C1esFsS+dtXLAS28WxhE8AmT9d0AY=; b=vhJCyBJ1+eD7ENMSQsGQfbmJ1BnOl9CuOBzj0drhQFsLFAOmqRY65+zAigI5CgX1jw FeAjP769meFGjjMTpwlnRcK0IjRNeBk7giqN14nawzdpJHPbS7F+E270m8qq414ULRsV 2zHO16NY+jPTFQwwbXFmjEM2fVBCjqUqZh+Q8= MIME-Version: 1.0 Received: by 10.224.177.74 with SMTP id bh10mr5227099qab.155.1311728076621; Tue, 26 Jul 2011 17:54:36 -0700 (PDT) Received: by 10.224.73.194 with HTTP; Tue, 26 Jul 2011 17:54:36 -0700 (PDT) In-Reply-To: References: <201107261355.p6QDt1422976@ftpeng-update.cisco.com> Date: Tue, 26 Jul 2011 20:54:36 -0400 Message-ID: From: sowmini varadhan To: Geoff Huston Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, rvaithia@cisco.com Subject: Re: [v6ops] new draft: draft-xli-v6ops-ivi-icmp-address-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 00:54:38 -0000 On Tue, Jul 26, 2011 at 6:08 PM, Geoff Huston wrote: >> Section 5: what happens if the algorithm ends up generating a Martian source >> address (e.g., subnet broadcast)? >> > > > Nothing happens. There is no subnet here. As section 4 states: "Addresses from the > assigned address prefix are intended to be used as source addresses and not as > destination addresses" So the receiver should ignore Section 5.3.7 of rfc1812 for this case? Also, are duplicate source addresses a problem? --Sowmini From marka@isc.org Tue Jul 26 19:10:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C7F21F874C for ; Tue, 26 Jul 2011 19:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCFLWMAiLe0m for ; Tue, 26 Jul 2011 19:10:11 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id F369021F8678 for ; Tue, 26 Jul 2011 19:10:10 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 2D8985F9921; Wed, 27 Jul 2011 02:09:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6B93B216C86; Wed, 27 Jul 2011 02:09:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id CF46A123200A; Wed, 27 Jul 2011 12:09:04 +1000 (EST) To: Ari Keranen From: Mark Andrews References: <4E2F124D.1080706@nomadiclab.com> In-reply-to: Your message of "Tue, 26 Jul 2011 15:15:25 -0400." <4E2F124D.1080706@nomadiclab.com> Date: Wed, 27 Jul 2011 12:09:04 +1000 Message-Id: <20110727020904.CF46A123200A@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments for draft-keranen-ipv6day-measurements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 02:10:11 -0000 What we need is Radware, F5 and other load balancer vendors to send out instructions to their customer on how to correctly configure their load balancers to serve A records at the top of a zone rather that one label deep in a zone. This misconfiguration is responsible for +90% of AAAA lookup failures. Lots of load balancers are delegated to as "www.example.com" but the load balancer is configured to serve "example.com" rather than the zone that is *actually* delegated to it. This results in invalid negative responses being sent (the SOA record returned in the negative response is for "example.com" rather than "www.example.com") which is then rejected by the recursive nameserver. Radware and F5 are mention because I've chased down actual failures, in the last 3 months, and these were the reported products involved. I'm sure there will be other vendor that also have similar issues. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Tue Jul 26 19:39:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB56D11E80BE; Tue, 26 Jul 2011 19:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDtoA7PccFX9; Tue, 26 Jul 2011 19:39:21 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2A99411E80A5; Tue, 26 Jul 2011 19:39:21 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id BE1265F99DB; Wed, 27 Jul 2011 02:39:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 069F1216C81; Wed, 27 Jul 2011 02:38:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5C72D1232958; Wed, 27 Jul 2011 12:38:33 +1000 (EST) To: Brian E Carpenter From: Mark Andrews References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> In-reply-to: Your message of "Wed, 27 Jul 2011 10:49:53 +1200." <4E2F4491.30102@gmail.com> Date: Wed, 27 Jul 2011 12:38:33 +1000 Message-Id: <20110727023833.5C72D1232958@drugs.dv.isc.org> Cc: Alexandru Petrescu , IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 02:39:21 -0000 In message <4E2F4491.30102@gmail.com>, Brian E Carpenter writes: > Alex, > > Since 6to4 is a transition mechanism it has no long term future > *by definition*. Even if someone chooses to design a v2, who is going to > implement it? > > If you have a reason to install and enable 6to4, why would the nominal > status of a couple of RFCs make you do anything different? > > Of course, if implementors choose to drop the code you might not be > able to upgrade software versions - but hopefully by that time you > will have native IPv6 service anyway. Which is exactly why HISTORIC is NOT appropriate. > Regards > Brian Carpenter -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From gih@apnic.net Wed Jul 27 01:12:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDEB21F8BE1 for ; Wed, 27 Jul 2011 01:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.709 X-Spam-Level: X-Spam-Status: No, score=-101.709 tagged_above=-999 required=5 tests=[AWL=0.890, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEIIyD-mHALb for ; Wed, 27 Jul 2011 01:12:16 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 3D37121F8BE0 for ; Wed, 27 Jul 2011 01:12:16 -0700 (PDT) Received: from dhcp-4331.meeting.ietf.org (dhcp-4331.meeting.ietf.org [130.129.67.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D60ACB67ED; Wed, 27 Jul 2011 18:12:12 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Wed, 27 Jul 2011 18:12:03 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <31C7A154-5F9A-4FF2-8093-8461F14F9B8E@apnic.net> References: <201107261355.p6QDt1422976@ftpeng-update.cisco.com> To: sowmini varadhan X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, rvaithia@cisco.com Subject: Re: [v6ops] new draft: draft-xli-v6ops-ivi-icmp-address-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 08:12:17 -0000 On 27/07/2011, at 10:54 AM, sowmini varadhan wrote: > On Tue, Jul 26, 2011 at 6:08 PM, Geoff Huston wrote: >=20 >>> Section 5: what happens if the algorithm ends up generating a = Martian source >>> address (e.g., subnet broadcast)? >>>=20 >>=20 >>=20 >> Nothing happens. There is no subnet here. As section 4 states: = "Addresses from the >> assigned address prefix are intended to be used as source addresses = and not as >> destination addresses" >=20 > So the receiver should ignore Section 5.3.7 of rfc1812 for this case? not at all - the entire purpose of this draft is to request the = designation of a block of conventional (non-'martian') addresses to use as source = addresses in a stateless IPv6/IPv4 mapping scenario.=20 > Also, are duplicate source addresses a problem? no. Geoff From pch-b2B3A6689@u-1.phicoh.com Wed Jul 27 01:33:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E808E21F8BEA; Wed, 27 Jul 2011 01:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGCnmAR0mZrV; Wed, 27 Jul 2011 01:33:00 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 8368321F8BE9; Wed, 27 Jul 2011 01:32:51 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QlzXt-0001gSC; Wed, 27 Jul 2011 10:32:49 +0200 Message-Id: To: Mark Andrews From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 27 Jul 2011 12:38:33 +1000 ." <20110727023833.5C72D1232958@drugs.dv.isc.org> Date: Wed, 27 Jul 2011 10:32:19 +0200 Cc: IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 08:33:01 -0000 In your letter dated Wed, 27 Jul 2011 12:38:33 +1000 you wrote: >In message <4E2F4491.30102@gmail.com>, Brian E Carpenter writes: >> Of course, if implementors choose to drop the code you might not be >> able to upgrade software versions - but hopefully by that time you >> will have native IPv6 service anyway. > >Which is exactly why HISTORIC is NOT appropriate. With rfc3484-revise and the documented brokenness of 6to4, it doesn't make any sense for implementors to offer 6to4 anyhow. So I think it would be quite weird to keep 6to4 at standards track just to prevent some vendors from dropping 6to4 support. From fred@cisco.com Wed Jul 27 04:10:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E46921F8548; Wed, 27 Jul 2011 04:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.109 X-Spam-Level: X-Spam-Status: No, score=-103.109 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnhJ1MC4Bq1T; Wed, 27 Jul 2011 04:10:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B6E7521F854C; Wed, 27 Jul 2011 04:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=304; q=dns/txt; s=iport; t=1311765025; x=1312974625; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=1hin4uOQkS5g+jSDNnAebBaB/3C6zDOjcxMIYRhoq7E=; b=bpTs4M1fD7dKBfE7do6X9B2GF6H0lU3r3y5Mhjuz7gUdRnJ33KxlWkWf ykQcEQe9iI9ewz2OcAZoTP0EwOdjBtjQsNZnL0jlLY+YNPQRWDaLTAgFi e1kZHW5uHGOwIyr5w5tlk7XgrvEZwYG6Zmly0PSwj08wLfeZSTP96W5rh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADzxL06rRDoI/2dsb2JhbAA1AQEBAQIBFAErRQUMDFIUUQc+pxp3iHyieJ5mhWFfBJJ1hQeLdw X-IronPort-AV: E=Sophos;i="4.67,276,1309737600"; d="scan'208";a="6905634" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2011 11:09:49 +0000 Received: from dhcp-4466.meeting.ietf.org (sjc-vpn6-314.cisco.com [10.21.121.58]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6RB8MU5020644; Wed, 27 Jul 2011 11:09:47 GMT Received: from [127.0.0.1] by dhcp-4466.meeting.ietf.org (PGP Universal service); Wed, 27 Jul 2011 07:09:48 -0400 X-PGP-Universal: processed; by dhcp-4466.meeting.ietf.org on Wed, 27 Jul 2011 07:09:48 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E2F4491.30102@gmail.com> Date: Wed, 27 Jul 2011 07:09:47 -0400 Message-Id: <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Alexandru Petrescu , IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 11:10:26 -0000 On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: > Since 6to4 is a transition mechanism it has no long term future *by = definition*. Even if someone chooses to design a v2, who is going to = implement it? Actually, I think one could argue pretty effectively that 6rd is = 6to4-bis.=20= From mark@townsley.net Wed Jul 27 04:32:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B8421F8AF1; Wed, 27 Jul 2011 04:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6643XnFsS5W8; Wed, 27 Jul 2011 04:32:01 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEBD21F8ACE; Wed, 27 Jul 2011 04:32:01 -0700 (PDT) Received: by pzk6 with SMTP id 6so2407487pzk.26 for ; Wed, 27 Jul 2011 04:32:01 -0700 (PDT) Received: by 10.68.50.67 with SMTP id a3mr12552750pbo.377.1311766321071; Wed, 27 Jul 2011 04:32:01 -0700 (PDT) Received: from [10.255.254.113] (rtp-isp-nat1.cisco.com [64.102.254.33]) by mx.google.com with ESMTPS id 9sm12505pbx.82.2011.07.27.04.31.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 04:31:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> Date: Wed, 27 Jul 2011 07:31:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39EEA819-6D8D-4FE7-958D-D7DCEDF893C1@townsley.net> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: Alexandru Petrescu , ietf@ietf.org, IPv6 Operations Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 11:32:02 -0000 On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: >=20 > On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: >=20 >> Since 6to4 is a transition mechanism it has no long term future *by = definition*. Even if someone chooses to design a v2, who is going to = implement it? >=20 > Actually, I think one could argue pretty effectively that 6rd is = 6to4-bis.=20 +1 - Mark > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rick@openfortress.nl Wed Jul 27 04:40:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86ED621F8500 for ; Wed, 27 Jul 2011 04:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.582 X-Spam-Level: * X-Spam-Status: No, score=1.582 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS-oVykaaM2U for ; Wed, 27 Jul 2011 04:40:42 -0700 (PDT) Received: from fame.vanrein.org (openfortress.nl [213.189.19.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0063621F8506 for ; Wed, 27 Jul 2011 04:40:41 -0700 (PDT) Received: from phantom.vanrein.org (phantom.vanrein.org [83.163.207.110]) by fame.vanrein.org (Postfix) with ESMTP id 4DF864040CD; Wed, 27 Jul 2011 12:40:40 +0100 (BST) Received: by phantom.vanrein.org (Postfix, from userid 1000) id E3984940B1; Wed, 27 Jul 2011 11:40:38 +0000 (CEST) Date: Wed, 27 Jul 2011 11:40:38 +0000 From: Rick van Rein To: v6ops@ietf.org Message-ID: <20110727114038.GE7494@phantom.vanrein.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM User-Agent: Mutt/1.5.11 Subject: Re: [v6ops] slight comments on draft-vanrein-v6ops-6bed4-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 11:41:52 -0000 Hello Washam, Thanks for commenting on my 6bed4 proposal. > For first glance, i have a rough impression this draft has some > similarity with another draft written a while ago at least in terms of > udp encapsulation of ipv6. please refer to > http://tools.ietf.org/html/draft-lee-softwire-6rd-udp I will look it up. Packing it up in UDP is commonly done, and has shown to make a tunnel independent of the router used. AICCU in the SIXXS project does it too, for instance. And so does TSP from RFC 5572. What 6bed4 does different, is employ autoconfiguration to get an IPv6 address from a remote tunnel server. > 1. fe80::/128 seems to me a subnet router anycast address according to > section 2.6.1, rfc4291. so you should not consider it as a unicast > address. although, i dont see any issues under the circumstances. I was not aware that the router address was an anycast address, but you are right. Strictly speaking it is routed to precisely one router using the underlying IPv4 address. I wonder if it can be called an improper implementation to have an anycast addresses on a pointopoint link? > 2. you use DiffServ field several times, do you actually mean > TrafficClass field? please in line with rfc2460. Yes, that is what I meant. I have fixed it for -01, thanks. Has this ever been renamed in IPv4, or is it still officially called Type Of Service? > 3. why don't you mention direct encapsulated ipv6 end embeded system > to end embeded communication? is it not in your senario or anything > else? I have difficulties parsing this one... I mentioned peer-to-peer traffic in 2.2; encapsulating IPv6 in IPv4 (proto-41) is not independent of the router used; is that what you were asking about? > 4. you seem omit MTU and fragment/reassembly discussion. Good point, thanks. Thanks, -Rick From jeroen@unfix.org Wed Jul 27 05:11:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30CC21F8ABD for ; Wed, 27 Jul 2011 05:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m+WA3DqExmt for ; Wed, 27 Jul 2011 05:11:09 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id D959E21F86A5 for ; Wed, 27 Jul 2011 05:11:08 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:41e0:ff42:99:ca2a:14ff:fe1f:2b7b]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id B4732801C2BF; Wed, 27 Jul 2011 14:11:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1311768665; bh=40J2aNaPIiyuYHSLKetTiQqKIdwjpZa0TSB50lARxQY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dhzf+gWKkfRQdfXEci9GwidYPDWqF0xuHkiF+cuTtrogfqoIRaswzQG6GQuuTgWe3 /ogOH2rHZDiz0ZIjme6eHZkYrsfjgJ5UaYlfwGuB6k+Fn/PW2+JNpa+7QSx/7Ka8R9 kaBA8CyzPieZsqYGxXkETdDJkQ4bzcieWcO1xrU3TnXtlplRfIvBiG5yyWkbtqk41o boaBbhdrfrfUSU99EACifxk1rEipZ32+t/+FSO17g88LIC5KLW5oSrotK6BwICtqoQ UzUfKYXkdd1mJxhQuo/FKEPEujrDJgFgqCic3BA4NJUuO63zIWfb2cR57ZZ8mJKfIg xIHNh2vDpCfeQ== Message-ID: <4E30005A.8080205@unfix.org> Date: Wed, 27 Jul 2011 14:11:06 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Rick van Rein References: <20110727114038.GE7494@phantom.vanrein.org> In-Reply-To: <20110727114038.GE7494@phantom.vanrein.org> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] slight comments on draft-vanrein-v6ops-6bed4-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 12:11:10 -0000 On 2011-07-27 13:40 , Rick van Rein wrote: > Hello Washam, > > Thanks for commenting on my 6bed4 proposal. > >> For first glance, i have a rough impression this draft has some >> similarity with another draft written a while ago at least in terms of >> udp encapsulation of ipv6. please refer to >> http://tools.ietf.org/html/draft-lee-softwire-6rd-udp > > I will look it up. Packing it up in UDP is commonly done, and has > shown to make a tunnel independent of the router used. AICCU in > the SIXXS project does it too, for instance. And so does TSP from > RFC 5572. AICCU is a tool, the protocol that you mean is AYIYA. Teredo, which is mostly stateless and already deploy would fit your requirements quite well, especially as you are only connecting a single host. As your main 'requirement' is embedded system, you might want to look at 6lowpan and of course simple native IPv6. But I really wonder why you mention that 'embedded' is so special while having both a full IPv4 and IPv6 stack in it is actually the heaviest portion you can have. Stripping the IPv4 stack would serve your purpose much better. Also if there is no native IPv6, then let an external device do the IPv6 gatewaying to the Internet. Also you are forgetting about a VERY important aspect that Teredo does solve: local traffic between hosts. As your made-up global IPv6 address is based on the outmost IPv4-NAT IP address + port (because otherwise the PoP would have to keep state), I really wonder how you stick that address as a source address in the IPv6 header that is inside the IPv4 packet. I can only suggest that you look at Teredo which solves most of these issues with autoconfiguration and not state. Teredo matches most of your 'requirements'... Greets, Jeroen From moore@network-heretics.com Wed Jul 27 05:15:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4482821F84FC; Wed, 27 Jul 2011 05:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzM7Hb9gPlkB; Wed, 27 Jul 2011 05:15:34 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9F47121F84FB; Wed, 27 Jul 2011 05:15:34 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id D880D20F47; Wed, 27 Jul 2011 08:15:33 -0400 (EDT) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 27 Jul 2011 08:15:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=cSBNGM13VFnp8lqVB1hXedmpbjw=; b=Lt 2JvXEJ49RKmJCg/Bz6l4QZR0rUTSMu5EM++nFzOcPBn7WPy+Jx9ig52Qg6tU4pEN 9bXvXrMivZlgsvU+dtAMN1NDrKn+TGOUIUVoJTpBbavOf0nLLFfK3ygYoweVrSAn CcdnkkulHHc9QITvlLHr5M3TdE1EE9f8Kec6xBx0g= X-Sasl-enc: l/0kR7TzKstpxO2P2tBGQ9c1SOPMRqhYSbHINIEv8yZO 1311768933 Received: from [192.168.210.100] (modemcable114.145-70-69.static.videotron.ca [69.70.145.114]) by mail.messagingengine.com (Postfix) with ESMTPSA id 57C5D455412; Wed, 27 Jul 2011 08:15:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> Date: Wed, 27 Jul 2011 08:15:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5A600744-8605-46D3-82B2-C3C30E30E4AC@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , ietf@ietf.org, Keith Moore Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 12:15:35 -0000 On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: >=20 > On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: >=20 >> Since 6to4 is a transition mechanism it has no long term future *by = definition*. Even if someone chooses to design a v2, who is going to = implement it? >=20 > Actually, I think one could argue pretty effectively that 6rd is = 6to4-bis. only if you're confused about the use cases for each. Keith From rick@vanrein.org Wed Jul 27 05:51:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027CB21F855A for ; Wed, 27 Jul 2011 05:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.356 X-Spam-Level: X-Spam-Status: No, score=0.356 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHICo+hKYnMp for ; Wed, 27 Jul 2011 05:51:37 -0700 (PDT) Received: from fame.vanrein.org (openfortress.nl [213.189.19.244]) by ietfa.amsl.com (Postfix) with ESMTP id F023321F8557 for ; Wed, 27 Jul 2011 05:51:36 -0700 (PDT) Received: from phantom.vanrein.org (phantom.vanrein.org [83.163.207.110]) by fame.vanrein.org (Postfix) with ESMTP id 423B64040CD for ; Wed, 27 Jul 2011 13:51:35 +0100 (BST) Received: by phantom.vanrein.org (Postfix, from userid 1000) id 62D36940B1; Wed, 27 Jul 2011 12:51:34 +0000 (CEST) Resent-From: rick@vanrein.org Resent-Date: Wed, 27 Jul 2011 12:51:34 +0000 Resent-Message-ID: <20110727125134.GB1237@phantom.vanrein.org> Resent-To: v6ops@ietf.org X-Original-To: rick@openfortress.nl Received: by phantom.vanrein.org (Postfix, from userid 1000) id 5BC75940B1; Wed, 27 Jul 2011 12:51:14 +0000 (CEST) Date: Wed, 27 Jul 2011 12:51:14 +0000 From: Rick van Rein To: Jeroen Massar Message-ID: <20110727125114.GA1237@phantom.vanrein.org> References: <20110727114038.GE7494@phantom.vanrein.org> <4E30005A.8080205@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E30005A.8080205@unfix.org> X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM User-Agent: Mutt/1.5.11 Subject: Re: [v6ops] slight comments on draft-vanrein-v6ops-6bed4-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 12:56:18 -0000 Hello Jeroen, Thanks. Not all my answers are technical, but they also relate to what (lack of) movement I observe in practice: > Teredo, which is mostly stateless and already deploy would fit your > requirements quite well, especially as you are only connecting a single > host. Teredo does not keep the address space transparent; peer-to-peer connectivity is just as much a problem with Teredo as with IPv4. One application area that I want to see moving towards IPv6 is SIP (and I am working hard on that) and Teredo is not suitable for that application -- traffic would still need to pass through an RTP proxy under the limiting control of a provider. My work on SIP over IPv6 is the background of 6bed4, which I have generalised to what I think is a good option for IPv6 acceptance in embedded devices in general. To free SIP from the trouble that NAT causes (not firewalls, but the translation side of NAT) it should be IPv6-only. With that in place, reliable over-the-internet connection mechanisms are possible without intervention of a service provider whose RTP proxy won't connect anything but (say) voice, or who is not willing to support a deaf man's realtimetext session. > As your main 'requirement' is embedded system, you might want to look at > 6lowpan and of course simple native IPv6. With 6lowpan, there would be no support for general (ether)networks. Native IPv6 rocks (even more than your SIXXS tunnels) and I have it :) but this is not an assumption that a device manufacturer can rely on, so the support of IPv6 feels like an added frivolity to them. > But I really wonder why you mention that 'embedded' is so special while > having both a full IPv4 and IPv6 stack in it is actually the heaviest > portion you can have. Stripping the IPv4 stack would serve your purpose > much better. I kept these things a bit general in the draft, but walk up to your local gadget store and you will see no support for IPv6 to match the support found in operating systems. Programming a dual-stack system means that your code cannot make an implicit assumption throughout that it is a single-stack system. Or, if it does, it may step up to IPv6 if it can at the same time drop IPv4. Even mature open source networking tools contain this assumption; embedded environments are even more likely places for short-cuts like these, and so these are very hard platforms to get to become dual-stack. If it is hard, and it does not bring any new sales, then why go for dual-stack devices? > Also if there is no native IPv6, then let an external device do the IPv6 > gatewaying to the Internet. The academic in me agrees. But it is very hard to sell to everyday customers, and device manufacturers would not take that leap. > Also you are forgetting about a VERY important aspect that Teredo does > solve: local traffic between hosts. Thanks, this is indeed not the connectivity I was concerned about. Good point, need to think it over. > As your made-up global IPv6 address is based on the outmost IPv4-NAT IP > address + port (because otherwise the PoP would have to keep state), I > really wonder how you stick that address as a source address in the IPv6 > header that is inside the IPv4 packet. The first thing done is autoconfiguration, with the tunnel server as a target. The tunnel server can find this information in the IPv4 header that it receives. > I can only suggest that you look at Teredo which solves most of these > issues with autoconfiguration and not state. Teredo matches most of your > 'requirements'... Except for a transparant IPv6 address space! Thanks, -Rick From shemant@cisco.com Wed Jul 27 06:05:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E1B21F852E; Wed, 27 Jul 2011 06:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgQ8OkhVEjRs; Wed, 27 Jul 2011 06:05:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 61CF921F850E; Wed, 27 Jul 2011 06:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4848; q=dns/txt; s=iport; t=1311771926; x=1312981526; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=zP20pfgAQuZJfS6rJFcAfbHc53O7S5yXAXqRvZBf4wk=; b=FAp2kajnuYNKrR2y99wqSdOD/9UZ2iZ7P/fXIWklSKOA26i79FT7qChm +qQp3vfVddSnfTEyM8nNQpxje0kvRiEPLB4c5hxjipPvUsajTgUIoNLLZ P0qems1Bin/YtWbQUcaxSZWNvmVZsLRgqhUHcK9yWei6RAVPYwzQLAyNd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAGUMME6tJXG9/2dsb2JhbAA1AQEBAQMUAQwSA08RAgEJDgMEAQELBiMBBgETOw4IAQEFFwwbgjaVGo9Hd6sDnmCFYV8Eh1eQLotw X-IronPort-AV: E=Sophos;i="4.67,276,1309737600"; d="scan'208,217";a="6952449" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 27 Jul 2011 13:05:25 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6RD5PDv028793; Wed, 27 Jul 2011 13:05:25 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 08:05:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4C5D.D9481194" Date: Wed, 27 Jul 2011 08:04:01 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C302589DA4@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc Thread-Index: AcxL1ke6QeSpMOOVQ5yJeHkwEIDwegAhUNwg References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com><3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com><5B6B2B64C9FE2A489045EEEADDAFF2C302589C62@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Andre Kostur" X-OriginalArrivalTime: 27 Jul 2011 13:05:25.0804 (UTC) FILETIME=[D9E206C0:01CC4C5D] Cc: dhcwg@ietf.org, IPv6 Operations Subject: Re: [v6ops] [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:05:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4C5D.D9481194 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Andre Kostur [mailto:akostur@incognito.com]=20 Sent: Tuesday, July 26, 2011 4:55 PM To: Hemant Singh (shemant) Cc: Ted Lemon; dhcwg@ietf.org; IPv6 Operations Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc =20 >Why would the server necessarily wait for the IA_NA to expire before talking about the IA_PD again? Those two should be on separate timers. The preferred/valid/T1/T2 timers are all per IA, and the IA_NA is separate from the IA_PD. I am discussing the client since Ted asked why not wait for the IA_NA to timeout. If a CPE router has failed IA_PD acquisition, the IA_NA is not much use for the CPE and then CPE should try DHCPv6 forever to get both an IA_NA and IA_PD. The CPE router DHCv6 client hasn't even completed DHCPv6 to consider a client renewal/rebind or the server to send a Reconfigure. =20 Hemant ------_=_NextPart_001_01CC4C5D.D9481194 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From:= Andre = Kostur [mailto:akostur@incognito.com]
Sent: Tuesday, July 26, 2011 4:55 PM
To: Hemant Singh (shemant)
Cc: Ted Lemon; dhcwg@ietf.org; IPv6 Operations
Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 = CE rtr bis doc

 

>Why would the server necessarily wait for the IA_NA to expire before talking = about the IA_PD again?  Those two should be on separate timers.  The preferred/valid/T1/T2 timers are all per IA, and the IA_NA is separate = from the IA_PD.

I am discussing the = client since Ted asked why not wait for the IA_NA to timeout.   If a CPE = router has failed IA_PD acquisition, the IA_NA is not much use for the CPE and = then CPE should try DHCPv6 forever to get both an IA_NA and IA_PD.  The = CPE router DHCv6 client hasn’t even completed DHCPv6 to consider a = client renewal/rebind or the server to send a = Reconfigure.

 

Hemant

------_=_NextPart_001_01CC4C5D.D9481194-- From john.mann@monash.edu Wed Jul 27 06:07:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4BA21F8B72; Wed, 27 Jul 2011 06:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0Dl2u9bBDEh; Wed, 27 Jul 2011 06:07:55 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id D8CA721F8B71; Wed, 27 Jul 2011 06:07:54 -0700 (PDT) Received: from mail-vw0-f48.google.com ([209.85.212.48]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTjANqmFtk0IWhpuqU8EKGG6L+uRrv8NW@postini.com; Wed, 27 Jul 2011 06:07:55 PDT Received: by mail-vw0-f48.google.com with SMTP id 7so1208416vws.7 for ; Wed, 27 Jul 2011 06:07:54 -0700 (PDT) Received: by 10.52.19.161 with SMTP id g1mr55012vde.11.1311772074107; Wed, 27 Jul 2011 06:07:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.108.193 with HTTP; Wed, 27 Jul 2011 06:07:34 -0700 (PDT) In-Reply-To: <5A600744-8605-46D3-82B2-C3C30E30E4AC@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> <5A600744-8605-46D3-82B2-C3C30E30E4AC@network-heretics.com> From: "John Mann (ITS)" Date: Wed, 27 Jul 2011 23:07:34 +1000 Message-ID: To: Keith Moore Content-Type: multipart/alternative; boundary=20cf307c9c2e80e1b804a90cbce0 Cc: IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:07:55 -0000 --20cf307c9c2e80e1b804a90cbce0 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 27 July 2011 22:15, Keith Moore wrote: > > On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: > > > > > On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: > > > >> Since 6to4 is a transition mechanism it has no long term future *by > definition*. Even if someone chooses to design a v2, who is going to > implement it? > > > > Actually, I think one could argue pretty effectively that 6rd is > 6to4-bis. > > only if you're confused about the use cases for each. In my opinion: 6to4 use case - D.I.Y setup - no ISP involvement - depend upon kindness of strangers to run the anycast relays - some users have hard-to-solve reliability problems - experimental / historic / not-recommended - should be off by default - for users who would prefer "unreliable IPv6" to "no IPv6" 6rd use case - configuration parameters set by ISP - ISP runs the relays - apparently production quality (see free.fr) - for users who would prefer "no IPv6" to "unreliable Internet" I agree that 6rd is not a replacement protocol for the 6to4 use case. I will argue that the "6rd use case" is a replacement for the "6to4 use case". [ And that native dual-stack is a replacement for both. ] We want normal users to move past "experimental IPv6" towards "production IPv6". Thanks, John --20cf307c9c2e80e1b804a90cbce0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 27 July 2011 22:15, Keith Moore <moore@net= work-heretics.com> wrote:

On Jul 27, 2011, at 7:09 AM, Fred Baker wrote:

>
> On Jul 26, 2011, at 6:49 PM, Brian E Carpenter= wrote:
>
>> Since 6to4 is a transition mechanism it has no long term future *b= y definition*. Even if someone chooses to design a v2, who is going to impl= ement it?
>
> Actually, I think one could argue pretty effectively that 6rd is 6to4-= bis.

only if you're confused about the use cases for each.

In my opinion:

6to4 use case<= /div>
- D.I.Y setup - no ISP involvement
- depend upon kindne= ss of strangers to run the anycast relays
- some users have hard-to-solve reliability problems
- exper= imental / historic / not-recommended - should be off by default
-= for users who would prefer "unreliable IPv6" to "no IPv6&qu= ot;

6rd use case
- configuration parameters set b= y ISP
- ISP runs the relays
- apparently production qua= lity (see free.fr)
- for users who= would prefer "no IPv6" to "unreliable Internet"

I agree that 6rd is not a replacement protocol for the = 6to4 use case.

I will argue that the "6rd use= case" is a replacement for the "6to4 use case".
[ And that native dual-stack is a replacement for both. ]
We want= normal users to move past "experimental IPv6" towards "prod= uction IPv6".

Thanks,
=A0 =A0 John<= /div>
--20cf307c9c2e80e1b804a90cbce0-- From moore@network-heretics.com Wed Jul 27 06:35:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC3A11E8096; Wed, 27 Jul 2011 06:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WAIRM19Zo+u; Wed, 27 Jul 2011 06:35:20 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5C04F11E8085; Wed, 27 Jul 2011 06:35:20 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 1283A20F40; Wed, 27 Jul 2011 09:35:20 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 27 Jul 2011 09:35:20 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=rCs j39ZbfoAVzvPfEqAJNrlH4c8=; b=D/ceINFAGorplUwH3pfg9/zo8iuQA0f8ttH efGq5DtYi1LTZ94sfnnkFUrthejYUCU/OvuY2bnVacuaq13CPwTr+fUxNtx0ggbu uGpgQbrJLEJta8/Z0WMEJnkl4LD6NRVyymeKdYHQAP38CvEXooyZeevn4zPpvtgW MJTiUCDc= X-Sasl-enc: iogXk/Dp105PWrSJa8ojR3bky+dg9Gzr9aYU7P8TZCiX 1311773719 Received: from dhcp-12d1.meeting.ietf.org (dhcp-12d1.meeting.ietf.org [130.129.18.209]) by mail.messagingengine.com (Postfix) with ESMTPSA id A8A0E414428; Wed, 27 Jul 2011 09:35:19 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-35-606553518 From: Keith Moore In-Reply-To: Date: Wed, 27 Jul 2011 09:35:18 -0400 Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> <5A600744-8605-46D3-82B2-C3C30E30E4AC@network-heretics.com> To: "John Mann (ITS)" X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , ietf@ietf.org, Keith Moore Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:35:21 -0000 --Apple-Mail-35-606553518 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 27, 2011, at 9:07 AM, John Mann (ITS) wrote: >=20 > > Actually, I think one could argue pretty effectively that 6rd is = 6to4-bis. >=20 > only if you're confused about the use cases for each. >=20 > In my opinion: >=20 > 6to4 use case > - D.I.Y setup - no ISP involvement > - depend upon kindness of strangers to run the anycast relays > - some users have hard-to-solve reliability problems > - experimental / historic / not-recommended - should be off by default > - for users who would prefer "unreliable IPv6" to "no IPv6" close, but no cigar. the use case for 6to4 is when - you have a public IPv4 address - your ISP doesn't support any kind of IPv6 access - there's no good native v6 tunnel endpoint near your host, or your host = is mobile - you have applications for IPv6 other than to access content that is = also available via IPv4, OR your hosts are set up to prefer native IPv4 = over 6to4 addresses >=20 > 6rd use case > - configuration parameters set by ISP > - ISP runs the relays > - apparently production quality (see free.fr) > - for users who would prefer "no IPv6" to "unreliable Internet" >=20 > I agree that 6rd is not a replacement protocol for the 6to4 use case. >=20 > I will argue that the "6rd use case" is a replacement for the "6to4 = use case". If you have 6rd or any kind of native IPv6 available to you, you'll = almost certainly prefer it to 6to4, except perhaps when needing to = communicate with other hosts using 6to4. The problem is that native IPv6 is not widely available, and will not be = universally available for maybe 10 years. =20 (Or maybe, never, because the deployment model in many people's minds = assumes that the only reason to use IPv6 is to "access content" that = will continue to be available via IPv4 indefinitely.) > We want normal users to move past "experimental IPv6" towards = "production IPv6". I want that too. What I object to is a denial-of-service attack on = people who find 6to4 useful, just because it doesn't work as well as = IPv4 for services that support both IPv4 and IPv6. Keith --Apple-Mail-35-606553518 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

> Actually, I think one could argue pretty effectively that 6rd is = 6to4-bis.

only if you're confused about the use cases for = each.

In my = opinion:

6to4 use case
- D.I.Y setup = - no ISP involvement
- depend upon kindness of strangers to = run the anycast relays
- some users have hard-to-solve reliability problems
- = experimental / historic / not-recommended - should be off by = default
- for users who would prefer "unreliable IPv6" to "no = IPv6"

close, but no = cigar.

the use case for 6to4 is = when
- you have a public IPv4 address
- your ISP = doesn't support any kind of IPv6 access
- there's no good = native v6 tunnel endpoint near your host, or your host is = mobile
- you have applications for IPv6 other than to access = content that is also available via IPv4, OR your hosts are set up to = prefer native IPv4 over 6to4 addresses


6rd use case
- configuration parameters = set by ISP
- ISP runs the relays
- apparently = production quality (see free.fr)
- for users who would = prefer "no IPv6" to "unreliable Internet"

I agree that 6rd is not a replacement protocol for = the 6to4 use case.

I will argue that the "6rd = use case" is a replacement for the "6to4 use = case".

If you have 6rd or any = kind of native IPv6 available to you, you'll almost certainly prefer it = to 6to4, except perhaps when needing to communicate with other hosts = using 6to4.

The problem is that native IPv6 is = not widely available, and will not be universally available for maybe 10 = years.  

(Or maybe, never, because the = deployment model in many people's minds assumes that the only reason to = use IPv6 is to "access content" that will continue to be available via = IPv4 indefinitely.)

We want normal users to = move past "experimental IPv6" towards "production = IPv6".

I want that too.   = What I object to is a denial-of-service attack on people who find 6to4 = useful, just because it doesn't work as well as IPv4 for services that = support both IPv4 and = IPv6.

Keith

= --Apple-Mail-35-606553518-- From Ted.Lemon@nominum.com Wed Jul 27 07:20:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF9B11E80AE; Wed, 27 Jul 2011 07:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vg1QFQDFRMz; Wed, 27 Jul 2011 07:20:20 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id B422711E807A; Wed, 27 Jul 2011 07:20:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTjAeohXLl8Yw2JWYFnDeV4ss8Nox9s8t@postini.com; Wed, 27 Jul 2011 07:20:19 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E526E1B81B2; Wed, 27 Jul 2011 07:20:11 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CA325190058; Wed, 27 Jul 2011 07:20:11 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Wed, 27 Jul 2011 07:20:11 -0700 From: Ted Lemon To: Mark Andrews Thread-Topic: [v6ops] 6to4v2 (as in ripv2)? Thread-Index: AQHMS+Z/8YBivn23ZUinspFJsOVzppT/dTzEgAE45wA= Date: Wed, 27 Jul 2011 14:20:11 +0000 Message-ID: <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> In-Reply-To: <20110727023833.5C72D1232958@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.66.66] Content-Type: multipart/alternative; boundary="_000_968F0B1CD0824A598213FD58C74AF89Dnominumcom_" MIME-Version: 1.0 Cc: Alexandru Petrescu , "" , IPv6 Operations Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 14:20:21 -0000 --_000_968F0B1CD0824A598213FD58C74AF89Dnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you have a reason to install and enable 6to4, why would the nominal status of a couple of RFCs make you do anything different? This seems like an easy question to answer. You'd implement and use 6to4v= 2 because it works better than the historic 6to4 protocol. --_000_968F0B1CD0824A598213FD58C74AF89Dnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9F2F18C90D0CDB48A580ED2F6A936632@nominum.com> Content-Transfer-Encoding: quoted-printable
If you have a reason to install and enable 6to4, = why would the nominal
status of a couple of RFCs make you do anything d= ifferent?

This seems like an easy question to answer.   You'd implement and= use 6to4v2 because it works better than the historic 6to4 protocol.

--_000_968F0B1CD0824A598213FD58C74AF89Dnominumcom_-- From cb.list6@gmail.com Wed Jul 27 07:27:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849FA21F8A30; Wed, 27 Jul 2011 07:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rT3Q1du6HVBm; Wed, 27 Jul 2011 07:27:20 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9914821F89C1; Wed, 27 Jul 2011 07:27:19 -0700 (PDT) Received: by wyj26 with SMTP id 26so984462wyj.31 for ; Wed, 27 Jul 2011 07:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SFMZOTL1Ip0BEnt5jeAOMIGrnWcDWH5bj8N1Hd8ITZE=; b=mAXsv27UUsY6KdsG2FaN4/BfxAu2kEUN5PQripOwJICm3FTKmOSmMIfCy135EP8UEn TcnPzLfJhEy/2BU7U2ZwpnvKsUGENUJSldOz2MyfVDHh+cGb/8echO5cK68yiI2Ir3dU CDXWFmtSLfmvNodXn1e5BpiW+Nr+cTPn/rzB4= MIME-Version: 1.0 Received: by 10.217.3.17 with SMTP id q17mr2682230wes.107.1311776838109; Wed, 27 Jul 2011 07:27:18 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Wed, 27 Jul 2011 07:27:17 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Wed, 27 Jul 2011 07:27:17 -0700 (PDT) In-Reply-To: <39EEA819-6D8D-4FE7-958D-D7DCEDF893C1@townsley.net> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> <39EEA819-6D8D-4FE7-958D-D7DCEDF893C1@townsley.net> Date: Wed, 27 Jul 2011 07:27:17 -0700 Message-ID: From: Cameron Byrne To: Mark Townsley Content-Type: multipart/alternative; boundary=20cf301e2f2775cb4c04a90dd8d8 Cc: Alexandru Petrescu , IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 14:27:20 -0000 --20cf301e2f2775cb4c04a90dd8d8 Content-Type: text/plain; charset=ISO-8859-1 On Jul 27, 2011 4:32 AM, "Mark Townsley" wrote: > > > On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: > > > > > On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: > > > >> Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it? > > > > Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. > > +1 > +1 as well as 6in4 or native v6. The full requirements of 6to4 are based on currently unrealistic requirements for no-nat (apnic is post exhaust ) and service providers to stand up relays without a reasonable business case > - Mark > > > _______________________________________________ > > 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 --20cf301e2f2775cb4c04a90dd8d8 Content-Type: text/html; charset=ISO-8859-1


On Jul 27, 2011 4:32 AM, "Mark Townsley" <mark@townsley.net> wrote:
>
>
> On Jul 27, 2011, at 7:09 AM, Fred Baker wrote:
>
> >
> > On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote:
> >
> >> Since 6to4 is a transition mechanism it has no long term future *by definition*. Even if someone chooses to design a v2, who is going to implement it?
> >
> > Actually, I think one could argue pretty effectively that 6rd is 6to4-bis.
>
> +1
>

+1 as well as 6in4 or native v6.

The full requirements of 6to4 are based on currently unrealistic requirements for no-nat (apnic is post exhaust ) and service providers to stand up relays without a reasonable business case

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

--20cf301e2f2775cb4c04a90dd8d8-- From cb.list6@gmail.com Wed Jul 27 07:37:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D88721F8639; Wed, 27 Jul 2011 07:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEcDSRbS-atM; Wed, 27 Jul 2011 07:37:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D519921F861E; Wed, 27 Jul 2011 07:37:24 -0700 (PDT) Received: by wwe5 with SMTP id 5so978752wwe.13 for ; Wed, 27 Jul 2011 07:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oPXhWh34+TyOxPVNjseeYUd+oFMs5Eim5DWCp99dHlM=; b=miMFPYHR323W4hy2uYH+4gL/jd62qcfcwe1qDYbV8LP9cHlPr2MI2gJQVE+tGn8CXh bmUyfaML0MpdWAKekm7gS1zuPC4bRZCOuHolCuWHMVWEV1UnfcJf9yyz7oU5v18olXBG 5c5GHj/7BRToKnTUzPu84VabbtfrljbjWQMXs= MIME-Version: 1.0 Received: by 10.216.8.204 with SMTP id 54mr87991wer.92.1311777443806; Wed, 27 Jul 2011 07:37:23 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Wed, 27 Jul 2011 07:37:22 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Wed, 27 Jul 2011 07:37:22 -0700 (PDT) In-Reply-To: <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> Date: Wed, 27 Jul 2011 07:37:22 -0700 Message-ID: From: Cameron Byrne To: Ted Lemon Content-Type: multipart/alternative; boundary=0016364c7a7f8ffec104a90dfc22 Cc: Alexandru Petrescu , IPv6 Operations , "" Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 14:37:26 -0000 --0016364c7a7f8ffec104a90dfc22 Content-Type: text/plain; charset=ISO-8859-1 On Jul 27, 2011 7:20 AM, "Ted Lemon" wrote: >>> >>> If you have a reason to install and enable 6to4, why would the nominal >>> >>> status of a couple of RFCs make you do anything different? > > > This seems like an easy question to answer. You'd implement and use 6to4v2 because it works better than the historic 6to4 protocol. > > It seems like there is this deep philosophical discussion about historic status. From what I can tell, ietf sent nat-pt to historic well before nat64 came about. Many people were using nat-pt too ... but going to historic forced things along. It was a good choice in hindsight. Cb > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0016364c7a7f8ffec104a90dfc22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 27, 2011 7:20 AM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:
>>>
>>> If you have a reason to install and enable 6to4, why would the= nominal
>>>
>>> status of a couple of RFCs make you do anything different?
>
>
> This seems like an easy question to answer. =A0 You'd implement an= d use 6to4v2 because it works better than the historic 6to4 protocol.
>
>

It seems like there is this deep philosophical discussion about historic= status. From what I can tell, ietf sent nat-pt to historic well before nat= 64 came about. Many people were using nat-pt too ... but going to historic = forced things along. It was a good choice in hindsight.

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

--0016364c7a7f8ffec104a90dfc22-- From marka@isc.org Wed Jul 27 08:09:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5E521F8BC3; Wed, 27 Jul 2011 08:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JB+E2oG3jZF; Wed, 27 Jul 2011 08:09:05 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 1A03A21F8BC2; Wed, 27 Jul 2011 08:09:05 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id CE5385F991A; Wed, 27 Jul 2011 15:08:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C09C0216C86; Wed, 27 Jul 2011 15:08:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 69F5B1235C62; Thu, 28 Jul 2011 01:08:32 +1000 (EST) To: Cameron Byrne From: Mark Andrews References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> <39EEA819-6D8D-4FE7-958D-D7DCEDF893C1@townsley.net> In-reply-to: Your message of "Wed, 27 Jul 2011 07:27:17 MST." Date: Thu, 28 Jul 2011 01:08:32 +1000 Message-Id: <20110727150832.69F5B1235C62@drugs.dv.isc.org> Cc: IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:09:06 -0000 In message , Cameron Byrne writes: > > On Jul 27, 2011 4:32 AM, "Mark Townsley" wrote: > > > > > > On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: > > > > > > > > On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: > > > > > >> Since 6to4 is a transition mechanism it has no long term future *by > definition*. Even if someone chooses to design a v2, who is going to > implement it? > > > > > > Actually, I think one could argue pretty effectively that 6rd is > 6to4-bis. > > > > +1 > > > > +1 as well as 6in4 or native v6. > > The full requirements of 6to4 are based on currently unrealistic > requirements for no-nat (apnic is post exhaust ) and service providers to > stand up relays without a reasonable business case There are lots of things that require no-nat. 6to4 is just one of them. ISP will end up providing no-nat for those that need it the same way as they provide unfiltered port 25 for those that need it and it also shouldn't cost more. Yet there are relays out there and there are business cases to run them. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From akostur@incognito.com Tue Jul 26 13:54:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B2221F8A56; Tue, 26 Jul 2011 13:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2BraZ2jAzyH; Tue, 26 Jul 2011 13:54:56 -0700 (PDT) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with SMTP id 163A021F8A4B; Tue, 26 Jul 2011 13:54:55 -0700 (PDT) Received: from mail-gw0-f41.google.com ([74.125.83.41]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKTi8pnsQgEOl8ORjJv5mMAULPif3hjAcv@postini.com; Tue, 26 Jul 2011 13:54:56 PDT Received: by mail-gw0-f41.google.com with SMTP id a12so772092gwa.14 for ; Tue, 26 Jul 2011 13:54:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.173.41 with SMTP id u29mr8065626yhl.463.1311713694657; Tue, 26 Jul 2011 13:54:54 -0700 (PDT) Received: by 10.236.170.34 with HTTP; Tue, 26 Jul 2011 13:54:54 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302589C62@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com> <3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com> <5B6B2B64C9FE2A489045EEEADDAFF2C302589C62@XMB-RCD-109.cisco.com> Date: Tue, 26 Jul 2011 13:54:54 -0700 Message-ID: From: Andre Kostur To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=20cf305e2567d12cbb04a8ff2477 X-Mailman-Approved-At: Wed, 27 Jul 2011 08:09:34 -0700 Cc: dhcwg@ietf.org, IPv6 Operations Subject: Re: [v6ops] [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 20:54:57 -0000 --20cf305e2567d12cbb04a8ff2477 Content-Type: text/plain; charset=ISO-8859-1 Why would the server necessarily wait for the IA_NA to expire before talking about the IA_PD again? Those two should be on separate timers. The preferred/valid/T1/T2 timers are all per IA, and the IA_NA is separate from the IA_PD. On Tue, Jul 26, 2011 at 13:38, Hemant Singh (shemant) wrote: > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Tuesday, July 26, 2011 1:28 PM > To: Hemant Singh (shemant) > Cc: IPv6 Operations > Subject: Re: socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc > > >You should raise this on the DHCP mailing list. > > Done - thanks. > > >The questions I'd want to see answered are why just waiting for the > IA_NA to time out doesn't work, and why Reconfigure doesn't work. > > The IPv6 CE router DHC6 client sent its first SOLICIT with IA_NA and > IA_PD options and the server replied back with a valid IA_NA but failure > for the IA_PD (due to a mis-configured server for IA_PD). So if the > client waits for the IA_NA to timeout before the client sends any > subsequent SOLICIT for both IA_NA and IA_PD. The IA_NA IA_Address Valid > Lifetime is one week and thus the home LAN has no PD assigned for a > week. Note also that if a server is mis-configured for IA_PD, when the > mis-configuration is fixed, the IA_NA is may change as well. Thus it > makes sense to send both IA_NA and the IA_PD options is subsequent > SOLICITs. Agreed, when the IA_NA changes a Reconfigure can be sent from > the server to the client. But there is no automated means to detect the > mis-configuration and when does the server send the Reconfigure? > > Hemant > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- Andre Kostur Senior Software Design Engineer P: 604-678-2864 SIP: 864@incognito.com --20cf305e2567d12cbb04a8ff2477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Why would the server necessarily wait for the IA_NA to exp= ire before talking about the IA_PD again? =A0Those two should be on separat= e timers. =A0The preferred/valid/T1/T2 timers are all per IA, and the IA_NA= is separate from the IA_PD.

On Tue, Jul 26, 2011 at 13:38, Hemant Singh = (shemant) <sheman= t@cisco.com> wrote:
-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@= nominum.com]
Sent: Tuesday, July 26, 2011 1:28 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc

>You should raise this on the DHCP mailing list.

Done - thanks.

>The questions I'd want to see answered are why just waiting for the=
IA_NA to time out doesn't work, and why Reconfigure doesn't work.
The IPv6 CE router DHC6 client sent its first SOLICIT with IA_NA and
IA_PD options and the server replied back with a valid IA_NA but failure for the IA_PD (due to a mis-configured server for IA_PD). So if the
client waits for the IA_NA to timeout before the client sends any
subsequent SOLICIT for both IA_NA and IA_PD. =A0The IA_NA IA_Address Valid<= br> Lifetime is one week and thus the home LAN has no PD assigned for a
week. =A0Note also that if a server is mis-configured for IA_PD, when the mis-configuration is fixed, the IA_NA is may change as well. Thus it
makes sense to send both IA_NA and the IA_PD options is subsequent
SOLICITs. =A0Agreed, when the IA_NA changes a Reconfigure can be sent from<= br> the server to the client. =A0But there is no automated means to detect the<= br> mis-configuration and when does the server send the Reconfigure?

Hemant



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



--
Andre Kostur
Senior Softwa= re Design Engineer
P: 604-678-2864


--20cf305e2567d12cbb04a8ff2477-- From ek@google.com Wed Jul 27 08:12:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC3F21F8556 for ; Wed, 27 Jul 2011 08:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKQ2cPCwT5AM for ; Wed, 27 Jul 2011 08:12:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id BF5E521F859F for ; Wed, 27 Jul 2011 08:12:34 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p6RFCRxD001363 for ; Wed, 27 Jul 2011 08:12:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311779547; bh=6yNm7yArp9ui6NA18GGCwIasXuw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=gnjWvAt8mOihHBKcdolYL07jpG8UgeThIMGvxLyEeyuQ2i/h0qQKV74WCIPRCUsPG fxBUpMTKLxzi/G9FJN6oA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=lSwTkA16yfGbgWdEOlbprJLDDX5nWNUbJisqvVQmxHrOGecflksiC5qSnXKBGJ4ec U8PYPNgKrzwl9Vkbptf2g== Received: from qyk38 (qyk38.prod.google.com [10.241.83.166]) by wpaz29.hot.corp.google.com with ESMTP id p6RFCMoS022071 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 27 Jul 2011 08:12:26 -0700 Received: by qyk38 with SMTP id 38so1039629qyk.20 for ; Wed, 27 Jul 2011 08:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oRl2TDL/DdkCrHjDT4uRwWLTSzAk1dsHqlFNa3ohmt8=; b=PfjyfEEaVm3jGECW1529iC4fuN/QgftR1PH2sh60tejD61VWJuXSI1wrwNmXF89kKz LJ2X2ksLBWiwIB7/vPYQ== MIME-Version: 1.0 Received: by 10.229.217.72 with SMTP id hl8mr140836qcb.65.1311779546074; Wed, 27 Jul 2011 08:12:26 -0700 (PDT) Received: by 10.229.136.66 with HTTP; Wed, 27 Jul 2011 08:12:25 -0700 (PDT) In-Reply-To: <20110727150832.69F5B1235C62@drugs.dv.isc.org> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> <39EEA819-6D8D-4FE7-958D-D7DCEDF893C1@townsley.net> <20110727150832.69F5B1235C62@drugs.dv.isc.org> Date: Wed, 27 Jul 2011 15:12:25 +0000 Message-ID: From: Erik Kline To: Mark Andrews Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:12:35 -0000 Moving 6to4 to historic does not in any way impact your ability to use it as you wish. 6to4 support is not part of the IPv6 node requirements, as I understand it. Therefore I believe that any vendor (OS, router, otherwise) could deleted 6to4 support in any release and be in violation of anything, regardless of historic status. From marka@isc.org Wed Jul 27 08:16:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F108B21F889A; Wed, 27 Jul 2011 08:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OVWx59CBn33; Wed, 27 Jul 2011 08:16:12 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC6421F885E; Wed, 27 Jul 2011 08:16:12 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id D674E5F9978; Wed, 27 Jul 2011 15:15:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 19CD9216C86; Wed, 27 Jul 2011 15:15:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id CF9371235D70; Thu, 28 Jul 2011 01:15:17 +1000 (EST) To: Ted Lemon From: Mark Andrews References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> In-reply-to: Your message of "Wed, 27 Jul 2011 14:20:11 GMT." <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> Date: Thu, 28 Jul 2011 01:15:17 +1000 Message-Id: <20110727151517.CF9371235D70@drugs.dv.isc.org> Cc: Alexandru Petrescu , "" , IPv6 Operations Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:16:13 -0000 In message <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com>, Ted Lemon writes : > If you have a reason to install and enable 6to4, why would the nominal > status of a couple of RFCs make you do anything different? Because it will come down to "run 6to4 and be exposed to some bug" or "not run 6to4 but be safe from the bug". We already have vendors saying they are thinking about pulling 6to4 from their code bases if it becomes historic. > This seems like an easy question to answer. You'd implement and use 6to4v= > 2 because it works better than the historic 6to4 protocol. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From cb.list6@gmail.com Wed Jul 27 08:27:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0B721F8B04; Wed, 27 Jul 2011 08:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.994 X-Spam-Level: X-Spam-Status: No, score=-2.994 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o74oUzDVFbHN; Wed, 27 Jul 2011 08:27:55 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3327A21F8783; Wed, 27 Jul 2011 08:27:54 -0700 (PDT) Received: by wyj26 with SMTP id 26so1032064wyj.31 for ; Wed, 27 Jul 2011 08:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YiGuEk+4OEeEBFbClf3M4GzDg3z11MjUn2SutStxkk0=; b=nNJ1pOnG7T7pNJQrOBnwv2XhBzYkCwDWR5sersCojYOaccv9dEAfePpPDMEcMxOLbY VndjI3rzOy9qZykvwjk6ppTb/tT+PKylUFU73lbgyYsxmoeBvlMS+fa8b8q/mNg/3J5G ZH/tUfa9kHwvbET//B5OYqdzn88JodMC0X5o4= MIME-Version: 1.0 Received: by 10.217.3.17 with SMTP id q17mr906wes.107.1311780474124; Wed, 27 Jul 2011 08:27:54 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Wed, 27 Jul 2011 08:27:54 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Wed, 27 Jul 2011 08:27:54 -0700 (PDT) In-Reply-To: <20110727151517.CF9371235D70@drugs.dv.isc.org> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> <20110727151517.CF9371235D70@drugs.dv.isc.org> Date: Wed, 27 Jul 2011 08:27:54 -0700 Message-ID: From: Cameron Byrne To: Mark Andrews Content-Type: multipart/alternative; boundary=20cf301e2f272efb3604a90eb1e5 Cc: Alexandru Petrescu , "" , IPv6 Operations Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:27:56 -0000 --20cf301e2f272efb3604a90eb1e5 Content-Type: text/plain; charset=ISO-8859-1 On Jul 27, 2011 8:16 AM, "Mark Andrews" wrote: > > > In message <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com>, Ted Lemon writes > : > > If you have a reason to install and enable 6to4, why would the nominal > > status of a couple of RFCs make you do anything different? > > Because it will come down to "run 6to4 and be exposed to some bug" > or "not run 6to4 but be safe from the bug". We already have vendors > saying they are thinking about pulling 6to4 from their code bases > if it becomes historic. > You also have content owners that say no aaaa while 6to4 is tanking reliability stats. Pick your battles. Cb > > This seems like an easy question to answer. You'd implement and use 6to4v= > > 2 because it works better than the historic 6to4 protocol. > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --20cf301e2f272efb3604a90eb1e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 27, 2011 8:16 AM, "Mark Andrews" <marka@isc.org> wrote:
>
>
> In message <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com>, Ted = Lemon writes
> :
> > If you have a reason to install and enable 6to4, why would the no= minal
> > status of a couple of RFCs make you do anything different?
>
> Because it will come down to "run 6to4 and be exposed to some bug= "
> or "not run 6to4 but be safe from the bug". =A0We already ha= ve vendors
> saying they are thinking about pulling 6to4 from their code bases
> if it becomes historic.
>

You also have content owners that say no aaaa while 6to4 is tanking reli= ability stats.

Pick your battles.

Cb
> > This seems like an easy question to answer. =A0 You'd impleme= nt and use 6to4v=3D
> > 2 because it works better than the historic 6to4 protocol.
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--20cf301e2f272efb3604a90eb1e5-- From joelja@bogus.com Wed Jul 27 08:29:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6981821F8B04; Wed, 27 Jul 2011 08:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNEg4MeyNXrx; Wed, 27 Jul 2011 08:29:05 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9315921F8783; Wed, 27 Jul 2011 08:29:04 -0700 (PDT) Received: from [IPv6:2001:df8::80:129a:ddff:feb1:e750] ([IPv6:2001:df8:0:80:129a:ddff:feb1:e750]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6RFSwa5025754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Jul 2011 15:29:00 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-24-613313371 From: Joel Jaeggli In-Reply-To: Date: Wed, 27 Jul 2011 11:27:58 -0400 Message-Id: <9C388DC9-A440-4C78-8798-9FE822AC78BE@bogus.com> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [IPv6:2001:418:1::81]); Wed, 27 Jul 2011 15:29:00 +0000 (UTC) Cc: IPv6 Operations , "" Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:29:05 -0000 --Apple-Mail-24-613313371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 27, 2011, at 10:37 AM, Cameron Byrne wrote: >=20 > On Jul 27, 2011 7:20 AM, "Ted Lemon" wrote: > >>> > >>> If you have a reason to install and enable 6to4, why would the = nominal > >>> > >>> status of a couple of RFCs make you do anything different? > > > > > > This seems like an easy question to answer. You'd implement and = use 6to4v2 because it works better than the historic 6to4 protocol. > > > > >=20 > It seems like there is this deep philosophical discussion about = historic status. =46rom what I can tell, ietf sent nat-pt to historic = well before nat64 came about. Many people were using nat-pt too ... but = going to historic forced things along. It was a good choice in = hindsight. >=20 And natpt implementations still exist and are used by consenting adults. = At a previous employer we were considering the business case for an = implementation well after it's historic status. better solutions came = along. > Cb=20 >=20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --Apple-Mail-24-613313371 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 27, 2011, at 10:37 AM, Cameron Byrne wrote:


On Jul 27, 2011 7:20 AM, "Ted Lemon" <Ted.Lemon@nominum.com> wrote:
>>>
>>> If you have a reason to install and enable 6to4, why would the nominal
>>>
>>> status of a couple of RFCs make you do anything different?
>
>
> This seems like an easy question to answer.   You'd implement and use 6to4v2 because it works better than the historic 6to4 protocol.
>
>

It seems like there is this deep philosophical discussion about historic status. From what I can tell, ietf sent nat-pt to historic well before nat64 came about. Many people were using nat-pt too ... but going to historic forced things along. It was a good choice in hindsight.


And natpt implementations still exist and are used by consenting adults. At a previous employer we were considering the business case for an implementation well after it's historic status. better solutions came along.

Cb 

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

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

--Apple-Mail-24-613313371-- From akostur@incognito.com Wed Jul 27 08:32:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E52A21F8880; Wed, 27 Jul 2011 08:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRXTBjlcn996; Wed, 27 Jul 2011 08:32:15 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with SMTP id A385E21F84F2; Wed, 27 Jul 2011 08:32:14 -0700 (PDT) Received: from mail-yi0-f51.google.com ([209.85.218.51]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKTjAvff/bCyszj+ywGZzcGYK+UGgqXVKR@postini.com; Wed, 27 Jul 2011 08:32:15 PDT Received: by yib2 with SMTP id 2so1404754yib.24 for ; Wed, 27 Jul 2011 08:32:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.145.66 with SMTP id o42mr273755yhj.61.1311780733042; Wed, 27 Jul 2011 08:32:13 -0700 (PDT) Received: by 10.236.170.34 with HTTP; Wed, 27 Jul 2011 08:32:13 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302589DA4@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com> <3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com> <5B6B2B64C9FE2A489045EEEADDAFF2C302589C62@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C302589DA4@XMB-RCD-109.cisco.com> Date: Wed, 27 Jul 2011 08:32:13 -0700 Message-ID: From: Andre Kostur To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=20cf303b3be39dbf8604a90ec05b X-Mailman-Approved-At: Wed, 27 Jul 2011 08:33:28 -0700 Cc: dhcwg@ietf.org, IPv6 Operations Subject: Re: [v6ops] [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:32:16 -0000 --20cf303b3be39dbf8604a90ec05b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable (Whups... I meant "Why would the _client_ necessarily wait....") Again, why shouldn't the CPE wait the natural lifespan of the IA_NA before talking about it again? The CPE has lots of uses for the IA_NA. Namely it's own management, SNMP monitoring, source IP for syslog notifications, whatever. Otherwise why does it want an IA_NA at all? The client device shouldn't be tying the IA_NA together with the IA_PD. They are separate transactions that may travel together in a single DHCP packet. Not to put words in Ted's mouth, but I believe he was asking the same question. Why should the device abandon the perfectly good IA_NA that it has (or could have) already obtained just because the IA_PD was wrong. If the IA_NA stuff was changed on the DHCP server, the DHCP server knows who already has a lease which may be affected by whatever configuration change happened and either the admin can wait for the IA_NA to timeout (Renew, Rebind, or expiry), or explicitly send a Reconfigure to the device. Prevents this errant device from endlessly pounding the DHCP server about an IA_NA that it has already given the device. PS: I slightly misspoke about the preferred/valid times being per IA, those are per-iaddr, or prefix). On Wed, Jul 27, 2011 at 06:04, Hemant Singh (shemant) wr= ote: > ** ** > > *From:* Andre Kostur [mailto:akostur@incognito.com] > *Sent:* Tuesday, July 26, 2011 4:55 PM > *To:* Hemant Singh (shemant) > *Cc:* Ted Lemon; dhcwg@ietf.org; IPv6 Operations > *Subject:* Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr > bis doc**** > > ** ** > > >Why would the server necessarily wait for the IA_NA to expire before > talking about the IA_PD again? Those two should be on separate timers. = The > preferred/valid/T1/T2 timers are all per IA, and the IA_NA is separate fr= om > the IA_PD.**** > > I am discussing the client since Ted asked why not wait for the IA_NA to > timeout. If a CPE router has failed IA_PD acquisition, the IA_NA is not > much use for the CPE and then CPE should try DHCPv6 forever to get both a= n > IA_NA and IA_PD. The CPE router DHCv6 client hasn=92t even completed DHC= Pv6 > to consider a client renewal/rebind or the server to send a Reconfigure.*= * > ** > > ** ** > > Hemant**** > --=20 Andre Kostur Senior Software Design Engineer P: 604-678-2864 SIP: 864@incognito.com --20cf303b3be39dbf8604a90ec05b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
(Whups... I meant "Why would the _client_ necess= arily wait....")

Again, why shouldn't the CPE = wait the natural lifespan of the IA_NA before talking about it again? =A0Th= e CPE has lots of uses for the IA_NA. =A0Namely it's own management, SN= MP monitoring, source IP for syslog notifications, whatever. =A0Otherwise w= hy does it want an IA_NA at all? =A0The client device shouldn't be tyin= g the IA_NA together with the IA_PD. =A0They are separate transactions that= may travel together in a single DHCP packet.

Not to put words in Ted's mouth, but I believe he was as= king the same question. =A0Why should the device abandon the perfectly good= IA_NA that it has (or could have) already obtained just because the IA_PD = was wrong. =A0If the IA_NA stuff was changed on the DHCP server, the DHCP s= erver knows who already has a lease which may be affected by whatever confi= guration change happened and either the admin can wait for the IA_NA to tim= eout (Renew, Rebind, or expiry), or explicitly send a Reconfigure to the de= vice. =A0Prevents this errant device from endlessly pounding the DHCP serve= r about an IA_NA that it has already given the device.


PS: I slightly misspoke about the prefer= red/valid times being per IA, those are per-iaddr, or prefix).

On Wed, Jul 27, 2011 at 06:04, Hemant Sin= gh (shemant) <she= mant@cisco.com> wrote:

=A0

From:= Andre Kostur [mailto:akostur@= incognito.com]
Sent: Tuesday, July 26, 2011 4:55 PM
To: Hemant Singh (shemant)
Cc: Ted Lemon; d= hcwg@ietf.org; IPv6 Operations
Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE = rtr bis doc

=A0

>Why would the server necessarily wait for the IA_NA to expire before talking ab= out the IA_PD again? =A0Those two should be on separate timers. =A0The preferred/valid/T1/T2 timers are all per IA, and the IA_NA is separate from= the IA_PD.

I am discussing the cl= ient since Ted asked why not wait for the IA_NA to timeout.=A0 =A0If a CPE router has failed IA_PD acquisition, the IA_NA is not much use for the CPE and the= n CPE should try DHCPv6 forever to get both an IA_NA and IA_PD. =A0The CPE router DHCv6 client hasn=92t even completed DHCPv6 to consider a client renewal/rebind or the server to send a Reconfigure.

=A0

Hemant




--
Andre Kostur
Senior Softwa= re Design Engineer
P: 604-678-2864


--20cf303b3be39dbf8604a90ec05b-- From tjc@ecs.soton.ac.uk Wed Jul 27 08:35:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6EE21F8BDB; Wed, 27 Jul 2011 08:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItQBnxRW1JXU; Wed, 27 Jul 2011 08:35:17 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 7B55621F8BD8; Wed, 27 Jul 2011 08:35:17 -0700 (PDT) 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 p6RFZCao005041; Wed, 27 Jul 2011 16:35:12 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p6RFZCao005041 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1311780912; bh=euyLtAa7+f1ooboyltGPlCkk5DU=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=o8ogwwELSpzNaxbIHLQ+AAPbo+C4/lcrmGUuJLPVhg0AsXKe85RXOW87+hK9eBvWo HL9WUbwlhzJRfR3VgJVnBk9/LcPFHKAXGWtsuKjVYR0RWY02qrKzuwauNEkA77/tag /21jAXwxhxq8/gKjWmwvTn6Vngwha+w0amhX7HIY= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n6QGZC0366144739vf ret-id none; Wed, 27 Jul 2011 16:35:12 +0100 Received: from [IPv6:2001:df8::16:704d:e106:4b6a:660a] ([IPv6:2001:df8:0:16:704d:e106:4b6a:660a]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p6RFZ7i7031397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jul 2011 16:35:08 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Tim Chown In-Reply-To: <20110727151517.CF9371235D70@drugs.dv.isc.org> Date: Wed, 27 Jul 2011 16:35:07 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> <20110727151517.CF9371235D70@drugs.dv.isc.org> To: IETF Discussion , IPv6 Operations X-Mailer: Apple Mail (2.1244.3) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n6QGZC036614473900; tid=n6QGZC0366144739vf; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p6RFZCao005041 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:35:19 -0000 On 27 Jul 2011, at 16:15, Mark Andrews wrote: >=20 > Because it will come down to "run 6to4 and be exposed to some bug" > or "not run 6to4 but be safe from the bug". We already have vendors > saying they are thinking about pulling 6to4 from their code bases > if it becomes historic. I would note that RIPE-501 does not mention 6to4: http://www.ripe.net/ripe/docs/ripe-501 As far as I can see, it only mentions RFC4213. I would ask what is the alternative if as Mark suggests the vendors = begin removing 6to4 support? a) use 6to4 anyway on an open platform like OpenWRT b) use a tunnel broker - this works much better through NATs and with = dynamic IPv4 addresses c) use your $work VPN if it supports IPv6, which it could/should if your = company values IPv6 d) get IPv6 from your ISP, or move to one that has it if yours does not I suspect, but have no proof, that the huge majority of 6to4 users don't = use it intentionally, and the content they are trying to reach is also = available over IPv4. But for people who want to develop and use new = IPv6-specific apps, then either a broker or something like OpenWRT ought = to meet their needs? Tim= From marka@isc.org Wed Jul 27 09:04:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A524311E80E8; Wed, 27 Jul 2011 09:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-1.451, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_COMPNY=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81LifpFrt4xR; Wed, 27 Jul 2011 09:04:21 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D8FC611E80F2; Wed, 27 Jul 2011 09:04:20 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id DB20B5F997F; Wed, 27 Jul 2011 16:04:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C125C216C87; Wed, 27 Jul 2011 16:03:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id A07C31236670; Thu, 28 Jul 2011 02:03:31 +1000 (EST) To: Tim Chown From: Mark Andrews References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> <20110727151517.CF9371235D70@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 27 Jul 2011 16:35:07 +0100." Date: Thu, 28 Jul 2011 02:03:31 +1000 Message-Id: <20110727160331.A07C31236670@drugs.dv.isc.org> Cc: IPv6 Operations , IETF Discussion Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:04:21 -0000 In message , Tim Chown writes: > > On 27 Jul 2011, at 16:15, Mark Andrews wrote: > > > > Because it will come down to "run 6to4 and be exposed to some bug" > > or "not run 6to4 but be safe from the bug". We already have vendors > > saying they are thinking about pulling 6to4 from their code bases > > if it becomes historic. > > I would note that RIPE-501 does not mention 6to4: > http://www.ripe.net/ripe/docs/ripe-501 > As far as I can see, it only mentions RFC4213. > > I would ask what is the alternative if as Mark suggests the vendors begin rem > oving 6to4 support? > a) use 6to4 anyway on an open platform like OpenWRT Which may or may not still have the code. OpenWRT could remove support just the same as another source could. OpenWRT is also not widely supported by CPE vendors. i.e. you are own your own if something goes wrong in most (not all) cases. > b) use a tunnel broker - this works much better through NATs and with dynamic > IPv4 addresses For which there is only experimental / ad-hoc code. Please name CPE vendors that support tsp? Please name CPE vendors that support tunnel re-configuration on re-number. > c) use your $work VPN if it supports IPv6, which it could/should if your comp > any values IPv6 > d) get IPv6 from your ISP, or move to one that has it if yours does not Which is not always a viable option. > I suspect, but have no proof, that the huge majority of 6to4 users don't use > it intentionally, and the content they are trying to reach is also available > over IPv4. But for people who want to develop and use new IPv6-specific apps, > then either a broker or something like OpenWRT ought to meet their needs? > > Tim > _______________________________________________ > 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 jnc@mercury.lcs.mit.edu Wed Jul 27 09:14:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD7911E8071; Wed, 27 Jul 2011 09:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbYeS1cc4l8s; Wed, 27 Jul 2011 09:14:46 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id E381721F8666; Wed, 27 Jul 2011 09:14:45 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1C00A18C0CB; Wed, 27 Jul 2011 12:14:45 -0400 (EDT) To: ietf@ietf.org Message-Id: <20110727161445.1C00A18C0CB@mercury.lcs.mit.edu> Date: Wed, 27 Jul 2011 12:14:45 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: v6ops@ietf.org, jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:14:46 -0000 > From: Philip Homburg > I think it would be quite weird to keep 6to4 at standards track just to > prevent some vendors from dropping 6to4 support. There have been suggestions that it might be more appropriate to reclassify it as Experimental, and I think that makes a lot of sense - as you correctly (IMO) point out, due to its issues 6to4 is not really appropriate for standards track (at least, in its current form). Noel From marka@isc.org Wed Jul 27 09:26:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3F321F8A4B; Wed, 27 Jul 2011 09:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yxAyVuBiWdl; Wed, 27 Jul 2011 09:26:27 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D8B8921F899F; Wed, 27 Jul 2011 09:26:26 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 899D65F996E; Wed, 27 Jul 2011 16:26:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 928C7216C84; Wed, 27 Jul 2011 16:25:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 93E3C1236E8D; Thu, 28 Jul 2011 02:25:34 +1000 (EST) To: Cameron Byrne From: Mark Andrews References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> <20110727151517.CF9371235D70@drugs.dv.isc.org> In-reply-to: Your message of "Wed, 27 Jul 2011 08:27:54 MST." Date: Thu, 28 Jul 2011 02:25:34 +1000 Message-Id: <20110727162534.93E3C1236E8D@drugs.dv.isc.org> Cc: Alexandru Petrescu , "" , IPv6 Operations Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:26:27 -0000 In message , Cameron Byrne writes: > On Jul 27, 2011 8:16 AM, "Mark Andrews" wrote: > > > > > > In message <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com>, Ted Lemon > writes > > : > > > If you have a reason to install and enable 6to4, why would the nominal > > > status of a couple of RFCs make you do anything different? > > > > Because it will come down to "run 6to4 and be exposed to some bug" > > or "not run 6to4 but be safe from the bug". We already have vendors > > saying they are thinking about pulling 6to4 from their code bases > > if it becomes historic. > > You also have content owners that say no aaaa while 6to4 is tanking > reliability stats. You have Google Chrome and Firefox already implementing HE. You have new address selection rules out there. You have a dramatic decrease in 6to4 traffic already as a result. You have improved throughput for the 80% of machines for which 6to4 does work. We are yet to see the effects of Mac OS Lion both the 6to4 side and the HE side. > Pick your battles. > > Cb > > > This seems like an easy question to answer. You'd implement and use > 6to4v= > > > 2 because it works better than the historic 6to4 protocol. > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From shemant@cisco.com Wed Jul 27 09:28:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FEA11E8127 for ; Wed, 27 Jul 2011 09:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8F0ZE0TbHXF for ; Wed, 27 Jul 2011 09:28:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DEE7A11E80F2 for ; Wed, 27 Jul 2011 09:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2870; q=dns/txt; s=iport; t=1311784111; x=1312993711; h=mime-version:subject:date:message-id:from:to; bh=3b+KyxyA7wiklEjEUFjzn36l6tegszvcAWvX1/BO4zk=; b=lnKJaI6hz79svxtTAnUh1h8tRs3jCC4WxsxYOSx6h71EtKYir6HeHGgj q4ljPunkMhYvW0Kx+pjN/11rHXqC4t9h4K86p266Gvo2vC8Ieb8L2RiNI QQelmAAWg3FagcgrVtA58i8R/qQm50KjwQuoBMNoZ3ow2mA4UQYMJzq+E Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGQ8ME6tJXHA/2dsb2JhbAA3AQEDFAEMEgNiAQ0eBiQHE1IBBSMbgjakanerOIEjnm+FYV8Eh1eQLotw X-IronPort-AV: E=Sophos;i="4.67,277,1309737600"; d="scan'208,217";a="7046610" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 27 Jul 2011 16:28:27 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6RGSRBf027096 for ; Wed, 27 Jul 2011 16:28:27 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 11:28:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4C7A.36116116" Date: Wed, 27 Jul 2011 11:28:30 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: default LAN routing protocol for IPv6 CE router Thread-Index: AcxMejiPUZQ36kGBRni7tfpceY7Few== From: "Hemant Singh (shemant)" To: "IPv6 Operations" X-OriginalArrivalTime: 27 Jul 2011 16:28:27.0253 (UTC) FILETIME=[3697A250:01CC4C7A] Subject: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:28:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4C7A.36116116 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPv6 CPE router vendors, please give feedback. Does anyone object if we specify the default routing protocol as OSPFv3 with only area zero for the IPv6 CE router bis document? Or would you prefer the document is silent on specification of any default? =20 Thanks, =20 Hemant =20 ------_=_NextPart_001_01CC4C7A.36116116 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IPv6 CPE router vendors, please give = feedback.  Does anyone object if we specify the default routing protocol as OSPFv3 with only = area zero for the IPv6 CE router bis document?   Or would you prefer the = document is silent on specification of any  default?

 

Thanks,

 

Hemant

 

------_=_NextPart_001_01CC4C7A.36116116-- From jeroen@unfix.org Wed Jul 27 09:29:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C5511E8133; Wed, 27 Jul 2011 09:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOu4jpsiVidb; Wed, 27 Jul 2011 09:28:59 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC4311E80E8; Wed, 27 Jul 2011 09:28:59 -0700 (PDT) Received: from yomi.ch.unfix.org (223-95.60-188.cust.bluewin.ch [188.60.95.223]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 5C835801C2BF; Wed, 27 Jul 2011 18:28:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1311784136; bh=b0bm6WD1UlGKKVAT39bNA2kaHLj7zibSlQUgGqveif8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=yEVdQ2RLQT8NgUkSbH4Hq6Sj8gTLLYW/WkXuZ/UFKYWRoU67Lc4v+2d/22w0unBnk UKNQx21EAqMCjgDAEGf8bG3f8oljVHVxGku48g3kTe2KO77GwJmlxZbVP6P3HZfndp 0kjSJ1W+Uv3oHuYFMDuBfcC+t+Icm+o6Acp+LbPxzOplf5vlcH7+wEt4rUTrpCF099 0l2hDMc4GBRyF07QL1GSR4fek5vsSNP90mClBy3mvPysIh2sfHXqZItLDLhwO0ipdv AOlaIXVJvN2FDLefimIRaYpc1JcX+vzCzwx2p0FA6FcXn8B0yYWULabR/+VkwlemUK FLekm5pMjfTOQ== Message-ID: <4E303CB5.9050606@unfix.org> Date: Wed, 27 Jul 2011 18:28:37 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Andrews References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> <20110727151517.CF9371235D70@drugs.dv.isc.org> <20110727160331.A07C31236670@drugs.dv.isc.org> In-Reply-To: <20110727160331.A07C31236670@drugs.dv.isc.org> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , IETF Discussion Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:29:10 -0000 On 2011-07-27 18:03 , Mark Andrews wrote: [..] >> b) use a tunnel broker - this works much better through NATs and with dynamic >> IPv4 addresses > > For which there is only experimental / ad-hoc code. You call my code Experimental/ad-hoc? :) Like a good whiskey it matured over the years and hopefully soon I will be releasing the next edition of AICCU which solves, at least in that implementation, a couple of quirks that we have encountered in the recent years. > Please name > CPE vendors that support tsp? Please name CPE vendors that support > tunnel re-configuration on re-number. I don't know about TSP, but for the combination of TIC/heartbeat + AYIYA in some cases there are a variety of vendors, amongst which AVM Fritz!Box, Draytek, ZyXel Motorola, and various others I tend to forget ;) I unfortunately do not have an exact list of devices/models as I had nothing to do with them, we just get users saying that they have a device which supports it ;) The fun part though with CPEs is that they tend to sit on the public IP address, which is also the reason why the Fritz!Box only does TIC/heartbeat. And of course every self respecting distribtion has support for it too by just adding AICCU, that includes the various WRTs, pfSense, m0nowall, Astaro and many many others. As you said, everybody can decide themselves what options they add ;) Greets, Jeroen From d.sturek@att.net Wed Jul 27 09:34:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAA411E8108 for ; Wed, 27 Jul 2011 09:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.049 X-Spam-Level: * X-Spam-Status: No, score=1.049 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X+HJ1gLZ-5N for ; Wed, 27 Jul 2011 09:34:00 -0700 (PDT) Received: from nm27.access.bullet.mail.mud.yahoo.com (nm27.access.bullet.mail.mud.yahoo.com [66.94.237.92]) by ietfa.amsl.com (Postfix) with SMTP id 2682211E80FE for ; Wed, 27 Jul 2011 09:34:00 -0700 (PDT) Received: from [66.94.237.194] by nm27.access.bullet.mail.mud.yahoo.com with NNFMP; 27 Jul 2011 16:33:55 -0000 Received: from [66.94.237.119] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 27 Jul 2011 16:33:55 -0000 Received: from [127.0.0.1] by omp1024.access.mail.mud.yahoo.com with NNFMP; 27 Jul 2011 16:33:55 -0000 X-Yahoo-Newman-Id: 435969.16197.bm@omp1024.access.mail.mud.yahoo.com Received: (qmail 14592 invoked from network); 27 Jul 2011 16:33:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1311784435; bh=Pa0ejdKHRY6fBe+g6BbkG74NXOvCsIGR2pAdnTBu+oc=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=5BBSf9mx7bwGK5zS4cxI7isVoh3V3jwpkhTc59iOHpLWhEkNgnBqBuLEDoaASFh9UngPlEuG8vfdtNc+FCA7wMQd4Cnea/NwYsVJvzb+WgZ2+JOkO48P2PvmD41RT7sS4pK9F4Id+rCMApXUoRRrYzvDzSIb98ChWV1AHz30f3w= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: TP27lPcVM1mdkE9dXmFDziKnteo2Zc32HPpkrJIMn2T_Na2 xLDzts1Svb4OTcvXr4fYBiE9AxQnk5yCXqMn5fhUHTniJ72c.nkPnaQx8g_U J4hszO4GwG79q2bDmWgyvupCYJuh23yO_KkiDw3Alh.qbASRMjR8_TGVyFSy Uqlt3YrtoklituCp8v3GVmtvOHXmg837EWW6jP.RVKDL6Agl5qwpEYJ7SfkL xiiT7NvIkb2QP0UHxRV0DquCnA6dpmPkxz5A8cnS1zUwiT.EJJk5ozFbZqLE boEr574lgS4SkVc9rG_lp4PMH6KJOVGAfD6Vj.VP5DfZI0siu1ncZo8tlLHJ 1Gl_qBvt.6ONppGGY.6YplucRzRlJvu9AeGCIORcb X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [172.20.53.194] (d.sturek@12.69.234.130 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 27 Jul 2011 09:33:52 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 27 Jul 2011 09:33:44 -0700 From: Don Sturek To: "Hemant Singh \(shemant\)" , IPv6 Operations Message-ID: Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3394604032_34503" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:34:00 -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_3394604032_34503 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Hemant, I think we need some type of default routing protocol. We need to enable deployment of devices into the home with the expectation that the various sub-nets can be reached in terms of site local multicast (service discovery, etc.) and I think that means we need to select a default routing protocol. Don From: "Hemant Singh (shemant)" Date: Wed, 27 Jul 2011 11:28:30 -0500 To: IPv6 Operations Subject: [v6ops] default LAN routing protocol for IPv6 CE router IPv6 CPE router vendors, please give feedback. Does anyone object if we specify the default routing protocol as OSPFv3 with only area zero for the IPv6 CE router bis document? Or would you prefer the document is silent on specification of any default? Thanks, Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --B_3394604032_34503 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Hemant,

I think we need some type of default routing protocol.  We need= to enable deployment of devices into the home with the expectation that the= various sub-nets can be reached in terms of site local multicast (service d= iscovery, etc.) and I think that means we need to select a default routing p= rotocol.

Don



From: "Hemant Singh (shemant= )" <shemant@cisco.com>
Date: Wed, 27 Jul 2011 11:28:30 -0500
<= span style=3D"font-weight:bold">To: IPv6 Operations <v6ops@ietf.org>
S= ubject: [v6ops] default LAN routing protocol for IPv6 CE router
<= /div>

IPv6 CPE router vendors,= please give feedback.  Does anyone object if we specify the default routing protocol as OSPFv3 with only area = zero for the IPv6 CE router bis document?   Or would you prefer the do= cument is silent on specification of any  default?

 

Thanks,

 

Hemant

 

_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/= mailman/listinfo/v6ops --B_3394604032_34503-- From Fred.L.Templin@boeing.com Wed Jul 27 10:15:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2EE21F8681 for ; Wed, 27 Jul 2011 10:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWentUhVS1l5 for ; Wed, 27 Jul 2011 10:15:35 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id C30CF21F8570 for ; Wed, 27 Jul 2011 10:15:35 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p6RHFUgJ019770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Jul 2011 10:15:33 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p6RHFTTk002063; Wed, 27 Jul 2011 10:15:29 -0700 (PDT) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p6RHFTd8002000 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 27 Jul 2011 10:15:29 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Wed, 27 Jul 2011 10:15:28 -0700 From: "Templin, Fred L" To: "John Mann (ITS)" , "v6ops@ietf.org" Date: Wed, 27 Jul 2011 10:15:27 -0700 Thread-Topic: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? Thread-Index: AcxBvQWtQWZ7hrh3T4215ads+OUiBwKwmhFw Message-ID: References: <31BCF9EC-7A49-4C5B-B62A-CAECF66F23F1@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:15:36 -0000 Hi John, Regarding your message from 7/14/2011: http://www.ietf.org/mail-archive/web/v6ops/current/msg09637.html I have posted a new draft version which which contains a number of updates based on our discussions. Please see below for the I-D announcement, and let me know if this satisfies the concerns. Thanks - Fred fred.l.templin@boeing.com -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Wednesday, July 27, 2011 9:40 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-v6ops-isops-13.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Operational Guidance for IPv6 Deployment in IPv4 Sites u= sing ISATAP Author(s) : Fred L. Templin Filename : draft-templin-v6ops-isops-13.txt Pages : 21 Date : 2011-07-27 Many end user sites in the Internet today still have predominantly IPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 continues to provide satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed in the Internet, however, end user devices within such sites will increasingly require at least basic IPv6 functionality for external access. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-templin-v6ops-isops-13.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt= From tjc@ecs.soton.ac.uk Wed Jul 27 10:25:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35E821F86CA; Wed, 27 Jul 2011 10:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[AWL=-1.107, BAYES_00=-2.599, MANGLED_COMPNY=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk0d1n4yArMM; Wed, 27 Jul 2011 10:25:18 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id B041721F854E; Wed, 27 Jul 2011 10:25:17 -0700 (PDT) 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 p6RHPF9s032351; Wed, 27 Jul 2011 18:25:15 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p6RHPF9s032351 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1311787516; bh=9ae6gc4yomJzXJMKKl9ywczf524=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=VtTbqVU3qMsXBjmLE7aDtiSc/fSE4Bbi85YiAvy1QRlY1NxOKIfw4PokMnyK8Q8Dn j/kgVags7l03TNdUNgwRAZA18DSPcT5UZI3yWj91HUopf/4Jeu7mXoJ/uSYeannNhs hOou5FFWMygvAt6keJeiUJ3gAzNmju+Z3KCcf0KI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n6QIPF0366145710mB ret-id none; Wed, 27 Jul 2011 18:25:16 +0100 Received: from [IPv6:2001:df8::112:dd15:b32:a2fa:af1f] ([IPv6:2001:df8:0:112:dd15:b32:a2fa:af1f]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p6RHP6X7025232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jul 2011 18:25:06 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Tim Chown In-Reply-To: <20110727160331.A07C31236670@drugs.dv.isc.org> Date: Wed, 27 Jul 2011 18:25:06 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> <20110727151517.CF9371235D70@drugs.dv.isc.org> <20110727160331.A07C31236670@drugs.dv.isc.org> To: IPv6 Operations , IETF Discussion X-Mailer: Apple Mail (2.1244.3) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n6QIPF036614571000; tid=n6QIPF0366145710mB; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p6RHPF9s032351 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:25:18 -0000 On 27 Jul 2011, at 17:03, Mark Andrews wrote: > 0D20EB6-78C9-415D-9493-3AA08FAACEEF@ecs.soton.ac.uk>, Tim Chown = writes: >>=20 >> a) use 6to4 anyway on an open platform like OpenWRT >=20 > Which may or may not still have the code. OpenWRT could remove > support just the same as another source could. OpenWRT is also not > widely supported by CPE vendors. i.e. you are own your own if > something goes wrong in most (not all) cases. In the event OpenWRT should remove 6to4 support, just get like-minded = people together (if there are lots of people that consciously want to = use 6to4 for application development and testing) and roll your own. >> b) use a tunnel broker - this works much better through NATs and with = dynamic >> IPv4 addresses >=20 > For which there is only experimental / ad-hoc code. Please name > CPE vendors that support tsp? Please name CPE vendors that support > tunnel re-configuration on re-number. Jeroen has answered this, but I would point out, as an example of what = can be done in short time, that I had a student last year who developed = a mini-ITX Linux build with tunnel broker support, and IPv6 firewall and = QoS support, using a web interface driving existing tools like iptables = and tc. He chose to use the HE broker, and it's a one-time registration = after which it just works without further user intervention with HE. It would be very interesting to see brokenness figures for well-known = broker prefixes as against 6to4, if anyone is gathering such data. >> c) use your $work VPN if it supports IPv6, which it could/should if = your comp >> any values IPv6 >> d) get IPv6 from your ISP, or move to one that has it if yours does = not >=20 > Which is not always a viable option. It is in the UK, at least. Tim= From lorenzo@google.com Wed Jul 27 10:26:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FF821F85C0 for ; Wed, 27 Jul 2011 10:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.751 X-Spam-Level: X-Spam-Status: No, score=-105.751 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QXqGMiRBuuc for ; Wed, 27 Jul 2011 10:26:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5F81021F85CE for ; Wed, 27 Jul 2011 10:25:59 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p6RHPw3v029524 for ; Wed, 27 Jul 2011 10:25:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311787558; bh=N90Pp9216wWm9/5A1v4QJA7BUqM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Ny9yUlv9jINx8CqDO40I1cSMqW6gcdVp6sYXLbISka6qIdF0ylGWWkapVG3rxfayG xWsYyQWfWVS6m84F+RVZQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=cdAWO28/vduBdw/Brp66JpGmiKRVi4SCmnbQUjIE8T0Vot+DsHT0/XaFum89oeK1o woVJj+xhGpBCad30F0v0g== Received: from gxk7 (gxk7.prod.google.com [10.202.11.7]) by wpaz21.hot.corp.google.com with ESMTP id p6RHNodd016909 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 27 Jul 2011 10:25:57 -0700 Received: by gxk7 with SMTP id 7so1769471gxk.21 for ; Wed, 27 Jul 2011 10:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8DYWlq9hYLJOaGrNOR8cXPTxcAOL+s1rJBmVsI+uLQc=; b=ccPFuV2o03BktzWAZn/zuYwkxUdDdGm1xjFCLFJp6bcZV+jxpRQQFOjbUL1Rp9A1CE +RykXeuAKlNhHsEdZZ0g== Received: by 10.150.160.21 with SMTP id i21mr79984ybe.57.1311787557407; Wed, 27 Jul 2011 10:25:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.156.5 with HTTP; Wed, 27 Jul 2011 10:25:37 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> From: Lorenzo Colitti Date: Wed, 27 Jul 2011 13:25:37 -0400 Message-ID: To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=000e0cdf1c56614dce04a910579c X-System-Of-Record: true Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:26:09 -0000 --000e0cdf1c56614dce04a910579c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 27, 2011 at 12:28, Hemant Singh (shemant) wrote: > IPv6 CPE router vendors, please give feedback. Does anyone object if we > specify the default routing protocol as OSPFv3 with only area zero for the > IPv6 CE router bis document? Or would you prefer the document is silent on > specification of any default? > Can such a default be extensible to exchange different types of information than just reachability? For example, can it propagate information such as "this is a guest network and this is an internal network" or "this is a prefix that I have tentatively assigned but do not own yet"? If not, then perhaps something more flexible like IS-IS would be better. --000e0cdf1c56614dce04a910579c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 27, 2011 at 12:28, Hemant Singh (she= mant) <shemant@ci= sco.com> wrote:

IPv6 CPE router vendors, please give feedback.=A0 Do= es anyone object if we specify the default routing protocol as OSPFv3 with only area = zero for the IPv6 CE router bis document?=A0=A0 Or would you prefer the document is silent on specification of any=A0 default?

<= div>
Can such a default be extensible to exchange different t= ypes of information than just reachability? For example, can it propagate i= nformation such as "this is a guest network and this is an internal ne= twork" or "this is a prefix that I have tentatively assigned but = do not own yet"? If not, then perhaps something more flexible like IS-= IS would be better.
--000e0cdf1c56614dce04a910579c-- From shtsuchi@cisco.com Wed Jul 27 10:37:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CDA21F8A4D for ; Wed, 27 Jul 2011 10:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f23vB6JvZXIj for ; Wed, 27 Jul 2011 10:37:28 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B093821F8A4B for ; Wed, 27 Jul 2011 10:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=683; q=dns/txt; s=iport; t=1311788248; x=1312997848; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JnappTgUUK+fjk+GKghDtM5OjcjK7y+swf3yL22b8Fk=; b=jJf7tUG0ZakBtILuLkrizywsZtNsifsoNiRGvv+LjJswrTKakaBMMcGb /2OxjMIqlDWiAmI2qJb5vTpSD3Bt7kjqzoZci77O7oKb0Gy5AJeEW1gd8 u964VIBDrJXuUh6D7YHB10B5IpySKqy/oy7Hc4HLxFa25YL27J+Ufq6W1 Q=; X-IronPort-AV: E=Sophos;i="4.67,277,1309737600"; d="scan'208";a="7074467" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 27 Jul 2011 17:37:28 +0000 Received: from [10.82.236.208] (rtp-vpn5-1228.cisco.com [10.82.236.208]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6RHbR2f028691; Wed, 27 Jul 2011 17:37:27 GMT Message-ID: <4E304CD7.3010209@cisco.com> Date: Wed, 27 Jul 2011 13:37:27 -0400 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: shemant@cisco.com References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:37:29 -0000 Hemant I would like to comment as member of IPv6 home gateway sub working group in Japan. I think OSPFv3 is not acceptable as default routing protocol on CPE router. We considered RIPng as optional requirement when we made IPv6 home router guideline which published in June 2009. http://www.v6pc.jp/pdf/v6hgw_Guideline_1_0-English.pdf Regards, -Shishio Hemant Singh (shemant) wrote: > IPv6 CPE router vendors, please give feedback. Does anyone object if we specify the default routing protocol as OSPFv3 with only area zero for the IPv6 CE router bis document? Or would you prefer the document is silent on specification of any default? > > Thanks, > > Hemant > From swmike@swm.pp.se Wed Jul 27 10:49:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6C021F8AE4 for ; Wed, 27 Jul 2011 10:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KMN-hmqAMT7 for ; Wed, 27 Jul 2011 10:49:13 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3755E21F8AE1 for ; Wed, 27 Jul 2011 10:49:13 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 33B579C; Wed, 27 Jul 2011 19:49:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2D4259A; Wed, 27 Jul 2011 19:49:11 +0200 (CEST) Date: Wed, 27 Jul 2011 19:49:11 +0200 (CEST) From: Mikael Abrahamsson To: Shishio Tsuchiya In-Reply-To: <4E304CD7.3010209@cisco.com> Message-ID: References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> <4E304CD7.3010209@cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:49:13 -0000 On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: > I think OSPFv3 is not acceptable as default routing protocol on CPE router. Care to elaborate on that? -- Mikael Abrahamsson email: swmike@swm.pp.se From shtsuchi@cisco.com Wed Jul 27 11:21:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F36C11E80E3 for ; Wed, 27 Jul 2011 11:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnEi3bFqJDCG for ; Wed, 27 Jul 2011 11:21:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 29C0111E8103 for ; Wed, 27 Jul 2011 11:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=575; q=dns/txt; s=iport; t=1311790876; x=1313000476; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7FoAYcp8qCxXqgN4hJI/KGdB/9BJH8P35EmhLCdDaTU=; b=Z57qnH+sXTqZsLEoU8BmU6H2Hhouio8tZXyC/Rh8+H7d52UzZxuNrJJ5 CGw7RsjCyPDMlieYNCt1MI0JxZJTyzgJaljE8t12e+CNRVrDPr0AmK80N qBUDc7rS+aYGQXlsQjt1vGhkv2VSGghDLbg3xBCcPo2DKn9eAD3PZmreK 0=; X-IronPort-AV: E=Sophos;i="4.67,277,1309737600"; d="scan'208";a="7094813" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jul 2011 18:21:15 +0000 Received: from [10.82.236.208] (rtp-vpn5-1228.cisco.com [10.82.236.208]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6RILFUY009009; Wed, 27 Jul 2011 18:21:15 GMT Message-ID: <4E30571A.9000104@cisco.com> Date: Wed, 27 Jul 2011 14:21:14 -0400 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: swmike@swm.pp.se References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> <4E304CD7.3010209@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:21:18 -0000 Mikael Mikael Abrahamsson wrote: > On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: > >> I think OSPFv3 is not acceptable as default routing protocol on CPE router. > > Care to elaborate on that? > Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol. The reasons are.. -OSPF consumes CPU/memory than RIP. -OSPF operetaion is needed more knowledge compare with RIP. The character of these protocol does not change on IPv6 environment,too. So we thought RIPng would be acceptable routing protocol for IPv6 CPE router,also. Regards, -Shishio From moore@network-heretics.com Wed Jul 27 11:21:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54ED411E8098; Wed, 27 Jul 2011 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEs-K45GiKHC; Wed, 27 Jul 2011 11:21:55 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id 07E3711E8084; Wed, 27 Jul 2011 11:21:55 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id AFE052014A; Wed, 27 Jul 2011 14:21:54 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 27 Jul 2011 14:21:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=FdTyeunTpaEp9WHc/3MTV5Q+fSM=; b=HF p+OzH9QF45AytZtg2fUasoLQZzYceEvLKgiFYNrlxxPDVqKgtirZnpuU2POMIc3O ovrfDNiW98CMOHq6H1DDoii7JL3yd2nib/l+cswYtXoEE7OpxxKGWw2u2RWdQPO/ 6J1TclfFmKNJ3qRg+Mlanuq6OwiFFn4sJsc7/okdA= X-Sasl-enc: DReTjSDezDBlsELwTh9P78HUWSXvh3WKUPoP7/ibnDia 1311790914 Received: from dhcp-12d1.meeting.ietf.org (dhcp-12d1.meeting.ietf.org [130.129.18.209]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6EEB841443D; Wed, 27 Jul 2011 14:21:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 27 Jul 2011 14:21:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <999C3229-649D-4242-BB0F-2BB494EDF1D9@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> <20110727151517.CF9371235D70@drugs.dv.isc.org> To: Tim Chown X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , Keith Moore , IETF Discussion Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:21:56 -0000 On Jul 27, 2011, at 11:35 AM, Tim Chown wrote: > I suspect, but have no proof, that the huge majority of 6to4 users = don't use it intentionally, and the content they are trying to reach is = also available over IPv4. But for people who want to develop and use new = IPv6-specific apps, then either a broker or something like OpenWRT ought = to meet their needs? tunnel brokers suck if the tunnel endpoint isn't near your current = network location. there are currently no universally applicable, or even widely = applicable, v6-over-v4 solutions. Keith From moore@network-heretics.com Wed Jul 27 11:25:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AF011E8118; Wed, 27 Jul 2011 11:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.539 X-Spam-Level: X-Spam-Status: No, score=-4.539 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EptQYWq6bV8; Wed, 27 Jul 2011 11:25:22 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id E26C711E8101; Wed, 27 Jul 2011 11:25:21 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 90C1A20FFA; Wed, 27 Jul 2011 14:25:21 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 27 Jul 2011 14:25:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=5BwXqaSaa4uQt1F7EJahX6cP8X8=; b=MG 5hEk/aj50DIc5/gAc5S+lI6Lwy0Ldvs+Tb8MCjfg5R3ni86LosvelrOmWbJDrzuI riLvsFWhlNPsZPTM/ZFTgoz6hdmQlZJdgVF5dq8HOrygefxvwyCxYsjvn5RUSEJK kMJKpzStmnXJv48GjSGqIaRTOt/e7f3NrQQQ9U8i8= X-Sasl-enc: oqafjX1/v3BikDW+EfMMfRqrRM7dGTrgSRTGEuHECygz 1311791121 Received: from dhcp-12d1.meeting.ietf.org (dhcp-12d1.meeting.ietf.org [130.129.18.209]) by mail.messagingengine.com (Postfix) with ESMTPSA id 3A51A4145D1; Wed, 27 Jul 2011 14:25:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 27 Jul 2011 14:25:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <52599079-C6E9-48F9-AFAE-78E7989FB105@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , Keith Moore , ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:25:22 -0000 On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote: > In your letter dated Wed, 27 Jul 2011 12:38:33 +1000 you wrote: >> In message <4E2F4491.30102@gmail.com>, Brian E Carpenter writes: >>> Of course, if implementors choose to drop the code you might not be >>> able to upgrade software versions - but hopefully by that time you >>> will have native IPv6 service anyway. >>=20 >> Which is exactly why HISTORIC is NOT appropriate.=20 >=20 > With rfc3484-revise and the documented brokenness of 6to4, it doesn't = make > any sense for implementors to offer 6to4 anyhow. False. It makes even more sense to offer 6to4 because it significantly = decreases the chance that it will cause a bad experience for users of = services that provide both v4 and v6 addresses, while increasing the = chance letting local hosts/users talk to v6-only services/hosts. > So I think it would be > quite weird to keep 6to4 at standards track just to prevent some = vendors from > dropping 6to4 support.=20 Vendors can drop 6to4 support, or for that matter any other feature, = anytime they wish. They don't need permission from IETF to do that. Keith From tnadeau@lucidvision.com Wed Jul 27 10:07:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3314421F8C0A; Wed, 27 Jul 2011 10:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DapZ4EfOBSG6; Wed, 27 Jul 2011 10:07:46 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9007121F8C02; Wed, 27 Jul 2011 10:07:46 -0700 (PDT) Received: from [130.129.19.44] (dhcp-132c.meeting.ietf.org [130.129.19.44]) by lucidvision.com (Postfix) with ESMTP id 207BB1D2C37C; Wed, 27 Jul 2011 13:07:46 -0400 (EDT) References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> <39EEA819-6D8D-4FE7-958D-D7DCEDF893C1@townsley.net> In-Reply-To: <39EEA819-6D8D-4FE7-958D-D7DCEDF893C1@townsley.net> Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <315867B5-EE5F-4440-999D-5E4253A68C2D@lucidvision.com> X-Mailer: iPad Mail (8J2) From: Thomas Nadeau Date: Wed, 27 Jul 2011 13:08:09 -0400 To: Mark Townsley X-Mailman-Approved-At: Wed, 27 Jul 2011 11:27:40 -0700 Cc: IPv6 Operations , "ietf@ietf.org" Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:07:47 -0000 On Jul 27, 2011, at 7:31 AM, Mark Townsley wrote: >=20 > On Jul 27, 2011, at 7:09 AM, Fred Baker wrote: >=20 >>=20 >> On Jul 26, 2011, at 6:49 PM, Brian E Carpenter wrote: >>=20 >>> Since 6to4 is a transition mechanism it has no long term future *by defi= nition*. Even if someone chooses to design a v2, who is going to implement i= t? >>=20 >> Actually, I think one could argue pretty effectively that 6rd is 6to4-bis= .=20 >=20 > +1 >=20 > - Mark +2 >=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From moore@network-heretics.com Wed Jul 27 11:28:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095E721F8A71; Wed, 27 Jul 2011 11:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.715 X-Spam-Level: X-Spam-Status: No, score=-3.715 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Os5Pl9CPcE8; Wed, 27 Jul 2011 11:28:49 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id B379D21F8A70; Wed, 27 Jul 2011 11:28:48 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 654D520D6D; Wed, 27 Jul 2011 14:28:48 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 27 Jul 2011 14:28:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=t3Di7Ii+yuAtmWoN56+lE8FEUcg=; b=Jr f+tACyEBX1M/34Xcmf9swy7NNdHCqneGrnTUypnV8/6NvZLEFZpH1rNpq2uNOflY lJatwy62BZqxXKPjfYSA0GhMahynHIZ+xZ8aG32p9mTqaB4EgTHjpnUSYLHA6dnV tZXRmRQIxEKKxCkkkufvsLA5jcKDBYSFwrssMDQYI= X-Sasl-enc: uEdfOQ1+uGMBSghRXB9jEUl73kvctsz3rAkxRAEcae76 1311791328 Received: from dhcp-12d1.meeting.ietf.org (dhcp-12d1.meeting.ietf.org [130.129.18.209]) by mail.messagingengine.com (Postfix) with ESMTPSA id 272E240542E; Wed, 27 Jul 2011 14:28:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Wed, 27 Jul 2011 14:28:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5E7CB355-4223-42CC-A621-B1BFD464B57C@network-heretics.com> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> <39EEA819-6D8D-4FE7-958D-D7DCEDF893C1@townsley.net> <20110727150832.69F5B1235C62@drugs.dv.isc.org> To: Erik Kline X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , Keith Moore , ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:28:50 -0000 On Jul 27, 2011, at 11:12 AM, Erik Kline wrote: > Moving 6to4 to historic does not in any way impact your ability to use > it as you wish. False. Moving 6to4 to Historic is inviting people to mount denial of = service attacks on things that actually work for people today. Moving = 6to4 to Historic will also invite vendors to remove 6to4 support from = future versions or updates of their products, forcing users to make = difficult choices between using 6to4 on one hand and changing equipment = or vendors on another. There's no reason to cause that kind of collateral damage. Denial of = service attacks are completely inappropriate. > 6to4 support is not part of the IPv6 node requirements, as I > understand it. Therefore I believe that any vendor (OS, router, > otherwise) could deleted 6to4 support in any release and be in > violation of anything, regardless of historic status. Nothing that IETF specifies requires 6to4. Vendors can indeed delete = it if they want to. But IETF should not recommend that they do so, or = imply that they should do so. Keith From ichiroumakino@gmail.com Wed Jul 27 11:32:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1D711E8103 for ; Wed, 27 Jul 2011 11:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyllSYWhCNa4 for ; Wed, 27 Jul 2011 11:32:51 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id B428511E8084 for ; Wed, 27 Jul 2011 11:32:50 -0700 (PDT) Received: by yie30 with SMTP id 30so1539219yie.31 for ; Wed, 27 Jul 2011 11:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=TRz/2/btDr/xoIFMIjHrHeEIS34UO4Zh0NJQ2psVFi8=; b=SBfh3jgN58eZgeVuhTEOHLl6+KNcLBoND4nzAjjo4N+BqIdoTLGWk0RN4y1smA4F9k gURq1FYa3REl97ML++meYtKcopBEDs5X6ctT0QVMXWJYggX1QNz9KtyrknPd33TbJK+g unjIVXekh6Gte1Nd6q0lo1tLYpKVLHWkSR4xI= Received: by 10.143.63.16 with SMTP id q16mr52957wfk.383.1311791569881; Wed, 27 Jul 2011 11:32:49 -0700 (PDT) Received: from ?IPv6:2001:df8::80:226:bbff:fe1a:772e? ([2001:df8:0:80:226:bbff:fe1a:772e]) by mx.google.com with ESMTPS id d1sm129060pbj.24.2011.07.27.11.32.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 11:32:48 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> Date: Wed, 27 Jul 2011 13:41:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:32:52 -0000 > IPv6 CPE router vendors, please give feedback. Does anyone object if = we specify the default routing protocol as OSPFv3 with only area zero = for the IPv6 CE router bis document? Or would you prefer the document = is silent on specification of any default? I think this choice should be left for homenet. e.g. there are proposals = for prefix assignment tightly coupled with a routing protocol. cheers, Ole From pthubert@cisco.com Wed Jul 27 11:40:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E236221F8B6B for ; Wed, 27 Jul 2011 11:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.974 X-Spam-Level: X-Spam-Status: No, score=-10.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPFR-HxIua4q for ; Wed, 27 Jul 2011 11:40:20 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2A521F8B73 for ; Wed, 27 Jul 2011 11:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=735; q=dns/txt; s=iport; t=1311792020; x=1313001620; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=YRK5xgZil65ZstPqmyZsTNUIP7pchBNzRshJlcseQUE=; b=TD2Qk3SDuSdBIQ7iubzJxoSrtT3DGVYMXzvmaSR+0JaMMwHbO8FV6yhZ rQjI4qlsN11YD2bAWj5fkc0FS43TEXWen0xr7bUEt7zMAOLpzik1+IhBt 99gByJUHvTofMuZxc54ZlH3GxbaH17TLqOq+pzKtev4fxx91vLzYxjIwf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAFhbME6Q/khR/2dsb2JhbAA1AQEBAQMUASEKRQwFAgEJDgMEAQELBiMBBgETOw4IAQEFARYMG5dbj0h3rD+ebIVhXwSYBYtU X-IronPort-AV: E=Sophos;i="4.67,277,1309737600"; d="scan'208";a="105041854" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 27 Jul 2011 18:40:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6RIeJ6W020683; Wed, 27 Jul 2011 18:40:19 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 20:40:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2011 20:40:05 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D052DEDA2@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxMi55cZ7pG85skTAKxIm/vz2YS3QAAPF8w References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> From: "Pascal Thubert (pthubert)" To: "Ole Troan" , "Hemant Singh (shemant)" X-OriginalArrivalTime: 27 Jul 2011 18:40:19.0327 (UTC) FILETIME=[A28E50F0:01CC4C8C] Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:40:21 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Ole Troan > Sent: Wednesday, July 27, 2011 7:41 PM > To: Hemant Singh (shemant) > Cc: IPv6 Operations > Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >=20 > > IPv6 CPE router vendors, please give feedback. Does anyone object if we > specify the default routing protocol as OSPFv3 with only area zero for the > IPv6 CE router bis document? Or would you prefer the document is silent on > specification of any default? >=20 > I think this choice should be left for homenet. e.g. there are proposals for > prefix assignment tightly coupled with a routing protocol. >=20 +1 Pascal From fred@cisco.com Wed Jul 27 11:41:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134F921F8BA6 for ; Wed, 27 Jul 2011 11:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.796 X-Spam-Level: X-Spam-Status: No, score=-102.796 tagged_above=-999 required=5 tests=[AWL=-0.797, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+cEmJe9Ageh for ; Wed, 27 Jul 2011 11:41:21 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4B221F8B73 for ; Wed, 27 Jul 2011 11:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1661; q=dns/txt; s=iport; t=1311792081; x=1313001681; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=G2IFdi4uTWHIXSZjc/r7MDHHu4m5AnnMZFf5UU7SueU=; b=eieoiI5K+lHDFdIOhSrsiQCCyTuvFikhX4HTx8hdbhXwaVu5Ih5BiPpJ hItnbKV3XIeIcX7cdwZt6xb6eEWX3hyw5JRARDV8BZV/eYurUwTORBTgS pPi4sA2puwkaqoJd+bme1T8HntBDhm7KotWDlAfV6MdXNqGRmuaQEvnWO M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOdaME6rRDoI/2dsb2JhbAA1AQEBAQIBFAErOhAMHQMBAjsURwIIBxcnpyN3iHyjQZ5rhWFfBJJ1hQeLdw X-IronPort-AV: E=Sophos;i="4.67,277,1309737600"; d="scan'208";a="7097344" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-5.cisco.com with ESMTP; 27 Jul 2011 18:41:21 +0000 Received: from dhcp-57cd.meeting.ietf.org (sjc-vpn2-97.cisco.com [10.21.112.97]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6RIfKSX000716 for ; Wed, 27 Jul 2011 18:41:20 GMT Received: from [127.0.0.1] by dhcp-57cd.meeting.ietf.org (PGP Universal service); Wed, 27 Jul 2011 14:41:20 -0400 X-PGP-Universal: processed; by dhcp-57cd.meeting.ietf.org on Wed, 27 Jul 2011 14:41:20 -0400 From: Fred Baker Date: Wed, 27 Jul 2011 14:40:59 -0400 References: <4E2ED0F0.1070301@cernet.edu.cn> To: IPv6 Operations Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:41:22 -0000 Folks: the chairs are in receipt of this note. Please read the draft and = comment. In short, the draft requests an IPv4 prefix to be used in ICMPv4 to = refer to IPv6 routers on the far side of a translator. In the reverse = case, ICMPv6 would translate the address to an IPv4-embedded address as = defined in RFC 6145 (an IPv6 address containing and statelessly = translatable to an IPv4 address). If we buy off on it - and that's a = discussion we should have on this list - Ron can walk it through the = IESG and get the assignment. Begin forwarded message: > From: Xing Li > Date: July 26, 2011 10:36:32 AM EDT > To: v6ops-chairs@tools.ietf.org > Cc: v6ops@ietf.org, draft-xli-v6ops-ivi-icmp-address@tools.ietf.org > Subject: Request for WG Adoption of = draft-xli-v6ops-ivi-icmp-address-00 >=20 > Hi V6ops Chairs, >=20 > The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to = request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt = as a WG adoption. >=20 > The draft describes the operational considerations of mapping ICMPv6 = packets through an RFC6145 gateway where the IPv6 address is not = directly translatable into an IPv4 address, and requests an IANA Special = Purpose IPv4 address allocation to allow this address mapping to take = place using a protocol-specific designated address block in IPv4. >=20 > The authors are hopeful that this will not require any valuable = face-to-face WG time at IETF 81 and the WG's consideration of this = document can be undertaken entirely on the mailing list. >=20 > regards, >=20 > Xing Li >=20 >=20 >=20 >=20 From roberta.maglione@telecomitalia.it Wed Jul 27 11:41:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1079921F8BD7 for ; Wed, 27 Jul 2011 11:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.917 X-Spam-Level: X-Spam-Status: No, score=0.917 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxQF14266Ytw for ; Wed, 27 Jul 2011 11:41:25 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4372221F8BD4 for ; Wed, 27 Jul 2011 11:41:25 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Jul 2011 20:41:22 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Wed, 27 Jul 2011 20:41:22 +0200 From: Maglione Roberta To: 'Shishio Tsuchiya' , "swmike@swm.pp.se" Date: Wed, 27 Jul 2011 20:41:22 +0200 Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxMihzex8/Gpry+QFarJPk6d5exEgAAmeAQ Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D60@GRFMBX704BA020.griffon.local> References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> <4E304CD7.3010209@cisco.com> <4E30571A.9000104@cisco.com> In-Reply-To: <4E30571A.9000104@cisco.com> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:41:26 -0000 for scalability problems ISPs don't usually exchange routes with CPE router= s/residential customers. Regards, Roberta -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of S= hishio Tsuchiya Sent: mercoled=EC 27 luglio 2011 20.21 To: swmike@swm.pp.se Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router Mikael Mikael Abrahamsson wrote: > On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: > >> I think OSPFv3 is not acceptable as default routing protocol on CPE rout= er. > > Care to elaborate on that? > Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol. The reasons are.. -OSPF consumes CPU/memory than RIP. -OSPF operetaion is needed more knowledge compare with RIP. The character of these protocol does not change on IPv6 environment,too. So we thought RIPng would be acceptable routing protocol for IPv6 CPE route= r,also. Regards, -Shishio _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From jeroen@unfix.org Wed Jul 27 11:51:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0379621F8B8B; Wed, 27 Jul 2011 11:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPst8-rKpwiz; Wed, 27 Jul 2011 11:51:46 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 70C2D21F8B84; Wed, 27 Jul 2011 11:51:45 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:41e0:ff42:99:ca2a:14ff:fe1f:2b7b]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 7EEF0801C2BF; Wed, 27 Jul 2011 20:51:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1311792702; bh=dY6UU4jsNi/bnlZac8EgJN2pD26m5K/elv77P/UQp7I=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=TKlzw1Em/gUT7GNolV4YOtWd/1+P4mYmG2TB7zopbHxyGYRnVvPx6ASQILO7Cepx+ J620jU7do548fNrthpvuXVZrW2xpc8Ycw/d5ZUhZkqbYOw6C/Ah3Jb4sF1k/DkLPHu VhujM70KJdbA6w6Fn9J9eyjMbCr7Ybidl/1MH9E5afjxFZPA/FkZ79QDNQDutBojsa beT1PUoFo8/qAxkr01xsiUphYLbFe083OCeA5IS1A2ykd3erjZ/oPxD+j9dA2Y0Iv3 wIiJ9PGAAn7iLfOSVpo7lCBPfGSpcAP7nn6m0rS5nOIY1JERJ+Cy5WYIPAYbMUhUpB oTEYUHuJjm4AQ== Message-ID: <4E305E3E.2040607@unfix.org> Date: Wed, 27 Jul 2011 20:51:42 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Keith Moore References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> <20110727151517.CF9371235D70@drugs.dv.isc.org> <999C3229-649D-4242-BB0F-2BB494EDF1D9@network-heretics.com> In-Reply-To: <999C3229-649D-4242-BB0F-2BB494EDF1D9@network-heretics.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , IETF Discussion Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:51:47 -0000 On 2011-07-27 20:21 , Keith Moore wrote: > On Jul 27, 2011, at 11:35 AM, Tim Chown wrote: > >> I suspect, but have no proof, that the huge majority of 6to4 users don't use it intentionally, and the content they are trying to reach is also available over IPv4. But for people who want to develop and use new IPv6-specific apps, then either a broker or something like OpenWRT ought to meet their needs? > > tunnel brokers suck if the tunnel endpoint isn't near your current network location. Let me rewrite that sentence for you: "transition mechanisms suck if the tunnel endpoint isn't near your current network location" It does not matter much if that mechanism is static proto-41 (6in4), 6to4, AYIYA, TSP, PPTP, HTTP Proxies or whatever, there is going to be a bit more latency if they are not directly next to you. Not much you can do about except deploy more of them or And this will always be the case unless you deploy enough of them in all places possible. For SixXS we are at 48 boxes around the world, Hurricane has 25 and Gogo6 has 4 of them of their own for Freenet6 and then there are 4 others at other organizations and there are a couple of other services out there which provide tunnels see: http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers > there are currently no universally applicable, or even widely applicable, v6-over-v4 solutions. For your set of requirements maybe but especially Tunnel Brokers are working very well for a lot of people and if one sees the traffic stats on Teredo and 6to4 nodes due to this little thing called NNTP I would state that those are doing quite fine too for giving access to what people need to get to. Your major requirement seems to involve latency though, thus as such, there is only one thing to do, get one of those boxes deployed locally to your endpoint. Do note to yourself that the next issue you will run into that the service you are actually contacting will be far away, and you suddenly understand that you need that Akamai content box and a Google one and various other closeby too ;) If you want to solve your problem though, I guess for HE you'll have to give them connectivity to their network and space in a rack for a box, gogo6 will sell you a box and for SixXS you provide the box+connectivity and we'll set up the software for free for you and handle the tunneling completely. Greets, Jeroen From joelja@bogus.com Wed Jul 27 11:53:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A7911E8157 for ; Wed, 27 Jul 2011 11:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.779 X-Spam-Level: X-Spam-Status: No, score=-101.779 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT1SLizAW-dN for ; Wed, 27 Jul 2011 11:53:59 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id DB37511E8155 for ; Wed, 27 Jul 2011 11:53:58 -0700 (PDT) Received: from dhcp-5710.meeting.ietf.org (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6RIrtMk040725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 Jul 2011 18:53:56 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Joel Jaeggli In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D60@GRFMBX704BA020.griffon.local> Date: Wed, 27 Jul 2011 14:53:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> <4E304CD7.3010209@cisco.com> <4E30571A.9000104@cisco.com> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D60@GRFMBX704BA020.griffon.local> To: Maglione Roberta X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 27 Jul 2011 18:53:57 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:53:59 -0000 On Jul 27, 2011, at 2:41 PM, Maglione Roberta wrote: > for scalability problems ISPs don't usually exchange routes with CPE = routers/residential customers. Nor would they in this case. In fact from a isp perspective you want the = igp used in the home to be identifiable and easy to filter such that = inadvertant leakage is effectively impossible. Although best practices = for PE ports generally would be sufficient to preclude that, you also = want to do one better. joel > Regards, > Roberta >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Shishio Tsuchiya > Sent: mercoled=EC 27 luglio 2011 20.21 > To: swmike@swm.pp.se > Cc: v6ops@ietf.org > Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >=20 > Mikael > Mikael Abrahamsson wrote: >> On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: >>=20 >>> I think OSPFv3 is not acceptable as default routing protocol on CPE = router. >>=20 >> Care to elaborate on that? >>=20 >=20 > Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol. > The reasons are.. > -OSPF consumes CPU/memory than RIP. > -OSPF operetaion is needed more knowledge compare with RIP. > The character of these protocol does not change on IPv6 = environment,too. > So we thought RIPng would be acceptable routing protocol for IPv6 CPE = router,also. >=20 > Regards, > -Shishio > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From shtsuchi@cisco.com Wed Jul 27 11:57:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8A811E8152 for ; Wed, 27 Jul 2011 11:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwwPxRzjdq5T for ; Wed, 27 Jul 2011 11:57:28 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BA36411E814B for ; Wed, 27 Jul 2011 11:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=2051; q=dns/txt; s=iport; t=1311793048; x=1313002648; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xugpewaa2nldm5yjs8ObTrdfgK/DyH6L95JDDgkzHxc=; b=LvbzJZur9FsNHsfNhMx+0ueRdQ5C377/M6QO9D+Ff97JPTmGY1U9fdgk w5hD4K7GulZkXNNVhzOYaVrQwJX/EPQAEOFsLGduasjEqBkmGkh1OdPSE loYC+VBZtysOSlh+41v8/V01JKDHTa1J5iaA6Vs7yHpro27gUTjoIWDpb g=; X-IronPort-AV: E=Sophos;i="4.67,278,1309737600"; d="scan'208";a="7103237" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 27 Jul 2011 18:57:28 +0000 Received: from [10.82.236.208] (rtp-vpn5-1228.cisco.com [10.82.236.208]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6RIvRFH028994; Wed, 27 Jul 2011 18:57:27 GMT Message-ID: <4E305F97.100@cisco.com> Date: Wed, 27 Jul 2011 14:57:27 -0400 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: roberta.maglione@telecomitalia.it References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com><4E304CD7.3010209@cisco.com> <4E30571A.9000104@cisco.com> <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D60@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D60@GRFMBX704BA020.griffon.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 18:57:29 -0000 Roberta Yes,I agree. This routing protocol purpose would be exchange of internal home network. Regards, -Shishio Maglione Roberta wrote: > for scalability problems ISPs don't usually exchange routes with CPE routers/residential customers. > > Regards, > Roberta > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Shishio Tsuchiya > Sent: mercoledì 27 luglio 2011 20.21 > To: swmike@swm.pp.se > Cc: v6ops@ietf.org > Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router > > Mikael > Mikael Abrahamsson wrote: > > On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: > > > >> I think OSPFv3 is not acceptable as default routing protocol on CPE router. > > > > Care to elaborate on that? > > > > Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol. > The reasons are.. > -OSPF consumes CPU/memory than RIP. > -OSPF operetaion is needed more knowledge compare with RIP. > The character of these protocol does not change on IPv6 environment,too. > So we thought RIPng would be acceptable routing protocol for IPv6 CPE router,also. > > Regards, > -Shishio > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > From nmilovanov@nbu.bg Wed Jul 27 12:00:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE60E11E8113 for ; Wed, 27 Jul 2011 12:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd5T0DK8kAun for ; Wed, 27 Jul 2011 12:00:33 -0700 (PDT) Received: from mail.nbu.bg (mail.nbu.bg [193.19.172.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3798311E8118 for ; Wed, 27 Jul 2011 12:00:32 -0700 (PDT) Received: by mail.nbu.bg (Postfix, from userid 5001) id DC76529CC0CC; Wed, 27 Jul 2011 22:00:29 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.6.0 mail.nbu.bg DC76529CC0CC DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nbu.bg; s=mail; t=1311793229; bh=63wpWSVDe0HV0ra06ueygs2rTfvpdBPT+nIbvDhFXqQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Is/502oOI7v/MvBe9Ngr8ClDMKmyk9XeJLSgmeYu6zbC gOkjEJm9bWYyHjmo959ZKpMLN8ljkwmiZoY4tnVVi4pdO3uyicy3Ag7IFziJZJDrPXf yVOP/wNIhZUw1f2RgnVgIZPy96Lby8ge/j18ZqN3ROTuhvYZO441N0fpUb8c= Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (not verified)) by mail.nbu.bg (Postfix) with ESMTP id B855229CC0CB for ; Wed, 27 Jul 2011 22:00:25 +0300 (EEST) X-DKIM: Sendmail DKIM Filter v2.6.0 mail.nbu.bg B855229CC0CB DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nbu.bg; s=mail; t=1311793226; bh=63wpWSVDe0HV0ra06ueygs2rTfvpdBPT+nIbvDhFXqQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=MPvvHz8IA+PV9o11yEOVK7J5jFiH5PA5Cv6uSK8R8/GK +gJ/Ub7XL0S4zRiDh976R+YPxQyhHBsErpKGJr0xEhngzNjIro9mOOL1fBZKRLQ0vH0 42CmrSZtD0rx5qcOzF9sgN4vwoSsxfqU0KftktJkNJBaqtc1Q1erYN9OfTMg= Received: by qyk9 with SMTP id 9so2645587qyk.10 for ; Wed, 27 Jul 2011 12:00:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.216.66 with SMTP id hh2mr143121qab.174.1311793225303; Wed, 27 Jul 2011 12:00:25 -0700 (PDT) Received: by 10.224.67.72 with HTTP; Wed, 27 Jul 2011 12:00:25 -0700 (PDT) In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0BBE71FD@PRVPEXVS04.corp.twcable.com> References: <067E6CE33034954AAC05C9EC85E2577C0575FDC5@XMB-RCD-111.cisco.com> <34E4F50CAFA10349A41E0756550084FB0BBE71FD@PRVPEXVS04.corp.twcable.com> Date: Wed, 27 Jul 2011 22:00:25 +0300 Message-ID: From: Nikolay Milovanov To: IPv6 Operations Content-Type: multipart/alternative; boundary=20cf3005152436880004a911a91c X-Virus-Scanned: clamav-milter 0.95.3 at mail.nbu.bg X-Virus-Status: Clean Subject: Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:00:35 -0000 --20cf3005152436880004a911a91c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Very interesting draft indeed. I like that sentence: Many supporting systems are also under development and have newly developed IPv6 functionality including vendor implementations of DHCPv6, Management Tools, Monitoring Systems, Diagnostic systems, along with other systems. As per my perspective more or less OSS/BSS part of operator's infrastructur= e is not at all ready for handling IPv6 network transition or Service transitions/activation. Will be happy to hear more from the author about that part of the transition. BR, Nikolay Milovanov Network Engineer NBU On Fri, Jul 22, 2011 at 9:09 PM, George, Wesley wrote: > > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Victor Kuarsingh > Sent: Friday, July 22, 2011 12:51 AM > To: Rajiv Asati (rajiva); Brian E Carpenter; IPv6 Operations > Subject: Re: [v6ops] I-D Action: > draft-kuarsingh-wireline-incremental-ipv6-00.txt > > > One additional option that was noted to me offline was NAT64. I think > > NAT64 poses challenges in the near to mid term future (in Wireline > > Networks) since there is way too much IPv4-only equipment in customer > prem > > today. I am hesitant to promote options which are based on eliminating > > variables I don't control - consumer controlled and operated equipment. > > Therefore assumed Dual Stack home for the foreseeable future (the reali= st > > in me). On the NAT64 note, I do think it is usable in some environment= s > > (like some Wireless services), but I stuck with common Wireline > > environments for now. > > Victor - this is a useful consideration around NAT64. You should add some > comments to this effect in your draft. I understand the rationale, but it= 's > better to include it and explain like you did here than to simply omit it= . > > Also, I think that there is an opportunity for a little shameless plug in > section 3.3, especially the 3rd paragraph - IETF needs feedback from > operators as they discover new issues and problems during their > implementation phase :-) > > You also may want to discuss the option of moving some things in the > operator's infrastructure which can support it to IPv6-only fairly early = in > the process in order to free up IPv4 resources for use in support of lega= cy > applications and devices which cannot. You mention it in the context of > DS-Lite in 5.5, but I think it's more generally applicable. For that matt= er, > there is probably room for some discussion about phasing with regards to > infrastructure (such as management of devices, back office, etc) vs custo= mer > facing services and when those all get enabled for IPv6, since "all at > once" is rarely practical. > > 5.1.2 may want to discuss considerations about OSPFv3 vs ISIS as an IGP (= or > reference an existing document that does, if exist) > > 5.2 may also want to include discussion of 6PE as a means to bridge gaps > where IPv6 cannot be supported in the network infrastructure. > > Nits: > 4.3 : %s/defiantly/definitely > 5.1.1: %s/vial/vital > 5.2: %s/Na=EFve/Native > > Wes George > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely = for > the use of the individual or entity to which it is addressed. If you are = not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may= be > unlawful. If you have received this E-mail in error, please notify the > sender immediately and permanently delete the original and any copy of th= is > E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 BR, Nikolay Milovanov Network Engineer CCIE SP# 20094 Mob: +359898763322 Email: nmilovanov@nbu.bg --20cf3005152436880004a911a91c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Very interesting draft indeed.
I like that sentence:
=A0= =A0 Many supporting systems are also under development and have newly
= =A0=A0 developed IPv6 functionality including vendor implementations of
= =A0=A0 DHCPv6, Management Tools, Monitoring Systems, Diagnostic systems, =A0=A0 along with other systems.

As per my perspective more or less = OSS/BSS part of operator's infrastructure is not at all ready for handl= ing IPv6 network transition or Service transitions/activation. Will be happ= y to hear more from the author about that part of the transition.

BR,
Nikolay Milovanov
Network Engineer
NBU

On Fri, Jul 22, 2011 at 9:09 PM, George, Wesley <wesley.george@twc= able.com> wrote:


-----Original Message-----
From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of Victor Kuarsingh
Sent: Friday, July 22, 2011 12:51 AM
To: Rajiv Asati (rajiva); Brian E Carpenter; IPv6 Operations
Subject: Re: [v6ops] I-D Action: draft-kuarsingh-wireline-incremental-ipv6-= 00.txt

> One additional option that was noted to me off= line was NAT64. =A0I think
> NAT64 poses challenges in the near to mid term future (in Wireline
> Networks) since there is way too much IPv4-only equipment in customer = prem
> today. I am hesitant to promote options which are based on eliminating=
> variables I don't control - consumer controlled and operated equip= ment.
> Therefore assumed Dual Stack home for the foreseeable future (the real= ist
> in me). =A0On the NAT64 note, I do think it is usable in some environm= ents
> (like some Wireless services), but I stuck with common Wireline
> environments for now.

Victor - this is a useful consideration around NAT64. You should add = some comments to this effect in your draft. I understand the rationale, but= it's better to include it and explain like you did here than to simply= omit it.

Also, I think that there is an opportunity for a little shameless plug in s= ection 3.3, especially the 3rd paragraph - IETF needs feedback from operato= rs as they discover new issues and problems during their implementation pha= se :-)

You also may want to discuss the option of moving some things in the operat= or's infrastructure which can support it to IPv6-only fairly early in t= he process in order to free up IPv4 resources for use in support of legacy = applications and devices which cannot. You mention it in the context of DS-= Lite in 5.5, but I think it's more generally applicable. For that matte= r, there is probably room for some discussion about phasing with regards to= infrastructure (such as management of devices, back office, etc) vs custom= er facing =A0services and when those all get enabled for IPv6, since "= all at once" is rarely practical.

5.1.2 may want to discuss considerations about OSPFv3 vs ISIS as an IGP (or= reference an existing document that does, if exist)

5.2 may also want to include discussion of 6PE as a means to bridge gaps wh= ere IPv6 cannot be supported in the network infrastructure.

Nits:
4.3 : %s/defiantly/definitely
5.1.1: %s/vial/vital
5.2: %s/Na=EFve/Native

Wes George

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



--
BR,
Nikolay Milovanov
Network Engineer
CCIE SP# 20094
Mob: +3598987= 63322
Email: nmil= ovanov@nbu.bg

--20cf3005152436880004a911a91c-- From rogerj@gmail.com Wed Jul 27 12:25:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1815121F8BCF; Wed, 27 Jul 2011 12:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwC6qm-OyKxx; Wed, 27 Jul 2011 12:25:03 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53B4121F8BD2; Wed, 27 Jul 2011 12:25:03 -0700 (PDT) Received: by wwe5 with SMTP id 5so1181784wwe.13 for ; Wed, 27 Jul 2011 12:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=P/7bDl04pRoBQeRZp7YD6rrbbGVQUAOB7E989VcigI8=; b=EcgA0Rv/+n8fBnmVnrhCfNWHA9BdvEnaCA/7vA5AKdFRUo2MAecXc/1buuXqgoWk9s 3tQAshT5qBb3YiVj2wb4vt5YmO30tZ9RyPOBFUuf4QeLg7k0VE79OazUXDxsZOfOOV4H c1NZLpvOh4EGZos2E5v/Gx08pytkWihX3Iwd0= MIME-Version: 1.0 Received: by 10.227.201.207 with SMTP id fb15mr1237275wbb.113.1311794702049; Wed, 27 Jul 2011 12:25:02 -0700 (PDT) Received: by 10.227.155.197 with HTTP; Wed, 27 Jul 2011 12:25:01 -0700 (PDT) In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> <5A600744-8605-46D3-82B2-C3C30E30E4AC@network-heretics.com> Date: Wed, 27 Jul 2011 21:25:01 +0200 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: "John Mann (ITS)" , Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:25:05 -0000 On Wed, Jul 27, 2011 at 3:07 PM, John Mann (ITS) wro= te: > [ And that native dual-stack is a replacement for both. ] > We want normal users to move past "experimental IPv6" towards "production > IPv6". Exactly, we should focus on doing production IPv6, not wasting our time on something that run on top of something else, whatever it's called (are way too many to choice from already and I will recommend anyone that ask me to never walk down that road, never). So, can we please stop this never ending SPAMMING with regards to 6to4? It is a total waste of time, really Keith, please stop. pretty please stop. --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From shemant@cisco.com Wed Jul 27 12:31:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E971611E80AD; Wed, 27 Jul 2011 12:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM8xDdEWAUwn; Wed, 27 Jul 2011 12:31:58 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9695E8028; Wed, 27 Jul 2011 12:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10825; q=dns/txt; s=iport; t=1311795118; x=1313004718; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=uKuBGbSONoyAnrlZYagnDMNW1iXALvi9JIGCy5nAY9g=; b=NqUv0TFRNrHn2R77RhCW3dqLLq4OhwU3en0QZzHbsUaL9mPGyuwd1Tt3 S93JwzIRHD0eogULePaFm62IjirYctEcPCoboZfilPwawoTqmj5kRlAS3 YNpvBya+vcyCY8oGAbXNU9K+6KfBwI2riVSya43QLo7JJC9QDKcH+II+l 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAHBmME6tJV2a/2dsb2JhbAAqCwEBAQEDFAEMEgNPEQIBCQ4DBAEBCwYjAQYBEzsOCAEBBRcMG4I2lSaPSHerf55thWFfBIdXkC6LcA X-IronPort-AV: E=Sophos;i="4.67,278,1309737600"; d="scan'208,217";a="7112421" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 27 Jul 2011 19:31:55 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6RJVthb031820; Wed, 27 Jul 2011 19:31:55 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 14:31:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4C93.D7A8C21C" Date: Wed, 27 Jul 2011 14:31:51 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30258A028@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc Thread-Index: AcxMclwnKq0M3m5GT5ioMV5CXtVTTAAH06Sg References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589B59@XMB-RCD-109.cisco.com><3946F646-0B16-49A4-A146-A93CFF26C21F@nominum.com><5B6B2B64C9FE2A489045EEEADDAFF2C302589C62@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C302589DA4@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Andre Kostur" X-OriginalArrivalTime: 27 Jul 2011 19:31:55.0257 (UTC) FILETIME=[D7DFBE90:01CC4C93] Cc: dhcwg@ietf.org, IPv6 Operations Subject: Re: [v6ops] [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:32:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4C93.D7A8C21C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Andre Kostur [mailto:akostur@incognito.com]=20 Sent: Wednesday, July 27, 2011 11:32 AM To: Hemant Singh (shemant) Cc: dhcwg@ietf.org; IPv6 Operations Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc =20 >The CPE has lots of uses for the IA_NA. Namely it's own management, SNMP monitoring, source IP for syslog notifications, whatever.=20 =20 The CPE rtr document supports both a managed CPE and a unmanaged CPE. There is no SNMP in the unmanaged case, nor any syslog. I don't understand "own management". Without the IA_PD no device in the home will be able to obtain an IPv6 address that is globally routable via the SP network. Thus one broadband deployment in the cable one has already specified a CPE rtr inside a cable modem deems IP address acquisition as failed unless both of the IA_NA and IA_PD are obtained from the DHCPv6 server.=20 =20 >Otherwise why does it want an IA_NA at all? The client device shouldn't be tying the IA_NA together with the IA_PD. They are separate transactions that may tr>avel together in a single DHCP packet. =20 The CPE rtr document supports an unnumbered WAN or a numbered WAN when the WAN has an IA_NA assigned. There are several uses for the IA_NA that have been discussed during the past four years in the IETF. Will get to those later. =20 =20 Not to put words in Ted's mouth, but I believe he was asking the same question. Why should the device abandon the perfectly good IA_NA that it has (or could have) already obtained just because the IA_PD was wrong. =20 =20 The IA_PD was responded to by a failure error code - it wasn't a wrong PD. Thus the CPE router resets and starts DHCPv6 again. So why should the CPE rtr not send both options in the new SOLICIT? =20 If the IA_NA stuff was changed on the DHCP server, the DHCP server knows who already has a lease which may be affected by whatever configuration change happened and either the admin can wait for the IA_NA to timeout (Renew, Rebind, or expiry), or explicitly send a Reconfigure to the device. =20 =20 Operator intervention is not acceptable in a SP broadband network and also the intervention can be delayed. I have already spoken to this fact.=20 =20 Prevents this errant device from endlessly pounding the DHCP server about an IA_NA that it has already given the device. =20 Each day in a cable SP deployment we see a failed DHCPv4 client try forever. I am not sold on endless pounding of the server. Actually some pounding at the server is a cue to the admin to look into their server configuration. =20 =20 Hemant =20 ------_=_NextPart_001_01CC4C93.D7A8C21C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From:= Andre = Kostur [mailto:akostur@incognito.com]
Sent: Wednesday, July 27, 2011 11:32 AM
To: Hemant Singh (shemant)
Cc: dhcwg@ietf.org; IPv6 Operations
Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 = CE rtr bis doc

 

>The CPE = has lots of uses for the IA_NA.  Namely it's own management, SNMP monitoring, = source IP for syslog notifications, whatever.

 

The CPE rtr document supports both a managed CPE and a = unmanaged CPE.  There is no SNMP in the unmanaged case, nor any syslog.  = I don’t understand “own management”.   Without the IA_PD = no device in the home will be able to obtain an IPv6 address that is = globally routable via the SP network.    Thus one broadband = deployment in the cable one has already specified a CPE rtr inside a cable modem deems = IP address acquisition as failed unless both of the IA_NA and IA_PD are = obtained from the DHCPv6 server.

 

>Otherwise = why does it want an IA_NA at all?  The client device shouldn't be tying the = IA_NA together with the IA_PD.  They are separate transactions that may = tr>avel together in a single DHCP = packet.

 

The CPE rtr document supports an unnumbered WAN or a = numbered WAN when the WAN has an IA_NA assigned.   There are several = uses for the IA_NA that have been discussed during the past four years in the IETF.   Will get to those later. 

 

Not to put words in Ted's mouth, but I believe he = was asking the same question.  Why should the device abandon the perfectly = good IA_NA that it has (or could have) already obtained just because the IA_PD was = wrong.  

 

The IA_PD  was responded to by a failure error code = – it wasn’t a wrong PD.   Thus the CPE router resets and = starts DHCPv6 again.   So why should the CPE rtr not send both = options in the new SOLICIT?

 

If the IA_NA stuff was changed on the DHCP server, = the DHCP server knows who already has a lease which may be affected by whatever configuration change happened and either the admin can wait for the = IA_NA to timeout (Renew, Rebind, or expiry), or explicitly send a Reconfigure to = the device.  

 

Operator intervention is not acceptable in a SP broadband network and also the intervention can be delayed.   I have = already spoken to this fact.

 

Prevents this errant device from endlessly pounding = the DHCP server about an IA_NA that it has already given the = device.

 

Each day in a cable SP deployment we see a failed DHCPv4 = client try forever.  I am not sold on endless pounding of the = server.  Actually some pounding at the server is a cue to the admin to look into = their server configuration.   

 

Hemant

 

------_=_NextPart_001_01CC4C93.D7A8C21C-- From Jean-Francois.TremblayING@videotron.com Wed Jul 27 12:35:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E0611E8084; Wed, 27 Jul 2011 12:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzojN2hiNA2a; Wed, 27 Jul 2011 12:35:57 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 746A911E8075; Wed, 27 Jul 2011 12:35:57 -0700 (PDT) In-Reply-To: <4E305F97.100@cisco.com> To: Shishio Tsuchiya MIME-Version: 1.0 X-KeepSent: B53B3628:B649D537-852578DA:006A298F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Wed, 27 Jul 2011 15:35:44 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 07/27/2011 15:35:46, Serialize complete at 07/27/2011 15:35:46 Content-Type: multipart/alternative; boundary="=_alternative 006BA4DA852578DA_=" Cc: v6ops@ietf.org, v6ops-bounces@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:35:58 -0000 Message en plusieurs parties au format MIME --=_alternative 006BA4DA852578DA_= Content-Type: text/plain; charset="US-ASCII" >> for scalability problems ISPs don't usually exchange routes with CPE routers/residential customers. > Yes,I agree. > This routing protocol purpose would be exchange of internal home network. Disagree. Cable ISPs use an IGP (usually RIP) to exchange (a) route(s) with residential or SMB routers on the WAN interface. This provides a stable prefix to the CPE even in the case of topology changes (happening quite frequently in cable networks). If the LAN IGP chosen in homenet is different than the one required by ISPs on the WAN side, home routing equipement vendors may not be able to support both at the same time because of resources constraints. /JF --=_alternative 006BA4DA852578DA_= Content-Type: text/html; charset="US-ASCII"
>> for scalability problems ISPs don't usually exchange routes with CPE routers/residential customers.
> Yes,I agree.
> This routing protocol purpose would be exchange of internal home network.

Disagree. Cable ISPs use an IGP (usually RIP) to exchange (a) route(s) with residential or SMB routers on the WAN interface. This provides a stable prefix to the CPE even in the case of topology changes (happening quite frequently in cable networks).

If the LAN IGP chosen in homenet is different than the one required by ISPs on the WAN side, home routing equipement vendors may not be able to support both at the same time because of resources constraints.

/JF
--=_alternative 006BA4DA852578DA_=-- From d.sturek@att.net Wed Jul 27 12:40:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0B95E803A for ; Wed, 27 Jul 2011 12:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4NgtrnKYt-n for ; Wed, 27 Jul 2011 12:40:00 -0700 (PDT) Received: from nm2-vm0.access.bullet.mail.sp2.yahoo.com (nm2-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.158]) by ietfa.amsl.com (Postfix) with SMTP id E09F85E8037 for ; Wed, 27 Jul 2011 12:40:00 -0700 (PDT) Received: from [98.139.44.96] by nm2.access.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 19:39:57 -0000 Received: from [98.139.44.68] by tm1.access.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 19:39:57 -0000 Received: from [127.0.0.1] by omp1005.access.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 19:39:57 -0000 X-Yahoo-Newman-Id: 915103.11068.bm@omp1005.access.mail.sp2.yahoo.com Received: (qmail 60072 invoked from network); 27 Jul 2011 19:39:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1311795597; bh=gVEi6/K1iPD26RW8yqB6QYZBR3HSekzFCukvMzU1HYk=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=5siTRxRm9AVJ97Y0FhjLSZYNdAf/GffpTfQP3973NvSrSypzFuKAhx7Xhm4F9Wtg01ZK1pS7xwvJWN9IrGLUDNKGAs97F/YsSPnohLo3chin4enfb/Plco6CVxh5N+VGVH9ChqWtENDTBo0TAt4TZ6n/3LZshJtxMBmIPi4kOWo= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kiqGPf0VM1lwJ8d904nG_D52fflfGJ_2F4IgPQZW2o4fZnR po.9lECEKg6J6uCX9KsbOKCpFkqftVtLF9FtJ9KfK7qXEX..PI.UQduE13BW fXdX7Zku4_E9ILgC5d1AmFX69o1RJIL2er4CuYEOrfY2qjKkXbrgYc1ZgfUB tiaT.Jk0vObLy3PR8.8LhiCoyymSVfLjoG8xNFdUZRG1.S2H7hGuCzDuK2Ln ZXz5Ttz702ggqa_9WH.tONRya14qmvO9N5UgXNFBXMtFtrRP5DjLNmsDOFpf XHw5Q16MRH2eAdiXJwYE.Lw3keAVdmDiiUzHdV17.wjucwa75XIoPhrbkqGc 5OLfHSDPiIu9htL5U1fGZ9aGnNrgx9MXuacnOO9RH X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [172.31.39.252] (d.sturek@64.168.229.50 with login) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 27 Jul 2011 12:39:55 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 27 Jul 2011 12:39:48 -0700 From: Don Sturek To: Joel Jaeggli , Maglione Roberta Message-ID: Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:40:01 -0000 Hi Joel (and Roberta), Correct, the routing protocol is to support multiple CPE in the home each of which is connected to a separate WAN with different global prefixes. The use case (and one actively being worked on with deployment next year) is: 1) Customer has a CPE router connected to broadband service 2) Smart meter is installed with a different global prefix supplied by the energy service provider. Devices on the subnet for the CPE router in (1) want to deploy energy applications that connect to the smart meter. The issue is that around 17M smart meters have been deployed with IEEE 802.15.4. This MAC/PHY offers a 127 byte frame so you need 6LoWPAN and a mesh routing protocol like ROLL RPL (in the case used by ZigBee IP). This subnet cannot be bridged with subnets typically deployed with broadband service (hence the need in an intra-home routing protocol). Note that neither of the service providers in (1) or (2) need to do anything special routing wise with the CPE routing protocol in the home. Don On 7/27/11 11:53 AM, "Joel Jaeggli" wrote: > >On Jul 27, 2011, at 2:41 PM, Maglione Roberta wrote: > >> for scalability problems ISPs don't usually exchange routes with CPE >>routers/residential customers. > >Nor would they in this case. In fact from a isp perspective you want the >igp used in the home to be identifiable and easy to filter such that >inadvertant leakage is effectively impossible. Although best practices >for PE ports generally would be sufficient to preclude that, you also >want to do one better. > >joel > >> Regards, >> Roberta >>=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >>Of Shishio Tsuchiya >> Sent: mercoled=EC 27 luglio 2011 20.21 >> To: swmike@swm.pp.se >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >>=20 >> Mikael >> Mikael Abrahamsson wrote: >>> On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: >>>=20 >>>> I think OSPFv3 is not acceptable as default routing protocol on CPE >>>>router. >>>=20 >>> Care to elaborate on that? >>>=20 >>=20 >> Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol. >> The reasons are.. >> -OSPF consumes CPU/memory than RIP. >> -OSPF operetaion is needed more knowledge compare with RIP. >> The character of these protocol does not change on IPv6 environment,too. >> So we thought RIPng would be acceptable routing protocol for IPv6 CPE >>router,also. >>=20 >> Regards, >> -Shishio >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >>persone indicate. La diffusione, copia o qualsiasi altra azione >>derivante dalla conoscenza di queste informazioni sono rigorosamente >>vietate. Qualora abbiate ricevuto questo documento per errore siete >>cortesemente pregati di darne immediata comunicazione al mittente e di >>provvedere alla sua distruzione, Grazie. >>=20 >> This e-mail and any attachments is confidential and may contain >>privileged information intended for the addressee(s) only. >>Dissemination, copying, printing or use by anybody else is unauthorised. >>If you are not the intended recipient, please delete this message and >>any attachments and advise the sender by return e-mail, Thanks. >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From roberta.maglione@telecomitalia.it Wed Jul 27 12:48:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD0811E8084 for ; Wed, 27 Jul 2011 12:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.59 X-Spam-Level: X-Spam-Status: No, score=0.59 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUI0MjG9XYEY for ; Wed, 27 Jul 2011 12:48:34 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 437FD11E8075 for ; Wed, 27 Jul 2011 12:48:08 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Jul 2011 21:47:58 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Wed, 27 Jul 2011 21:47:57 +0200 From: Maglione Roberta To: 'Don Sturek' Date: Wed, 27 Jul 2011 21:47:57 +0200 Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxMlPl6MH1+xnWHSWiXpTAXYftteQAAKpag Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D61@GRFMBX704BA020.griffon.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:48:34 -0000 Hi Don, In your environment you have a routing protocol running in the home netw= ork for the reasons you explained, but my understanding is that you don't h= ave a routing protocol on the WAN link between the CPE and the Service prov= ider's network; is it correct? Thanks, Regards, Roberta -----Original Message----- From: Don Sturek [mailto:d.sturek@att.net] Sent: mercoled=EC 27 luglio 2011 21.40 To: Joel Jaeggli; Maglione Roberta Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router Hi Joel (and Roberta), Correct, the routing protocol is to support multiple CPE in the home each of which is connected to a separate WAN with different global prefixes. The use case (and one actively being worked on with deployment next year) is: 1) Customer has a CPE router connected to broadband service 2) Smart meter is installed with a different global prefix supplied by the energy service provider. Devices on the subnet for the CPE router in (1) want to deploy energy applications that connect to the smart meter. The issue is that around 17M smart meters have been deployed with IEEE 802.15.4. This MAC/PHY offers a 127 byte frame so you need 6LoWPAN and a mesh routing protocol like ROLL RPL (in the case used by ZigBee IP). This subnet cannot be bridged with subnets typically deployed with broadband service (hence the need in an intra-home routing protocol). Note that neither of the service providers in (1) or (2) need to do anything special routing wise with the CPE routing protocol in the home. Don On 7/27/11 11:53 AM, "Joel Jaeggli" wrote: > >On Jul 27, 2011, at 2:41 PM, Maglione Roberta wrote: > >> for scalability problems ISPs don't usually exchange routes with CPE >>routers/residential customers. > >Nor would they in this case. In fact from a isp perspective you want the >igp used in the home to be identifiable and easy to filter such that >inadvertant leakage is effectively impossible. Although best practices >for PE ports generally would be sufficient to preclude that, you also >want to do one better. > >joel > >> Regards, >> Roberta >> >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >>Of Shishio Tsuchiya >> Sent: mercoled=EC 27 luglio 2011 20.21 >> To: swmike@swm.pp.se >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >> >> Mikael >> Mikael Abrahamsson wrote: >>> On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: >>> >>>> I think OSPFv3 is not acceptable as default routing protocol on CPE >>>>router. >>> >>> Care to elaborate on that? >>> >> >> Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol. >> The reasons are.. >> -OSPF consumes CPU/memory than RIP. >> -OSPF operetaion is needed more knowledge compare with RIP. >> The character of these protocol does not change on IPv6 environment,too. >> So we thought RIPng would be acceptable routing protocol for IPv6 CPE >>router,also. >> >> Regards, >> -Shishio >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >>persone indicate. La diffusione, copia o qualsiasi altra azione >>derivante dalla conoscenza di queste informazioni sono rigorosamente >>vietate. Qualora abbiate ricevuto questo documento per errore siete >>cortesemente pregati di darne immediata comunicazione al mittente e di >>provvedere alla sua distruzione, Grazie. >> >> This e-mail and any attachments is confidential and may contain >>privileged information intended for the addressee(s) only. >>Dissemination, copying, printing or use by anybody else is unauthorised. >>If you are not the intended recipient, please delete this message and >>any attachments and advise the sender by return e-mail, Thanks. >> >> _______________________________________________ >> 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From shemant@cisco.com Wed Jul 27 12:50:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F9B11E8155 for ; Wed, 27 Jul 2011 12:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22s0B4GbuIpE for ; Wed, 27 Jul 2011 12:50:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C829C11E80F2 for ; Wed, 27 Jul 2011 12:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9504; q=dns/txt; s=iport; t=1311796232; x=1313005832; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Si9ypa8P8YapEfrMF/wSV+KljEQPhUTdj2FCkH7XquM=; b=as5NHivgWLP4it+Ys9fZvLmRqAj7iuiOrjsrt9VpjfGIKFmpA9VVqEqH PHIUM89P4XuG/Nrxvpbr3yLHDiIx5ltEZ66nPgQPl5QsksnnSQ/WbdJlu EUl1HZXWlYMdTiNmFTbjnGApZSsTl6xgTjOzYRxxhfTzAT99hzdrMa6jC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAACFrME6tJXHA/2dsb2JhbAA1AQEBAQMUAQwSA08RAgEJEQQBAQsGIwEGARM7DggBAQUXDBuCNpUmj0h3rAqeZoVhXwSHV5Aui3A X-IronPort-AV: E=Sophos;i="4.67,278,1309737600"; d="scan'208,217";a="7119732" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 27 Jul 2011 19:50:32 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6RJoWKx002124; Wed, 27 Jul 2011 19:50:32 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 14:50:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4C96.712EACC4" Date: Wed, 27 Jul 2011 14:50:31 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30258A039@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AcxMgkrNXMeoHGNbSUqZ6CUQkFwy8wADwbjw References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" X-OriginalArrivalTime: 27 Jul 2011 19:50:31.0801 (UTC) FILETIME=[7162D690:01CC4C96] Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 19:50:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4C96.712EACC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Lorenzo Colitti [mailto:lorenzo@google.com]=20 Sent: Wednesday, July 27, 2011 1:26 PM To: Hemant Singh (shemant) Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router =20 =20 >Can such a default be extensible to exchange different types of information than just reachability? For example, can it propagate information such as "this is a guest network and this is an internal network" or "this is a prefix that I have tentatively >assigned but do not own yet"? If not, then perhaps something more flexible like IS-IS would be better. =20 Not possible because the proposal is not workable. Someone brought up using OSPFv3 for use in prefix delegation in the home LAN to our IETF CPE router design team. See the questions I asked followed by the person's reply and my responses back to show no routing protocol can be used to delegate prefixes in the LAN. =20 =20 I asked, HS: How do you know OSPF has converged before responding to DHCPv6 PD requests? =20 Reply: The CE router SHOULD wait until two sequential link-state advertisements have no link state changes before delegating any prefixes. This allows time for OSPF to converge, and for the router to build a topology map. =20 Seeing the above reply, I made my comment: =20 HS: Still does not work. After OSPF converges, what happens if the user changes the network such as unplugging a router and moving the router? =20 Reply: The router has a link state table-when it changes, you go through discovery again and issue a Reconfigure where appropriate. =20 =20 HS: There is a network bridge between two routers and the bridge does not have any means to report link-up or down. Further, what if a network interface of a router is flapping all the time and thus basing any algorithm on OSPF convergence breaks down. The flapping interface problem becomes worse if one has a cyclic network. Your proposal still does not work. =20 =20 Hemant =20 =20 ------_=_NextPart_001_01CC4C96.712EACC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From:= Lorenzo = Colitti [mailto:lorenzo@google.com]
Sent: Wednesday, July 27, 2011 1:26 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE = router

 

 

>Can such a = default be extensible to exchange different types of information than just = reachability? For example, can it propagate information such as "this is a guest = network and this is an internal network" or "this is a prefix that I = have tentatively >assigned but do not = own yet"? If not, then perhaps something more flexible like IS-IS would = be better.

 

Not possible because the proposal is not workable. =   Someone brought up using OSPFv3 for use in prefix delegation in the home LAN to = our IETF CPE router design team.  See the questions I asked followed by = the person’s reply and my responses back to show no routing protocol = can be used to delegate prefixes in the LAN.  

 

I asked, HS: How do you know OSPF has converged before responding to DHCPv6 PD requests?

 

Reply: The CE router SHOULD wait until two sequential = link-state advertisements have no link state  changes before delegating any prefixes.  This allows time for OSPF to converge, and for the =  router to build a topology map.

 

Seeing the above reply, I made my = comment:

 

HS: Still does not work.  After OSPF converges, what happens if the user changes the network such  as unplugging a = router and moving the router?

 

Reply: The router has a link state table—when it = changes, you go through discovery again and issue a  Reconfigure where appropriate. 

 

HS:  There is a network bridge between two routers = and the bridge does not have any means to report link-up  or down.  = Further, what if a network interface of a router is flapping all the time and thus =  basing any algorithm on OSPF convergence breaks down.  The flapping = interface problem becomes  worse if one has a cyclic network.  Your = proposal still does not work. 

 

Hemant

 

 

------_=_NextPart_001_01CC4C96.712EACC4-- From d.sturek@att.net Wed Jul 27 13:00:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFB011E80D9 for ; Wed, 27 Jul 2011 13:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXNxqTs5oqQ9 for ; Wed, 27 Jul 2011 13:00:15 -0700 (PDT) Received: from nm5-vm0.access.bullet.mail.sp2.yahoo.com (nm5-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.112]) by ietfa.amsl.com (Postfix) with SMTP id C24CD11E80D2 for ; Wed, 27 Jul 2011 13:00:15 -0700 (PDT) Received: from [98.139.44.103] by nm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 20:00:13 -0000 Received: from [98.139.44.77] by tm8.access.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 20:00:13 -0000 Received: from [127.0.0.1] by omp1014.access.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 20:00:13 -0000 X-Yahoo-Newman-Id: 53751.22164.bm@omp1014.access.mail.sp2.yahoo.com Received: (qmail 15921 invoked from network); 27 Jul 2011 20:00:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1311796812; bh=yL4HCKQsTdi4kmIfBK1Niv08dTLq3SuXQ+zNVxehtV8=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=m9TiIjBb0i9JdkNfqQhGEIazYaPdqA9ZOkH1n7UMOBcMZyKgeTe+U7XelRiAsAQmA493aI3TdoR/xhypkQNQYKvc1YmXUOVKKPwADhImjmHT3PW5Ub8Ad5sxHSGWwlTGz+5j5ZTOzWpgb40kuVHsNufLcElV4QejDO7FMN5hMQc= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5hRi5NoVM1ku2ZkZ0ft8njNhXT9oVusNto4vldXXzq9Ioho MUWgfaqM2iAicDARH40DQ_KcFzzbQ6xbrUxuRfFk7DiN69pHhBxiZT0QFAqX 1efXgRoU2ozA4qznvs3.dfY.ZjtgoFU2RLd_bhhWW0i.cyj9lZ1i2SeFf.D1 5Qo_zF9ABtv285vJp781C1X7bLRy85fkzEuaBslFflrJp_f.AhR_qNps9_0y JV2y.6kpYtR8NVkn71OUlyLwr21XxTK_ZTnmA._VFlMF6GeSz0W9aihpxp6h n7k1DzGT.4dvTw1R..X.ZlFEXcDyVSE_oDLKEWKV5nohlIQDh5WSDny1wwo. tDNMu1iWMzo7UUF6R7S90xg-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [172.31.39.252] (d.sturek@64.168.229.50 with login) by smtp105.sbc.mail.ne1.yahoo.com with SMTP; 27 Jul 2011 13:00:11 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 27 Jul 2011 12:54:34 -0700 From: Don Sturek To: Maglione Roberta Message-ID: Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D61@GRFMBX704BA020.griffon.local> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 20:00:16 -0000 Hi Roberta, I don't think any special routing protocol is needed on the WAN link. The main problem we see is routing between subnets in the home. As Ole pointed out, there are probably some defensive best practices needed to ensure these routing protocols don't transmit onto the WAN..... Don On 7/27/11 12:47 PM, "Maglione Roberta" wrote: >Hi Don, > In your environment you have a routing protocol running in the home >network for the reasons you explained, but my understanding is that you >don't have a routing protocol on the WAN link between the CPE and the >Service provider's network; is it correct? >Thanks, >Regards, >Roberta > >-----Original Message----- >From: Don Sturek [mailto:d.sturek@att.net] >Sent: mercoled=EC 27 luglio 2011 21.40 >To: Joel Jaeggli; Maglione Roberta >Cc: v6ops@ietf.org >Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router > >Hi Joel (and Roberta), > >Correct, the routing protocol is to support multiple CPE in the home each >of which is connected to a separate WAN with different global prefixes. > >The use case (and one actively being worked on with deployment next year) >is: >1) Customer has a CPE router connected to broadband service >2) Smart meter is installed with a different global prefix supplied by >the energy service provider. Devices on the subnet for the CPE router in >(1) want to deploy energy applications that connect to the smart meter. > >The issue is that around 17M smart meters have been deployed with IEEE >802.15.4. This MAC/PHY offers a 127 byte frame so you need 6LoWPAN and a >mesh routing protocol like ROLL RPL (in the case used by ZigBee IP). This >subnet cannot be bridged with subnets typically deployed with broadband >service (hence the need in an intra-home routing protocol). > >Note that neither of the service providers in (1) or (2) need to do >anything special routing wise with the CPE routing protocol in the home. > >Don > > > > >On 7/27/11 11:53 AM, "Joel Jaeggli" wrote: > >> >>On Jul 27, 2011, at 2:41 PM, Maglione Roberta wrote: >> >>> for scalability problems ISPs don't usually exchange routes with CPE >>>routers/residential customers. >> >>Nor would they in this case. In fact from a isp perspective you want the >>igp used in the home to be identifiable and easy to filter such that >>inadvertant leakage is effectively impossible. Although best practices >>for PE ports generally would be sufficient to preclude that, you also >>want to do one better. >> >>joel >> >>> Regards, >>> Roberta >>> >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >>>Of Shishio Tsuchiya >>> Sent: mercoled=EC 27 luglio 2011 20.21 >>> To: swmike@swm.pp.se >>> Cc: v6ops@ietf.org >>> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >>> >>> Mikael >>> Mikael Abrahamsson wrote: >>>> On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: >>>> >>>>> I think OSPFv3 is not acceptable as default routing protocol on CPE >>>>>router. >>>> >>>> Care to elaborate on that? >>>> >>> >>> Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol. >>> The reasons are.. >>> -OSPF consumes CPU/memory than RIP. >>> -OSPF operetaion is needed more knowledge compare with RIP. >>> The character of these protocol does not change on IPv6 >>>environment,too. >>> So we thought RIPng would be acceptable routing protocol for IPv6 CPE >>>router,also. >>> >>> Regards, >>> -Shishio >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >>>persone indicate. La diffusione, copia o qualsiasi altra azione >>>derivante dalla conoscenza di queste informazioni sono rigorosamente >>>vietate. Qualora abbiate ricevuto questo documento per errore siete >>>cortesemente pregati di darne immediata comunicazione al mittente e di >>>provvedere alla sua distruzione, Grazie. >>> >>> This e-mail and any attachments is confidential and may contain >>>privileged information intended for the addressee(s) only. >>>Dissemination, copying, printing or use by anybody else is unauthorised. >>>If you are not the intended recipient, please delete this message and >>>any attachments and advise the sender by return e-mail, Thanks. >>> >>> _______________________________________________ >>> 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 > > > >Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >persone indicate. La diffusione, copia o qualsiasi altra azione derivante >dalla conoscenza di queste informazioni sono rigorosamente vietate. >Qualora abbiate ricevuto questo documento per errore siete cortesemente >pregati di darne immediata comunicazione al mittente e di provvedere alla >sua distruzione, Grazie. > >This e-mail and any attachments is confidential and may contain >privileged information intended for the addressee(s) only. Dissemination, >copying, printing or use by anybody else is unauthorised. If you are not >the intended recipient, please delete this message and any attachments >and advise the sender by return e-mail, Thanks. > From v6ops@globis.net Wed Jul 27 13:14:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D4721F8B42 for ; Wed, 27 Jul 2011 13:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 203cGfzrPdeC for ; Wed, 27 Jul 2011 13:14:57 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E54321F8B3D for ; Wed, 27 Jul 2011 13:14:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 970118700E7; Wed, 27 Jul 2011 22:14:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6lQbOkbPDSm; Wed, 27 Jul 2011 22:14:46 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 116E687006B; Wed, 27 Jul 2011 22:14:46 +0200 (CEST) Message-ID: <4E3071B6.3060807@globis.net> Date: Wed, 27 Jul 2011 22:14:46 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "v6ops@ietf.org WG" , Fred Baker Content-Type: multipart/alternative; boundary="------------010904020202080906000904" Subject: Re: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 20:14:58 -0000 This is a multi-part message in MIME format. --------------010904020202080906000904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am I permitted to ask some dumb questions about this draft since it seems to be urgent? The draft talks about translating IPv6 ICMPv6 responses back to a special shared /24 public IPv4 source range where responses are not 1:1 IPv6 source - IPv4 source mappable (presumably because network links and equipment on the IPv6 side are using IPv6 space from outside the mapped range). Don't we have this situation already when traversing multiple IPv4 networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN links? In that case doesn't ICMP just have to live with an RFC1918 source address, and no one seems to have complained too bitterly so far? What's so special about this new IPv6 mapped situation that is different to the existing situation of overlapping RFC 1918 addresses used by multiple providers, where it's already unclear which unique node on the path generated the ICMP message, and where uRPF filters would already be an issue? i.e. why should the ICMP messages just not be dropped in this case at the AS border, or be sent with RFC 1918 source addresses within an AS, or be sent using a source address from a globally unique (/24) sub-range of the existing provider IPv4 space assigned to the translator if they are so important? I'm sorry, and maybe it's me being totally dumb, but I just don't see the added value of a "special" /24 shared amongst multiple providers, especially if there are possibly multiple translators and multiple providers on a path. It just doesn't seem to give any significant extra information to the intended recipient, and if anything may lead to more confusion. 128 into 32 doesn't go. End of story. regards, RayH > Subject: > [v6ops] Fwd: Request for WG Adoption of > draft-xli-v6ops-ivi-icmp-address-00 > From: > Fred Baker > Date: > Wed, 27 Jul 2011 14:40:59 -0400 > > To: > IPv6 Operations > > Content-Transfer-Encoding: > quoted-printable > Precedence: > list > MIME-Version: > 1.0 (Apple Message framework v1084) > References: > <4E2ED0F0.1070301@cernet.edu.cn> > Message-ID: > > Content-Type: > text/plain; charset=us-ascii > Message: > 6 > > > Folks: the chairs are in receipt of this note. Please read the draft and comment. > > In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment. > > Begin forwarded message: > > >> > From: Xing Li >> > Date: July 26, 2011 10:36:32 AM EDT >> > To:v6ops-chairs@tools.ietf.org >> > Cc:v6ops@ietf.org,draft-xli-v6ops-ivi-icmp-address@tools.ietf.org >> > Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 >> > >> > Hi V6ops Chairs, >> > >> > The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption. >> > >> > The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4. >> > >> > The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list. >> > >> > regards, >> > >> > Xing Li >> > >> > >> > >> > >> --------------010904020202080906000904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Am I permitted to ask some dumb questions about this draft since it seems to be urgent?

The draft talks about translating IPv6 ICMPv6 responses back to a special shared /24 public IPv4 source range where responses are not 1:1 IPv6 source - IPv4 source mappable (presumably because network links and equipment on the IPv6 side are using IPv6 space from outside the mapped range).

Don't we have this situation already when traversing multiple IPv4 networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN links?

In that case doesn't ICMP just have to live with an RFC1918 source address, and no one seems to have complained too bitterly so far?

What's so special about this new IPv6 mapped situation that is different to the existing situation of overlapping RFC 1918 addresses used by multiple providers, where it's already unclear which unique node on the path generated the ICMP message, and where uRPF filters would already be an issue?

i.e. why should the ICMP messages just not be dropped in this case at the AS border, or be sent with RFC 1918 source addresses within an AS, or be sent using a source address from a globally unique (/24) sub-range of the existing provider IPv4 space assigned to the translator if they are so important?

I'm sorry, and maybe it's me being totally dumb, but I just don't see the added value of a "special" /24 shared amongst multiple providers, especially if there are possibly multiple translators and multiple providers on a path. It just doesn't seem to give any significant extra information to the intended recipient, and if anything may lead to more confusion. 128 into 32 doesn't go. End of story.

regards,
RayH

Subject:
[v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
From:
Fred Baker <fred@cisco.com>
Date:
Wed, 27 Jul 2011 14:40:59 -0400
To:
IPv6 Operations <v6ops@ietf.org>
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1084)
References:
<4E2ED0F0.1070301@cernet.edu.cn>
Message-ID:
<FEA206CA-692A-443E-A2C5-8C437D0AB42A@cisco.com>
Content-Type:
text/plain; charset=us-ascii
Message:
6		 

Folks: the chairs are in receipt of this note. Please read the draft and comment.

In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment.

Begin forwarded message:

  
> From: Xing Li <xing@cernet.edu.cn>
> Date: July 26, 2011 10:36:32 AM EDT
> To: v6ops-chairs@tools.ietf.org
> Cc: v6ops@ietf.org, draft-xli-v6ops-ivi-icmp-address@tools.ietf.org
> Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
> 
> Hi V6ops Chairs,
> 
> The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption.
> 
> The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4.
> 
> The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list.
> 
> regards,
> 
> Xing Li
> 
> 
> 
>
--------------010904020202080906000904-- From pch-b2B3A6689@u-1.phicoh.com Wed Jul 27 13:16:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479E111E8082 for ; Wed, 27 Jul 2011 13:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcE+YHGllnis for ; Wed, 27 Jul 2011 13:16:11 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9FB11E8073 for ; Wed, 27 Jul 2011 13:16:11 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QmAWP-0001cKC; Wed, 27 Jul 2011 22:16:01 +0200 Message-Id: To: "Hemant Singh (shemant)" From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30258A039@XMB-RCD-109.cisco.com> In-reply-to: Your message of "Wed, 27 Jul 2011 14:50:31 -0500 ." <5B6B2B64C9FE2A489045EEEADDAFF2C30258A039@XMB-RCD-109.cisco.com> Date: Wed, 27 Jul 2011 22:15:54 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 20:16:12 -0000 In your letter dated Wed, 27 Jul 2011 14:50:31 -0500 you wrote: >>Can such a default be extensible to exchange different types of >information than just reachability? For example, can it propagate >information such as "this is a guest network and this is an internal >network" or "this is a prefix that I have tentatively >assigned but do >not own yet"? If not, then perhaps something more flexible like IS-IS >would be better. > >=20 > >Not possible because the proposal is not workable. Someone brought up >using OSPFv3 for use in prefix delegation in the home LAN to our IETF >CPE router design team. See the questions I asked followed by the >person's reply and my responses back to show no routing protocol can be >used to delegate prefixes in the LAN. =20 Assuming a relatively small home network: Why not use PD just to assign unique network numbers to networks and let the routing protocol figure out how to get packets from one net to another? I.e. the WAN router hands out /64s from a /48 or /56 to whatever router want one and interior routers work as DHCP relay agents for routers further removed from the WAN router. If the topology is tree, every link gets at most one prefix. If not, there maybe a need for a protocol to figure out which one to use. From fred@cisco.com Wed Jul 27 13:30:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5100411E814F for ; Wed, 27 Jul 2011 13:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.087 X-Spam-Level: X-Spam-Status: No, score=-103.087 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQ8xNv0oa3dT for ; Wed, 27 Jul 2011 13:30:05 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BCA1811E8092 for ; Wed, 27 Jul 2011 13:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1978; q=dns/txt; s=iport; t=1311798606; x=1313008206; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=lGPdKDQCfp5gS10HHoaWNon11BOWt+pW52caaOOTgSk=; b=Nl0iZgFBTRIU8fGWCR7irHUTNL1SAO8C4XmqFRou99aTa6c0qR20m3KV zuj26ixStyBCPhQXyz0CJ1iqylhsr5uVRoNtC/0oWTNp/Pd1XXX37HiH2 UIaToFaB1KRoqXnwrEQhDxbRTIDv7sUX8r8NsFlQvjVVAjEU8ZTSi46Rg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAK50ME6rRDoH/2dsb2JhbABPAStFgQNYFyenJHeJAKJynl6FYV8EknWFB4t3 X-IronPort-AV: E=Sophos;i="4.67,278,1309737600"; d="scan'208";a="7131547" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 27 Jul 2011 20:30:05 +0000 Received: from dhcp-57cd.meeting.ietf.org (sjc-vpn4-1212.cisco.com [10.21.84.187]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6RKU4Za028290; Wed, 27 Jul 2011 20:30:04 GMT Received: from [127.0.0.1] by dhcp-57cd.meeting.ietf.org (PGP Universal service); Wed, 27 Jul 2011 16:30:04 -0400 X-PGP-Universal: processed; by dhcp-57cd.meeting.ietf.org on Wed, 27 Jul 2011 16:30:04 -0400 From: Fred Baker Date: Wed, 27 Jul 2011 16:29:51 -0400 Message-Id: <9DE40639-ECFF-4330-B64B-3F1391E7E1E9@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Behave Chairs Subject: [v6ops] Requirements for logging in NAT44, NAT64, and NPTv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 20:30:06 -0000 This afternoon, in behave, there was a brief discussion of NAT logging. = behave has a draft in progress, but has no real idea how it relates to = enterprise or service provider logging requirements. What would really = help would be for network operators with NAT logging requirements (most = likely broadband service providers, mobile service providers, and = educational or enterprise networks with similar requirements) to review = the draft and comment to behave@ietf.org. The draft is = http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging "Logging of NAT Events", Senthil Sivakumar, Reinaldo Penno, 13-Jul-11 My perception is that the primary NAT logging requirements derive from = forensic requirements, and potentially differ based on regional or = national requirements - important requirement sets include US, European, = Australian, Japanese, and Chinese directives. I would summarize them in = this way: - With stateless NAT64, I don't think there is a need for translation = logging, as it is statelessly predictable.=20 - There are legal requirements around logging for NAT44 and stateful = NAT64, primarily around forensic requirements. I believe that comes down = to, when configured, a message with a timestamp, an interface = identifier, and an address/port (IPv4 or IPv6) four-or-five-tuple. Given = that this would happen on the first packet to cross the NAT, there would = be no data retention capability in the same message - data retention = requirements for NAT44, stateful NAT64, and stateless NAT64 would have = to be met by IPFIX, much as they are now. It probably also implies a statement that this is Internet layer = information; one cannot expect it to come up with email addresses, URLs, = instant messaging handles, or other wishful thinking we have read in = ill-informed legal documents. This implies a capability (tool) to interpret the two databases in = response to legal inquiries. From shtsuchi@cisco.com Wed Jul 27 14:14:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F06821F8AFF; Wed, 27 Jul 2011 14:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.459 X-Spam-Level: X-Spam-Status: No, score=-1.459 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxZg96QhAQe7; Wed, 27 Jul 2011 14:14:46 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5C521F8AFA; Wed, 27 Jul 2011 14:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=955; q=dns/txt; s=iport; t=1311801286; x=1313010886; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=q9Vj5PjHIRJXSdKx+bBcNRH2RZWxnjjfeY64ujSMgAc=; b=kG8h4P9IKi5KRGxQJNmh1SmfuHf9hXVPikNJqa+pWsbPM98CLp3HS3Gh Im5hosQ4Vd3M1B9rEofGXtNT+smwXvWKROTBioTJAQXrujS81BmR/+CLc eLYiksF1EM9GhSLKV5uP2bLo2rwbQyPadnOVfhlLprmp+1Te+UYD7pcLq o=; X-IronPort-AV: E=Sophos;i="4.67,278,1309737600"; d="scan'208";a="7144676" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2011 21:14:46 +0000 Received: from [10.82.235.16] (rtp-vpn5-781.cisco.com [10.82.235.16]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6RLEjVF010507; Wed, 27 Jul 2011 21:14:45 GMT Message-ID: <4E307FC5.3080905@cisco.com> Date: Wed, 27 Jul 2011 17:14:45 -0400 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Jean-Francois.TremblayING@videotron.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-bounces@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 21:14:47 -0000 JF I see.I agree your opinion,in your environment. Our home gateway guideline not included cable eRouters and well-managed CPE as scope. We need define scope of discussion on homenet. Regards, -Shishio Jean-Francois.TremblayING@videotron.com wrote: > > >> for scalability problems ISPs don't usually exchange routes with CPE routers/residential customers. > > Yes,I agree. > > This routing protocol purpose would be exchange of internal home network. > > Disagree. Cable ISPs use an IGP (usually RIP) to exchange (a) route(s) with residential or SMB routers on the WAN interface. This provides a stable prefix to the CPE even in the case of topology changes (happening quite frequently in cable networks). > > If the LAN IGP chosen in homenet is different than the one required by ISPs on the WAN side, home routing equipement vendors may not be able to support both at the same time because of resources constraints. > > /JF From fred@cisco.com Wed Jul 27 14:31:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31C822800F for ; Wed, 27 Jul 2011 14:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIaLIy5h0vld for ; Wed, 27 Jul 2011 14:31:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4239022800D for ; Wed, 27 Jul 2011 14:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1008; q=dns/txt; s=iport; t=1311802311; x=1313011911; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=ivrZ43MM0tjGRFAKyJC+HsL0pThOVQsiLNkaeo2okw0=; b=h4iny35lgvDSgaeaJbiATYpiFBEudtH329d+UcnP8T2+O7f7MlBlOpF7 xOjSWml6kXUIYk6wS5yWqvaSRVge/gFcda4dcBpCJ8Qf7xuZywdYw92El mDr+w6yodpXM2y4Y3CX8itnlWwMhmtfBJJmpZl9RP4vKlCmmtwJHIp2vY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAA+DME6rRDoH/2dsb2JhbABPASs6gQ5YPqckd6p4gSOeWoVhXwSSdYUHi3c X-IronPort-AV: E=Sophos;i="4.67,278,1309737600"; d="scan'208";a="7149821" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-1.cisco.com with ESMTP; 27 Jul 2011 21:31:50 +0000 Received: from dhcp-57cd.meeting.ietf.org (sjc-vpn4-1243.cisco.com [10.21.84.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6RLVnGx015056 for ; Wed, 27 Jul 2011 21:31:50 GMT Received: from [127.0.0.1] by dhcp-57cd.meeting.ietf.org (PGP Universal service); Wed, 27 Jul 2011 17:31:50 -0400 X-PGP-Universal: processed; by dhcp-57cd.meeting.ietf.org on Wed, 27 Jul 2011 17:31:50 -0400 From: Fred Baker Date: Wed, 27 Jul 2011 17:31:41 -0400 Message-Id: <987EEA6D-59F9-4D6F-9FFE-6DD2DE3C71D1@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 21:31:51 -0000 Given the growth of drafts in v6ops, Joel and I are forever trying to = figure out how to make our lives a little simpler. I'm thinking about an = interim meeting, in which we would discuss drafts that have been updated = or posted no later than a week in advance and for which interest has = materialized on the mailing list. Are folks interested in having such a meeting? What drafts do folks specifically feel would benefit from review then? = I'm thinking about our working group drafts = (draft-ietf-v6ops-6to4-to-historic, draft-ietf-v6ops-happy-eyeballs, = draft-ietf-v6ops-ipv6-cpe-router-bis, = draft-ietf-v6ops-v6-aaaa-whitelisting-implications) and other drafts = that are of prime interest. Note to authors/editors of drafts: regardless of whether we're talking = about interim or f2f meetings, I will (well, my bot will) post a note = inviting comment when there is a new -00 draft, but after that I am = depending on you to discuss the issues of your drafts on the list.= From fred@cisco.com Wed Jul 27 14:35:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5E521F84FC for ; Wed, 27 Jul 2011 14:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.771 X-Spam-Level: X-Spam-Status: No, score=-102.771 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAxw3t4+BVm4 for ; Wed, 27 Jul 2011 14:35:27 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C1A7C21F8426 for ; Wed, 27 Jul 2011 14:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=12453; q=dns/txt; s=iport; t=1311802527; x=1313012127; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=7N36K+66P5Ru1zT2kJFPwAr2tHozfi+R6+1AaHcSLJQ=; b=UxaP9CsI5T11H/CcHz7VMgzlNaHqMu2QAoKZZACKAenUAa2c9ZcAjgx0 18iniU3XC+w/+IYJaZKVf5tcsywffbUF/rq5BJilkrcPokWFWU/13IJ1l UbtjSX/OEDsg723D0kS0sjcWacuwSR1j9neTWs1waIEw8aYgmuPaB6zkq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHOEME6rRDoH/2dsb2JhbAA0AQEBAQIBFAFlCwUMDA4DAwECOxRJCAcLDCenJHeIfKMonlqFYV8EknWFB4t3 X-IronPort-AV: E=Sophos;i="4.67,278,1309737600"; d="scan'208,217";a="7151953" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-9.cisco.com with ESMTP; 27 Jul 2011 21:35:23 +0000 Received: from dhcp-57cd.meeting.ietf.org (sjc-vpn4-1243.cisco.com [10.21.84.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6RLYsvQ017387; Wed, 27 Jul 2011 21:35:22 GMT Received: from [127.0.0.1] by dhcp-57cd.meeting.ietf.org (PGP Universal service); Wed, 27 Jul 2011 17:35:22 -0400 X-PGP-Universal: processed; by dhcp-57cd.meeting.ietf.org on Wed, 27 Jul 2011 17:35:22 -0400 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4E3071B6.3060807@globis.net> Date: Wed, 27 Jul 2011 17:35:22 -0400 Message-Id: <851D47FA-41FB-4845-A2A4-A259CCE77D39@cisco.com> References: <4E3071B6.3060807@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-33-635356955 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 21:35:28 -0000 --Apple-Mail-33-635356955 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 27, 2011, at 4:14 PM, Ray Hunter wrote: > Am I permitted to ask some dumb questions about this draft since it = seems to be urgent? Certainly. I will ask the authors to respond to them. > The draft talks about translating IPv6 ICMPv6 responses back to a = special shared /24 public IPv4 source range where responses are not 1:1 = IPv6 source - IPv4 source mappable (presumably because network links and = equipment on the IPv6 side are using IPv6 space from outside the mapped = range). >=20 > Don't we have this situation already when traversing multiple IPv4 = networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN = links? >=20 > In that case doesn't ICMP just have to live with an RFC1918 source = address, and no one seems to have complained too bitterly so far? >=20 > What's so special about this new IPv6 mapped situation that is = different to the existing situation of overlapping RFC 1918 addresses = used by multiple providers, where it's already unclear which unique node = on the path generated the ICMP message, and where uRPF filters would = already be an issue? >=20 > i.e. why should the ICMP messages just not be dropped in this case at = the AS border, or be sent with RFC 1918 source addresses within an AS, = or be sent using a source address from a globally unique (/24) sub-range = of the existing provider IPv4 space assigned to the translator if they = are so important? >=20 > I'm sorry, and maybe it's me being totally dumb, but I just don't see = the added value of a "special" /24 shared amongst multiple providers, = especially if there are possibly multiple translators and multiple = providers on a path. It just doesn't seem to give any significant extra = information to the intended recipient, and if anything may lead to more = confusion. 128 into 32 doesn't go. End of story. >=20 > regards, > RayH >=20 >> Subject: [v6ops] Fwd: Request for WG Adoption of = draft-xli-v6ops-ivi-icmp-address-00 >> From: Fred Baker >> Date: Wed, 27 Jul 2011 14:40:59 -0400 >> To: IPv6 Operations >> Content-Transfer-Encoding: quoted-printable >> Precedence: list >> MIME-Version: 1.0 (Apple Message framework v1084) >> References: <4E2ED0F0.1070301@cernet.edu.cn> >> Message-ID: >> Content-Type: text/plain; charset=3Dus-ascii >> Message: 6 >> Folks: the chairs are in receipt of this note. Please read the draft = and comment. >>=20 >> In short, the draft requests an IPv4 prefix to be used in ICMPv4 to = refer to IPv6 routers on the far side of a translator. In the reverse = case, ICMPv6 would translate the address to an IPv4-embedded address as = defined in RFC 6145 (an IPv6 address containing and statelessly = translatable to an IPv4 address). If we buy off on it - and that's a = discussion we should have on this list - Ron can walk it through the = IESG and get the assignment. >>=20 >> Begin forwarded message: >>=20 >> =20 >>> > From: Xing Li >>> > Date: July 26, 2011 10:36:32 AM EDT >>> > To: v6ops-chairs@tools.ietf.org >>> > Cc: v6ops@ietf.org, = draft-xli-v6ops-ivi-icmp-address@tools.ietf.org >>> > Subject: Request for WG Adoption of = draft-xli-v6ops-ivi-icmp-address-00 >>> >=20 >>> > Hi V6ops Chairs, >>> >=20 >>> > The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to = request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt = as a WG adoption. >>> >=20 >>> > The draft describes the operational considerations of mapping = ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not = directly translatable into an IPv4 address, and requests an IANA Special = Purpose IPv4 address allocation to allow this address mapping to take = place using a protocol-specific designated address block in IPv4. >>> >=20 >>> > The authors are hopeful that this will not require any valuable = face-to-face WG time at IETF 81 and the WG's consideration of this = document can be undertaken entirely on the mailing list. >>> >=20 >>> > regards, >>> >=20 >>> > Xing Li >>> >=20 >>> >=20 >>> >=20 >>> >=20 >>> =20 --Apple-Mail-33-635356955 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 27, 2011, at 4:14 PM, Ray Hunter wrote:

Am I permitted to ask some dumb questions about this draft since it seems to be urgent?

Certainly. I will ask the authors to respond to them.

The draft talks about translating IPv6 ICMPv6 responses back to a special shared /24 public IPv4 source range where responses are not 1:1 IPv6 source - IPv4 source mappable (presumably because network links and equipment on the IPv6 side are using IPv6 space from outside the mapped range).

Don't we have this situation already when traversing multiple IPv4 networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN links?

In that case doesn't ICMP just have to live with an RFC1918 source address, and no one seems to have complained too bitterly so far?

What's so special about this new IPv6 mapped situation that is different to the existing situation of overlapping RFC 1918 addresses used by multiple providers, where it's already unclear which unique node on the path generated the ICMP message, and where uRPF filters would already be an issue?

i.e. why should the ICMP messages just not be dropped in this case at the AS border, or be sent with RFC 1918 source addresses within an AS, or be sent using a source address from a globally unique (/24) sub-range of the existing provider IPv4 space assigned to the translator if they are so important?

I'm sorry, and maybe it's me being totally dumb, but I just don't see the added value of a "special" /24 shared amongst multiple providers, especially if there are possibly multiple translators and multiple providers on a path. It just doesn't seem to give any significant extra information to the intended recipient, and if anything may lead to more confusion. 128 into 32 doesn't go. End of story.

regards,
RayH

Subject:
[v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
From:
Fred Baker <fred@cisco.com>
Date:
Wed, 27 Jul 2011 14:40:59 -0400
To:
IPv6 Operations <v6ops@ietf.org>
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1084)
References:
<4E2ED0F0.1070301@cernet.edu.cn>
Message-ID:
<FEA206CA-692A-443E-A2C5-8C437D0AB42A@cisco.com>
Content-Type:
text/plain; charset=us-ascii
Message:
6		 

Folks: the chairs are in receipt of this note. Please read the draft and comment.

In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment.

Begin forwarded message:

  
> From: Xing Li <xing@cernet.edu.cn>
> Date: July 26, 2011 10:36:32 AM EDT
> To: v6ops-chairs@tools.ietf.org
> Cc: v6ops@ietf.org, draft-xli-v6ops-ivi-icmp-address@tools.ietf.org
> Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
> 
> Hi V6ops Chairs,
> 
> The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption.
> 
> The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4.
> 
> The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list.
> 
> regards,
> 
> Xing Li
> 
> 
> 
>

--Apple-Mail-33-635356955-- From mcr@sandelman.ca Wed Jul 27 15:26:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0458E11E8136; Wed, 27 Jul 2011 15:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=0.863, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQlcT6Ejdt3d; Wed, 27 Jul 2011 15:26:29 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 87DA411E8097; Wed, 27 Jul 2011 15:26:29 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-174f.meeting.ietf.org [130.129.23.79]) by relay.sandelman.ca (Postfix) with ESMTPS id C6C9934138; Wed, 27 Jul 2011 18:26:07 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 8C2AE980EA; Wed, 27 Jul 2011 18:26:43 -0400 (EDT) From: Michael Richardson To: IPv6 Operations , ietf@ietf.org In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <72A76FC2-CA5F-4DD5-91FF-280B6A42268B@cisco.com> <5A600744-8605-46D3-82B2-C3C30E30E4AC@network-heretics.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2011 18:26:43 -0400 Message-ID: <26682.1311805603@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:26:30 -0000 >>>>> "Roger" =3D=3D Roger J=F8rgensen writes: >> We want normal users to move past "experimental IPv6" towards "produ= ction >> IPv6". Roger> Exactly, we should focus on doing production IPv6, not wasting o= ur Roger> time on something that run on top of something else, whatever Roger> it's So, in your opinion, a production host will never have more than one address? This is the fundamental problem. 6to4 is just the thing shining the light on the problem. From ichiroumakino@gmail.com Wed Jul 27 15:36:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBDE11E80BA for ; Wed, 27 Jul 2011 15:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of1hD2gQbSiI for ; Wed, 27 Jul 2011 15:36:05 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 09CF511E8084 for ; Wed, 27 Jul 2011 15:36:02 -0700 (PDT) Received: by pzk6 with SMTP id 6so3205566pzk.26 for ; Wed, 27 Jul 2011 15:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9+FDHqemwgupeY0B/31YhxOT9ugf+AgR2IXZ9WWCMuU=; b=E90PfWu239GahU9ngvkKZyxtfNU6IxGQWyYuZlTEgGffQY3PhiW5buUqvpAVgT9WMx I24l4PUuvY5XN6fWNt364+B7air9aiCtYYxxqadQzzMIw6tNgvFRcmg2i6kZ0lUZUdrV GcdRuqZvYeKfkcy5dmxiKLK5RXR/l5b+7n+2s= Received: by 10.68.56.135 with SMTP id a7mr570777pbq.228.1311806161390; Wed, 27 Jul 2011 15:36:01 -0700 (PDT) Received: from sjc-vpn7-292.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id z6sm297263pbc.94.2011.07.27.15.35.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 15:36:00 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ole Troan In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30258A039@XMB-RCD-109.cisco.com> Date: Wed, 27 Jul 2011 18:35:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2614800C-492E-406C-85CF-7D5603862EB5@employees.org> References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30258A039@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:36:05 -0000 Hemant, > Not possible because the proposal is not workable. Someone brought = up using OSPFv3 for use in prefix delegation in the home LAN to our IETF = CPE router design team. See the questions I asked followed by the = person=92s reply and my responses back to show no routing protocol can = be used to delegate prefixes in the LAN. https://datatracker.ietf.org/doc/draft-dimitri-zospf/ this belongs in homenet. cheers, Ole From Jean-Francois.TremblayING@videotron.com Wed Jul 27 16:22:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3927D11E809C; Wed, 27 Jul 2011 16:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZD1qUMYhpTa; Wed, 27 Jul 2011 16:22:08 -0700 (PDT) Received: from mx02.videotron.com (mx02.videotron.com [24.201.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 82C4011E8084; Wed, 27 Jul 2011 16:22:07 -0700 (PDT) In-Reply-To: <4E307FC5.3080905@cisco.com> To: Shishio Tsuchiya MIME-Version: 1.0 X-KeepSent: 6047A917:D2944145-852578DA:007F2FD6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Wed, 27 Jul 2011 19:21:50 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 07/27/2011 19:21:56, Serialize complete at 07/27/2011 19:21:56 Content-Type: multipart/alternative; boundary="=_alternative 008057FF852578DA_=" Cc: v6ops@ietf.org, v6ops-bounces@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 23:22:10 -0000 Message en plusieurs parties au format MIME --=_alternative 008057FF852578DA_= Content-Type: text/plain; charset="US-ASCII" > I see.I agree your opinion,in your environment. > Our home gateway guideline not included cable eRouters and well-managed CPE as scope. > We need define scope of discussion on homenet. Understood. However not all SMB routers are eRouters. Most of them are actually off-the-shelf devices, often considered as "home" routers. In this regard, the choice of a homenet IGP has an impact on the WAN side, because most implementors will not want to support two IGPs. The position I wanted to express here is the same than yours, that RIPng seems a better and simpler choice. But as Ole suggested, let's move this thread in homenet, it doesn't belong in v6ops. /JF --=_alternative 008057FF852578DA_= Content-Type: text/html; charset="US-ASCII"

> I see.I agree your opinion,in your environment.
> Our home gateway guideline not included cable eRouters and well-managed CPE as  scope.
> We need define scope of discussion on homenet.

Understood. However not all SMB routers are eRouters. Most of them are actually
off-the-shelf devices, often considered as "home" routers.

In this regard, the choice of a homenet IGP has an impact on the WAN side, because
most implementors will not want to support two IGPs. The position I wanted to express
here is the same than yours, that RIPng seems a better and simpler choice.  

But as Ole suggested, let's move this thread in homenet, it doesn't belong in v6ops.

/JF
--=_alternative 008057FF852578DA_=-- From marka@isc.org Wed Jul 27 16:37:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABB711E80D1; Wed, 27 Jul 2011 16:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9zBQQWuN5Nc; Wed, 27 Jul 2011 16:37:03 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5546611E8084; Wed, 27 Jul 2011 16:37:02 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id A2A945F995F; Wed, 27 Jul 2011 23:36:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5FE52216C86; Wed, 27 Jul 2011 23:36:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 406021238970; Thu, 28 Jul 2011 09:36:34 +1000 (EST) To: Jeroen Massar From: Mark Andrews References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> <20110727151517.CF9371235D70@drugs.dv.isc.org> <999C3229-649D-4242-BB0F-2BB494EDF1D9@network-heretics.com> <4E305E3E.2040607@unfix.org> In-reply-to: Your message of "Wed, 27 Jul 2011 20:51:42 +0200." <4E305E3E.2040607@unfix.org> Date: Thu, 28 Jul 2011 09:36:34 +1000 Message-Id: <20110727233634.406021238970@drugs.dv.isc.org> Cc: IPv6 Operations , Keith Moore , IETF Discussion Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 23:37:04 -0000 In message <4E305E3E.2040607@unfix.org>, Jeroen Massar writes: > On 2011-07-27 20:21 , Keith Moore wrote: > > On Jul 27, 2011, at 11:35 AM, Tim Chown wrote: > > > >> I suspect, but have no proof, that the huge majority of 6to4 users don't u > se it intentionally, and the content they are trying to reach is also availab > le over IPv4. But for people who want to develop and use new IPv6-specific ap > ps, then either a broker or something like OpenWRT ought to meet their needs? > > > > tunnel brokers suck if the tunnel endpoint isn't near your current network > location. > > Let me rewrite that sentence for you: > > "transition mechanisms suck if the tunnel endpoint isn't near your > current network location" > > It does not matter much if that mechanism is static proto-41 (6in4), > 6to4, AYIYA, TSP, PPTP, HTTP Proxies or whatever, there is going to be a > bit more latency if they are not directly next to you. Not much you can > do about except deploy more of them or > > And this will always be the case unless you deploy enough of them in all > places possible. For SixXS we are at 48 boxes around the world, > Hurricane has 25 and Gogo6 has 4 of them of their own for Freenet6 and > then there are 4 others at other organizations and there are a couple of > other services out there which provide tunnels see: Is there *one* tunnel management protocol that they all support or does a cpe vendor have to implement multiple ones to reach them all? I'm pretty sure I know the answer to this question but I'd love to be proved wrong. One of the advantages of 6to4 anycast is that it is just needs a check box to turn on and off. Everybody speaks the same thing. Another advantage of 6to4 is it doesn't require manual intervention on renumber events. Manual tunnel don't pass muster. Another advantage of 6to4 is you don't have to register. For most of the tunnel brokers you have to register. > http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers > > > there are currently no universally applicable, or even widely applicable, v > 6-over-v4 solutions. > > For your set of requirements maybe but especially Tunnel Brokers are > working very well for a lot of people and if one sees the traffic stats > on Teredo and 6to4 nodes due to this little thing called NNTP I would > state that those are doing quite fine too for giving access to what > people need to get to. > > Your major requirement seems to involve latency though, thus as such, > there is only one thing to do, get one of those boxes deployed locally > to your endpoint. > > Do note to yourself that the next issue you will run into that the > service you are actually contacting will be far away, and you suddenly > understand that you need that Akamai content box and a Google one and > various other closeby too ;) > > If you want to solve your problem though, I guess for HE you'll have to > give them connectivity to their network and space in a rack for a box, > gogo6 will sell you a box and for SixXS you provide the box+connectivity > and we'll set up the software for free for you and handle the tunneling > completely. > > 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 jhw@apple.com Wed Jul 27 18:57:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE0521F8B8A; Wed, 27 Jul 2011 18:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbJqrt8lUv+V; Wed, 27 Jul 2011 18:57:16 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFAD21F8B89; Wed, 27 Jul 2011 18:57:16 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LP000106TF298T1@mail-out.apple.com>; Wed, 27 Jul 2011 18:57:06 -0700 (PDT) X-AuditID: 11807130-b7c45ae000001381-d1-4e30c1a7b6b6 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id D7.F3.04993.7A1C03E4; Wed, 27 Jul 2011 18:55:51 -0700 (PDT) Received: from [10.0.1.2] (unknown [207.96.251.20]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LP000M43TEUR440@koseret.apple.com>; Wed, 27 Jul 2011 18:57:06 -0700 (PDT) From: james woodyatt In-reply-to: Date: Wed, 27 Jul 2011 21:56:51 -0400 Content-transfer-encoding: quoted-printable Message-id: <2D290C0C-E845-42EF-9690-D92D3D86641C@apple.com> References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> To: Philip Homburg X-Mailer: Apple Mail (2.1244.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUiON1OXXf5QQM/gz9z5S2ebZzPYnH62F5m ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlfLn2kbHgOkfFoyV3mRoY/7N1MXJySAiYSDzb1cIC YYtJXLi3HijOxSEk0MkkMelTHztIgldAUOLH5HtARRwczAJ6EvcvakHUNDFJLFs3lxWkRlhA S6Lj/X6wejYBFYlvl+8ygdRzChhLTHkMNp9FQFXi1KspYHuZBQIkbpzczghha0s8eXeBFWKV jcS1W/PZIebfZZLYcv0ZWEJEQFfizc1pzBCHykssbvnMOIFRYBaS82YhnDcLydgFjMyrGAWL UnMSKw0N9RILCnJS9ZLzczcxgkKwodBgB+Pan/yHGAU4GJV4eBfoGPgJsSaWFVfmHmKU4GBW EuG9JAcU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzpv9Q9VPSCA9sSQ1OzW1ILUIJsvEwSnVwHhs v9zPRgvfC1OU/r2YoHtwpq/GcvNI7kdf1wavfPghl1NMJ2Oh/kSLwIaMh1XGS/77ZnYUmL+o 1v51r2ytOvO7wJlh4p7P6sz/bKz+PfPRbXuLJ48eXw/n/Ch0Ifr4bIEXzBeWisarvRXe8u3+ vRns6ysb4pVWTZaWDFCTKcktuPVb7U7F9l1KLMUZiYZazEXFiQBqAYt8PQIAAA== Cc: IPv6 Operations , "ietf@ietf.org Discussion" Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 01:57:17 -0000 On Jul 27, 2011, at 4:32 AM, Philip Homburg wrote: >=20 > So I think it would be quite weird to keep 6to4 at standards track = just to prevent some vendors from dropping 6to4 support.=20 As one of those implementers-- as in, it will probably be *my* commit to = the repository that does "rm $XNU/bsd/net/if_stf.c"=97- I now feel = compelled to reiterate that I would prefer a more controlled phase-out = plan than, "equipment vendors and operators are free to commence the = destruction of 6to4 at their individual convenience and without further = warning to the user community." In the absence of a coherent instruction from IETF for a phase-out plan, = declaring this protocol historic under the current proposed language, = will do precisely that. Please please please, if IETF wants 6to4 to = die, then publish a phase-out plan so that the current users of 6to4 can = have fair warning before the relays go dark and forthcoming = hardware/software upgrades rip the feature out from under them. -- james woodyatt member of technical staff, core os networking From lee@asgard.org Wed Jul 27 19:20:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5176B21F8540 for ; Wed, 27 Jul 2011 19:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMEqzOh1sJSt for ; Wed, 27 Jul 2011 19:20:27 -0700 (PDT) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8F98C21F844F for ; Wed, 27 Jul 2011 19:20:27 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p6S2KQwC026989 for ; Wed, 27 Jul 2011 22:20:26 -0400 Authentication-Results: cm-omr6 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [70.25.120.2] ([70.25.120.2:1289] helo=HDC00027112) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 42/DF-19187-867C03E4; Wed, 27 Jul 2011 22:20:26 -0400 From: "Lee Howard" To: "'Fred Baker'" , "'IPv6 Operations'" References: <987EEA6D-59F9-4D6F-9FFE-6DD2DE3C71D1@cisco.com> In-Reply-To: <987EEA6D-59F9-4D6F-9FFE-6DD2DE3C71D1@cisco.com> Date: Wed, 27 Jul 2011 22:20:07 -0400 Message-ID: <000001cc4ccc$e411c170$ac354450$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxMpJtBI9J32gBXRe6q3/ttl9n9xAAI9noA Content-Language: en-us Subject: Re: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 02:20:28 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker > Sent: Wednesday, July 27, 2011 5:32 PM > To: IPv6 Operations > Subject: [v6ops] A question: Interim meeting > > Given the growth of drafts in v6ops, Joel and I are forever trying to figure out how to make > our lives a little simpler. I'm thinking about an interim meeting, in which we would discuss > drafts that have been updated or posted no later than a week in advance and for which > interest has materialized on the mailing list. > > Are folks interested in having such a meeting? Yes. > What drafts do folks specifically feel would benefit from review then? I'm more interested in the non-WG drafts than the fairly mature WG items. Also, I need breaks every hour or so. Lee From john_brzozowski@cable.comcast.com Wed Jul 27 19:46:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB6921F8777 for ; Wed, 27 Jul 2011 19:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.296 X-Spam-Level: X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKxnpu3d-kz4 for ; Wed, 27 Jul 2011 19:46:06 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1002E21F86D7 for ; Wed, 27 Jul 2011 19:46:05 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46476922; Wed, 27 Jul 2011 20:50:49 -0600 Received: from PACDCEXMB02.cable.comcast.com ([fe80::9803:aba4:1ac8:474e]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Wed, 27 Jul 2011 22:46:01 -0400 From: "Brzozowski, John" To: Fred Baker , IPv6 Operations Thread-Topic: [v6ops] A question: Interim meeting Thread-Index: AQHMTKSkZB9AmUr2YEKIBJJ3sAVCYZUBB6qA Date: Thu, 28 Jul 2011 02:46:00 +0000 Message-ID: In-Reply-To: <987EEA6D-59F9-4D6F-9FFE-6DD2DE3C71D1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <95B88B1A70BAB54996205ED6D67B2E59@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 02:46:06 -0000 On 7/27/11 5:31 PM, "Fred Baker" wrote: >Are folks interested in having such a meeting? [jjmb] yes From washam.fan@gmail.com Wed Jul 27 19:48:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C3A21F8782 for ; Wed, 27 Jul 2011 19:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE4+xqarjV8b for ; Wed, 27 Jul 2011 19:48:02 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D627C21F86D7 for ; Wed, 27 Jul 2011 19:48:01 -0700 (PDT) Received: by wyj26 with SMTP id 26so1407872wyj.31 for ; Wed, 27 Jul 2011 19:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0b+JmLcSYOSnP+T6JJSAsKfd7goU7wZW9wwvo3MptZc=; b=rNjM+61Uo3AdrJUw/gD2QoGnhCS0WzLxAW01jKiGHB3ke277+gLh/uRbrEsO7qZFkl fy+awwwR19Th+YuAj/AlrRWDfFpxSMPDX3aPRhc4Idbu+zOOBtI8enMFqubZtjtCG03q bPMEM++are4PdxapxbniO+rQFbUhwCBNu8v84= MIME-Version: 1.0 Received: by 10.227.160.140 with SMTP id n12mr610031wbx.69.1311821280955; Wed, 27 Jul 2011 19:48:00 -0700 (PDT) Received: by 10.216.52.134 with HTTP; Wed, 27 Jul 2011 19:48:00 -0700 (PDT) In-Reply-To: <20110727114038.GE7494@phantom.vanrein.org> References: <20110727114038.GE7494@phantom.vanrein.org> Date: Thu, 28 Jul 2011 10:48:00 +0800 Message-ID: From: Washam Fan To: Rick van Rein Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] slight comments on draft-vanrein-v6ops-6bed4-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 02:48:02 -0000 Hi Rick, Please see inline. >> 3. why don't you mention direct encapsulated ipv6 end embeded system >> to end embeded communication? is it not in your senario or anything >> else? > > I have difficulties parsing this one... > > I mentioned peer-to-peer traffic in 2.2; encapsulating IPv6 in IPv4 > (proto-41) is not independent of the router used; is that what you > were asking about? I was referring to section 4.3. it seems to me all internal ipv6 traffic U-turn the tunnel server. How about 'direct' tunnelled between 2 embeded hosts without going thru the tunnel server? if it is applicable, it would mitigate the burden of the server and the possibility of a single point failure. Thanks, washam From v6ops@globis.net Wed Jul 27 19:52:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A844E21F8879 for ; Wed, 27 Jul 2011 19:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z4zsPdF74QO for ; Wed, 27 Jul 2011 19:52:57 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id CB9D321F8877 for ; Wed, 27 Jul 2011 19:52:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B60D58700F3; Thu, 28 Jul 2011 04:52:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuF0Nrn2PEMK; Thu, 28 Jul 2011 04:52:49 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 9BC4387005C; Thu, 28 Jul 2011 04:52:49 +0200 (CEST) Message-ID: <4E30CF01.9000705@globis.net> Date: Thu, 28 Jul 2011 04:52:49 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Fred Baker References: <4E3071B6.3060807@globis.net> <851D47FA-41FB-4845-A2A4-A259CCE77D39@cisco.com> In-Reply-To: <851D47FA-41FB-4845-A2A4-A259CCE77D39@cisco.com> Content-Type: multipart/alternative; boundary="------------000507050204010600040206" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 02:52:58 -0000 This is a multi-part message in MIME format. --------------000507050204010600040206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The concern would be that the special /24 is creating a new range that: - carries ICMP control messages, which could also be used to attempt to alter a senders' behavior - is shared between multiple providers - is not traceable - should not be filtered at AS boundaries which could grant an attacker a perfect set of source addresses for mounting a DDOS attack. Yes the range isn't routable as a destination, but that possibly makes it even worse, as the target of any DDOS sourced from this range would have absolutely no idea who was sending them the huge volume of junk packets, except by incoming interface at the AS boundary. I see no reason why a network operator would want to accept such a packet from another AS into their network, so they'll basically get filtered everywhere after the very first attack IMHO. regards, RayH Fred Baker wrote: > On Jul 27, 2011, at 4:14 PM, Ray Hunter wrote: > >> Am I permitted to ask some dumb questions about this draft since it >> seems to be urgent? > > Certainly. I will ask the authors to respond to them. > >> The draft talks about translating IPv6 ICMPv6 responses back to a >> special shared /24 public IPv4 source range where responses are not >> 1:1 IPv6 source - IPv4 source mappable (presumably because network >> links and equipment on the IPv6 side are using IPv6 space from >> outside the mapped range). >> >> Don't we have this situation already when traversing multiple IPv4 >> networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN links? >> >> In that case doesn't ICMP just have to live with an RFC1918 source >> address, and no one seems to have complained too bitterly so far? >> >> What's so special about this new IPv6 mapped situation that is >> different to the existing situation of overlapping RFC 1918 addresses >> used by multiple providers, where it's already unclear which unique >> node on the path generated the ICMP message, and where uRPF filters >> would already be an issue? >> >> i.e. why should the ICMP messages just not be dropped in this case at >> the AS border, or be sent with RFC 1918 source addresses within an >> AS, or be sent using a source address from a globally unique (/24) >> sub-range of the existing provider IPv4 space assigned to the >> translator if they are so important? >> >> I'm sorry, and maybe it's me being totally dumb, but I just don't see >> the added value of a "special" /24 shared amongst multiple providers, >> especially if there are possibly multiple translators and multiple >> providers on a path. It just doesn't seem to give any significant >> extra information to the intended recipient, and if anything may lead >> to more confusion. 128 into 32 doesn't go. End of story. >> >> regards, >> RayH >> >>> Subject: >>> [v6ops] Fwd: Request for WG Adoption of >>> draft-xli-v6ops-ivi-icmp-address-00 >>> From: >>> Fred Baker >>> Date: >>> Wed, 27 Jul 2011 14:40:59 -0400 >>> >>> To: >>> IPv6 Operations >>> >>> Content-Transfer-Encoding: >>> quoted-printable >>> Precedence: >>> list >>> MIME-Version: >>> 1.0 (Apple Message framework v1084) >>> References: >>> <4E2ED0F0.1070301@cernet.edu.cn> >>> Message-ID: >>> >>> Content-Type: >>> text/plain; charset=us-ascii >>> Message: >>> 6 >>> >>> >>> Folks: the chairs are in receipt of this note. Please read the draft and comment. >>> >>> In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment. >>> >>> Begin forwarded message: >>> >>> >>>> > From: Xing Li >>>> > Date: July 26, 2011 10:36:32 AM EDT >>>> > To:v6ops-chairs@tools.ietf.org >>>> > Cc:v6ops@ietf.org,draft-xli-v6ops-ivi-icmp-address@tools.ietf.org >>>> > Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 >>>> > >>>> > Hi V6ops Chairs, >>>> > >>>> > The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption. >>>> > >>>> > The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4. >>>> > >>>> > The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list. >>>> > >>>> > regards, >>>> > >>>> > Xing Li >>>> > >>>> > >>>> > >>>> > >>>> --------------000507050204010600040206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The concern would be that the special /24 is creating a new range that:

- carries ICMP control messages, which could also be used to attempt to alter a senders' behavior
- is shared between multiple providers
- is not traceable
- should not be filtered at AS boundaries

which could grant an attacker a perfect set of source addresses for mounting a DDOS attack.

Yes the range isn't routable as a destination, but that possibly makes it even worse, as the target of any DDOS sourced from this range would have absolutely no idea who was sending them the huge volume of junk packets, except by incoming interface at the AS boundary. I see no reason why a network operator would want to accept such a packet from another AS into their network, so they'll basically get filtered everywhere after the very first attack IMHO.

regards,
RayH

Fred Baker wrote:
On Jul 27, 2011, at 4:14 PM, Ray Hunter wrote:

Am I permitted to ask some dumb questions about this draft since it seems to be urgent?

Certainly. I will ask the authors to respond to them.

The draft talks about translating IPv6 ICMPv6 responses back to a special shared /24 public IPv4 source range where responses are not 1:1 IPv6 source - IPv4 source mappable (presumably because network links and equipment on the IPv6 side are using IPv6 space from outside the mapped range).

Don't we have this situation already when traversing multiple IPv4 networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN links?

In that case doesn't ICMP just have to live with an RFC1918 source address, and no one seems to have complained too bitterly so far?

What's so special about this new IPv6 mapped situation that is different to the existing situation of overlapping RFC 1918 addresses used by multiple providers, where it's already unclear which unique node on the path generated the ICMP message, and where uRPF filters would already be an issue?

i.e. why should the ICMP messages just not be dropped in this case at the AS border, or be sent with RFC 1918 source addresses within an AS, or be sent using a source address from a globally unique (/24) sub-range of the existing provider IPv4 space assigned to the translator if they are so important?

I'm sorry, and maybe it's me being totally dumb, but I just don't see the added value of a "special" /24 shared amongst multiple providers, especially if there are possibly multiple translators and multiple providers on a path. It just doesn't seem to give any significant extra information to the intended recipient, and if anything may lead to more confusion. 128 into 32 doesn't go. End of story.

regards,
RayH

Subject:
[v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
From:
Fred Baker <fred@cisco.com>
Date:
Wed, 27 Jul 2011 14:40:59 -0400
To:
IPv6 Operations <v6ops@ietf.org>
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1084)
References:
<4E2ED0F0.1070301@cernet.edu.cn>
Message-ID:
<FEA206CA-692A-443E-A2C5-8C437D0AB42A@cisco.com>
Content-Type:
text/plain; charset=us-ascii
Message:
6		 

Folks: the chairs are in receipt of this note. Please read the draft and comment.

In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment.

Begin forwarded message:

  
> From: Xing Li <xing@cernet.edu.cn>
> Date: July 26, 2011 10:36:32 AM EDT
> To: v6ops-chairs@tools.ietf.org
> Cc: v6ops@ietf.org, draft-xli-v6ops-ivi-icmp-address@tools.ietf.org
> Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
> 
> Hi V6ops Chairs,
> 
> The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption.
> 
> The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4.
> 
> The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list.
> 
> regards,
> 
> Xing Li
> 
> 
> 
>

--------------000507050204010600040206-- From brian.e.carpenter@gmail.com Wed Jul 27 19:56:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646C521F8A7E for ; Wed, 27 Jul 2011 19:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.602 X-Spam-Level: X-Spam-Status: No, score=-103.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBIOGuM9695W for ; Wed, 27 Jul 2011 19:56:01 -0700 (PDT) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCDF21F8A70 for ; Wed, 27 Jul 2011 19:56:01 -0700 (PDT) Received: by vws18 with SMTP id 18so3107914vws.27 for ; Wed, 27 Jul 2011 19:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=a1FNtL7sGizSRk0etgLHEBrWMGeY1+jlzAs7lUfQ9U4=; b=X1o2dKqfB6DrOBtnXE3FJvyHq92LE8EDeNLmZSehk2oJfE16adm7bmNZ0WzI5IwA73 ymJ2Afs3xTNlSrd0O3Y4jKMkbaPaUwce3KFwSHRDY5iMy2Ff4bs5GhZvxMI1tEFFhGBz P9Jwe/JrRm77jEF7Mf24qQGDMTb2Yt3jaYWdU= Received: by 10.52.68.171 with SMTP id x11mr511764vdt.406.1311821756206; Wed, 27 Jul 2011 19:55:56 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id ed4sm300956vdb.21.2011.07.27.19.55.54 (version=SSLv3 cipher=OTHER); Wed, 27 Jul 2011 19:55:55 -0700 (PDT) Message-ID: <4E30CFBB.1050809@gmail.com> Date: Thu, 28 Jul 2011 14:55:55 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: rick@openfortress.nl References: <20110725120140.30929.29211.idtracker@ietfa.amsl.com> In-Reply-To: <20110725120140.30929.29211.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vanrein-v6ops-6bed4-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 02:56:02 -0000 Rick, Somebody suggested Teredo instead. The problem with Teredo is that it uses a generic prefix and an anycast IPv4 address. Thus it has some operational problems (less serious than 6to4, but still...). A variant of Teredo that can use a provider-specific prefix and a unicast IPv4 address would surely do for the embedded systems market. But we haven't found enough interest in the IETF for that approach. See draft-carpenter-softwire-sample-00.txt, draft-lee-softwire-6rd-udp-02.txt and draft-despres-6a44-00.txt for the historic trail. Regards Brian Carpenter On 2011-07-26 00:01, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : IPv6 Tunneling for Embedded Systems (6bed4) > Author(s) : Rick van Rein > Filename : draft-vanrein-v6ops-6bed4-00.txt > Pages : 17 > Date : 2011-07-25 > > Given the limited resources available to a lot of embedded systems, > dual-stack solutions are not always feasible for such hosts. A > mechanism that supports a direct transition from IPv4-only to > IPv6-only may prove beneficial in getting the smallest hosts to make > a transition to IPv6 at a much earlier stage than would otherwise be > possible. This calls for tunnels, but no current tunnel technique > appears to be optimal for embedded systems. > > This specification details an IPv6 tunneling technique over UDP and > IPv4. The technique is specifically designed to benefit embedded > systems, and to work without end user configuration. The working > principle for obtaining a routable IPv6 address is through stateless > autoconfiguration from an anycast tunnel service. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-vanrein-v6ops-6bed4-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-vanrein-v6ops-6bed4-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From warren@kumari.net Wed Jul 27 20:03:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3634921F8B6F for ; Wed, 27 Jul 2011 20:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.601 X-Spam-Level: X-Spam-Status: No, score=-101.601 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep4PSys72WQd for ; Wed, 27 Jul 2011 20:03:26 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id BABE121F8B6C for ; Wed, 27 Jul 2011 20:03:26 -0700 (PDT) Received: from [192.168.1.6] (dhcp-46bc.meeting.ietf.org [130.129.70.188]) by vimes.kumari.net (Postfix) with ESMTPSA id DB2D71B404F8; Wed, 27 Jul 2011 23:03:25 -0400 (EDT) References: <987EEA6D-59F9-4D6F-9FFE-6DD2DE3C71D1@cisco.com> In-Reply-To: <987EEA6D-59F9-4D6F-9FFE-6DD2DE3C71D1@cisco.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8C148) From: Warren Kumari Date: Wed, 27 Jul 2011 23:03:13 -0400 To: Fred Baker Cc: IPv6 Operations Subject: Re: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 03:03:27 -0000 Warren Kumari ------ Please excuse typing, etc -- This was sent from a device with a tiny keyboar= d. On Jul 27, 2011, at 5:31 PM, Fred Baker wrote: > Given the growth of drafts in v6ops, Joel and I are forever trying to figu= re out how to make our lives a little simpler. I'm thinking about an interim= meeting, in which we would discuss drafts that have been updated or posted n= o later than a week in advance and for which interest has materialized on th= e mailing list. >=20 > Are folks interested in having such a meeting? Yes. >=20 > What drafts do folks specifically feel would benefit from review then? I'm= thinking about our working group drafts (draft-ietf-v6ops-6to4-to-historic,= draft-ietf-v6ops-happy-eyeballs, draft-ietf-v6ops-ipv6-cpe-router-bis, draf= t-ietf-v6ops-v6-aaaa-whitelisting-implications) and other drafts that are of= prime interest. >=20 Whatever the chairs feel are the ones that should be discussed (yes, I purpo= sefully didn't answer...) > Note to authors/editors of drafts: regardless of whether we're talking abo= ut interim or f2f meetings, I will (well, my bot will) post a note inviting c= omment when there is a new -00 draft, but after that I am depending on you t= o discuss the issues of your drafts on the list. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From pch-b2B3A6689@u-1.phicoh.com Thu Jul 28 01:08:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FF721F8B9D; Thu, 28 Jul 2011 01:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.558 X-Spam-Level: X-Spam-Status: No, score=-4.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wIu+WQlDvGu; Thu, 28 Jul 2011 01:08:18 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 848C521F8B98; Thu, 28 Jul 2011 01:08:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QmLdc-0001mlC; Thu, 28 Jul 2011 10:08:12 +0200 Message-Id: To: james woodyatt From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Wed, 27 Jul 2011 21:56:51 -0400 ." <2D290C0C-E845-42EF-9690-D92D3D86641C@apple.com> Date: Thu, 28 Jul 2011 10:08:11 +0200 Cc: IPv6 Operations , "ietf@ietf.org Discussion" Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 08:08:18 -0000 In your letter dated Wed, 27 Jul 2011 21:56:51 -0400 you wrote: > In the absence of a coherent instruction from IETF for a phase-out > plan, declaring this protocol historic under the current proposed > language, will do precisely that. Please please please, if IETF > wants 6to4 to die, then publish a phase-out plan so that the > current users of 6to4 can have fair warning before the relays go > dark and forthcoming hardware/software upgrades rip the feature > out from under them. I would hope that big companies like Apple would actually do an impact analysis before removing a feature. Big content providers can measure how much 6to4 is enabled, so they can probably say something about trends. But that doesn't say much about how many users actually care about 6to4. Vendors seem to be best equiped to analyse the users' need for 6to4. I don't think relay operators have expressed a desire for a specific cut off date. So I guess they just figure out for themselves when to switch off the relays. From jeroen@unfix.org Thu Jul 28 01:39:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725BD21F8B40 for ; Thu, 28 Jul 2011 01:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEkAXgSBYlrl for ; Thu, 28 Jul 2011 01:39:13 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 7A15221F8AE1 for ; Thu, 28 Jul 2011 01:39:13 -0700 (PDT) Received: from yomi.ch.unfix.org (yomi.ch.unfix.org [IPv6:2001:41e0:ff42:99:ca2a:14ff:fe1f:2b7b]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id ECB46801C2BF; Thu, 28 Jul 2011 10:39:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1311842350; bh=u5q4j4VesCjT8iglS/KL3QTpPO9PRQHhyxKcAOREbg8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=e1dwoOElBv9cTBpVFeNCUimCBvaqQ9T7W2E1ev7bFw1x2AAi4IqwVn9q7srl67o8r 4+1rGORS192JnJUTPf8s5x6lhg1fvQoJQV7Sr+ZIKPJ8Y+quxNjhTrzYgt0KHaM4n4 n3kvtAJvsAnUjZP/Hc53Wlmk3SqXKPyxJRFseC3oNikHRh9ziA51Myinhh7nCssKMi LlR6Xy2uvXwGxgbDpoVq6OvC9srrVSCtc3jkFlPNIJwVDzb7ruW3POlm63/4p6X4kR 4/04YP5i7n/sN63ZWlC3DUhGnXdYGFynB4HA43ewr5nVTjmw2ikphwsutirAr7OpaX GbtKQ7h9VEW8g== Message-ID: <4E31202E.40605@unfix.org> Date: Thu, 28 Jul 2011 10:39:10 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Brian E Carpenter References: <20110725120140.30929.29211.idtracker@ietfa.amsl.com> <4E30CFBB.1050809@gmail.com> In-Reply-To: <4E30CFBB.1050809@gmail.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vanrein-v6ops-6bed4-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 08:39:14 -0000 On 2011-07-28 04:55 , Brian E Carpenter wrote: > Rick, > > Somebody suggested Teredo instead. The problem with Teredo is that it > uses a generic prefix and an anycast IPv4 address. Thus it has some > operational problems (less serious than 6to4, but still...). > > A variant of Teredo that can use a provider-specific prefix and a > unicast IPv4 address would surely do for the embedded systems market. > But we haven't found enough interest in the IETF for that approach. For those there is already TSP, which is already an RFC, AYIYA which I might be redoing the draft for in a few weeks. Greets, Jeroen From rick@openfortress.nl Thu Jul 28 01:57:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF33421F8B84 for ; Thu, 28 Jul 2011 01:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8D2Otd4DPeF for ; Thu, 28 Jul 2011 01:57:03 -0700 (PDT) Received: from fame.vanrein.org (openfortress.nl [213.189.19.244]) by ietfa.amsl.com (Postfix) with ESMTP id C42E321F8B8E for ; Thu, 28 Jul 2011 01:57:02 -0700 (PDT) Received: from phantom.vanrein.org (phantom.vanrein.org [83.163.207.110]) by fame.vanrein.org (Postfix) with ESMTP id BC0994040CD; Thu, 28 Jul 2011 09:56:59 +0100 (BST) Received: by phantom.vanrein.org (Postfix, from userid 1000) id B5AFF940B1; Thu, 28 Jul 2011 08:56:58 +0000 (CEST) Date: Thu, 28 Jul 2011 08:56:58 +0000 From: Rick van Rein To: Jeroen Massar Message-ID: <20110728085658.GC21519@phantom.vanrein.org> References: <20110727114038.GE7494@phantom.vanrein.org> <4E30005A.8080205@unfix.org> <20110727125114.GA1237@phantom.vanrein.org> <4E30207A.5080500@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E30207A.5080500@unfix.org> X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM User-Agent: Mutt/1.5.11 Cc: v6ops@ietf.org Subject: Re: [v6ops] slight comments on draft-vanrein-v6ops-6bed4-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 08:57:04 -0000 Hi, > > Teredo does not keep the address space transparent; peer-to-peer > > connectivity is just as much a problem with Teredo as with IPv4. > > Can you elaborate on what you actually mean with this and what the > problems are? Especially how you try to resolve them with your proposal? 1. Personal experience with Teredo: ping time variations, failure to route to certain IPv6 ranges. 2. Teredo is not a general solution -- and it won't help the SIP wish that I am developing for. From RFC 4380 section 8.3: - Teredo service will not work through NATs of the symmetric variety. - Teredo introduces jitter into the IPv6 service it provides, due to the queuing of packets while bubble exchanges take place. This jitter can negatively impact applications, particularly latency sensitive ones, such as Voice over IP (VoIP). If you are saying that I over-generalised by speaking of "embedded systems" instead of a tighter area, and that Teredo may work for certain embedded systems then I agree. But specifically for SIP, I still have not found an existing zeroconfig tunnel service that can do the job. > Where exactly does a "RTP proxy" come into play unless you are > translating from IPv4 to IPv6 and vice versa? I did make a translator between SIP over IPv4 and SIP over IPv6, but that is not what I meant. (Link: http://devel.0cpm.org/sipproxy64/) An RTP proxy is needed as a general solution to connect phones behind NAT. To open a hole for RTP in a firewall, traffic must be sent out. At that point, the address translation is also set. The same applies to the other side, so neither can start the transmission as the remote address is not known. This is specifically a problem to symmetric NAT, which means that to be general you will need a server at a fixed IP that bounces RTP back and forth, known as an RTP proxy. Needing an RTP proxy means to most users that they become dependent on service providers, who prefer to sell you bit-stuffed POTS connections. If you don't need an RTP proxy, you can embrace Internet-style schemes for locating phones: ENUM, freenum.org, sip:bakker@orvelte.nep > Are you talking about "embedded devices" as in "8kb memory" or "embedded > devices" which are actually full blown Linux boxes? Sort of in between -- 128-ish kB RAM. > For instance the Gigaset S675IP and related boxes running their Chagall > firmware are a good example [...] Indeed. But there are also examples that do cannot run fullblown Linux but that do networking. I am getting a simple SIP app running in about 64 kB of code, and a few kB of RAM. With IPv6 on any network, thanks to 6bed4. IPv6 may turn out to be a way to rely on cheaper hardware ;-) > You stated 'embedded' and thus I think of 8kB memory and low-resources > available. If you have resources then doing any of the currently > available tunneling protocols should work like a charm. I investigated every single tunnel that I could find, but none works for the application area I have in mind. One thing I wish to avoid is asking end users to configure accounts. > It completely depends on what your deployment model is though and the > actual problems you are trying to solve. SIP telephony, IPv6-only, no end user configuration of IPv6. > Your requirements section just lists the features that your protocol > has, not why that requirement is important for you to solve and for what > purposes. Ah, hence the quotes around 'requirements'. Fair enough, although the requirements really did come up as requirements. I hope the above helps. I am thinking that the requirements might be better dropped from the draft, but felt a need to describe, in general terms, what I was looking for and why yet another tunnel was IMHO needed. I am starting to feel that it might be better to just stick to the technology. > Another option is to do what we call pre-configured AYIYA tunnels. In > the cases where we deployed these they where vendor-bound though and > thus effectively took care of the problem of getting IPv6 packets to the > vendors servers, thus avoiding the need for IPv4 as everything was just > IPv6 (except for the tunnel). Is there a place where I can read more about pre-configured AYIYA? Neither Ecosia nor Google has heard of it. Could such a setup be pre-configured into a device and then shipped off to customers, and could that not lead to non-local tunnel service and potential abuse of an account? > As they all simply use NAT-PMP/uPNP to overcome the issue of IPv4 NAT. > That only works with a single layer of NAT but that is what is generally > the case. Need to dig more into this. Not sure why I don't see phones and SIP providers relying on this (for their RTP connections). > See the above vendor-specific AYIYA support. That works like a charm. Could pre-configured AYIYA be part of the open source SIP firmware for IPv6-only that I am developing? And could it be configured into the Java applet that we are maing to connect IPv6-only from an IPv4-only browser environment? Best wishes, -Rick From rick@openfortress.nl Thu Jul 28 01:58:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA38B21F8C60 for ; Thu, 28 Jul 2011 01:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKvX2HaD5ToF for ; Thu, 28 Jul 2011 01:58:27 -0700 (PDT) Received: from fame.vanrein.org (openfortress.nl [213.189.19.244]) by ietfa.amsl.com (Postfix) with ESMTP id 7F79621F8B84 for ; Thu, 28 Jul 2011 01:58:27 -0700 (PDT) Received: from phantom.vanrein.org (phantom.vanrein.org [83.163.207.110]) by fame.vanrein.org (Postfix) with ESMTP id E1F044040CD; Thu, 28 Jul 2011 09:58:25 +0100 (BST) Received: by phantom.vanrein.org (Postfix, from userid 1000) id 0FBD6940B1; Thu, 28 Jul 2011 08:58:25 +0000 (CEST) Date: Thu, 28 Jul 2011 08:58:24 +0000 From: Rick van Rein To: Washam Fan Message-ID: <20110728085824.GD21519@phantom.vanrein.org> References: <20110727114038.GE7494@phantom.vanrein.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM User-Agent: Mutt/1.5.11 Cc: v6ops@ietf.org Subject: Re: [v6ops] slight comments on draft-vanrein-v6ops-6bed4-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 08:58:28 -0000 Hello, > I was referring to section 4.3. it seems to me all internal ipv6 > traffic U-turn the tunnel server. How about 'direct' tunnelled between > 2 embeded hosts without going thru the tunnel server? if it is > applicable, it would mitigate the burden of the server and the > possibility of a single point failure. Jeroen also raised this, and I have overlooked it in the tunnel design. I will need to think it over. It is a very good point. -Rick From rick@openfortress.nl Thu Jul 28 02:04:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5846321F8C4F for ; Thu, 28 Jul 2011 02:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClLJdpDJnqhP for ; Thu, 28 Jul 2011 02:04:41 -0700 (PDT) Received: from fame.vanrein.org (openfortress.nl [213.189.19.244]) by ietfa.amsl.com (Postfix) with ESMTP id CD3BF21F8C48 for ; Thu, 28 Jul 2011 02:04:40 -0700 (PDT) Received: from phantom.vanrein.org (phantom.vanrein.org [83.163.207.110]) by fame.vanrein.org (Postfix) with ESMTP id 36CAA4040CD; Thu, 28 Jul 2011 10:04:39 +0100 (BST) Received: by phantom.vanrein.org (Postfix, from userid 1000) id 25317940B1; Thu, 28 Jul 2011 09:04:38 +0000 (CEST) Date: Thu, 28 Jul 2011 09:04:38 +0000 From: Rick van Rein To: Jeroen Massar Message-ID: <20110728090438.GE21519@phantom.vanrein.org> References: <20110725120140.30929.29211.idtracker@ietfa.amsl.com> <4E30CFBB.1050809@gmail.com> <4E31202E.40605@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E31202E.40605@unfix.org> X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM User-Agent: Mutt/1.5.11 Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vanrein-v6ops-6bed4-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 09:04:41 -0000 Hi, > > A variant of Teredo that can use a provider-specific prefix and a > > unicast IPv4 address would surely do for the embedded systems market. > > But we haven't found enough interest in the IETF for that approach. > > For those there is already TSP, which is already an RFC, AYIYA which I > might be redoing the draft for in a few weeks. TSP has a number of problems: * There is no open source server-side implementation; I started one, but moved over to 6bed4 because of the following shortcomings. * Existing client implementations do not work according to the RFCs. * Correcting those clients demonstrated that the available servers won't accept RFC-compliant traffic. -Rick From jeroen@unfix.org Thu Jul 28 02:12:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47FF21F8C41; Thu, 28 Jul 2011 02:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnK4QTv95XqS; Thu, 28 Jul 2011 02:12:42 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 125EE21F8AE9; Thu, 28 Jul 2011 02:12:41 -0700 (PDT) Received: from yomi.ch.unfix.org (223-95.60-188.cust.bluewin.ch [188.60.95.223]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id E91F4801C2BF; Thu, 28 Jul 2011 11:12:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1311844357; bh=JkSTCVhxy50/bL2QgF/S7YbegE+aPMoVd3F1oTnDFEA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=UzCVdcmVTR6Y2emlvpe0VgUOJCXG44Zyx0mSZyx+cDoWlHvA1uNBr3PQGfG8WG67q w8LmJ9qE3CsbIoX8qmP/4fN7FjaGSArnhYjmhgl9Fk01GN6TdH8z3YiIFNy5yBGjrW 8xmdoq7aL+AHlaYlLb84/1sDxky6UbMjGqx8LwiG/wBmyseqOyvcGB2bkSqPZXIGRm m67pRX18eMAIwtCgiC+nVhwxR+AHspW4luifap0mkHK+TdBX3pq0bhChq0bbV2UpRA 7o8mr7kLUMny0uiE/gU2ppUUJTZbwCFPLaQiryZZHSHZvYTC6m2lmEUdVPVMA01qiR KoVqgHl2GGmtA== Message-ID: <4E3127F1.2030708@unfix.org> Date: Thu, 28 Jul 2011 11:12:17 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Andrews References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> <20110727151517.CF9371235D70@drugs.dv.isc.org> <999C3229-649D-4242-BB0F-2BB494EDF1D9@network-heretics.com> <4E305E3E.2040607@unfix.org> <20110727233634.406021238970@drugs.dv.isc.org> In-Reply-To: <20110727233634.406021238970@drugs.dv.isc.org> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Keith Moore , IETF Discussion Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 09:12:43 -0000 On 2011-07-28 01:36 , Mark Andrews wrote: [..] > Is there *one* tunnel management protocol that they all support or > does a cpe vendor have to implement multiple ones to reach them > all? I'm pretty sure I know the answer to this question but I'd > love to be proved wrong. There is no 'one' solution to the problems that they are solving. As such there tend to be a combo of: - static proto-41 tunnel - 6to4 - 6rd - TSP => dynamic NATted addresses - proto-41 + heartbeat + TIC => dynamic public addresses - AYIYA + TIC => dynamic NATted addresses TSP conveys configurartion information inline with the UDP packets. TIC is solely for configuration information and does not do tunneling but can be used for all proto-41/heartbeat/AYIYA protocols (and for instance AVM chose to only do proto-41 + heartbeat as their devices always have public IPv4 IPs). Teredo is only for a single host thus is not useful for CPEs and thus not included in them. > One of the advantages of 6to4 anycast is that it is just needs a > check box to turn on and off. Everybody speaks the same thing. Except that it does not work behind a NAT and most people do sit behind a NAT. Next to that those anycasts are even rarer around the world and on top of that it is hard to figure out issues when they are there (although some people have tricks to apparently debug them, the anycast on both IPv4 and IPv6 requires one to contact a lot of folks). The big advantage over a known tunnel endpoint is the known behavior of that endpoint and the simple way of complaining when something is broken. And people fortunately do complain when stuff is broken, unfortunately not always with the proper details though, but I am to blame for not finishing that program up... > Another advantage of 6to4 is it doesn't require manual intervention > on renumber events. Manual tunnel don't pass muster. I guess you are one of the lucky people to get a public static IPv4 address prefix at home that never renumbers? Guess what, most of the world does not have that luxury, they get 1 dynamic address and for instance in Germany they get a disconnect/force-renumber every 24 hours (according to the ISPs because of 'accounting' reasons...) Do realize that when you have that public IPv4 address, when it changes you are renumbering your 2002:::/48 prefix everywhere. Fun... (I hope you also like asking 6to4.nro.net everytime to change your reverse) The tunnels above all have ISP-supplied prefixes and tend to be static (I think TSP anonymous tunnels rotate addresses, but the majority just keeps on returning the same static allocation, in the case of SixXS you really get a fixed address, much easier on the PoP side and we can do whois and store it in the relevant RIR registry) > Another advantage of 6to4 is you don't have to register. For most of > the tunnel brokers you have to register. I guess you also where able to anonymously sign up to your IPv4 ISP!? :) Especially that static IPv4 address must be wonderful to get that way. Note that Freenet6 offers 'anonymous' tunnels, thus that is just a TSP away. Something with the amounts of abuse made us (SixXS) require that we require valid address data. Next to that it is a RIPE requirement to register /48 prefixes. Other Tunnelbrokers just started blocking things like IRC and NNTP because there was too much abuse or traffic.... We kill off accounts of people when they abuse, google my name and you will find various people who where caught in the act and are quite mad that they can't have funny vhosts on IRC anymore and attract 500mbit DoSses and other such nonsense which are not the goal of providing IPv6. Also, the registration means that people can just type in their username/password (and optionally which tunnel they want to use out of the multiple tunnels they might have) in their CPE and the CPE then uses TIC or TSP to fetch this configuration and set it all up, and it will just work(tm). As a nice example see http://www.sixxs.net/wiki/images/FritzboxHowto.jpg and http://www.sixxs.net/wiki/Fritz!Box_7270 Next to that knowing where the user is and more importantly their endpoint allows one to select a proper PoP for that user close to their endpoint causing low latency and generally high throughput. With anycast you are just hoping that that all will work. Greets, Jeroen From pch-b2B3A6689@u-1.phicoh.com Thu Jul 28 02:14:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AC521F8C57 for ; Thu, 28 Jul 2011 02:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKu6KL0HzV-p for ; Thu, 28 Jul 2011 02:14:05 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE3621F8C52 for ; Thu, 28 Jul 2011 02:14:05 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QmMfB-0001iVC; Thu, 28 Jul 2011 11:13:53 +0200 Message-Id: To: Rick van Rein From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <20110725120140.30929.29211.idtracker@ietfa.amsl.com> <4E30CFBB.1050809@gmail.com> <4E31202E.40605@unfix.org> <20110728090438.GE21519@phantom.vanrein.org> In-reply-to: Your message of "Thu, 28 Jul 2011 09:04:38 +0000 ." <20110728090438.GE21519@phantom.vanrein.org> Date: Thu, 28 Jul 2011 11:13:44 +0200 Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vanrein-v6ops-6bed4-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 09:14:06 -0000 Maybe I am missing something, but this protocol sounds a lot like 6to4 but then on top of udp instead of protocol 41. From jeroen@unfix.org Thu Jul 28 02:17:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7490D21F8C70 for ; Thu, 28 Jul 2011 02:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IoH8OvyyFoA for ; Thu, 28 Jul 2011 02:17:56 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id B41BB21F8C71 for ; Thu, 28 Jul 2011 02:17:55 -0700 (PDT) Received: from yomi.ch.unfix.org (223-95.60-188.cust.bluewin.ch [188.60.95.223]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 31B10801C2BF; Thu, 28 Jul 2011 11:17:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1311844673; bh=w8Vc8pSL2j1VTan4PHbjSZQpNAf+cREy9PYwjIPffrE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=C2Jm7k3bLshclow2BHQzxqNJ53qaEMJRcqaT7wsJKv2IgIiB0XR25AqZ4Tg/kAk1r 9zP5LLMbYz6WevUfjeMzr7cNrIZndJVr5roWqxZYTe4IABWmGqxmjgR8xoMOJQMKDo SRt/C8S17UVLmIQ8kotJknFTgup4VAwvEq2myoRe4btp993jVN0Uupa4Usvm6hOlAA aHzTWjdKBPWXGw0RowovJ+V8cFIVOCdTW7dqBtzekqmkLedBW1QcQiUOMHziflv1FC Bi/RuTTuARhbj5ndcYluAlHx/frS4tVCV94wR/WJ819wzbUKyNL6ilwjTkEaPREnvs dCi9+rhq1NjmA== Message-ID: <4E312933.3020508@unfix.org> Date: Thu, 28 Jul 2011 11:17:39 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Rick van Rein References: <20110725120140.30929.29211.idtracker@ietfa.amsl.com> <4E30CFBB.1050809@gmail.com> <4E31202E.40605@unfix.org> <20110728090438.GE21519@phantom.vanrein.org> In-Reply-To: <20110728090438.GE21519@phantom.vanrein.org> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vanrein-v6ops-6bed4-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 09:17:57 -0000 On 2011-07-28 11:04 , Rick van Rein wrote: > Hi, > >>> A variant of Teredo that can use a provider-specific prefix and a >>> unicast IPv4 address would surely do for the embedded systems market. >>> But we haven't found enough interest in the IETF for that approach. >> >> For those there is already TSP, which is already an RFC, AYIYA which I >> might be redoing the draft for in a few weeks. > > TSP has a number of problems: > > * There is no open source server-side implementation; That is really the problem of the person who wants to build it. There are multiple implementations in use. > I started one, but moved over to 6bed4 because of the following shortcomings. > > * Existing client implementations do not work according to the RFCs. > > * Correcting those clients demonstrated that the available servers > won't accept RFC-compliant traffic. Maybe you should contact the programmers of the client and the operators of the service about this? There must be a reason why they are different. IPv6.org.sa / CITC apparently did their own implementation[1] of the server side based on the RFCs and the standard gogo6 client works for them... so are you sure you did not do something wrong? They also state in those slides that they might open source the thing. Greets, Jeroen [1] Google docs/cache URL as their website is unreachable for me a google(www.ipv6.org.sa) pops it up https://docs.google.com/viewer?a=v&q=cache:iSgSvLpRDk8J:www.ipv6.org.sa/sites/default/files/CITC%2520IPv6%2520Tunnel%2520Broker%2520-%2520CITC.pdf+%22www.ipv6.org.sa%22&hl=en&gl=ch&pid=bl&srcid=ADGEEShkmEVwfkVJPXHgGkNjb1EavvadxA7C6RmkqCSm95ovr5oK-Cdyql6i0WsOOk024dJhFJSgWhVJ8kraB8WGpRdeffavGCKtHJ9BppZm9ajmHA_4x6PfSW8hOd7N-TIuc_mjPZkv&sig=AHIEtbTllhdinArwegu8bKsd1F2iAwJr0w From jeroen@unfix.org Thu Jul 28 02:32:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069BD21F8BB8 for ; Thu, 28 Jul 2011 02:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmmiJHn0ZU5y for ; Thu, 28 Jul 2011 02:32:21 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 92B3F21F8B90 for ; Thu, 28 Jul 2011 02:32:20 -0700 (PDT) Received: from yomi.ch.unfix.org (223-95.60-188.cust.bluewin.ch [188.60.95.223]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id A9D21801C2BF; Thu, 28 Jul 2011 11:32:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1311845536; bh=3lefAoZFCAajMezhyLXSWtgGNnB0ZN+sGsaQlkzpJoo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YurfaeTR9lHkcsomfqG8HXATTmQCQ2p1f++UvHDEUQxLO6kzPVnFYQ86DmXdqexH5 uJQ7whfxpkjpBqWtXBHjRDSYEkcqIwAIm5yNUIcGi+AfJYTTyxPeUgVsqwRNoEZP7R PZQ45e5EKo4WuMIGoDMmWSgKqxF8b/KuwfT8MzJJmK3h0ue2Um/xZCLwg6nv2KqPOv 5gD6P8Qc4g64oMBwVABJ1nv4DHGgQjOGB3Qztm1Xcyt5qV731T3zH6tlEYzA6gqLvD w/FtPCqmSCt/i6wjxiN/eJAEbkD4CeK9AlI/bS4YhAEL4exFxqCc7B1xZMe+AEScmS bOjrATwkaOlAw== Message-ID: <4E312C97.2020208@unfix.org> Date: Thu, 28 Jul 2011 11:32:07 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Rick van Rein References: <20110727114038.GE7494@phantom.vanrein.org> <4E30005A.8080205@unfix.org> <20110727125114.GA1237@phantom.vanrein.org> <4E30207A.5080500@unfix.org> <20110728085658.GC21519@phantom.vanrein.org> In-Reply-To: <20110728085658.GC21519@phantom.vanrein.org> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] slight comments on draft-vanrein-v6ops-6bed4-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 09:32:22 -0000 On 2011-07-28 10:56 , Rick van Rein wrote: > Hi, > >>> Teredo does not keep the address space transparent; peer-to-peer >>> connectivity is just as much a problem with Teredo as with IPv4. >> >> Can you elaborate on what you actually mean with this and what the >> problems are? Especially how you try to resolve them with your proposal? > > 1. Personal experience with Teredo: ping time variations, failure > to route to certain IPv6 ranges. That is because you are using a service of which you don't know where it is (and anycast on both IPv4 and IPv6 means you will have routing difference/guesses in both IPv4 and IPv6) and maybe that the service provider has some bad/missing routes. Like every other thing you will have to contact the operator to resolve these. Which is tough as you can't directly see where the traffic is flowing over IPv4+IPv6 and maybe it is the route back that is the problem. > 2. Teredo is not a general solution -- and it won't help the SIP > wish that I am developing for. From RFC 4380 section 8.3: > > - Teredo service will not work through NATs of the symmetric variety. Which apparently is only a couple of percent of the internet. > - Teredo introduces jitter into the IPv6 service it provides, due to > the queuing of packets while bubble exchanges take place. This > jitter can negatively impact applications, particularly latency > sensitive ones, such as Voice over IP (VoIP). Those bubbles are only sent at the beginning after that rarely and should not impact your RTP streams too much. > But specifically for SIP, I still have not found an existing zeroconfig > tunnel service that can do the job. SIP should do fine, RTP is what you mean. As for Zeroconfig, well TSP can do the trick for that as Gogo6 does anonymous tunnels. >> Where exactly does a "RTP proxy" come into play unless you are >> translating from IPv4 to IPv6 and vice versa? > > I did make a translator between SIP over IPv4 and SIP over IPv6, but that > is not what I meant. (Link: http://devel.0cpm.org/sipproxy64/) > > An RTP proxy is needed as a general solution to connect phones behind > NAT. To open a hole for RTP in a firewall, traffic must be sent out. > At that point, the address translation is also set. The same applies > to the other side, so neither can start the transmission as the remote > address is not known. This is specifically a problem to symmetric > NAT, which means that to be general you will need a server at a fixed > IP that bounces RTP back and forth, known as an RTP proxy. Ever heard of this awesome protocol called STUN which where made by the IETF for this? And TURN and then we have NAT-PMP and uPNP which is implemented in almost any CPE. > Needing an RTP proxy means to most users that they become dependent on > service providers, who prefer to sell you bit-stuffed POTS connections. > If you don't need an RTP proxy, you can embrace Internet-style schemes > for locating phones: ENUM, freenum.org, sip:bakker@orvelte.nep The solution to your problem is: - get a public IPv4/IPv6 address - done I don't see end-user without technical knowhow do this kind of setup, generally they want [..] > I investigated every single tunnel that I could find, but none works > for the application area I have in mind. One thing I wish to avoid > is asking end users to configure accounts. TSP anonymous does not do that. But the fun thing is instead of asking people to create accounts you ask ISPs soon to all start adding your new thing which does not add anything new? :) (And creating a security nightmare...) >> It completely depends on what your deployment model is though and the >> actual problems you are trying to solve. > > SIP telephony, IPv6-only, no end user configuration of IPv6. Upgrade CPE to one which supports IPv6 (be it native or tunneling), presto. The user will upgrade to IPv6 at one point or another anyway. > Is there a place where I can read more about pre-configured AYIYA? > Neither Ecosia nor Google has heard of it. AYIYA is just the tunnel protocol. Pre-configured means that one can skip the TIC step as the parameters are already present that TIC would otherwise fetch. > Could such a setup be pre-configured into a device and then shipped > off to customers, and could that not lead to non-local tunnel service > and potential abuse of an account? If people are able to get into the firmware and figure out the AYIYA password, then yes of course they can then use that tunnel for other purposes than intended. But as it is known where that account is disabling it is also very easy. >> As they all simply use NAT-PMP/uPNP to overcome the issue of IPv4 NAT. >> That only works with a single layer of NAT but that is what is generally >> the case. > > Need to dig more into this. Not sure why I don't see phones and > SIP providers relying on this (for their RTP connections). Gigaset understands this really well ;) http://s-a.no/tmp/GizmoGigaset.gif for a little screenshot (googleimages(gigaset STUN)) And I expect most other providers to do the same. And they could easily do a "dear NAT-PMP/uPNP" please forward all port 5060 packets to me and then also be a full blown SIP server. >> See the above vendor-specific AYIYA support. That works like a charm. > > Could pre-configured AYIYA be part of the open source SIP firmware > for IPv6-only that I am developing? And could it be configured into the > Java applet that we are maing to connect IPv6-only from an IPv4-only > browser environment? As it is a protocol you can develop it in any language that you like. I don't really see how you can mix embedded and Java and low latency in the same message though.... Greets, Jeroen From moore@network-heretics.com Thu Jul 28 05:48:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8526621F8C66 for ; Thu, 28 Jul 2011 05:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.686 X-Spam-Level: X-Spam-Status: No, score=-3.686 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6Mv6fG+4yEL for ; Thu, 28 Jul 2011 05:48:47 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id E115821F8C65 for ; Thu, 28 Jul 2011 05:48:46 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 94263203CD; Thu, 28 Jul 2011 08:48:46 -0400 (EDT) Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 28 Jul 2011 08:48:46 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=references:in-reply-to:mime-version :content-type:content-transfer-encoding:subject:from:date:to:cc :message-id; s=smtpout; bh=KseEu9k5EULXTdYXsgkrVt822WA=; b=JvnW6 ssHg0vqt/lI3IoVcpW/xvuq57kT6EBLqmhwDL8IsRjCYxJZY/qUvFdDZv+R9M39i +TPyzWDi8gTnC2EZJiYj0f8FAuhfsMFeWzPJVmx9KnVsju8kOQT7dVmBC5TzQJI+ wbkKTZcOlVKHPUCcmEo0cpXGFadzOUTiwKZrLY= X-Sasl-enc: TTekL4R0FYDJORuk/73hZq0L7ywBGZzWKaRTlL6sYTCH 1311857326 Received: from dhcp-12c6.meeting.ietf.org (dhcp-12c6.meeting.ietf.org [130.129.18.198]) by mail.messagingengine.com (Postfix) with ESMTPSA id 3790E414A5F; Thu, 28 Jul 2011 08:48:45 -0400 (EDT) References: <20110725120140.30929.29211.idtracker@ietfa.amsl.com> <4E30CFBB.1050809@gmail.com> User-Agent: K-9 Mail for Android In-Reply-To: <4E30CFBB.1050809@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Keith Moore Date: Thu, 28 Jul 2011 08:48:40 -0400 To: Brian E Carpenter ,rick@openfortress.nl Message-ID: Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vanrein-v6ops-6bed4-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 12:48:47 -0000 Brian E Carpenter wrote: >Rick, > >Somebody suggested Teredo instead. The problem with Teredo is that it >uses a generic prefix and an anycast IPv4 address. Thus it has some >operational problems (less serious than 6to4, but still...). I am not sure that Teredo has less serious operational problems than 6to4, or whether Teredo's problems have often been masked by the preference of 6to4 over Teredo in hosts that implement both. I keep hearing that Teredo performs significantly worse than 6to4. (Though perhaps not for a provider managed Teredo variant like you have proposed.) Keith -- Sent from my Android tablet with K-9 Mail. From joelja@bogus.com Thu Jul 28 06:04:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E932B21F8C94 for ; Thu, 28 Jul 2011 06:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.047 X-Spam-Level: X-Spam-Status: No, score=-102.047 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E55JLwTFoHoT for ; Thu, 28 Jul 2011 06:04:12 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6486B21F8C90 for ; Thu, 28 Jul 2011 06:04:12 -0700 (PDT) Received: from dhcp-677d.meeting.ietf.org (dhcp-677d.meeting.ietf.org [130.129.103.125]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6SD46Mu014267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2011 13:04:08 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Thu, 28 Jul 2011 09:04:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110725120140.30929.29211.idtracker@ietfa.amsl.com> <4E30CFBB.1050809@gmail.com> To: Keith Moore X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 28 Jul 2011 13:04:08 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vanrein-v6ops-6bed4-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 13:04:13 -0000 If you'd like to have a really slow, fairly unreliable experience teredo = is a pretty good choice. On Jul 28, 2011, at 8:48 AM, Keith Moore wrote: >=20 >=20 > Brian E Carpenter wrote: >=20 >> Rick, >>=20 >> Somebody suggested Teredo instead. The problem with Teredo is that it >> uses a generic prefix and an anycast IPv4 address. Thus it has some >> operational problems (less serious than 6to4, but still...). >=20 > I am not sure that Teredo has less serious operational problems than = 6to4, or whether Teredo's problems have often been masked by the = preference of 6to4 over Teredo in hosts that implement both. I keep = hearing that Teredo performs significantly worse than 6to4. (Though = perhaps not for a provider managed Teredo variant like you have = proposed.) >=20 > Keith >=20 > --=20 > Sent from my Android tablet with K-9 Mail.=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From jason_livingood@cable.comcast.com Thu Jul 28 06:29:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056CC21F8C44 for ; Thu, 28 Jul 2011 06:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.849 X-Spam-Level: X-Spam-Status: No, score=-104.849 tagged_above=-999 required=5 tests=[AWL=3.614, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKh0n-WpjTfM for ; Thu, 28 Jul 2011 06:29:29 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3C62821F8C3C for ; Thu, 28 Jul 2011 06:29:29 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.135430365; Thu, 28 Jul 2011 09:29:24 -0400 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Thu, 28 Jul 2011 09:29:14 -0400 From: "Livingood, Jason" To: Fred Baker , IPv6 Operations Thread-Topic: [v6ops] A question: Interim meeting Thread-Index: AQHMTKSkQi4hZbNO4kqUsA0S7giLR5UBT4uAgABr2AA= Date: Thu, 28 Jul 2011 13:29:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <7AD1DD82F594DA48AEB90E1A80502446@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 13:29:30 -0000 >>=20 >> Are folks interested in having such a meeting? And are we assuming f2f or virtual? JL From joelja@bogus.com Thu Jul 28 06:31:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A5C21F8C42 for ; Thu, 28 Jul 2011 06:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.044 X-Spam-Level: X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6P1VDDGIqv5 for ; Thu, 28 Jul 2011 06:31:48 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B39521F8569 for ; Thu, 28 Jul 2011 06:31:46 -0700 (PDT) Received: from dhcp-677d.meeting.ietf.org (dhcp-677d.meeting.ietf.org [130.129.103.125]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6SDVf3L016315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2011 13:31:42 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Thu, 28 Jul 2011 09:31:41 -0400 Content-Transfer-Encoding: 7bit Message-Id: <2A1F551B-AABB-46CA-A464-64AA0F104A4F@bogus.com> References: To: "Livingood, Jason" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 28 Jul 2011 13:31:43 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 13:31:49 -0000 On Jul 28, 2011, at 9:29 AM, Livingood, Jason wrote: > >>> >>> Are folks interested in having such a meeting? > > And are we assuming f2f or virtual? I was assuming virtual. > JL > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From ichiroumakino@gmail.com Thu Jul 28 07:34:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B3821F8BE7 for ; Thu, 28 Jul 2011 07:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A24gIqiAZbFt for ; Thu, 28 Jul 2011 07:34:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85ACE21F8B2E for ; Thu, 28 Jul 2011 07:34:35 -0700 (PDT) Received: by gyd5 with SMTP id 5so2249233gyd.31 for ; Thu, 28 Jul 2011 07:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nfPQ1JCSKMZkDZbLk7893T72QQzEcUs+gm4CryfqB5I=; b=VzHzOQS5hhr//8Ovcr9ee7+8ROGVom5dy7hoRPgKKciAr8RKpqDImDrC6IUsBXmV5e lyNw4Db1KGtIqARAJe9rYL5c5JRpe88r6viQD4vHPnpzlmFvuH1eVraNe7i1oJHg2O4V UNLfSBWGdPsCXWmLxVYkgqE82fA3jRYlC+UkE= Received: by 10.142.249.30 with SMTP id w30mr47582wfh.122.1311863674726; Thu, 28 Jul 2011 07:34:34 -0700 (PDT) Received: from sjc-vpn6-649.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id d3sm1055635pbh.85.2011.07.28.07.34.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 07:34:33 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <2A1F551B-AABB-46CA-A464-64AA0F104A4F@bogus.com> Date: Thu, 28 Jul 2011 10:34:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <25F1354F-4BF9-4D15-AC41-DF4361B342DA@employees.org> References: <2A1F551B-AABB-46CA-A464-64AA0F104A4F@bogus.com> To: Joel Jaeggli X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:34:36 -0000 >>>> Are folks interested in having such a meeting? >>=20 >> And are we assuming f2f or virtual? >=20 > I was assuming virtual. I've heard suggestions of interim meetings both in softwire and homenet. perhaps have a week of f2f interim meetings for all 3 working groups. or = is that too much of a mini IETF? cheers, Ole= From wesley.george@twcable.com Thu Jul 28 07:58:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67F221F8B82 for ; Thu, 28 Jul 2011 07:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.305 X-Spam-Level: X-Spam-Status: No, score=0.305 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48te2o1VOPr3 for ; Thu, 28 Jul 2011 07:58:24 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 05A1D21F8B2C for ; Thu, 28 Jul 2011 07:58:23 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,282,1309752000"; d="scan'208";a="255197271" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 28 Jul 2011 10:56:23 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 28 Jul 2011 10:58:22 -0400 From: "George, Wesley" To: Fred Baker , IPv6 Operations Date: Thu, 28 Jul 2011 10:58:22 -0400 Thread-Topic: [v6ops] A question: Interim meeting Thread-Index: AcxMpKM3CgFz5Px5QWKZbOI47tQnIwAkeTUQ Message-ID: <34E4F50CAFA10349A41E0756550084FB0BDC33FF@PRVPEXVS04.corp.twcable.com> References: <987EEA6D-59F9-4D6F-9FFE-6DD2DE3C71D1@cisco.com> In-Reply-To: <987EEA6D-59F9-4D6F-9FFE-6DD2DE3C71D1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:58:24 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= red Baker Sent: Wednesday, July 27, 2011 5:32 PM To: IPv6 Operations Subject: [v6ops] A question: Interim meeting ...an interim meeting, in which we would discuss drafts that have been upda= ted or posted no later than a week in advance and for which interest has ma= terialized on the mailing list. [WEG] a week is not long enough in advance, especially if you are trying to= gauge on-list interest to determine which drafts to discuss. The one excep= tion might be a new rev of an existing draft that already has WG interest. = A month might be more appropriate. related - There are somewhere north of 1000 people subscribed to v6ops and = therefore ostensibly "members" of this WG. While I don't expect anywhere ne= ar a majority of that amount to be active on the list at any given time, pe= rhaps we need a higher bar for quorum when gauging interest/consensus when = it comes to things like WG adoption/meeting discussion of drafts? Perhaps a= t least 1-2% response, with 5% being more preferable? Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From cb.list6@gmail.com Thu Jul 28 08:04:22 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E5B21F8CB1; Thu, 28 Jul 2011 08:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.024 X-Spam-Level: X-Spam-Status: No, score=-4.024 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CR6V7JSQJtR; Thu, 28 Jul 2011 08:04:21 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3334521F8C7B; Thu, 28 Jul 2011 08:04:20 -0700 (PDT) Received: by wyj26 with SMTP id 26so121309wyj.31 for ; Thu, 28 Jul 2011 08:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MQPOKYjlh9SIim+2JisYfxmU3kQQvZ+R4c8iXkLjihU=; b=FuEuLZlhP7REYC5yYH+EFl1YOARKoBfj0cfxuOJeR/UL+8xTdU2VaYalm6m99Rs0oC FUG8Bmx+XnjiL1WXLy0McTv+s0fu0i35NDvzlDz7fNBjaDpACwmKzhSoXjOzQkI835Pt 2I0rcACNNAJjoRiZECn1ELOGv8fE+HYpgVsfc= MIME-Version: 1.0 Received: by 10.227.154.6 with SMTP id m6mr125715wbw.73.1311865459356; Thu, 28 Jul 2011 08:04:19 -0700 (PDT) Received: by 10.216.179.71 with HTTP; Thu, 28 Jul 2011 08:04:17 -0700 (PDT) Received: by 10.216.179.71 with HTTP; Thu, 28 Jul 2011 08:04:17 -0700 (PDT) In-Reply-To: References: <2D290C0C-E845-42EF-9690-D92D3D86641C@apple.com> Date: Thu, 28 Jul 2011 08:04:17 -0700 Message-ID: From: Cameron Byrne To: Philip Homburg Content-Type: multipart/alternative; boundary=0016e64c1a30b2b4e904a9227a65 Cc: IPv6 Operations , "ietf@ietf.org Discussion" Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:04:22 -0000 --0016e64c1a30b2b4e904a9227a65 Content-Type: text/plain; charset=ISO-8859-1 On Jul 28, 2011 1:08 AM, "Philip Homburg" wrote: > > In your letter dated Wed, 27 Jul 2011 21:56:51 -0400 you wrote: > > In the absence of a coherent instruction from IETF for a phase-out > > plan, declaring this protocol historic under the current proposed > > language, will do precisely that. Please please please, if IETF > > wants 6to4 to die, then publish a phase-out plan so that the > > current users of 6to4 can have fair warning before the relays go > > dark and forthcoming hardware/software upgrades rip the feature > > out from under them. > > I would hope that big companies like Apple would actually do an impact > analysis before removing a feature. > Like how Apple does not support Flash in iOS? Just one example where a visionary drops an inferior solution to force a better one. This is also known as cracking some eggs to make an omelet. Cb > Big content providers can measure how much 6to4 is enabled, so they can > probably say something about trends. But that doesn't say much about how many > users actually care about 6to4. Vendors seem to be best equiped to analyse > the users' need for 6to4. > > I don't think relay operators have expressed a desire for a specific cut off > date. So I guess they just figure out for themselves when to switch off the > relays. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --0016e64c1a30b2b4e904a9227a65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 28, 2011 1:08 AM, "Philip Homburg" <pch-v6ops@u-1.phicoh.com> wrote:
>
> In your letter dated Wed, 27 Jul 2011 21:56:51 -0400 you wrote:
> > In the absence of a coherent instruction from IETF for a phase-ou= t
> > plan, declaring this protocol historic under the current proposed=
> > language, will do precisely that. =A0Please please please, if IET= F
> > wants 6to4 to die, then publish a phase-out plan so that the
> > current users of 6to4 can have fair warning before the relays go<= br> > > dark and forthcoming hardware/software upgrades rip the feature > > out from under them.
>
> I would hope that big companies like Apple would actually do an impact=
> analysis before removing a feature.
>

Like how Apple does not support Flash in iOS?

Just one example where a visionary drops an inferior solution to force a= better one.

This is also known as cracking some eggs to make an omelet.

Cb

> Big content providers can measure how much 6to4 is enabled, so they= can
> probably say something about trends. But that doesn't say much abo= ut how many
> users actually care about 6to4. Vendors seem to be best equiped to ana= lyse
> the users' need for 6to4.
>
> I don't think relay operators have expressed a desire for a specif= ic cut off
> date. So I guess they just figure out for themselves when to switch of= f the
> relays.
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--0016e64c1a30b2b4e904a9227a65-- From cb.list6@gmail.com Thu Jul 28 08:04:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFB111E8087 for ; Thu, 28 Jul 2011 08:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.071 X-Spam-Level: X-Spam-Status: No, score=-3.071 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6tmtz6nkSMl for ; Thu, 28 Jul 2011 08:04:22 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5E321F8CB6 for ; Thu, 28 Jul 2011 08:04:21 -0700 (PDT) Received: by wwe5 with SMTP id 5so1720460wwe.13 for ; Thu, 28 Jul 2011 08:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7HZCCpRkG2385OCJgqU+x9zx59nqfyCsw6YUHXln+DU=; b=VNs1oayHhmF8v6EhQnPfPmaaw+WI6LojM9xKAY/HCF9Q6YlvcJDFoBxTzy14Ul2KDS cyzQ/YjeueKYbRX196hvV3KS6Mc98+8GMmdNFChta5K3s7YGU9tK4/qpPYQKi5NtAoAr 6wXcEy2HZkLMrMHuSnCIugUC0wNhDSJbarh+k= MIME-Version: 1.0 Received: by 10.227.12.18 with SMTP id v18mr126562wbv.72.1311865460328; Thu, 28 Jul 2011 08:04:20 -0700 (PDT) Received: by 10.216.179.71 with HTTP; Thu, 28 Jul 2011 08:04:17 -0700 (PDT) Received: by 10.216.179.71 with HTTP; Thu, 28 Jul 2011 08:04:17 -0700 (PDT) In-Reply-To: <20110728085658.GC21519@phantom.vanrein.org> References: <20110727114038.GE7494@phantom.vanrein.org> <4E30005A.8080205@unfix.org> <20110727125114.GA1237@phantom.vanrein.org> <4E30207A.5080500@unfix.org> <20110728085658.GC21519@phantom.vanrein.org> Date: Thu, 28 Jul 2011 08:04:17 -0700 Message-ID: From: Cameron Byrne To: Rick van Rein Content-Type: multipart/alternative; boundary=002215975fe2c18b2004a9227a40 Cc: v6ops@ietf.org Subject: Re: [v6ops] slight comments on draft-vanrein-v6ops-6bed4-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:04:24 -0000 --002215975fe2c18b2004a9227a40 Content-Type: text/plain; charset=ISO-8859-1 On Jul 28, 2011 1:57 AM, "Rick van Rein" wrote: > > Hi, > > > > Teredo does not keep the address space transparent; peer-to-peer > > > connectivity is just as much a problem with Teredo as with IPv4. > > > > Can you elaborate on what you actually mean with this and what the > > problems are? Especially how you try to resolve them with your proposal? > > 1. Personal experience with Teredo: ping time variations, failure > to route to certain IPv6 ranges. > > 2. Teredo is not a general solution -- and it won't help the SIP > wish that I am developing for. From RFC 4380 section 8.3: > > - Teredo service will not work through NATs of the symmetric variety. > > - Teredo introduces jitter into the IPv6 service it provides, due to > the queuing of packets while bubble exchanges take place. This > jitter can negatively impact applications, particularly latency > sensitive ones, such as Voice over IP (VoIP). > > If you are saying that I over-generalised by speaking of "embedded > systems" instead of a tighter area, and that Teredo may work for > certain embedded systems then I agree. > > But specifically for SIP, I still have not found an existing zeroconfig > tunnel service that can do the job. > > > Where exactly does a "RTP proxy" come into play unless you are > > translating from IPv4 to IPv6 and vice versa? > > I did make a translator between SIP over IPv4 and SIP over IPv6, but that > is not what I meant. (Link: http://devel.0cpm.org/sipproxy64/) > > An RTP proxy is needed as a general solution to connect phones behind > NAT. To open a hole for RTP in a firewall, traffic must be sent out. > At that point, the address translation is also set. The same applies > to the other side, so neither can start the transmission as the remote > address is not known. This is specifically a problem to symmetric > NAT, which means that to be general you will need a server at a fixed > IP that bounces RTP back and forth, known as an RTP proxy. > > Needing an RTP proxy means to most users that they become dependent on > service providers, who prefer to sell you bit-stuffed POTS connections. > If you don't need an RTP proxy, you can embrace Internet-style schemes > for locating phones: ENUM, freenum.org, sip:bakker@orvelte.nep > > > Are you talking about "embedded devices" as in "8kb memory" or "embedded > > devices" which are actually full blown Linux boxes? > > Sort of in between -- 128-ish kB RAM. > > > For instance the Gigaset S675IP and related boxes running their Chagall > > firmware are a good example [...] > > Indeed. But there are also examples that do cannot run fullblown Linux > but that do networking. I am getting a simple SIP app running in about > 64 kB of code, and a few kB of RAM. With IPv6 on any network, thanks > to 6bed4. IPv6 may turn out to be a way to rely on cheaper hardware ;-) > > > You stated 'embedded' and thus I think of 8kB memory and low-resources > > available. If you have resources then doing any of the currently > > available tunneling protocols should work like a charm. > > I investigated every single tunnel that I could find, but none works > for the application area I have in mind. One thing I wish to avoid > is asking end users to configure accounts. > > > It completely depends on what your deployment model is though and the > > actual problems you are trying to solve. > > SIP telephony, IPv6-only, no end user configuration of IPv6. > Generally solved with a sip b2bua or SBC that terminates one call leg on v6 and the other on v4. You will see this commonly in VoLTE which is SIP on mobile phones. Cb > > Your requirements section just lists the features that your protocol > > has, not why that requirement is important for you to solve and for what > > purposes. > > Ah, hence the quotes around 'requirements'. Fair enough, although the > requirements really did come up as requirements. I hope the above helps. > > I am thinking that the requirements might be better dropped from the > draft, but felt a need to describe, in general terms, what I was > looking for and why yet another tunnel was IMHO needed. I am starting > to feel that it might be better to just stick to the technology. > > > Another option is to do what we call pre-configured AYIYA tunnels. In > > the cases where we deployed these they where vendor-bound though and > > thus effectively took care of the problem of getting IPv6 packets to the > > vendors servers, thus avoiding the need for IPv4 as everything was just > > IPv6 (except for the tunnel). > > Is there a place where I can read more about pre-configured AYIYA? > Neither Ecosia nor Google has heard of it. > > Could such a setup be pre-configured into a device and then shipped > off to customers, and could that not lead to non-local tunnel service > and potential abuse of an account? > > > As they all simply use NAT-PMP/uPNP to overcome the issue of IPv4 NAT. > > That only works with a single layer of NAT but that is what is generally > > the case. > > Need to dig more into this. Not sure why I don't see phones and > SIP providers relying on this (for their RTP connections). > > > See the above vendor-specific AYIYA support. That works like a charm. > > Could pre-configured AYIYA be part of the open source SIP firmware > for IPv6-only that I am developing? And could it be configured into the > Java applet that we are maing to connect IPv6-only from an IPv4-only > browser environment? > > > Best wishes, > -Rick > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --002215975fe2c18b2004a9227a40 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 28, 2011 1:57 AM, "Rick van Rein" <rick@openfortress.nl> wrote:
>
> Hi,
>
> > > Teredo does not keep the address space transparent; peer-to-= peer
> > > connectivity is just as much a problem with Teredo as with I= Pv4.
> >
> > Can you elaborate on what you actually mean with this and what th= e
> > problems are? Especially how you try to resolve them with your pr= oposal?
>
> 1. Personal experience with Teredo: ping time variations, failure
> =A0 to route to certain IPv6 ranges.
>
> 2. Teredo is not a general solution -- and it won't help the SIP > =A0 wish that I am developing for. =A0From RFC 4380 section 8.3:
>
> =A0 - Teredo service will not work through NATs of the symmetric varie= ty.
>
> =A0 - Teredo introduces jitter into the IPv6 service it provides, due = to
> =A0 =A0 the queuing of packets while bubble exchanges take place. =A0T= his
> =A0 =A0 jitter can negatively impact applications, particularly latenc= y
> =A0 =A0 sensitive ones, such as Voice over IP (VoIP).
>
> If you are saying that I over-generalised by speaking of "embedde= d
> systems" instead of a tighter area, and that Teredo may work for<= br> > certain embedded systems then I agree.
>
> But specifically for SIP, I still have not found an existing zeroconfi= g
> tunnel service that can do the job.
>
> > Where exactly does a "RTP proxy" come into play unless = you are
> > translating from IPv4 to IPv6 and vice versa?
>
> I did make a translator between SIP over IPv4 and SIP over IPv6, but t= hat
> is not what I meant. =A0(Link: http://devel.0cpm.org/sipproxy64/)
>
> An RTP proxy is needed as a general solution to connect phones behind<= br> > NAT. =A0To open a hole for RTP in a firewall, traffic must be sent out= .
> At that point, the address translation is also set. =A0The same applie= s
> to the other side, so neither can start the transmission as the remote=
> address is not known. =A0This is specifically a problem to symmetric > NAT, which means that to be general you will need a server at a fixed<= br> > IP that bounces RTP back and forth, known as an RTP proxy.
>
> Needing an RTP proxy means to most users that they become dependent on=
> service providers, who prefer to sell you bit-stuffed POTS connections= .
> If you don't need an RTP proxy, you can embrace Internet-style sch= emes
> for locating phones: ENUM, freenum.org<= /a>, sip:bakker@orvelte.nep
>
> > Are you talking about "embedded devices" as in "8k= b memory" or "embedded
> > devices" which are actually full blown Linux boxes?
>
> Sort of in between -- 128-ish kB RAM.
>
> > For instance the Gigaset S675IP and related boxes running their C= hagall
> > firmware are a good example [...]
>
> Indeed. =A0But there are also examples that do cannot run fullblown Li= nux
> but that do networking. =A0I am getting a simple SIP app running in ab= out
> 64 kB of code, and a few kB of RAM. =A0With IPv6 on any network, thank= s
> to 6bed4. =A0IPv6 may turn out to be a way to rely on cheaper hardware= ;-)
>
> > You stated 'embedded' and thus I think of 8kB memory and = low-resources
> > available. If you have resources then doing any of the currently<= br> > > available tunneling protocols should work like a charm.
>
> I investigated every single tunnel that I could find, but none works > for the application area I have in mind. =A0One thing I wish to avoid<= br> > is asking end users to configure accounts.
>
> > It completely depends on what your deployment model is though and= the
> > actual problems you are trying to solve.
>
> SIP telephony, IPv6-only, no end user configuration of IPv6.
>

Generally solved with a sip b2bua or SBC that terminates one call leg on= v6 and the other on v4.

You will see this commonly in VoLTE which is SIP on mobile phones.

Cb

> > Your requirements section just lists the features that your pr= otocol
> > has, not why that requirement is important for you to solve and f= or what
> > purposes.
>
> Ah, hence the quotes around 'requirements'. =A0Fair enough, al= though the
> requirements really did come up as requirements. =A0I hope the above h= elps.
>
> I am thinking that the requirements might be better dropped from the > draft, but felt a need to describe, in general terms, what I was
> looking for and why yet another tunnel was IMHO needed. =A0I am starti= ng
> to feel that it might be better to just stick to the technology.
>
> > Another option is to do what we call pre-configured AYIYA tunnels= . In
> > the cases where we deployed these they where vendor-bound though = and
> > thus effectively took care of the problem of getting IPv6 packets= to the
> > vendors servers, thus avoiding the need for IPv4 as everything wa= s just
> > IPv6 (except for the tunnel).
>
> Is there a place where I can read more about pre-configured AYIYA?
> Neither Ecosia nor Google has heard of it.
>
> Could such a setup be pre-configured into a device and then shipped > off to customers, and could that not lead to non-local tunnel service<= br> > and potential abuse of an account?
>
> > As they all simply use NAT-PMP/uPNP to overcome the issue of IPv4= NAT.
> > That only works with a single layer of NAT but that is what is ge= nerally
> > the case.
>
> Need to dig more into this. =A0Not sure why I don't see phones and=
> SIP providers relying on this (for their RTP connections).
>
> > See the above vendor-specific AYIYA support. That works like a ch= arm.
>
> Could pre-configured AYIYA be part of the open source SIP firmware
> for IPv6-only that I am developing? =A0And could it be configured into= the
> Java applet that we are maing to connect IPv6-only from an IPv4-only > browser environment?
>
>
> Best wishes,
> =A0-Rick
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--002215975fe2c18b2004a9227a40-- From joelja@bogus.com Thu Jul 28 08:09:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF3621F8BC6 for ; Thu, 28 Jul 2011 08:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.7 X-Spam-Level: X-Spam-Status: No, score=-101.7 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_64=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLhZ-Z8mHplW for ; Thu, 28 Jul 2011 08:09:41 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4151221F8B85 for ; Thu, 28 Jul 2011 08:09:37 -0700 (PDT) Received: from [IPv6:2001:df8::96:129a:ddff:feb1:e750] ([IPv6:2001:df8:0:96:129a:ddff:feb1:e750]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6SF9PkI022894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2011 15:09:26 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Joel Jaeggli In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D61@GRFMBX704BA020.griffon.local> Date: Thu, 28 Jul 2011 11:09:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB5E53D61@GRFMBX704BA020.griffon.local> To: Maglione Roberta X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [IPv6:2001:418:1::81]); Thu, 28 Jul 2011 15:09:27 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:09:54 -0000 Correct, default route is the operative thing on the outside. On Jul 27, 2011, at 3:47 PM, Maglione Roberta wrote: > Hi Don, > In your environment you have a routing protocol running in the home = network for the reasons you explained, but my understanding is that you = don't have a routing protocol on the WAN link between the CPE and the = Service provider's network; is it correct? > Thanks, > Regards, > Roberta >=20 > -----Original Message----- > From: Don Sturek [mailto:d.sturek@att.net] > Sent: mercoled=EC 27 luglio 2011 21.40 > To: Joel Jaeggli; Maglione Roberta > Cc: v6ops@ietf.org > Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >=20 > Hi Joel (and Roberta), >=20 > Correct, the routing protocol is to support multiple CPE in the home = each > of which is connected to a separate WAN with different global = prefixes. >=20 > The use case (and one actively being worked on with deployment next = year) > is: > 1) Customer has a CPE router connected to broadband service > 2) Smart meter is installed with a different global prefix supplied = by > the energy service provider. Devices on the subnet for the CPE router = in > (1) want to deploy energy applications that connect to the smart = meter. >=20 > The issue is that around 17M smart meters have been deployed with IEEE > 802.15.4. This MAC/PHY offers a 127 byte frame so you need 6LoWPAN = and a > mesh routing protocol like ROLL RPL (in the case used by ZigBee IP). = This > subnet cannot be bridged with subnets typically deployed with = broadband > service (hence the need in an intra-home routing protocol). >=20 > Note that neither of the service providers in (1) or (2) need to do > anything special routing wise with the CPE routing protocol in the = home. >=20 > Don >=20 >=20 >=20 >=20 > On 7/27/11 11:53 AM, "Joel Jaeggli" wrote: >=20 >>=20 >> On Jul 27, 2011, at 2:41 PM, Maglione Roberta wrote: >>=20 >>> for scalability problems ISPs don't usually exchange routes with CPE >>> routers/residential customers. >>=20 >> Nor would they in this case. In fact from a isp perspective you want = the >> igp used in the home to be identifiable and easy to filter such that >> inadvertant leakage is effectively impossible. Although best = practices >> for PE ports generally would be sufficient to preclude that, you also >> want to do one better. >>=20 >> joel >>=20 >>> Regards, >>> Roberta >>>=20 >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf >>> Of Shishio Tsuchiya >>> Sent: mercoled=EC 27 luglio 2011 20.21 >>> To: swmike@swm.pp.se >>> Cc: v6ops@ietf.org >>> Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router >>>=20 >>> Mikael >>> Mikael Abrahamsson wrote: >>>> On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: >>>>=20 >>>>> I think OSPFv3 is not acceptable as default routing protocol on = CPE >>>>> router. >>>>=20 >>>> Care to elaborate on that? >>>>=20 >>>=20 >>> Most of home gateway supports only RIPv1/v2 as IPv4 routing = protocol. >>> The reasons are.. >>> -OSPF consumes CPU/memory than RIP. >>> -OSPF operetaion is needed more knowledge compare with RIP. >>> The character of these protocol does not change on IPv6 = environment,too. >>> So we thought RIPng would be acceptable routing protocol for IPv6 = CPE >>> router,also. >>>=20 >>> Regards, >>> -Shishio >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle >>> persone indicate. La diffusione, copia o qualsiasi altra azione >>> derivante dalla conoscenza di queste informazioni sono rigorosamente >>> vietate. Qualora abbiate ricevuto questo documento per errore siete >>> cortesemente pregati di darne immediata comunicazione al mittente e = di >>> provvedere alla sua distruzione, Grazie. >>>=20 >>> This e-mail and any attachments is confidential and may contain >>> privileged information intended for the addressee(s) only. >>> Dissemination, copying, printing or use by anybody else is = unauthorised. >>> If you are not the intended recipient, please delete this message = and >>> any attachments and advise the sender by return e-mail, Thanks. >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle persone indicate. La diffusione, copia o qualsiasi altra azione = derivante dalla conoscenza di queste informazioni sono rigorosamente = vietate. Qualora abbiate ricevuto questo documento per errore siete = cortesemente pregati di darne immediata comunicazione al mittente e di = provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain = privileged information intended for the addressee(s) only. = Dissemination, copying, printing or use by anybody else is unauthorised. = If you are not the intended recipient, please delete this message and = any attachments and advise the sender by return e-mail, Thanks. >=20 >=20 From joelja@bogus.com Thu Jul 28 08:19:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A472E21F8C32 for ; Thu, 28 Jul 2011 08:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.65 X-Spam-Level: X-Spam-Status: No, score=-101.65 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_64=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v70SJ8XQixB for ; Thu, 28 Jul 2011 08:19:03 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0173C21F8C2F for ; Thu, 28 Jul 2011 08:19:02 -0700 (PDT) Received: from [IPv6:2001:df8::96:129a:ddff:feb1:e750] ([IPv6:2001:df8:0:96:129a:ddff:feb1:e750]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6SFIx8I023593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2011 15:19:00 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <4E30571A.9000104@cisco.com> Date: Thu, 28 Jul 2011 11:18:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> <4E304CD7.3010209@cisco.com> <4E30571A.9000104@cisco.com> To: Shishio Tsuchiya X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [IPv6:2001:418:1::81]); Thu, 28 Jul 2011 15:19:01 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:19:03 -0000 On Jul 27, 2011, at 2:21 PM, Shishio Tsuchiya wrote: > Mikael > Mikael Abrahamsson wrote: >> On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: >>=20 >>> I think OSPFv3 is not acceptable as default routing protocol on CPE = router. >>=20 >> Care to elaborate on that? >>=20 >=20 > Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol. > The reasons are.. > -OSPF consumes CPU/memory than RIP. > -OSPF operetaion is needed more knowledge compare with RIP. > The character of these protocol does not change on IPv6 = environment,too. > So we thought RIPng would be acceptable routing protocol for IPv6 CPE = router,also. So, if one is working with requirements rather than working backwards = from a selected protocol one would suppose that some of the requirements = might look something like: * can be used with acceptable defaults (e.g. no configuration) * has sensive safeguards to prevent interaction with isp IGP. * can distinguish between the desirability of a path on the basis of = something other than hop count. e.g. just because I happen to have = connected an 802.5.14 network to two largely ethernet devices doesn't = mean traffic to other parts of the network should traverse the former = when it happens to be the best path. > Regards, > -Shishio > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From jnc@mercury.lcs.mit.edu Thu Jul 28 08:20:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE2621F8BF2; Thu, 28 Jul 2011 08:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n49UkST3jdzU; Thu, 28 Jul 2011 08:20:20 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF5521F8CCC; Thu, 28 Jul 2011 08:20:20 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A2D8318C0F2; Thu, 28 Jul 2011 11:20:18 -0400 (EDT) To: ietf@ietf.org Message-Id: <20110728152018.A2D8318C0F2@mercury.lcs.mit.edu> Date: Thu, 28 Jul 2011 11:20:18 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: v6ops@ietf.org, jnc@mercury.lcs.mit.edu Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:20:20 -0000 > From: Cameron Byrne > Like how Apple does not support Flash in iOS? > Just one example where a visionary drops an inferior solution to force > a better one. Apple has enough market share to get away with that. IPv6 doesn't. Noel From gert@space.net Thu Jul 28 08:23:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0900021F8CD3 for ; Thu, 28 Jul 2011 08:23:44 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvkjuVT38751 for ; Thu, 28 Jul 2011 08:23:43 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3097221F8CDE for ; Thu, 28 Jul 2011 08:23:43 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 50C7FF8576 for ; Thu, 28 Jul 2011 17:23:41 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 3E5B4F857F for ; Thu, 28 Jul 2011 17:23:41 +0200 (CEST) Received: (qmail 26801 invoked by uid 1007); 28 Jul 2011 17:23:41 +0200 Date: Thu, 28 Jul 2011 17:23:41 +0200 From: Gert Doering To: Noel Chiappa Message-ID: <20110728152341.GT72014@Space.Net> References: <20110728152018.A2D8318C0F2@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110728152018.A2D8318C0F2@mercury.lcs.mit.edu> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, ietf@ietf.org Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:23:44 -0000 Hi, On Thu, Jul 28, 2011 at 11:20:18AM -0400, Noel Chiappa wrote: > Apple has enough market share to get away with that. IPv6 doesn't. Just how much market share has 6to4, if we exclude those two users? It's amazing how many human life cycles got wasted on this (and that I can't refuse to be sucked into this again). gert -- 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 (89) 32356-444 USt-IdNr.: DE813185279 From wesley.george@twcable.com Thu Jul 28 08:28:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515F721F8B6E for ; Thu, 28 Jul 2011 08:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZVScoyWLmVD for ; Thu, 28 Jul 2011 08:28:30 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB7521F8C79 for ; Thu, 28 Jul 2011 08:28:30 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,282,1309752000"; d="scan'208";a="255217720" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 28 Jul 2011 11:26:29 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 28 Jul 2011 11:28:29 -0400 From: "George, Wesley" To: Fred Baker , IPv6 Operations Date: Thu, 28 Jul 2011 11:28:27 -0400 Thread-Topic: [v6ops] A question: Interim meeting Thread-Index: AcxMpKM3CgFz5Px5QWKZbOI47tQnIwALiacQ Message-ID: <34E4F50CAFA10349A41E0756550084FB0BDC3464@PRVPEXVS04.corp.twcable.com> References: <987EEA6D-59F9-4D6F-9FFE-6DD2DE3C71D1@cisco.com> In-Reply-To: <987EEA6D-59F9-4D6F-9FFE-6DD2DE3C71D1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ops-ads@tools.ietf.org" Subject: Re: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:28:31 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= red Baker Sent: Wednesday, July 27, 2011 5:32 PM To: IPv6 Operations Subject: [v6ops] A question: Interim meeting Given the growth of drafts in v6ops, ...I'm thinking about an interim meeti= ng... Are folks interested in having such a meeting? [WEG] tl;dr version - speaking for myself, probably not, because I think th= at more meetings is treating the symptom, not the underlying cause. I think= this is a charter/goals problem causing a workload/meeting problem, not a = workload problem causing a meeting problem. Longer version - My question to the chairs and those in support of an interim is: what would= the goal of such a meeting be? IETF WGs are supposed to be conducting busi= ness primarily over the list, and meetings are for resolving things that ne= ed to be resolved face-to-face either because they are too contentious to b= e done strictly via email or because you need some people in the same room = to collaborate in real-time about the problem and the solution. Interims ar= e usually to push forward on milestone work items, not to compensate for a = lack of discussion on the list. I don't support having another meeting simply because we have more drafts s= ubmitted to the WG that we didn't discuss. I feel like V6ops has become the= gateway of last resort for anything with "IPv6" in the draft that is looki= ng for a home, especially if it has to do with transition technologies. As = a result, the signal to noise ratio has gotten unmanageable, as evidenced b= y the need for 3 sessions and the 40-odd drafts currently on our docket to = either adopt, consolidate or ignore. No matter how many meetings we have, t= his group certainly doesn't have the cycles to add valuable review and comm= ents to all of them, and it probably shouldn't adopt most of them, if for n= o other reason than they'd be just fine as individual submissions. Perhaps the better solution is to spend some time contemplating our charter= , and determine whether more of these drafts belong somewhere else, or whet= her we simply need to let more of them expire/pursue individual submission = in the interest of pushing the inverse relationship between quantity and qu= ality back the other direction somewhat by letting us focus on fewer drafts= as a WG. We currently have no milestones in our charter that are not completed, and = I think we're suffering from far too broad of a charter, coupled with too l= ow of a bar when deciding what drafts should be adopted as WG items or disc= ussed in the meeting, and that is what is leading to the high draft load. P= eople are contributing - that's a good thing. But they need some guidance t= o ensure that what they're contributing is useful. This is supposed to be an operations group, but I feel like we spend an ino= rdinate amount of time focused on BCP and theoretical analysis/overview/sur= vey on things with which we have very little actual operational experience = because they're not widely deployed yet. If we're not doing that, we're dis= cussing tweaked transition technologies whose main point is, "yes, but $exi= sting_implementation doesn't solve this corner case over here..." and the a= uthors proceed as if new work is necessary instead of trying to find a comm= on ground that makes the existing solution more flexible and widely applica= ble. Consequently, the output of both work streams is of questionable value= since each one seems to be written with such a narrow focus that it's unli= kely to be applicable outside of the specific case the authors had in mind = when writing it. IPv6 (and its associated transition technologies) is pretty well-baked at t= his point. IMO, what v6ops needs to be focused on is: * refining existing implementations and recommendations based on the resul= ts of actual, at-scale deployments (and yes I realize this means that poten= tial authors must wait for them to exist in some cases) * security/scaling considerations * a gap analysis around what features in IPv4 are still missing or incompl= ete in IPv6 with an eye towards enabling true IPv6-only network implementat= ions Continuing CPE requirements work is an open question given the existence of= homenet. We should *not* be focused on building more "better mousetraps" to aid in t= ransition without very clear signals from operators/implementers that there= are gaps in the existing tools that need to be addressed. We also need to = stop writing more survey/recipe documents for deployment unless they are sp= ecifically solicited by the operator community or specific technology SDO (= 3gpp, etc) so that we know that someone will actually pay attention to them= and can provide expertise to review them. We are not going to speed the ra= te of IPv6 deployment and adoption by burying it in words to cover every po= ssible permutation with 3 different solutions. Sorry for the long-ish rant, hopefully it's constructive, no offense to any= individual authors or contributors was intended. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From joelja@bogus.com Thu Jul 28 08:42:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E82321F8BEC for ; Thu, 28 Jul 2011 08:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.914 X-Spam-Level: X-Spam-Status: No, score=-101.914 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3hry-SqZOKr for ; Thu, 28 Jul 2011 08:42:18 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCFF21F8BC6 for ; Thu, 28 Jul 2011 08:42:18 -0700 (PDT) Received: from [IPv6:2001:df8::96:129a:ddff:feb1:e750] ([IPv6:2001:df8:0:96:129a:ddff:feb1:e750]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6SFgDrF025369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2011 15:42:15 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-30-700568306 From: Joel Jaeggli In-Reply-To: Date: Thu, 28 Jul 2011 11:42:13 -0400 Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [IPv6:2001:418:1::81]); Thu, 28 Jul 2011 15:42:15 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:42:19 -0000 --Apple-Mail-30-700568306 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 27, 2011, at 1:25 PM, Lorenzo Colitti wrote: > On Wed, Jul 27, 2011 at 12:28, Hemant Singh (shemant) = wrote: > IPv6 CPE router vendors, please give feedback. Does anyone object if = we specify the default routing protocol as OSPFv3 with only area zero = for the IPv6 CE router bis document? Or would you prefer the document = is silent on specification of any default? >=20 >=20 > Can such a default be extensible to exchange different types of = information than just reachability? For example, can it propagate = information such as "this is a guest network and this is an internal = network" or "this is a prefix that I have tentatively assigned but do = not own yet"? If not, then perhaps something more flexible like IS-IS = would be better. If the routing protocol were not dependent on the ip layer having = already been bootstrapped that might the ease the complexity and = depedancy graph during setup... > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-30-700568306 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Wed, Jul 27, 2011 at 12:28, = Hemant Singh (shemant) <shemant@cisco.com> = wrote:

IPv6 CPE router vendors, please give = feedback.  Does anyone object if we specify the default routing protocol as OSPFv3 with only = area zero for the IPv6 CE router bis document?   Or would you prefer the = document is silent on specification of any  = default?


Can such a = default be extensible to exchange different types of information than = just reachability? For example, can it propagate information such as = "this is a guest network and this is an internal network" or "this is a = prefix that I have tentatively assigned but do not own yet"? If not, = then perhaps something more flexible like IS-IS would be = better.

If the routing = protocol were not dependent on the ip layer having already been = bootstrapped that might the ease the complexity and depedancy graph = during setup...

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

= --Apple-Mail-30-700568306-- From d.sturek@att.net Thu Jul 28 08:55:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605D121F8B74 for ; Thu, 28 Jul 2011 08:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.475 X-Spam-Level: X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[AWL=1.524, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6GH-2NwS+vT for ; Thu, 28 Jul 2011 08:55:39 -0700 (PDT) Received: from nm11.access.bullet.mail.mud.yahoo.com (nm11.access.bullet.mail.mud.yahoo.com [66.94.237.212]) by ietfa.amsl.com (Postfix) with SMTP id 8360B21F8BB6 for ; Thu, 28 Jul 2011 08:55:39 -0700 (PDT) Received: from [66.94.237.199] by nm11.access.bullet.mail.mud.yahoo.com with NNFMP; 28 Jul 2011 15:55:35 -0000 Received: from [66.94.237.113] by tm10.access.bullet.mail.mud.yahoo.com with NNFMP; 28 Jul 2011 15:55:35 -0000 Received: from [127.0.0.1] by omp1018.access.mail.mud.yahoo.com with NNFMP; 28 Jul 2011 15:55:35 -0000 X-Yahoo-Newman-Id: 929132.50848.bm@omp1018.access.mail.mud.yahoo.com Received: (qmail 97305 invoked from network); 28 Jul 2011 15:55:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1311868535; bh=3PDsisTr42MHAwMvJByGxPKJPtrFYGbzvHN3qXtWyb4=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=g3PI26raOaZUUiZqR+yO+ZOQOMDQNBQr9zXw8C8yn1NR2NmU/gyjNDUR1IFZumUxNtFY85T4uB8TTjtWQyWFbR5mdzrlP8XTsuJXdNaljbvda8PW1Bu8NKyHqD1aTLFa9xUfBBnDHIvStvRfAfmxruugDht7wqpha6meB1QO9S8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: w.aEA.kVM1lwwOKdKJtL6_Zt6QfgZIMgZFQp6KXoaSd4zSa bj33xEsXPcU1KFQWy7D2hINnHML8__D_kN6sHdb4DVd2gMllW0cpOQKqHKwU fxnjJXuNtrVBfqp0y5HlopeAv.OJETREgUBStGxYCCv9Yx4J9EZPkoCp54CA YviN9pIU.KpvcERy8oWdQpmQKQtgoJCeBAs9DdAS2FbCJg8X1WJuqam1kG2L Y4c60qnRxpOUC1ZjOuCuejUPJptP_BlV.OLaYjzzGSR7E5LtdMqv5XJeM.64 xKFiwzF1Qs3OlIRdJ0WRj_yMl3UKyu7fU1XDhId7l9jylC273UpSeY46J.dE IjXYU_t77NcyeXNwKBWYklE5k7xISgZ1xJXirY9Eq X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.198] (d.sturek@67.124.203.43 with login) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 28 Jul 2011 08:55:35 -0700 PDT User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Thu, 28 Jul 2011 08:53:04 -0700 From: Don Sturek To: Joel Jaeggli , Shishio Tsuchiya Message-ID: Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:55:40 -0000 Hi Joel, I think the third point on desirability of a path is key. The routing protocol should avoid constrained paths like 802.15.4 mesh networks in favor of longer routes through technologies like Wi-Fi or Ethernet. We need to define appropriate routing metrics to make this happen. Also, new subnets will be added by the homeowner in an ad hoc fashion and new path characteristics must be determined automatically and factored into new routing paths. The idea would be to use some off the shelf existing routing protocol as is and maybe work on some intelligence on path cost (this topic might be an interesting one for Homenet). Don On 7/28/11 8:18 AM, "Joel Jaeggli" wrote: > >On Jul 27, 2011, at 2:21 PM, Shishio Tsuchiya wrote: > >> Mikael >> Mikael Abrahamsson wrote: >>> On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: >>> >>>> I think OSPFv3 is not acceptable as default routing protocol on CPE >>>>router. >>> >>> Care to elaborate on that? >>> >> >> Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol. >> The reasons are.. >> -OSPF consumes CPU/memory than RIP. >> -OSPF operetaion is needed more knowledge compare with RIP. >> The character of these protocol does not change on IPv6 environment,too. >> So we thought RIPng would be acceptable routing protocol for IPv6 CPE >>router,also. > >So, if one is working with requirements rather than working backwards >from a selected protocol one would suppose that some of the requirements >might look something like: > >* can be used with acceptable defaults (e.g. no configuration) >* has sensive safeguards to prevent interaction with isp IGP. >* can distinguish between the desirability of a path on the basis of >something other than hop count. e.g. just because I happen to have >connected an 802.5.14 network to two largely ethernet devices doesn't >mean traffic to other parts of the network should traverse the former >when it happens to be the best path. > >> Regards, >> -Shishio >> _______________________________________________ >> 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 Francis.Dupont@fdupont.fr Thu Jul 28 09:56:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869C821F8B9E for ; Thu, 28 Jul 2011 09:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2dlr02BSoVB for ; Thu, 28 Jul 2011 09:56:11 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 92F5721F86A4 for ; Thu, 28 Jul 2011 09:56:10 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p6SGu6a9009346; Thu, 28 Jul 2011 18:56:06 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201107281656.p6SGu6a9009346@givry.fdupont.fr> From: Francis Dupont To: "George, Wesley" In-reply-to: Your message of Thu, 28 Jul 2011 11:28:27 EDT. <34E4F50CAFA10349A41E0756550084FB0BDC3464@PRVPEXVS04.corp.twcable.com> Date: Thu, 28 Jul 2011 18:56:06 +0200 Sender: Francis.Dupont@fdupont.fr Cc: IPv6 Operations , "ops-ads@tools.ietf.org" Subject: Re: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 16:56:11 -0000 In your previous mail you wrote: [WEG] tl;dr version - speaking for myself, probably not, because I think that more meetings is treating the symptom, not the underlying cause. I think this is a charter/goals problem causing a workload/meeting problem, not a workload problem causing a meeting problem. => I tried to find the reason for an interim meeting and this led me to the same conclusion... Regards Francis.Dupont@fdupont.fr From shtsuchi@cisco.com Thu Jul 28 11:55:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82F121F8591 for ; Thu, 28 Jul 2011 11:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udSAi7tldc01 for ; Thu, 28 Jul 2011 11:55:44 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 59E2521F8586 for ; Thu, 28 Jul 2011 11:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=2142; q=dns/txt; s=iport; t=1311879340; x=1313088940; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=h6qTjOKg6c2ahnJxQ5Rt4Esl+lSAnYsD5Z0sTkYVArM=; b=GFMi0y20w+M7v7CrCGlrAeY1ejz80E1YWmAbJX8/a48BJxqNjoxOL25U q0MyVF7YtdNiHSCQk3lBbRQEpASfdJvFpDfk3Kg2LXHZQOtQppw3fVGHy rM/cu9JqKcT5vv7uGkBoQnFRwEuKfppvOEPUnBejkNpODo74h28v+yFhc E=; X-IronPort-AV: E=Sophos;i="4.67,283,1309737600"; d="scan'208";a="7499514" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jul 2011 18:54:54 +0000 Received: from [10.82.218.207] (rtp-vpn3-716.cisco.com [10.82.218.207]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6SIsrhS028735; Thu, 28 Jul 2011 18:54:53 GMT Message-ID: <4E31B074.4060000@cisco.com> Date: Thu, 28 Jul 2011 14:54:44 -0400 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: joelja@bogus.com References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> <4E304CD7.3010209@cisco.com> <4E30571A.9000104@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:55:45 -0000 Just for your information, We considered about routing protocol on LAN and WAN. http://www.v6pc.jp/pdf/v6hgw_Guideline_1_0-English.pdf I listed our consensus in below -Routing Control on WAN-side 1.Static route 2.Automatic Configuration of Default Route Using RA Both requirement as mandatory[MUST]. -Route Control to LAN-side 1.RIPng [RFC 2080] 2.More-Specific Route [RFC 4191] Both requirement as Optional[May]. We thought this is typical case for our countries. Of course,we are watching ietf homenet discussion. If the requirement would be acceptable in our environment too,we will modify our guideline. Regards, -Shishio Joel Jaeggli wrote: > > On Jul 27, 2011, at 2:21 PM, Shishio Tsuchiya wrote: > >> Mikael >> Mikael Abrahamsson wrote: >>> On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: >>> >>>> I think OSPFv3 is not acceptable as default routing protocol on CPE router. >>> >>> Care to elaborate on that? >>> >> >> Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol. >> The reasons are.. >> -OSPF consumes CPU/memory than RIP. >> -OSPF operetaion is needed more knowledge compare with RIP. >> The character of these protocol does not change on IPv6 environment,too. >> So we thought RIPng would be acceptable routing protocol for IPv6 CPE router,also. > > So, if one is working with requirements rather than working backwards from a selected protocol one would suppose that some of the requirements might look something like: > > * can be used with acceptable defaults (e.g. no configuration) > * has sensive safeguards to prevent interaction with isp IGP. > * can distinguish between the desirability of a path on the basis of something other than hop count. e.g. just because I happen to have connected an 802.5.14 network to two largely ethernet devices doesn't mean traffic to other parts of the network should traverse the former when it happens to be the best path. > >> Regards, >> -Shishio >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > From tjc@ecs.soton.ac.uk Thu Jul 28 11:56:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8850D228017 for ; Thu, 28 Jul 2011 11:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUEL+3xaMvL1 for ; Thu, 28 Jul 2011 11:56:48 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 6B72422800D for ; Thu, 28 Jul 2011 11:56:48 -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 p6SIuhRk024391; Thu, 28 Jul 2011 19:56:43 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p6SIuhRk024391 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1311879403; bh=48559dTMOQINLl3+l92j5MEsP7s=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=s+A0dUSBE2aKPRt0U3TGgBBOimsV8g/oEuN+JnGOroFoEMdLTLwda5JOYmh30mGlV 24PxG/T8VXLUJqBllEZ6egu9w6tNJBEoVsk5vYQkfYE9DGdyGXB3Nv68GHPCtELFEj fakSN108QCwzbe18oCjglveAKC+49AYL3MnArVKc= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n6RJuh0366153254m0 ret-id none; Thu, 28 Jul 2011 19:56:43 +0100 Received: from [IPv6:2001:df8::112:cdec:599d:44e1:2385] ([IPv6:2001:df8:0:112:cdec:599d:44e1:2385]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p6SIuc7p012027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jul 2011 19:56:39 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Tim Chown In-Reply-To: <201107281656.p6SGu6a9009346@givry.fdupont.fr> Date: Thu, 28 Jul 2011 19:56:37 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201107281656.p6SGu6a9009346@givry.fdupont.fr> <18B15EF7-5F22-4E8F-AFD4-737A67E03B51@ecs.soton.ac.uk> To: IPv6 Operations , ops-ads@tools.ietf.org X-Mailer: Apple Mail (2.1244.3) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n6RJuh036615325400; tid=n6RJuh0366153254m0; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p6SIuhRk024391 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:56:49 -0000 On 28 Jul 2011, at 17:56, Francis Dupont wrote: > In your previous mail you wrote: >=20 > [WEG] tl;dr version - speaking for myself, probably not, because I > think that more meetings is treating the symptom, not the > underlying cause. I think this is a charter/goals problem causing a > workload/meeting problem, not a workload problem causing a meeting > problem. >=20 > =3D> I tried to find the reason for an interim meeting and this led me > to the same conclusion... I was quite surprised to see the volume of drafts at = http://tools.ietf.org/wg/v6ops/, though only 4 are current WG active = drafts, with 3 more at the IESG phase. It's quite interesting the tools system includes/reveals some personal = drafts from nearly 10 years ago. It would be good to get some prioritisation on which drafts are the = highest value to work on, if there's 4 WG drafts and about 35 personal = drafts that are current (published/updated in 2011). Tim= From xing@cernet.edu.cn Thu Jul 28 12:21:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2ECA1F0C39 for ; Thu, 28 Jul 2011 12:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.512 X-Spam-Level: X-Spam-Status: No, score=-99.512 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPRujAh3dgBu for ; Thu, 28 Jul 2011 12:21:45 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 7F3AE5E801D for ; Thu, 28 Jul 2011 12:21:43 -0700 (PDT) Received: from [127.0.0.1]([130.129.19.192]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm74e31f46d; Fri, 29 Jul 2011 03:21:40 +0800 Message-ID: <4E31B2CD.7050507@cernet.edu.cn> Date: Fri, 29 Jul 2011 03:04:45 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ray Hunter References: <4E3071B6.3060807@globis.net> In-Reply-To: <4E3071B6.3060807@globis.net> Content-Type: multipart/alternative; boundary="------------000300070704080205080309" X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: cbWJ6m0B Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:21:49 -0000 This is a multi-part message in MIME format. --------------000300070704080205080309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Ray, Thanks for your mail. See inline. ? 2011/7/28 4:14, Ray Hunter ??: > Am I permitted to ask some dumb questions about this draft since it > seems to be urgent? > > The draft talks about translating IPv6 ICMPv6 responses back to a > special shared /24 public IPv4 source range where responses are not > 1:1 IPv6 source - IPv4 source mappable (presumably because network > links and equipment on the IPv6 side are using IPv6 space from outside > the mapped range). > > Don't we have this situation already when traversing multiple IPv4 > networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN links? > > In that case doesn't ICMP just have to live with an RFC1918 source > address, and no one seems to have complained too bitterly so far? Yes, using this special shared /24 will not introduce new problems compared with using RFC1918 space. > > What's so special about this new IPv6 mapped situation that is > different to the existing situation of overlapping RFC 1918 addresses > used by multiple providers, where it's already unclear which unique > node on the path generated the ICMP message, and where uRPF filters > would already be an issue? > > i.e. why should the ICMP messages just not be dropped in this case at > the AS border, or be sent with RFC 1918 source addresses within an AS, > or be sent using a source address from a globally unique (/24) > sub-range of the existing provider IPv4 space assigned to the > translator if they are so important? Introducing a new well-known IPv4 block can help to identify that the ICMP messages are actually translated from IPv6, which will make the management and trouble shooting easier. > > I'm sorry, and maybe it's me being totally dumb, but I just don't see > the added value of a "special" /24 shared amongst multiple providers, > especially if there are possibly multiple translators and multiple > providers on a path. It just doesn't seem to give any significant > extra information to the intended recipient, and if anything may lead > to more confusion. 128 into 32 doesn't go. End of story. > > regards, > RayH Regards, xing > >> Subject: >> [v6ops] Fwd: Request for WG Adoption of >> draft-xli-v6ops-ivi-icmp-address-00 >> From: >> Fred Baker >> Date: >> Wed, 27 Jul 2011 14:40:59 -0400 >> >> To: >> IPv6 Operations >> >> Content-Transfer-Encoding: >> quoted-printable >> Precedence: >> list >> MIME-Version: >> 1.0 (Apple Message framework v1084) >> References: >> <4E2ED0F0.1070301@cernet.edu.cn> >> Message-ID: >> >> Content-Type: >> text/plain; charset=us-ascii >> Message: >> 6 >> >> >> Folks: the chairs are in receipt of this note. Please read the draft and comment. >> >> In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment. >> >> Begin forwarded message: >> >> >>> > From: Xing Li >>> > Date: July 26, 2011 10:36:32 AM EDT >>> > To:v6ops-chairs@tools.ietf.org >>> > Cc:v6ops@ietf.org,draft-xli-v6ops-ivi-icmp-address@tools.ietf.org >>> > Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 >>> > >>> > Hi V6ops Chairs, >>> > >>> > The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption. >>> > >>> > The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4. >>> > >>> > The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list. >>> > >>> > regards, >>> > >>> > Xing Li >>> > >>> > >>> > >>> > >>> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------000300070704080205080309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Ray,

Thanks for your mail. See inline.

于 2011/7/28 4:14, Ray Hunter 写道:
Am I permitted to ask some dumb questions about this draft since it seems to be urgent?

The draft talks about translating IPv6 ICMPv6 responses back to a special shared /24 public IPv4 source range where responses are not 1:1 IPv6 source - IPv4 source mappable (presumably because network links and equipment on the IPv6 side are using IPv6 space from outside the mapped range).

Don't we have this situation already when traversing multiple IPv4 networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN links?

In that case doesn't ICMP just have to live with an RFC1918 source address, and no one seems to have complained too bitterly so far?

Yes,  using this special shared /24 will not introduce new problems compared with using RFC1918 space. 


What's so special about this new IPv6 mapped situation that is different to the existing situation of overlapping RFC 1918 addresses used by multiple providers, where it's already unclear which unique node on the path generated the ICMP message, and where uRPF filters would already be an issue?

i.e. why should the ICMP messages just not be dropped in this case at the AS border, or be sent with RFC 1918 source addresses within an AS, or be sent using a source address from a globally unique (/24) sub-range of the existing provider IPv4 space assigned to the translator if they are so important?

Introducing a new well-known IPv4 block can help  to identify that the ICMP messages are actually translated from IPv6, which will make the management and trouble shooting easier.


I'm sorry, and maybe it's me being totally dumb, but I just don't see the added value of a "special" /24 shared amongst multiple providers, especially if there are possibly multiple translators and multiple providers on a path. It just doesn't seem to give any significant extra information to the intended recipient, and if anything may lead to more confusion. 128 into 32 doesn't go. End of story.

regards,
RayH

Regards,

xing


Subject:
[v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
From:
Fred Baker <fred@cisco.com>
Date:
Wed, 27 Jul 2011 14:40:59 -0400
To:
IPv6 Operations <v6ops@ietf.org>
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1084)
References:
<4E2ED0F0.1070301@cernet.edu.cn>
Message-ID:
<FEA206CA-692A-443E-A2C5-8C437D0AB42A@cisco.com>
Content-Type:
text/plain; charset=us-ascii
Message:
6		 

Folks: the chairs are in receipt of this note. Please read the draft and comment.

In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment.

Begin forwarded message:

  
> From: Xing Li <xing@cernet.edu.cn>
> Date: July 26, 2011 10:36:32 AM EDT
> To: v6ops-chairs@tools.ietf.org
> Cc: v6ops@ietf.org, draft-xli-v6ops-ivi-icmp-address@tools.ietf.org
> Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
> 
> Hi V6ops Chairs,
> 
> The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption.
> 
> The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4.
> 
> The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list.
> 
> regards,
> 
> Xing Li
> 
> 
> 
> 
    

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

--------------000300070704080205080309-- From xing@cernet.edu.cn Thu Jul 28 12:21:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A898611E809E for ; Thu, 28 Jul 2011 12:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.477 X-Spam-Level: X-Spam-Status: No, score=-99.477 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5aNJeDflinE for ; Thu, 28 Jul 2011 12:21:48 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 0B3C95E8010 for ; Thu, 28 Jul 2011 12:21:45 -0700 (PDT) Received: from [127.0.0.1]([130.129.19.192]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm104e31f471; Fri, 29 Jul 2011 03:21:44 +0800 Message-ID: <4E31B4DA.1030700@cernet.edu.cn> Date: Fri, 29 Jul 2011 03:13:30 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ray Hunter References: <4E3071B6.3060807@globis.net> <851D47FA-41FB-4845-A2A4-A259CCE77D39@cisco.com> <4E30CF01.9000705@globis.net> In-Reply-To: <4E30CF01.9000705@globis.net> Content-Type: multipart/alternative; boundary="------------070508000002090506000704" X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: cc0J6m0B Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:21:51 -0000 This is a multi-part message in MIME format. --------------070508000002090506000704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Ray, ? 2011/7/28 10:52, Ray Hunter ??: > The concern would be that the special /24 is creating a new range that: > > - carries ICMP control messages, which could also be used to attempt > to alter a senders' behavior > - is shared between multiple providers > - is not traceable When the special /24 is used, it can identify that the ICMP messages are generated in IPv6. > - should not be filtered at AS boundaries > > which could grant an attacker a perfect set of source addresses for > mounting a DDOS attack. > > Yes the range isn't routable as a destination, but that possibly makes > it even worse, as the target of any DDOS sourced from this range would > have absolutely no idea who was sending them the huge volume of junk > packets, except by incoming interface at the AS boundary. I see no > reason why a network operator would want to accept such a packet from > another AS into their network, so they'll basically get filtered > everywhere after the very first attack IMHO. As partially discussed in previous mail. This will not introduce new issues compared with using RFC1918 space. In Section 6 of this draft says 6. Security Considerations The use of an address for source addresses in ICMP packets is considered "safe" in so far as ICMP packets are not intended to generate responses directed to the source address. However it is possible to use this address as a means of gaining anonymity when launching a denial of service attacks by using this address as the source address for other forms of malicious traffic. Packet firewall filters should be configured to treat addresses in the IANA-assigned /24 network as martian addresses by discarding all non-ICMP packets that use the IANA-assigned /24 network as a source address, and all packets that use the IANA-assigned /24 network as a destination address. Regards, xing > > regards, > RayH > > Fred Baker wrote: >> On Jul 27, 2011, at 4:14 PM, Ray Hunter wrote: >> >>> Am I permitted to ask some dumb questions about this draft since it >>> seems to be urgent? >> >> Certainly. I will ask the authors to respond to them. >> >>> The draft talks about translating IPv6 ICMPv6 responses back to a >>> special shared /24 public IPv4 source range where responses are not >>> 1:1 IPv6 source - IPv4 source mappable (presumably because network >>> links and equipment on the IPv6 side are using IPv6 space from >>> outside the mapped range). >>> >>> Don't we have this situation already when traversing multiple IPv4 >>> networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN >>> links? >>> >>> In that case doesn't ICMP just have to live with an RFC1918 source >>> address, and no one seems to have complained too bitterly so far? >>> >>> What's so special about this new IPv6 mapped situation that is >>> different to the existing situation of overlapping RFC 1918 >>> addresses used by multiple providers, where it's already unclear >>> which unique node on the path generated the ICMP message, and where >>> uRPF filters would already be an issue? >>> >>> i.e. why should the ICMP messages just not be dropped in this case >>> at the AS border, or be sent with RFC 1918 source addresses within >>> an AS, or be sent using a source address from a globally unique >>> (/24) sub-range of the existing provider IPv4 space assigned to the >>> translator if they are so important? >>> >>> I'm sorry, and maybe it's me being totally dumb, but I just don't >>> see the added value of a "special" /24 shared amongst multiple >>> providers, especially if there are possibly multiple translators and >>> multiple providers on a path. It just doesn't seem to give any >>> significant extra information to the intended recipient, and if >>> anything may lead to more confusion. 128 into 32 doesn't go. End of >>> story. >>> >>> regards, >>> RayH >>> >>>> Subject: >>>> [v6ops] Fwd: Request for WG Adoption of >>>> draft-xli-v6ops-ivi-icmp-address-00 >>>> From: >>>> Fred Baker >>>> Date: >>>> Wed, 27 Jul 2011 14:40:59 -0400 >>>> >>>> To: >>>> IPv6 Operations >>>> >>>> Content-Transfer-Encoding: >>>> quoted-printable >>>> Precedence: >>>> list >>>> MIME-Version: >>>> 1.0 (Apple Message framework v1084) >>>> References: >>>> <4E2ED0F0.1070301@cernet.edu.cn> >>>> Message-ID: >>>> >>>> Content-Type: >>>> text/plain; charset=us-ascii >>>> Message: >>>> 6 >>>> >>>> >>>> Folks: the chairs are in receipt of this note. Please read the draft and comment. >>>> >>>> In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment. >>>> >>>> Begin forwarded message: >>>> >>>> >>>>> > From: Xing Li >>>>> > Date: July 26, 2011 10:36:32 AM EDT >>>>> > To:v6ops-chairs@tools.ietf.org >>>>> > Cc:v6ops@ietf.org,draft-xli-v6ops-ivi-icmp-address@tools.ietf.org >>>>> > Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 >>>>> > >>>>> > Hi V6ops Chairs, >>>>> > >>>>> > The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption. >>>>> > >>>>> > The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4. >>>>> > >>>>> > The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list. >>>>> > >>>>> > regards, >>>>> > >>>>> > Xing Li >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------070508000002090506000704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Ray,

于 2011/7/28 10:52, Ray Hunter 写道:
The concern would be that the special /24 is creating a new range that:

- carries ICMP control messages, which could also be used to attempt to alter a senders' behavior
- is shared between multiple providers
- is not traceable

When the special /24 is used, it can identify that the ICMP messages are generated in IPv6.
- should not be filtered at AS boundaries

which could grant an attacker a perfect set of source addresses for mounting a DDOS attack.

Yes the range isn't routable as a destination, but that possibly makes it even worse, as the target of any DDOS sourced from this range would have absolutely no idea who was sending them the huge volume of junk packets, except by incoming interface at the AS boundary. I see no reason why a network operator would want to accept such a packet from another AS into their network, so they'll basically get filtered everywhere after the very first attack IMHO.

As partially discussed in previous mail. This will not introduce new issues compared with using RFC1918 space. In Section 6 of this draft says

6.  Security Considerations

   The use of an address for source addresses in ICMP packets is
   considered "safe" in so far as ICMP packets are not intended to
   generate responses directed to the source address.

   However it is possible to use this address as a means of gaining
   anonymity when launching a denial of service attacks by using this
   address as the source address for other forms of malicious traffic.
   Packet firewall filters should be configured to treat addresses in
   the IANA-assigned /24 network as martian addresses by discarding all
   non-ICMP packets that use the IANA-assigned /24 network as a source
   address, and all packets that use the IANA-assigned /24 network as a
   destination address.

Regards,

xing


regards,
RayH

Fred Baker wrote:
On Jul 27, 2011, at 4:14 PM, Ray Hunter wrote:

Am I permitted to ask some dumb questions about this draft since it seems to be urgent?

Certainly. I will ask the authors to respond to them.

The draft talks about translating IPv6 ICMPv6 responses back to a special shared /24 public IPv4 source range where responses are not 1:1 IPv6 source - IPv4 source mappable (presumably because network links and equipment on the IPv6 side are using IPv6 space from outside the mapped range).

Don't we have this situation already when traversing multiple IPv4 networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN links?

In that case doesn't ICMP just have to live with an RFC1918 source address, and no one seems to have complained too bitterly so far?

What's so special about this new IPv6 mapped situation that is different to the existing situation of overlapping RFC 1918 addresses used by multiple providers, where it's already unclear which unique node on the path generated the ICMP message, and where uRPF filters would already be an issue?

i.e. why should the ICMP messages just not be dropped in this case at the AS border, or be sent with RFC 1918 source addresses within an AS, or be sent using a source address from a globally unique (/24) sub-range of the existing provider IPv4 space assigned to the translator if they are so important?

I'm sorry, and maybe it's me being totally dumb, but I just don't see the added value of a "special" /24 shared amongst multiple providers, especially if there are possibly multiple translators and multiple providers on a path. It just doesn't seem to give any significant extra information to the intended recipient, and if anything may lead to more confusion. 128 into 32 doesn't go. End of story.

regards,
RayH

Subject:
[v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
From:
Fred Baker <fred@cisco.com>
Date:
Wed, 27 Jul 2011 14:40:59 -0400
To:
IPv6 Operations <v6ops@ietf.org>
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1084)
References:
<4E2ED0F0.1070301@cernet.edu.cn>
Message-ID:
<FEA206CA-692A-443E-A2C5-8C437D0AB42A@cisco.com>
Content-Type:
text/plain; charset=us-ascii
Message:
6		 

Folks: the chairs are in receipt of this note. Please read the draft and comment.

In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment.

Begin forwarded message:

  
> From: Xing Li <xing@cernet.edu.cn>
> Date: July 26, 2011 10:36:32 AM EDT
> To: v6ops-chairs@tools.ietf.org
> Cc: v6ops@ietf.org, draft-xli-v6ops-ivi-icmp-address@tools.ietf.org
> Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
> 
> Hi V6ops Chairs,
> 
> The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption.
> 
> The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4.
> 
> The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list.
> 
> regards,
> 
> Xing Li
> 
> 
> 
> 
    


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

--------------070508000002090506000704-- From v6ops@globis.net Thu Jul 28 13:09:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB53021F8AD9 for ; Thu, 28 Jul 2011 13:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aabK2MjAEEin for ; Thu, 28 Jul 2011 13:09:24 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 34D8E21F8AD6 for ; Thu, 28 Jul 2011 13:09:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8F6F48700EE; Thu, 28 Jul 2011 22:09:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFxSZ50wlIJ0; Thu, 28 Jul 2011 22:09:13 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id AB18887006B; Thu, 28 Jul 2011 22:09:13 +0200 (CEST) Message-ID: <4E31C1E9.1050706@globis.net> Date: Thu, 28 Jul 2011 22:09:13 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Xing Li References: <4E3071B6.3060807@globis.net> <851D47FA-41FB-4845-A2A4-A259CCE77D39@cisco.com> <4E30CF01.9000705@globis.net> <4E31B4DA.1030700@cernet.edu.cn> In-Reply-To: <4E31B4DA.1030700@cernet.edu.cn> Content-Type: multipart/alternative; boundary="------------090004010004040905000705" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:09:29 -0000 This is a multi-part message in MIME format. --------------090004010004040905000705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Following all IMVHO. Sorry I'm not convinced. It isn't just packet firewalls that are going to need/want to drop these packets. Imagine I'm acting as the responsible owner of an AS. Under this proposal I have all downside and no upside. Let me explain..... If this range is going to be used for sourcing DDOS traffic (and I strongly suspect it will), and it isn't going to be possible to easily isolate or debug which upstream AS or site or network interface or customer device was the source of that bad traffic, then the packets need to get dropped at the AS border and every other uncontrolled entry point on the network that connects to third party managed devices. I don't want untraceable packets sourced by someone else floating around in my network and potentially causing trouble tickets / problems that cost my staff's and my management time. Equally, if I'm acting as a responsible network operator, I don't want to act as a transit on a potential DDOS attack to other AS'es to avoid hurting my own good reputation (the downstream AS will have no idea if the DDOS attack originated in my AS, or another upstream AS, and my AS was just acting as a transit). Either way I'd look daft, and the DDOS attack would be difficult or impossible to trace: which is precisely one reason why ingress filters were recommended in the first place. So all ingress and egress filters will probably end up dropping the new special range, and no one will be any the wiser. In which case, using the special /24 shared range is actually less useful compared to just using a locally significant and existing RFC1918 range of addresses for each translator in my network for the translation of IMCPv6 messages sourced behind my own IPv6/IPv4 translator(s) IMHO. At least then I and my staff would know exactly which translator the ICMP message came from in my AS if there was more than one translator present, and I'd be able to take corrective action if necessary. Plus I'd know for certain if I saw such RFC1918 sourced ICMP traffic in my AS that they weren't sourced from someone else's translator in another AS that I don't even manage. And yes packets with RFC1918 source-addresses would also be dropped at the AS border, as today. regards, RayH Xing Li wrote: > Hi, Ray, > > ? 2011/7/28 10:52, Ray Hunter ??: >> The concern would be that the special /24 is creating a new range that: >> >> - carries ICMP control messages, which could also be used to attempt >> to alter a senders' behavior >> - is shared between multiple providers >> - is not traceable > > When the special /24 is used, it can identify that the ICMP messages > are generated in IPv6. >> - should not be filtered at AS boundaries >> >> which could grant an attacker a perfect set of source addresses for >> mounting a DDOS attack. >> >> Yes the range isn't routable as a destination, but that possibly >> makes it even worse, as the target of any DDOS sourced from this >> range would have absolutely no idea who was sending them the huge >> volume of junk packets, except by incoming interface at the AS >> boundary. I see no reason why a network operator would want to accept >> such a packet from another AS into their network, so they'll >> basically get filtered everywhere after the very first attack IMHO. > > As partially discussed in previous mail. This will not introduce new > issues compared with using RFC1918 space. In Section 6 of this draft says > > 6. Security Considerations > > The use of an address for source addresses in ICMP packets is > considered "safe" in so far as ICMP packets are not intended to > generate responses directed to the source address. > > However it is possible to use this address as a means of gaining > anonymity when launching a denial of service attacks by using this > address as the source address for other forms of malicious traffic. > Packet firewall filters should be configured to treat addresses in > the IANA-assigned /24 network as martian addresses by discarding all > non-ICMP packets that use the IANA-assigned /24 network as a source > address, and all packets that use the IANA-assigned /24 network as a > destination address. > > Regards, > > xing > > > >> regards, >> RayH >> >> Fred Baker wrote: >>> On Jul 27, 2011, at 4:14 PM, Ray Hunter wrote: >>> >>>> Am I permitted to ask some dumb questions about this draft since it >>>> seems to be urgent? >>> >>> Certainly. I will ask the authors to respond to them. >>> >>>> The draft talks about translating IPv6 ICMPv6 responses back to a >>>> special shared /24 public IPv4 source range where responses are not >>>> 1:1 IPv6 source - IPv4 source mappable (presumably because network >>>> links and equipment on the IPv6 side are using IPv6 space from >>>> outside the mapped range). >>>> >>>> Don't we have this situation already when traversing multiple IPv4 >>>> networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN >>>> links? >>>> >>>> In that case doesn't ICMP just have to live with an RFC1918 source >>>> address, and no one seems to have complained too bitterly so far? >>>> >>>> What's so special about this new IPv6 mapped situation that is >>>> different to the existing situation of overlapping RFC 1918 >>>> addresses used by multiple providers, where it's already unclear >>>> which unique node on the path generated the ICMP message, and where >>>> uRPF filters would already be an issue? >>>> >>>> i.e. why should the ICMP messages just not be dropped in this case >>>> at the AS border, or be sent with RFC 1918 source addresses within >>>> an AS, or be sent using a source address from a globally unique >>>> (/24) sub-range of the existing provider IPv4 space assigned to the >>>> translator if they are so important? >>>> >>>> I'm sorry, and maybe it's me being totally dumb, but I just don't >>>> see the added value of a "special" /24 shared amongst multiple >>>> providers, especially if there are possibly multiple translators >>>> and multiple providers on a path. It just doesn't seem to give any >>>> significant extra information to the intended recipient, and if >>>> anything may lead to more confusion. 128 into 32 doesn't go. End of >>>> story. >>>> >>>> regards, >>>> RayH >>>> >>>>> Subject: >>>>> [v6ops] Fwd: Request for WG Adoption of >>>>> draft-xli-v6ops-ivi-icmp-address-00 >>>>> From: >>>>> Fred Baker >>>>> Date: >>>>> Wed, 27 Jul 2011 14:40:59 -0400 >>>>> >>>>> To: >>>>> IPv6 Operations >>>>> >>>>> Content-Transfer-Encoding: >>>>> quoted-printable >>>>> Precedence: >>>>> list >>>>> MIME-Version: >>>>> 1.0 (Apple Message framework v1084) >>>>> References: >>>>> <4E2ED0F0.1070301@cernet.edu.cn> >>>>> Message-ID: >>>>> >>>>> Content-Type: >>>>> text/plain; charset=us-ascii >>>>> Message: >>>>> 6 >>>>> >>>>> >>>>> Folks: the chairs are in receipt of this note. Please read the draft and comment. >>>>> >>>>> In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment. >>>>> >>>>> Begin forwarded message: >>>>> >>>>> >>>>>> > From: Xing Li >>>>>> > Date: July 26, 2011 10:36:32 AM EDT >>>>>> > To:v6ops-chairs@tools.ietf.org >>>>>> > Cc:v6ops@ietf.org,draft-xli-v6ops-ivi-icmp-address@tools.ietf.org >>>>>> > Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 >>>>>> > >>>>>> > Hi V6ops Chairs, >>>>>> > >>>>>> > The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption. >>>>>> > >>>>>> > The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4. >>>>>> > >>>>>> > The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list. >>>>>> > >>>>>> > regards, >>>>>> > >>>>>> > Xing Li >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> --------------090004010004040905000705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Following all IMVHO.

Sorry I'm not convinced. It isn't just packet firewalls that are going to need/want to drop these packets.

Imagine I'm acting as the responsible owner of an AS. Under this proposal I have all downside and no upside. Let me explain.....

If this range is going to be used for sourcing DDOS traffic (and I strongly suspect it will), and it isn't going to be possible to easily isolate or debug which upstream AS or site or network interface or customer device was the source of that bad traffic, then the packets need to get dropped at the AS border and every other uncontrolled entry point on the network that connects to third party managed devices. I don't want untraceable packets sourced by someone else floating around in my network and potentially causing trouble tickets / problems that cost my staff's and my management time.

Equally, if I'm acting as a responsible network operator, I don't want to act as a transit on a potential DDOS attack to other AS'es to avoid hurting my own good reputation (the downstream AS will have no idea if the DDOS attack originated in my AS, or another upstream AS, and my AS was just acting as a transit). Either way I'd look daft, and the DDOS attack would be difficult or impossible to trace: which is precisely one reason why ingress filters were recommended in the first place.

So all ingress and egress filters will probably end up dropping the new special range, and no one will be any the wiser.

In which case, using the special /24 shared range is actually less useful compared to just using a locally significant and existing  RFC1918 range of addresses for each translator in my network for the translation of IMCPv6 messages sourced behind my own IPv6/IPv4 translator(s) IMHO. At least then I and my staff would know exactly which translator the ICMP message came from in my AS if there was more than one translator present, and I'd be able to take corrective action if necessary.  Plus I'd know for certain if I saw such RFC1918 sourced ICMP traffic in my AS that they weren't sourced from someone else's translator in another AS that I don't even manage. And yes packets with RFC1918 source-addresses would also be dropped at the AS border, as today.

regards,
RayH


Xing Li wrote:
Hi, Ray,

于 2011/7/28 10:52, Ray Hunter 写道:
The concern would be that the special /24 is creating a new range that:

- carries ICMP control messages, which could also be used to attempt to alter a senders' behavior
- is shared between multiple providers
- is not traceable

When the special /24 is used, it can identify that the ICMP messages are generated in IPv6.
- should not be filtered at AS boundaries

which could grant an attacker a perfect set of source addresses for mounting a DDOS attack.

Yes the range isn't routable as a destination, but that possibly makes it even worse, as the target of any DDOS sourced from this range would have absolutely no idea who was sending them the huge volume of junk packets, except by incoming interface at the AS boundary. I see no reason why a network operator would want to accept such a packet from another AS into their network, so they'll basically get filtered everywhere after the very first attack IMHO.

As partially discussed in previous mail. This will not introduce new issues compared with using RFC1918 space. In Section 6 of this draft says

6.  Security Considerations

   The use of an address for source addresses in ICMP packets is
   considered "safe" in so far as ICMP packets are not intended to
   generate responses directed to the source address.

   However it is possible to use this address as a means of gaining
   anonymity when launching a denial of service attacks by using this
   address as the source address for other forms of malicious traffic.
   Packet firewall filters should be configured to treat addresses in
   the IANA-assigned /24 network as martian addresses by discarding all
   non-ICMP packets that use the IANA-assigned /24 network as a source
   address, and all packets that use the IANA-assigned /24 network as a
   destination address.

Regards,

xing

regards,
RayH

Fred Baker wrote:
On Jul 27, 2011, at 4:14 PM, Ray Hunter wrote:

Am I permitted to ask some dumb questions about this draft since it seems to be urgent?

Certainly. I will ask the authors to respond to them.

The draft talks about translating IPv6 ICMPv6 responses back to a special shared /24 public IPv4 source range where responses are not 1:1 IPv6 source - IPv4 source mappable (presumably because network links and equipment on the IPv6 side are using IPv6 space from outside the mapped range).

Don't we have this situation already when traversing multiple IPv4 networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN links?

In that case doesn't ICMP just have to live with an RFC1918 source address, and no one seems to have complained too bitterly so far?

What's so special about this new IPv6 mapped situation that is different to the existing situation of overlapping RFC 1918 addresses used by multiple providers, where it's already unclear which unique node on the path generated the ICMP message, and where uRPF filters would already be an issue?

i.e. why should the ICMP messages just not be dropped in this case at the AS border, or be sent with RFC 1918 source addresses within an AS, or be sent using a source address from a globally unique (/24) sub-range of the existing provider IPv4 space assigned to the translator if they are so important?

I'm sorry, and maybe it's me being totally dumb, but I just don't see the added value of a "special" /24 shared amongst multiple providers, especially if there are possibly multiple translators and multiple providers on a path. It just doesn't seem to give any significant extra information to the intended recipient, and if anything may lead to more confusion. 128 into 32 doesn't go. End of story.

regards,
RayH

Subject:
[v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
From:
Fred Baker <fred@cisco.com>
Date:
Wed, 27 Jul 2011 14:40:59 -0400
To:
IPv6 Operations <v6ops@ietf.org>
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1084)
References:
<4E2ED0F0.1070301@cernet.edu.cn>
Message-ID:
<FEA206CA-692A-443E-A2C5-8C437D0AB42A@cisco.com>
Content-Type:
text/plain; charset=us-ascii
Message:
6		 

Folks: the chairs are in receipt of this note. Please read the draft and comment.

In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment.

Begin forwarded message:

  
> From: Xing Li <xing@cernet.edu.cn>
> Date: July 26, 2011 10:36:32 AM EDT
> To: v6ops-chairs@tools.ietf.org
> Cc: v6ops@ietf.org, draft-xli-v6ops-ivi-icmp-address@tools.ietf.org
> Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
> 
> Hi V6ops Chairs,
> 
> The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption.
> 
> The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4.
> 
> The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list.
> 
> regards,
> 
> Xing Li
> 
> 
> 
> 
    


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

--------------090004010004040905000705-- From fernando.gont.netbook.win@gmail.com Thu Jul 28 13:40:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C115E8010 for ; Thu, 28 Jul 2011 13:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znFJE1MZNL9o for ; Thu, 28 Jul 2011 13:40:43 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id D16675E800E for ; Thu, 28 Jul 2011 13:40:42 -0700 (PDT) Received: by yie30 with SMTP id 30so2584453yie.31 for ; Thu, 28 Jul 2011 13:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=EThAToh7n4xAs66hVO9KOCMQNSdkq4iwDoWg+nqIheQ=; b=cNlfR8g5r8jRJzgV3QKwcP5U9baFknIANryrFFT3sJov8uSi2yf4XTAmg+/b4fFW/v gPN+C8WrVh82/Fm2rCkVbiZ3Nf7mExpMwYSYRU9LU/YhyjlCNRI36QXNNlaPBFL1Cqbz HrElg68rx9haEiZEptCjv1MIQ2bI1SuHqcA3Q= Received: by 10.101.99.2 with SMTP id b2mr404960anm.47.1311885642255; Thu, 28 Jul 2011 13:40:42 -0700 (PDT) Received: from [192.168.123.103] ([190.48.251.24]) by mx.google.com with ESMTPS id o7sm1031939anj.36.2011.07.28.13.40.39 (version=SSLv3 cipher=OTHER); Thu, 28 Jul 2011 13:40:41 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E31C945.5060402@gont.com.ar> Date: Thu, 28 Jul 2011 17:40:37 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: IPv6 Operations X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: V6ops Chairs Subject: [v6ops] Presentation about ra-guard evasion (draft-gont-v6ops-ra-guard-evasion) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 20:40:43 -0000 Folks, A few minutes ago it was asked in the v6ops meeting whether adopting draft-gont-v6ops-ra-guard-evasion would step over 6man's work. I'd note that ra-gurd itself was produced by v6ops, and *not* 6man, and that is why I think this document should be pursued in this working group -- i.e., I see no reason for which an update to a document produced here (RFC6105) should be produced elsewhere. That aside, the filtering checks that are proposed in the aforementioned document are an operational mitigation to the described issues. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From gvandeve@cisco.com Thu Jul 28 14:06:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D1D11E80A8 for ; Thu, 28 Jul 2011 14:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uupfWGWlH+h for ; Thu, 28 Jul 2011 14:06:49 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0567311E8081 for ; Thu, 28 Jul 2011 14:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=2831; q=dns/txt; s=iport; t=1311887209; x=1313096809; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=O1otj5uwZGsE2hcUhnG3VC/nC8hY2abTWfuwDpH/ujU=; b=AFTp2I60VUMSQzNB7TGAtjkM1daMw+PpAmyoWYq/59gllZz7/zBIjcjA QahEX9WWaUD5xr747ytmjtuXqt9mxDGd8hWLNEI65JsdrOQCzlD7qatw8 PW95H+aaUg6XLKCweVFGdz6UHXMBWRV7zK9T9o3UuYhn1nqEAHmqg2VPq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACnPMU6Q/khR/2dsb2JhbAA0AQEBAQMBAQERASEKOgsMBQIBCREEAQELBiMBBgETGCMOCAEBBQEWDBQHpzp3iQCkeZ48hWJfBJgJi1Y X-IronPort-AV: E=Sophos;i="4.67,284,1309737600"; d="scan'208";a="45229612" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 28 Jul 2011 21:06:28 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6SL6SOF031589; Thu, 28 Jul 2011 21:06:28 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 23:06:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 23:06:26 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E504194BC8@XMB-AMS-101.cisco.com> In-Reply-To: <4E31C945.5060402@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Presentation about ra-guard evasion(draft-gont-v6ops-ra-guard-evasion) Thread-Index: AcxNZqnLfjqWQd5ETfGrSqowRZJMMQAAL5WA References: <4E31C945.5060402@gont.com.ar> From: "Gunter Van de Velde (gvandeve)" To: "Fernando Gont" , "IPv6 Operations" X-OriginalArrivalTime: 28 Jul 2011 21:06:28.0426 (UTC) FILETIME=[37C262A0:01CC4D6A] Cc: V6ops Chairs Subject: Re: [v6ops] Presentation about ra-guard evasion(draft-gont-v6ops-ra-guard-evasion) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 21:06:50 -0000 Hi Fernando, [Speaking as one of the co-authors of RA-Guard] The 'informational' RA-Guard paper was created on v6OPS because it describes a=20 method to mainly avoid misconfiguration. It is something that protects the access=20 layer better as nothing. For the most part it is a poor man solution and not at all a full flavor security solution. That is acknowledged in the RFC6105 in the abstract: " Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. " And more references to this are made later in the paper. IMHO the full solution for rogue RA's is SEND ... and not an even more complex form of RA-Guard and make it less Lite. Some of the elements documented are also valid for existing IPv4 and IPv6 Access-lists and other xxx-Guard=20 mechanisms.=20 In 6man meeting there were some serious flaws discussed in the proposed solutions as they break IPv6 technology=20 elements. (i.e. dropping RA packets with fragments, could break SEND where the certificate is larger as the=20 link MTU... there were more and I guess those can be found in the minutes soon). So looking at the fact RA-Guard is a lightweight protocol, and the evasion techniques discussed are quite=20 known as traditional mechanisms to also bypass most traditional access-lists, I think that changing any=20 protocol aspects does not make much sense... G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fernando Gont Sent: 28 July 2011 16:41 To: IPv6 Operations Cc: V6ops Chairs Subject: [v6ops] Presentation about ra-guard evasion(draft-gont-v6ops-ra-guard-evasion) Folks, A few minutes ago it was asked in the v6ops meeting whether adopting draft-gont-v6ops-ra-guard-evasion would step over 6man's work. I'd note that ra-gurd itself was produced by v6ops, and *not* 6man, and that is why I think this document should be pursued in this working group -- i.e., I see no reason for which an update to a document produced here (RFC6105) should be produced elsewhere. That aside, the filtering checks that are proposed in the aforementioned document are an operational mitigation to the described issues. Thanks, --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From wesley.george@twcable.com Thu Jul 28 14:09:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1FB21F855B for ; Thu, 28 Jul 2011 14:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.749 X-Spam-Level: X-Spam-Status: No, score=0.749 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk6cputY2jvE for ; Thu, 28 Jul 2011 14:09:30 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0A021F855A for ; Thu, 28 Jul 2011 14:09:30 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,284,1309752000"; d="scan'208,217";a="241142657" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 28 Jul 2011 17:07:13 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 28 Jul 2011 17:09:29 -0400 From: "George, Wesley" To: IPv6 Operations Date: Thu, 28 Jul 2011 17:09:27 -0400 Thread-Topic: comments on draft-chen-v6ops-ipv6-bearer-network-trials Thread-Index: AcxNaqKPbm0DtD0/TIis3CfiEexK8w== Message-ID: <34E4F50CAFA10349A41E0756550084FB0BEECA65@PRVPEXVS04.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_34E4F50CAFA10349A41E0756550084FB0BEECA65PRVPEXVS04corpt_" MIME-Version: 1.0 Subject: [v6ops] comments on draft-chen-v6ops-ipv6-bearer-network-trials X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 21:09:32 -0000 --_000_34E4F50CAFA10349A41E0756550084FB0BEECA65PRVPEXVS04corpt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To echo my comments at the mic - I'd recommend the MTU consideration be phrased in terms of the fact that th= e transport network should be designed to handle standard MTU (1500byte pay= load) plus any encaps overhead, rather than the end-user payload being redu= ced to meet a low MTU in the core. A review of 4459 may provide some text of use. Regarding the testing results - it would be helpful to classify which items= failed testing because of a known lack of vendor support vs items which fa= iled due to bugs or claimed vendor support that was incomplete or missing. = Naming and shaming is sometimes a good way to ensure that vendors pay close= r attention before claiming support for something, or warning others to be = aware of the problem. Also, this is interesting as a snapshot of your network, but the draft woul= d be more useful (and therefore more likely to be adopted as a WG draft) if= it identifies problems that the IETF (this WG or others) can help to solve= , gaps, broken things, BCP recommendations, etc. Thanks, Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_34E4F50CAFA10349A41E0756550084FB0BEECA65PRVPEXVS04corpt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To echo my comments at the mic –

 

I’d recommend the MTU consideration be phrased= in terms of the fact that the transport network should be designed to hand= le standard MTU (1500byte payload) plus any encaps overhead, rather than th= e end-user payload being reduced to meet a low MTU in the core.

A review of 4459 may provide some text of use.<= /o:p>

 

Regarding the testing results – it would be he= lpful to classify which items failed testing because of a known lack of ven= dor support vs items which failed due to bugs or claimed vendor support tha= t was incomplete or missing. Naming and shaming is sometimes a good way to ensure that vendors pay closer attentio= n before claiming support for something, or warning others to be aware of t= he problem.

 

Also, this is interesting as a snapshot of your netw= ork, but the draft would be more useful (and therefore more likely to be ad= opted as a WG draft) if it identifies problems that the IETF (this WG or ot= hers) can help to solve, gaps, broken things, BCP recommendations, etc.

 

Thanks,

 

Wes George


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_34E4F50CAFA10349A41E0756550084FB0BEECA65PRVPEXVS04corpt_-- From lorenzo@google.com Thu Jul 28 14:18:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA76811E8126 for ; Thu, 28 Jul 2011 14:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW7K2pcp2CZb for ; Thu, 28 Jul 2011 14:18:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0659911E8099 for ; Thu, 28 Jul 2011 14:18:24 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p6SLIN1r011195 for ; Thu, 28 Jul 2011 14:18:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311887904; bh=CmLg+mRX10qEvshRfnpsx2/ZUmk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ShDeytp5gMVIkdbAKGnS9MLQY5iiunvJdSTfkt6FJTP9gyscAT2UYh6EPZVn7+nNZ XTVNdgTMp1j3h4rp1GCbg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=NufUPYiLrCnaLLPiFjQ1W6DUbYeb6TuP06vUph76D8KACJxMNuCvrKPpA1uK0AeF6 aJMIdqZBA6Nfrf+AyrG1w== Received: from gxk27 (gxk27.prod.google.com [10.202.11.27]) by hpaq11.eem.corp.google.com with ESMTP id p6SLI11F019945 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 28 Jul 2011 14:18:22 -0700 Received: by gxk27 with SMTP id 27so4199389gxk.1 for ; Thu, 28 Jul 2011 14:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=d6cKDdUOdSt51Rq0Vx0dM1MBlrIlGLRzqN0TVnY79cw=; b=ouIDR1y/Il4Xy7PDvjqnSkhx4cY+M3cJAQfoXrKS2PqqOKlZA2GxZwBVD1fs+uVACs WiqXFYdKag94Hs/VULrQ== Received: by 10.150.62.6 with SMTP id k6mr38537yba.114.1311887902267; Thu, 28 Jul 2011 14:18:22 -0700 (PDT) Received: by 10.150.62.6 with SMTP id k6mr38528yba.114.1311887902114; Thu, 28 Jul 2011 14:18:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.156.5 with HTTP; Thu, 28 Jul 2011 14:18:02 -0700 (PDT) In-Reply-To: References: <5B6B2B64C9FE2A489045EEEADDAFF2C302589EE6@XMB-RCD-109.cisco.com> <4E304CD7.3010209@cisco.com> <4E30571A.9000104@cisco.com> From: Lorenzo Colitti Date: Thu, 28 Jul 2011 17:18:02 -0400 Message-ID: To: Joel Jaeggli Content-Type: multipart/alternative; boundary=000e0cd47baa64037d04a927b429 X-System-Of-Record: true Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 21:18:25 -0000 --000e0cd47baa64037d04a927b429 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 28, 2011 at 11:18, Joel Jaeggli wrote: > So, if one is working with requirements rather than working backwards from > a selected protocol one would suppose that some of the requirements might > look something like: > > * can be used with acceptable defaults (e.g. no configuration) > * has sensive safeguards to prevent interaction with isp IGP. > * can distinguish between the desirability of a path on the basis of > something other than hop count. e.g. just because I happen to have connected > an 802.5.14 network to two largely ethernet devices doesn't mean traffic to > other parts of the network should traverse the former when it happens to be > the best path. I would add: * can distribute information beyond IP reachability; for example, "this prefix belongs to a guest network" or "this is a prefix that I have tentatively assigned to my interface, not a prefix that is already in use". This would be useful for autoconfiguration. It might also be good if the protocol supported authentication so that unrelated devices could not join the network. Personally, I think preventing interaction with the ISP's IGP is the ISP's business, not the device's. An ISP that listens to routing protocol advertisements from home users with no prior agreement with them deserves what it gets. That said, you could use different authentication keys to prevent interaction, even if the protocol is the same. Others have asked to use a different protocol because some implementations can't run, e.g., multiple OSPF processes or multiple IS-IS processes, but it doesn't seem that this is an unsolvable technical problem. --000e0cd47baa64037d04a927b429 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 28, 2011 at 11:18, Joel Jaeggli <joe= lja@bogus.com> wrote:
So, if one is working with requirements rather than working backwards = from a selected protocol one would suppose that some of the requirements mi= ght look something like:

* can be used with acceptable defaults (e.g. no configuration)
* has sensive safeguards to prevent interaction with isp IGP.
* can distinguish between the desirability of a path on the basis of someth= ing other than hop count. e.g. just because I happen to have connected an 8= 02.5.14 network to two largely ethernet devices doesn't mean traffic to= other parts of the network should traverse the former when it happens to b= e the best path.

I would add:

* can distribute = information beyond IP reachability; for example, "this prefix belongs = to a guest network" or "this is a prefix that I have tentatively = assigned to my interface, not a prefix that is already in use". This w= ould be useful for autoconfiguration.

It might also be good if the protocol supported authent= ication so that unrelated devices could not join the network.
Personally, I think preventing interaction with the ISP's I= GP is the ISP's business, not the device's. An ISP that listens to = routing protocol advertisements from home users with no prior agreement wit= h them deserves what it gets. That said, you could use different authentica= tion keys to prevent interaction, even if the protocol is the same.=A0Other= s have asked to use a different protocol because some implementations can&#= 39;t run, e.g., multiple OSPF processes or multiple IS-IS processes, but it= doesn't seem that this is an unsolvable technical problem.
--000e0cd47baa64037d04a927b429-- From fernando.gont.netbook.win@gmail.com Thu Jul 28 14:54:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D8511E815E for ; Thu, 28 Jul 2011 14:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlG4+qnUSh1Q for ; Thu, 28 Jul 2011 14:54:22 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D58C11E80B8 for ; Thu, 28 Jul 2011 14:54:22 -0700 (PDT) Received: by gwb20 with SMTP id 20so2765292gwb.31 for ; Thu, 28 Jul 2011 14:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=9LMqOky1uZUlDAYqCeXzsPCwuTWi6w7lOqBlMSQElBc=; b=I8U0EiFia/nIVWSLSPSuT+4X1cNHi05tVBSHiHRPYcJ5TQjFt5we4wb3KVXEKoOGm3 HFZujtjxwT4jULfpLVx8oRADPF9J5EPogEM3bDWoWNy8CQfehyfr3MIZCwRFjhH9w/oq M6UJxGEe/NxNDVseDjqztd880BXnL6h+USPak= Received: by 10.91.159.19 with SMTP id l19mr462411ago.7.1311890062111; Thu, 28 Jul 2011 14:54:22 -0700 (PDT) Received: from [192.168.123.103] ([190.48.251.24]) by mx.google.com with ESMTPS id e20sm1078525anb.42.2011.07.28.14.54.18 (version=SSLv3 cipher=OTHER); Thu, 28 Jul 2011 14:54:21 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E31DA83.9080408@gont.com.ar> Date: Thu, 28 Jul 2011 18:54:11 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <4E31C945.5060402@gont.com.ar> <4269EA985EACD24987D82DAE2FEC62E504194BC8@XMB-AMS-101.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504194BC8@XMB-AMS-101.cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , V6ops Chairs Subject: Re: [v6ops] Presentation about ra-guard evasion(draft-gont-v6ops-ra-guard-evasion) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 21:54:23 -0000 Hi, Gunter, On 07/28/2011 06:06 PM, Gunter Van de Velde (gvandeve) wrote: > [Speaking as one of the co-authors of RA-Guard] > > The 'informational' RA-Guard paper was created on v6OPS because it > describes a method to mainly avoid misconfiguration. While RFC6104 (problem statement for rogue RAs) focuses on RAs resulting from misconfiguration, RFC6105 seems to focus on malicious RAs. > And more references to this are made later in the paper. > > IMHO the full solution for rogue RA's is SEND ... and not an even more > complex form of RA-Guard and make it less Lite. ... if only SEND was easily deployable. That aside, RA-Guard parallels existing functionality in IPv4 (DHCP snooping) -- hence that's, IMHO, enough of a motivation for it to be made "good enough" so that people that currently dhcp snooping in v4 have an equivalent mechanism in IPv6. > In 6man meeting there were some serious flaws discussed in the proposed > solutions as they break IPv6 technology > elements. (i.e. dropping RA packets with fragments, could break SEND > where the certificate is larger as the > link MTU... there were more and I guess those can be found in the > minutes soon). If you deploy and enable send, you can enable fragmentation with the same knob. That aside, draft-gont-v6ops-ra-guard-evasion does not disable fragmentation. It just drops fragmented traffic where the first fragment does not contain the upper layer protocol header -- which would only happen if you had large number of *IPv6* options in extension headers (dst options, hbh, etc.) > So looking at the fact RA-Guard is a lightweight protocol, and the > evasion techniques discussed are quite > known as traditional mechanisms to also bypass most traditional > access-lists, I think that changing any > protocol aspects does not make much sense... They are quite known for bypassing layer-3/4 filtering (e.g., a typical firewall). But I don't think they are so "quite known" for bypassing layer-2 filtering. For instance, these evasion techniques have no counterpart in the v4 world, since you cannot have an arbitrarily large amount of nonsense before the upper layer header (ICMPv6 in this case), because of the upper bound on the IPv4 header. Posts on some operations lists seem to indicate that evasion of ra-guard wasn't that obvious to everyone.... Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From joelja@bogus.com Thu Jul 28 15:01:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6FE11E8091 for ; Thu, 28 Jul 2011 15:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2VNGakgZPaF for ; Thu, 28 Jul 2011 15:01:13 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC0E11E8081 for ; Thu, 28 Jul 2011 15:01:13 -0700 (PDT) Received: from [IPv6:2001:df8::80:129a:ddff:feb1:e750] ([IPv6:2001:df8:0:80:129a:ddff:feb1:e750]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6SM1B4o052156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 28 Jul 2011 22:01:12 GMT (envelope-from joelja@bogus.com) From: Joel Jaeggli Content-Type: multipart/alternative; boundary=Apple-Mail-36-723305492 Date: Thu, 28 Jul 2011 18:01:10 -0400 Message-Id: To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [IPv6:2001:418:1::81]); Thu, 28 Jul 2011 22:01:12 +0000 (UTC) Subject: [v6ops] draft-hilliard-v6ops-ipv6-discard-prefix-00 wg Adoption X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 22:01:14 -0000 --Apple-Mail-36-723305492 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The consensus in the WG meeting appears to have been in favor of = adoption, if significant contrary opinions isn't registered on the list = we'll addopt it and probably ask for WG Last Lall shortly thereafter. please review: http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix-00 joel= --Apple-Mail-36-723305492 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
The consensus in the WG meeting appears to have been in favor of adoption, if significant contrary opinions isn't registered on the list we'll addopt it and probably ask for WG Last Lall shortly thereafter.

please review:

http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix-00

joel
--Apple-Mail-36-723305492-- From wesley.george@twcable.com Thu Jul 28 16:10:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756DA21F8B05 for ; Thu, 28 Jul 2011 16:10:44 -0700 (PDT) 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=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buCxvn3+AEk0 for ; Thu, 28 Jul 2011 16:10:43 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id BF8D921F8B00 for ; Thu, 28 Jul 2011 16:10:39 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,285,1309752000"; d="scan'208";a="255437512" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 28 Jul 2011 19:08:38 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 28 Jul 2011 19:10:38 -0400 From: "George, Wesley" To: Mark Andrews , Ari Keranen Date: Thu, 28 Jul 2011 19:10:38 -0400 Thread-Topic: [v6ops] Comments for draft-keranen-ipv6day-measurements-01 Thread-Index: AcxMAlXsvctMbVrXTUSpuHVwPojwhgBeOfRw Message-ID: <34E4F50CAFA10349A41E0756550084FB0BEECAFC@PRVPEXVS04.corp.twcable.com> References: <4E2F124D.1080706@nomadiclab.com> <20110727020904.CF46A123200A@drugs.dv.isc.org> In-Reply-To: <20110727020904.CF46A123200A@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comments for draft-keranen-ipv6day-measurements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 23:10:44 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of M= ark Andrews Sent: Tuesday, July 26, 2011 10:09 PM To: Ari Keranen Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments for draft-keranen-ipv6day-measurements-01 What we need is Radware, F5 and other load balancer vendors to send out instructions to their customer on how to correctly configure their load balancers to serve A records at the top of a zone rather that one label deep in a zone. This misconfiguration is responsible for +90% of AAAA lookup failures. Lots of load balancers are delegated to as "www.example.com" but the load balancer is configured to serve "example.com" rather than the zone that is *actually* delegated to it. This results in invalid negative responses being sent (the SOA record returned in the negative response is for "example.com" rather than "www.example.com") which is then rejected by the recursive nameserver. Radware and F5 are mention because I've chased down actual failures, in the last 3 months, and these were the reported products involved. I'm sure there will be other vendor that also have similar issues. [WEG] Should this perhaps be incorporated into the v6day call-to-arms draft= or some other draft? Not the vendor specific fixes, but perhaps a discussi= on about this issue that people should consider. Is it also documented in t= he appropriate IPv6 Wikis (ARIN, etc)? Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From frnkblk@iname.com Thu Jul 28 18:19:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8903021F8B31; Thu, 28 Jul 2011 18:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YuWKuITqeEo; Thu, 28 Jul 2011 18:19:40 -0700 (PDT) Received: from premieronline.net (smtp2-5.premieronline.net [96.31.0.30]) by ietfa.amsl.com (Postfix) with ESMTP id A234F21F8B30; Thu, 28 Jul 2011 18:19:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.26; Received: from BULKFAMLAPTOP (unverified [199.120.69.26]) by premieronline.net (SurgeMail 5.0n) with ESMTP id 2205779-1729245 for multiple; Thu, 28 Jul 2011 20:19:38 -0500 From: "Frank Bulk" To: "'Christian Huitema'" , "Philip Homburg" , "Mark Smith" References: <5022DA1A-2DAD-412F-9742-0780389D8B09@bogus.com> <424D0613-0E51-48CE-ACA9-8059D1071391@cisco.com> <20110717113237.0137abcd@opy.nosense.org> <20110717215320.73e71245@opy.nosense.org> <20110717224840.574ab41f@opy.nosense.org> <20110717234105.04069322@opy.nosense.org> <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <22F6318E46E26B498ABC828879B08D4F1BBA05@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 28 Jul 2011 20:19:36 -0500 Message-ID: <000701cc4d8d$94d0c860$be725920$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHMRJHLOaNFypP8jkSb4kdkNNCU2pTwpJNwgBHsZZA= Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (useraccess) X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=12 Friend=777 Surbl=0 Catch=0 r=0 ip=199.120.69.26 X-IP-stats: Incoming Outgoing Last 0, First 870, in=13506195, out=50842, spam=0 Known=true ip=199.120.69.26 Cc: IPv6 Operations , ipv6@ietf.org Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 01:19:40 -0000 Just like some routers allow one to partition the RIB between v4 and v6 address space, the ND cache could be customizably split between good and "bad" cache (i.e. 80-20), with the bad operating on a FIFO basis with some kind of customizable COPS-style rate-limiter attached to that "bad" cache. This would give the network guy the necessary knobs to manage ND DoS. Frank -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Christian Huitema Sent: Sunday, July 17, 2011 11:09 AM To: Philip Homburg; Mark Smith Cc: IPv6 Operations; ipv6@ietf.org Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ? >So perhaps the changes required would be mostly limited to - > >- DADs to all-nodes rather than solicited node addresses >- nodes receiving the DAD use that to create a neighbor cache entry >- NUD takes care of maintaining the validity of those entries >- ND NS to all nodes with an unspecified target address solicits NAs > from all nodes to cover the router (or any device) reboot situation I am not sure this addresses the problem too well. The DOS issue manifests itself at the gateway, and the main issue is the remote DOS: attacker sends packets to a very large number of putative IPv6 addresses in the subnet managed by the local gateway, causing the size of the neighbor cache to explode. If we want to protect the cache in the gateway, let's do that. The solution has to be a tweak in the implementation of ND in the gateway, along the lines of: - Upon arrival of a packet from the local network: - If the source address is already in ND cache, keep it there - if the source address is not already in the ND cache: Perform some quota check on the source MAC address, If the quota is exceeded, drop the packet to protect against local DOS If the quota is not exceeded, perform ND for the source address - Upon arrival of a packet bound to the local subnet - If the destination address is already in ND cache, route the packet; - If the destination address is not in ND cache: If the table is "too full," drop the packet Else, perform ND The basic idea is that remote parties should only be sending to addresses that have already been discovered in the local subnet. This is, in a way, a weak form of stateful filtering. It needs to be implemented softly, because routers/gateways sometime lose their memory, so we want to allow for some dynamic learning if the tables are not already populated. The proposed tweaks amount to making ND learn faster. They are fine in general, but they have the side effect of making local DOS easier. A local attacker could generate a large number of addresses, etc. -- Christian Huitema _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From farmer@umn.edu Thu Jul 28 18:40:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC125E8001 for ; Thu, 28 Jul 2011 18:40:43 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bx-ssOlwZZxs for ; Thu, 28 Jul 2011 18:40:42 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id B9D3621F8876 for ; Thu, 28 Jul 2011 18:40:42 -0700 (PDT) Received: from mail-gw0-f43.google.com (mail-gw0-f43.google.com [74.125.83.43]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 28 Jul 2011 20:40:34 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-gw0-f43.google.com [74.125.83.43] #+LO+TR X-Umn-Classification: local Received: by mail-gw0-f43.google.com with SMTP id 11so3886119gwm.16 for ; Thu, 28 Jul 2011 18:40:34 -0700 (PDT) Received: by 10.43.44.195 with SMTP id uh3mr527881icb.196.1311903634344; Thu, 28 Jul 2011 18:40:34 -0700 (PDT) Received: from nat-10-20-87-123.uofm.wireless.umn.edu (nat-portal-160-94-47-16.uofm.wireless.umn.edu [160.94.47.16]) by mx.google.com with ESMTPS id f14sm2048024icm.3.2011.07.28.18.40.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 18:40:33 -0700 (PDT) Message-ID: <4E320F8E.7040809@umn.edu> Date: Thu, 28 Jul 2011 20:40:30 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Xing Li References: <4E3071B6.3060807@globis.net> <851D47FA-41FB-4845-A2A4-A259CCE77D39@cisco.com> <4E30CF01.9000705@globis.net> <4E31B4DA.1030700@cernet.edu.cn> In-Reply-To: <4E31B4DA.1030700@cernet.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 01:40:43 -0000 On 7/28/11 14:13 CDT, Xing Li wrote: > Hi, Ray, > > 于 2011/7/28 10:52, Ray Hunter 写道: >> The concern would be that the special /24 is creating a new range that: >> >> - carries ICMP control messages, which could also be used to attempt >> to alter a senders' behavior >> - is shared between multiple providers >> - is not traceable > > When the special /24 is used, it can identify that the ICMP messages are > generated in IPv6. >> - should not be filtered at AS boundaries >> >> which could grant an attacker a perfect set of source addresses for >> mounting a DDOS attack. >> >> Yes the range isn't routable as a destination, but that possibly makes >> it even worse, as the target of any DDOS sourced from this range would >> have absolutely no idea who was sending them the huge volume of junk >> packets, except by incoming interface at the AS boundary. I see no >> reason why a network operator would want to accept such a packet from >> another AS into their network, so they'll basically get filtered >> everywhere after the very first attack IMHO. > > As partially discussed in previous mail. This will not introduce new > issues compared with using RFC1918 space. In Section 6 of this draft says > > 6. Security Considerations > > The use of an address for source addresses in ICMP packets is > considered "safe" in so far as ICMP packets are not intended to > generate responses directed to the source address. > > However it is possible to use this address as a means of gaining > anonymity when launching a denial of service attacks by using this > address as the source address for other forms of malicious traffic. > Packet firewall filters should be configured to treat addresses in > the IANA-assigned /24 network as martian addresses by discarding all > non-ICMP packets that use the IANA-assigned /24 network as a source > address, and all packets that use the IANA-assigned /24 network as a > destination address. If this draft goes forward, beyond the above, I would like to see recommendations of both filtering to an appropriate list of ICMP types and probably an overall rate limiting of traffic from the prefix as additional countermeasure against abuse of this prefix. Given the stated intended use I believe ICMP type 3 - Destination Unreachable, ICMP type 11 - Time Exceeded, and maybe ICMP type 12 - Parameter Problem, and I'm not sure this last one is needed, are the only ICMP messages that SHOULD be allowed to be sourced from this prefix. Additionally, this prefix SHOULD NOT be allowed to source any of the various ICMP request messages, as the response would necessarily have an destination address that is a martian address by even the current Security Considerations statement. Ray is correct that this needs to apply not just to firewall filters but probably most AS border filters as well. He is also correct, that many operators will just filter the prefix completely. However, I see an advantage to assigning a well-known prefix in that it simplifies coordination of like minded operators allowing the appropriate ICMP messages to pass through their AS borders if they find it advantageous, even if many or most operators do not and block all packets sourced or destined to the prefix. Trying to coordinate the use of an RFC 1918 prefix for this purpose across even a limited number of like minded operators is almost an impossible task. Finally, some consideration for Reverse DNS for this prefix should be given. This is probably one of the best arguments for assigning a well-known prefix, then some kind of human readable Reverse DNS can be provided, to help mortal Internet users when they traceroute through an IPv6/v4 translator. This probably belongs in the IANA considerations section, or a separate section discussing Reverse DNS. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From john.mann@monash.edu Thu Jul 28 18:48:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E0F21F8906 for ; Thu, 28 Jul 2011 18:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.776 X-Spam-Level: X-Spam-Status: No, score=-5.776 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTIrlB0NwWro for ; Thu, 28 Jul 2011 18:48:39 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by ietfa.amsl.com (Postfix) with ESMTP id 17D5D21F876F for ; Thu, 28 Jul 2011 18:48:39 -0700 (PDT) Received: from mail-vw0-f47.google.com ([209.85.212.47]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTjIRdoQml/cOCTiK5n/z2ka9x+aZJR/6@postini.com; Thu, 28 Jul 2011 18:48:39 PDT Received: by mail-vw0-f47.google.com with SMTP id 2so3766256vws.34 for ; Thu, 28 Jul 2011 18:48:38 -0700 (PDT) Received: by 10.52.22.4 with SMTP id z4mr748815vde.325.1311904118169; Thu, 28 Jul 2011 18:48:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.100 with HTTP; Thu, 28 Jul 2011 18:48:18 -0700 (PDT) In-Reply-To: References: <20110725120140.30929.29211.idtracker@ietfa.amsl.com> <4E30CFBB.1050809@gmail.com> <4E31202E.40605@unfix.org> <20110728090438.GE21519@phantom.vanrein.org> From: "John Mann (ITS)" Date: Fri, 29 Jul 2011 11:48:18 +1000 Message-ID: To: Philip Homburg Content-Type: multipart/alternative; boundary=bcaec5015e95f1604204a92b7a69 Cc: IPv6 Operations Subject: Re: [v6ops] I-D Action: draft-vanrein-v6ops-6bed4-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 01:48:40 -0000 --bcaec5015e95f1604204a92b7a69 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 28 July 2011 19:13, Philip Homburg wrote: > Maybe I am missing something, but this protocol sounds a lot like 6to4 but > then on top of udp instead of protocol 41. I was thinking that 6bed4 seems similar ISATAP, but with NAT traversal. Nice in that a successful RS/RA exchange is required before the client routes traffic through the tunnel. - 6to4 client is a router, and gets a /48 out of a single global address space - 6rd client is a router, and gets a /48../64 out of its' 6rd-ISP -provided address space - Teredo client is an end-system that gets one IPv6 address from a single global address space - ISATAP client is an end-system that gets one IPv6 address from an enterprise-defined subnet - 6bed4 client is an end-system that gets one IPv6 address from a (global) subnet selected by the tunnel server address/port - tunnel-broker clients - varies, and I don't know the specifics === 6rd gets its config from DHCPv4 option (or static config). ISATAP chooses its gateway using DNS A lookup of "ISATAP" name (or static config). Could 6bed4 get its config from a DNS A or SRV lookup, instead of statically defined? Or DHCPv4 option since we are already doing DHCPv4 of address assignment -- probably not suitable for global deployment. === I would have requested two well-known UDP ports. One for the tunnel destination, and also one for the client sending port. Would make it easier to create ACL permits, and also avoid being blocked by mistake. === I can think of a third profile - overlay. Say a researcher wants to sprinkle webcams across Australia. They will get Internet access via different ISPs, different NATs/CPEs, different local admins etc etc Choose a non-standard public IPv4 tunnel service addr/port from your enterprise address space and configure into each webcam. Choose a public or private IPv6 subnet for the gateway box. This would be a "managed" service like 6rd rather than an un-managed service depending upon the kindness/ability of strangers like 6to4 or Teredo. But, I think I have just re-invented an un-encrypted VPN, or anonymous tunnel-broker ... I don't think we need 20 slightly-different IPv6 transition mechanisms. It would be nice if we could filter/combine the options, and come up with a short list of good options for a short list of use cases. John --bcaec5015e95f1604204a92b7a69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 28 July 2011 19:13, Philip Homburg= <pch-v6op= s@u-1.phicoh.com> wrote:
Maybe I am missing something, but this protocol sounds a lot like 6to4 but<= br> then on top of udp instead of protocol 41.

= I was thinking that 6bed4 seems similar ISATAP, but with NAT traversal.
Nice in that a successful RS/RA exchange is required before the clie= nt routes traffic through the tunnel.

- 6to4 client is a router, and gets a /48 out of a sing= le global address space
- 6rd client is a router, and gets a /48.= ./64 out of its' 6rd-ISP -provided address space
- Teredo cli= ent is an end-system that gets one IPv6 address from a single global addres= s space
- ISATAP client is an end-system that gets one IPv6 address from an en= terprise-defined subnet
- 6bed4 client is an end-system that gets= one IPv6 address from a (global) subnet selected by the tunnel server addr= ess/port
- tunnel-broker clients - varies, and I don't know the specifics

=3D=3D=3D
6rd gets its config from DHCPv4= option (or static config).
ISATAP chooses its gateway using DNS = A lookup of "ISATAP" name (or static config).

Could 6bed4 get its config from a DNS A or SRV lookup, = instead of statically defined?
Or DHCPv4 option since we are alre= ady doing DHCPv4 of address assignment -- probably not suitable for global = deployment.

=3D=3D=3D
I would have requested two well-kno= wn UDP ports.
One for the tunnel destination, and also one for th= e client sending port.
Would make it easier to create ACL permits= , and also avoid being blocked by mistake.

=3D=3D=3D
I can think of a third profile - ov= erlay.
Say a researcher wants to sprinkle webcams across Australi= a.
They will get Internet access via different ISPs, different NA= Ts/CPEs, different local admins etc etc
Choose a non-standard public IPv4 tunnel service addr/port from your e= nterprise address space and configure into each webcam.
Choose a = public or private IPv6 subnet for the gateway box.

This would be a "managed" service like 6rd rather than an un= -managed service depending upon the kindness/ability of strangers like 6to4= or Teredo.

But, I think I have just re-invented a= n un-encrypted VPN, or anonymous tunnel-broker ...

I don't think we need 20 slightly-different IPv6 tr= ansition mechanisms.
It would be nice if we could filter/combine = the options, and come up with a short list of good options for a short list= of use cases.

=A0 =A0 John
--bcaec5015e95f1604204a92b7a69-- From swmike@swm.pp.se Thu Jul 28 22:29:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BC321F885A for ; Thu, 28 Jul 2011 22:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOtjmjdS-pcl for ; Thu, 28 Jul 2011 22:29:48 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D5BD121F8853 for ; Thu, 28 Jul 2011 22:29:47 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A80C69C; Fri, 29 Jul 2011 07:29:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A376C9A; Fri, 29 Jul 2011 07:29:43 +0200 (CEST) Date: Fri, 29 Jul 2011 07:29:43 +0200 (CEST) From: Mikael Abrahamsson To: "Gunter Van de Velde (gvandeve)" In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504194BC8@XMB-AMS-101.cisco.com> Message-ID: References: <4E31C945.5060402@gont.com.ar> <4269EA985EACD24987D82DAE2FEC62E504194BC8@XMB-AMS-101.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations , V6ops Chairs Subject: Re: [v6ops] Presentation about ra-guard evasion(draft-gont-v6ops-ra-guard-evasion) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 05:29:49 -0000 On Thu, 28 Jul 2011, Gunter Van de Velde (gvandeve) wrote: > IMHO the full solution for rogue RA's is SEND ... and not an even more > complex form of RA-Guard and make it less Lite. Some of the elements > documented are also valid for existing IPv4 and IPv6 Access-lists and > other xxx-Guard mechanisms. Personally I think SEND is too advanced for the general use, or it'll take way too long to get widely implemented in a user-friendly way. The certificate distribution and handling problem is the killer for me. > So looking at the fact RA-Guard is a lightweight protocol, and the > evasion techniques discussed are quite known as traditional mechanisms > to also bypass most traditional access-lists, I think that changing any > protocol aspects does not make much sense... I don't agree. Then again IPv6 was generally designed without L2 security in mind, so ISPs might have to go for full L2 separation of hosts anyway. I don't see any other short- or medium term solution. SEND in itself doesn't solve it from a practical point of view, even though it does from a theoretical PoV. -- Mikael Abrahamsson email: swmike@swm.pp.se From v6ops@globis.net Fri Jul 29 00:46:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86F21F8B44 for ; Fri, 29 Jul 2011 00:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjnIB7M8yZIa for ; Fri, 29 Jul 2011 00:46:50 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 35E2621F86C4 for ; Fri, 29 Jul 2011 00:46:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B212B8700D6; Fri, 29 Jul 2011 09:46:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpr1nxzqSr-q; Fri, 29 Jul 2011 09:46:42 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E9800870021; Fri, 29 Jul 2011 09:46:41 +0200 (CEST) Message-ID: <4E326561.6050601@globis.net> Date: Fri, 29 Jul 2011 09:46:41 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: David Farmer References: <4E3071B6.3060807@globis.net> <851D47FA-41FB-4845-A2A4-A259CCE77D39@cisco.com> <4E30CF01.9000705@globis.net> <4E31B4DA.1030700@cernet.edu.cn> <4E320F8E.7040809@umn.edu> In-Reply-To: <4E320F8E.7040809@umn.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 07:46:50 -0000 David Farmer wrote: > On 7/28/11 14:13 CDT, Xing Li wrote: >> > > If this draft goes forward, beyond the above, I would like to see > recommendations of both filtering to an appropriate list of ICMP types > and probably an overall rate limiting of traffic from the prefix as > additional countermeasure against abuse of this prefix. > > Given the stated intended use I believe ICMP type 3 - Destination > Unreachable, ICMP type 11 - Time Exceeded, and maybe ICMP type 12 - > Parameter Problem, and I'm not sure this last one is needed, are the > only ICMP messages that SHOULD be allowed to be sourced from this > prefix. Additionally, this prefix SHOULD NOT be allowed to source any > of the various ICMP request messages, as the response would > necessarily have an destination address that is a martian address by > even the current Security Considerations statement. > Agreed. That was one of my concerns too. ICMP is a diverse (and growing) collection of types and codes. Not just Echo Reply or Time Exceeded. Those same "unmappable" IPv6 routers and devices are also likely to initiate outbound traceroutes towards the IPv4 cloud. If you use RFC1918 addresses, there's a good chance that you could make that outbound traceroute work too across the translator, at least within the AS. That probably won't work when using a shared special purpose address and more than one translator in the IPv4 AS. > > However, I see an advantage to assigning a well-known prefix in that > it simplifies coordination of like minded operators allowing the > appropriate ICMP messages to pass through their AS borders if they > find it advantageous, even if many or most operators do not and block > all packets sourced or destined to the prefix. Trying to coordinate > the use of an RFC 1918 prefix for this purpose across even a limited > number of like minded operators is almost an impossible task. > Then they can use a publicly registered globally unique IPv4 address from one of their existing allocations that they agree to share across their group of AS'es. If it ever leaked out from their group of AS'es then at least it would be traceable back to one of the AS'es, who would then have to take responsibility for coordinating and solving any issues. No new standard required. But at least you'd have a problem owner to call. Which will save the rest of the World from updating their ingress & egress filters, DNS reverse records, operations instructions, intrusion detection systems, possible end node implementations to ensure they don't try to reply to martian addresses..... > Finally, some consideration for Reverse DNS for this prefix should be > given. This is probably one of the best arguments for assigning a > well-known prefix, then some kind of human readable Reverse DNS can be > provided, to help mortal Internet users when they traceroute through > an IPv6/v4 translator. This probably belongs in the IANA > considerations section, or a separate section discussing Reverse DNS. Can you think of any other example of a "one-way" special purpose packet that is allowed to leave the link, never mind the AS? From joelja@bogus.com Fri Jul 29 06:27:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D524E21F8B9A for ; Fri, 29 Jul 2011 06:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.94 X-Spam-Level: X-Spam-Status: No, score=-101.94 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3dDJGBxUpjD for ; Fri, 29 Jul 2011 06:27:05 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 17AC621F8506 for ; Fri, 29 Jul 2011 06:27:04 -0700 (PDT) Received: from [IPv6:2001:df8::80:129a:ddff:feb1:e750] ([IPv6:2001:df8:0:80:129a:ddff:feb1:e750]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p6TDQxr1014409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 29 Jul 2011 13:27:01 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Fri, 29 Jul 2011 09:26:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <38F93673-7B3F-489D-8856-5E9563D68989@bogus.com> References: <4E31C945.5060402@gont.com.ar> <4269EA985EACD24987D82DAE2FEC62E504194BC8@XMB-AMS-101.cisco.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [IPv6:2001:418:1::81]); Fri, 29 Jul 2011 13:27:02 +0000 (UTC) Cc: V6ops Chairs , IPv6 Operations Subject: Re: [v6ops] Presentation about ra-guard evasion(draft-gont-v6ops-ra-guard-evasion) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 13:27:05 -0000 On Jul 29, 2011, at 1:29 AM, Mikael Abrahamsson wrote: > On Thu, 28 Jul 2011, Gunter Van de Velde (gvandeve) wrote: >=20 >> IMHO the full solution for rogue RA's is SEND ... and not an even = more complex form of RA-Guard and make it less Lite. Some of the = elements documented are also valid for existing IPv4 and IPv6 = Access-lists and other xxx-Guard mechanisms. >=20 > Personally I think SEND is too advanced for the general use, or it'll = take way too long to get widely implemented in a user-friendly way. The = certificate distribution and handling problem is the killer for me. >=20 >> So looking at the fact RA-Guard is a lightweight protocol, and the = evasion techniques discussed are quite known as traditional mechanisms = to also bypass most traditional access-lists, I think that changing any = protocol aspects does not make much sense... >=20 > I don't agree. >=20 > Then again IPv6 was generally designed without L2 security in mind, so = ISPs might have to go for full L2 separation of hosts anyway. I don't = see any other short- or medium term solution. SEND in itself doesn't = solve it from a practical point of view, even though it does from a = theoretical PoV. Unsurprisingly the goal of having two to N hosts on a subnet with no = security association talk to each other does limit our options. Full L2 = isolation is great if that's what you want, but I want to be able to = talk to my printer and my apple tv. > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From despres.remi@laposte.net Fri Jul 29 06:19:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A66E21F8AD9; Fri, 29 Jul 2011 06:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gzBchC3or9Q; Fri, 29 Jul 2011 06:19:47 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id DD14D21F8B29; Fri, 29 Jul 2011 06:19:46 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 43212700008E; Fri, 29 Jul 2011 15:19:46 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id DD0277000083; Fri, 29 Jul 2011 15:19:43 +0200 (CEST) X-SFR-UUID: 20110729131943905.DD0277000083@msfrf2221.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20110727161445.1C00A18C0CB@mercury.lcs.mit.edu> Date: Fri, 29 Jul 2011 15:19:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65EB9DA2-255C-47F5-B6BB-EBE2B8BC219D@laposte.net> References: <20110727161445.1C00A18C0CB@mercury.lcs.mit.edu> To: IETF discussion list , v6ops v6ops WG X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 29 Jul 2011 06:28:11 -0700 Cc: Noel Chiappa Subject: Re: [v6ops] Make 6to4 Experimental (was6to4v2 (as in ripv2)?) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 13:19:47 -0000 +1 IMHO, it does make a lot of sense. (I made a similar comment before reading this one)-. Regards, RD Le 27 juil. 2011 =E0 18:14, Noel Chiappa a =E9crit : >> From: Philip Homburg >=20 >> I think it would be quite weird to keep 6to4 at standards track just = to >> prevent some vendors from dropping 6to4 support. >=20 > There have been suggestions that it might be more appropriate to = reclassify > it as Experimental, and I think that makes a lot of sense - as you = correctly > (IMO) point out, due to its issues 6to4 is not really appropriate for > standards track (at least, in its current form). >=20 > Noel > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From gvandeve@cisco.com Fri Jul 29 06:29:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304B321F8BCE for ; Fri, 29 Jul 2011 06:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.074 X-Spam-Level: X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aECi1Ev0zqRB for ; Fri, 29 Jul 2011 06:29:18 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E8B1121F8AF7 for ; Fri, 29 Jul 2011 06:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=3688; q=dns/txt; s=iport; t=1311946158; x=1313155758; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=pGjS0mfk8xaIMWD1vhHXQSNgTCZ9zC1A+ZKfefxUdyI=; b=RbbOB0JA73L2T9JeNL1pf26Zo8mz/TaNVGom3KMz6q6cZKq7ux+WWwNg sydiY/DpS9tWdycsr84G1E1G28bjAZYX0gzJhr84ol/1ZeSRKtBjh+03c 6hSZn95aWCK/gnsRweWSVZ/ihGRlGtKd0ERKNUwWy6sv4ZrvSVJ132ANS g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIy0Mk6Q/khM/2dsb2JhbAA0AQEBAQIBFAEhCkUFBwUCAQkRBAEBAQoGIwEGARMSKQ4IAQEFFwwUAwSnRXeIfKE8nkCFYl8EmAmEW4Z7 X-IronPort-AV: E=Sophos;i="4.67,287,1309737600"; d="scan'208";a="105664586" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2011 13:29:14 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6TDTEJq012630; Fri, 29 Jul 2011 13:29:14 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jul 2011 15:29:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jul 2011 15:29:10 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E504194DDE@XMB-AMS-101.cisco.com> In-Reply-To: <4E31DA83.9080408@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Presentation about ra-guard evasion(draft-gont-v6ops-ra-guard-evasion) Thread-Index: AcxNcOqBltExacrJSJeeLmPc0FBNgAAgcIHA References: <4E31C945.5060402@gont.com.ar> <4269EA985EACD24987D82DAE2FEC62E504194BC8@XMB-AMS-101.cisco.com> <4E31DA83.9080408@gont.com.ar> From: "Gunter Van de Velde (gvandeve)" To: "Fernando Gont" X-OriginalArrivalTime: 29 Jul 2011 13:29:14.0465 (UTC) FILETIME=[8241E510:01CC4DF3] Cc: IPv6 Operations , V6ops Chairs Subject: Re: [v6ops] Presentation about ra-guard evasion(draft-gont-v6ops-ra-guard-evasion) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 13:29:19 -0000 Hi Fernando, After further thinking on this there may be another approach available. RFC6105 mentions that RA-Guard drops the RA's. The tests you seem to have done indicate=20 that in some corner cases the existing implementations don't drop the RA. However that=20 is an implementation detail on how the vendor decided to put the mechanism in place to drop the RA's. (most vendors just use access-lists, and hence to bypass these any ACL evasion technology could be used) The RFC6105 does not inform/advice 'HOW' a L2 switch should drop the RA, it just specifies it should=20 be dropped on certain ports/interfaces What could be done is to create a draft on best practices to drop RA's, and have that complement RA-Guard. I think that could work pretty well actually. G/ -----Original Message----- From: Fernando Gont [mailto:fernando.gont.netbook.win@gmail.com] On Behalf Of Fernando Gont Sent: 28 July 2011 17:54 To: Gunter Van de Velde (gvandeve) Cc: IPv6 Operations; V6ops Chairs Subject: Re: [v6ops] Presentation about ra-guard evasion(draft-gont-v6ops-ra-guard-evasion) Hi, Gunter, On 07/28/2011 06:06 PM, Gunter Van de Velde (gvandeve) wrote: > [Speaking as one of the co-authors of RA-Guard] >=20 > The 'informational' RA-Guard paper was created on v6OPS because it > describes a method to mainly avoid misconfiguration.=20 While RFC6104 (problem statement for rogue RAs) focuses on RAs resulting from misconfiguration, RFC6105 seems to focus on malicious RAs. > And more references to this are made later in the paper. >=20 > IMHO the full solution for rogue RA's is SEND ... and not an even more > complex form of RA-Guard and make it less Lite. ... if only SEND was easily deployable. That aside, RA-Guard parallels existing functionality in IPv4 (DHCP snooping) -- hence that's, IMHO, enough of a motivation for it to be made "good enough" so that people that currently dhcp snooping in v4 have an equivalent mechanism in IPv6. > In 6man meeting there were some serious flaws discussed in the proposed > solutions as they break IPv6 technology=20 > elements. (i.e. dropping RA packets with fragments, could break SEND > where the certificate is larger as the=20 > link MTU... there were more and I guess those can be found in the > minutes soon). If you deploy and enable send, you can enable fragmentation with the same knob. That aside, draft-gont-v6ops-ra-guard-evasion does not disable fragmentation. It just drops fragmented traffic where the first fragment does not contain the upper layer protocol header -- which would only happen if you had large number of *IPv6* options in extension headers (dst options, hbh, etc.) > So looking at the fact RA-Guard is a lightweight protocol, and the > evasion techniques discussed are quite=20 > known as traditional mechanisms to also bypass most traditional > access-lists, I think that changing any=20 > protocol aspects does not make much sense... They are quite known for bypassing layer-3/4 filtering (e.g., a typical firewall). But I don't think they are so "quite known" for bypassing layer-2 filtering. For instance, these evasion techniques have no counterpart in the v4 world, since you cannot have an arbitrarily large amount of nonsense before the upper layer header (ICMPv6 in this case), because of the upper bound on the IPv4 header. Posts on some operations lists seem to indicate that evasion of ra-guard wasn't that obvious to everyone.... Thanks, --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Fri Jul 29 07:11:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4A21F8BA9 for ; Fri, 29 Jul 2011 07:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.405 X-Spam-Level: X-Spam-Status: No, score=-3.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R++9pt3GbItE for ; Fri, 29 Jul 2011 07:11:49 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9694521F8BD5 for ; Fri, 29 Jul 2011 07:11:49 -0700 (PDT) Received: by gyd5 with SMTP id 5so3072009gyd.31 for ; Fri, 29 Jul 2011 07:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=wm5sXMVA61FrlQmZTx8vtKhRtxnHUmEwXAJnxM/NJQg=; b=p6sgwJrZKBvUQuFsKG6teyNbq3l9IhCnaEheFi8owM/xTghHootVQ+2wLjatThwPv/ u8Kqm607mvse0CmPJHO9IdOsy7RJQDQFzHhtHSiuIidLR38zuPXcVAycP5xTGr2Wj6Gt OVmg1t1anXOKPmzZxQel7GyVziE7gL8cslQhw= Received: by 10.91.165.4 with SMTP id s4mr1224171ago.126.1311948709045; Fri, 29 Jul 2011 07:11:49 -0700 (PDT) Received: from [192.168.123.104] ([190.48.251.24]) by mx.google.com with ESMTPS id f33sm2011861ann.34.2011.07.29.07.11.45 (version=SSLv3 cipher=OTHER); Fri, 29 Jul 2011 07:11:48 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E32BD49.9080503@gont.com.ar> Date: Fri, 29 Jul 2011 11:01:45 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <4E31C945.5060402@gont.com.ar> <4269EA985EACD24987D82DAE2FEC62E504194BC8@XMB-AMS-101.cisco.com> <4E31DA83.9080408@gont.com.ar> <4269EA985EACD24987D82DAE2FEC62E504194DDE@XMB-AMS-101.cisco.com> In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E504194DDE@XMB-AMS-101.cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , V6ops Chairs Subject: Re: [v6ops] Presentation about ra-guard evasion(draft-gont-v6ops-ra-guard-evasion) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 14:11:50 -0000 Hi, Gunter, On 07/29/2011 10:29 AM, Gunter Van de Velde (gvandeve) wrote: > After further thinking on this there may be another approach available. > RFC6105 mentions that RA-Guard drops the RA's. The tests you seem to [....] > > The RFC6105 does not inform/advice 'HOW' a L2 switch should drop the RA, > it just specifies it should > be dropped on certain ports/interfaces > > What could be done is to create a draft on best practices to drop RA's, > and have that complement RA-Guard. > I think that could work pretty well actually. Sorry, what's the difference between what you propose, and draft-gont-v6ops-ra-guard-evasion? The only "difference" I see is that I might add two lines to my I-D noting that this is a common implementation flaw of RA-Guard.... Thoughts? Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rick@openfortress.nl Fri Jul 29 07:43:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2B321F8BD7 for ; Fri, 29 Jul 2011 07:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.043 X-Spam-Level: X-Spam-Status: No, score=-0.043 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw3JM+9kgpj1 for ; Fri, 29 Jul 2011 07:43:25 -0700 (PDT) Received: from fame.vanrein.org (openfortress.nl [213.189.19.244]) by ietfa.amsl.com (Postfix) with ESMTP id 551AE21F869D for ; Fri, 29 Jul 2011 07:43:25 -0700 (PDT) Received: from phantom.vanrein.org (phantom.vanrein.org [83.163.207.110]) by fame.vanrein.org (Postfix) with ESMTP id 9B7904040CD for ; Fri, 29 Jul 2011 15:43:21 +0100 (BST) Received: by phantom.vanrein.org (Postfix, from userid 1000) id 8E502940B1; Fri, 29 Jul 2011 14:43:20 +0000 (CEST) Date: Fri, 29 Jul 2011 14:43:20 +0000 From: Rick van Rein To: IPv6 Operations Message-ID: <20110729144320.GB17784@phantom.vanrein.org> References: <20110725120140.30929.29211.idtracker@ietfa.amsl.com> <4E30CFBB.1050809@gmail.com> <4E31202E.40605@unfix.org> <20110728090438.GE21519@phantom.vanrein.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM User-Agent: Mutt/1.5.11 Subject: Re: [v6ops] I-D Action: draft-vanrein-v6ops-6bed4-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 14:43:26 -0000 Guys, (and girls?) Thanks _very_ much for your feedback on the draft! It's hardly possible to respond to everyone, so much has been thrown my way! I am reading it all, and processing it. Based on plain Neighbour Discovery, I seem to have found a way to resolve not only local routing shortcuts, but even direct connections between IPv4 routers with cooperative NAT. I am working that out, and will turn in a -01 with (hopefully) all your critisism taken away! The general approach I'm taking is to start from what we can rely on with certainty (UDP can go out and becomes bidirectional for some time) and then try to find more optimal ways of doing the same (can I route it locally? to my own router's external IP through hairpin NAT? to the other router's external IPv4/port?) and only if it works, to change the routing policy. Interestingly, this saves 6bed4 from classifiying or understanding NAT while it is still possible to get the best out of it. I love simplicity :-D Thank you all! -Rick From swmike@swm.pp.se Fri Jul 29 11:05:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DAC21F89BE for ; Fri, 29 Jul 2011 11:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5k8TCeb5tKN for ; Fri, 29 Jul 2011 11:05:29 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8038121F8A71 for ; Fri, 29 Jul 2011 11:05:29 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C02219C; Fri, 29 Jul 2011 20:05:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B9B029A; Fri, 29 Jul 2011 20:05:19 +0200 (CEST) Date: Fri, 29 Jul 2011 20:05:19 +0200 (CEST) From: Mikael Abrahamsson To: Joel Jaeggli In-Reply-To: <38F93673-7B3F-489D-8856-5E9563D68989@bogus.com> Message-ID: References: <4E31C945.5060402@gont.com.ar> <4269EA985EACD24987D82DAE2FEC62E504194BC8@XMB-AMS-101.cisco.com> <38F93673-7B3F-489D-8856-5E9563D68989@bogus.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: V6ops Chairs , IPv6 Operations Subject: Re: [v6ops] Presentation about ra-guard evasion(draft-gont-v6ops-ra-guard-evasion) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 18:05:30 -0000 On Fri, 29 Jul 2011, Joel Jaeggli wrote: > Unsurprisingly the goal of having two to N hosts on a subnet with no > security association talk to each other does limit our options. Full L2 > isolation is great if that's what you want, but I want to be able to > talk to my printer and my apple tv. Well, I was referring to separation of customers (in this case I guess households). Also, I wasn't implying filtering of these devices, they can still talk L3 with each other, but it does limit automatic discovery of each other. -- Mikael Abrahamsson email: swmike@swm.pp.se From ari.keranen@nomadiclab.com Fri Jul 29 11:53:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA0A21F8AEA for ; Fri, 29 Jul 2011 11:53:17 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7-vYOYCDruZ for ; Fri, 29 Jul 2011 11:53:17 -0700 (PDT) Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by ietfa.amsl.com (Postfix) with ESMTP id 864CC21F8AF2 for ; Fri, 29 Jul 2011 11:53:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 6490E4E6DF; Fri, 29 Jul 2011 21:53:09 +0300 (EEST) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br6GxjQphzHg; Fri, 29 Jul 2011 21:53:08 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by gw.nomadiclab.com (Postfix) with ESMTP id 6F01B4E6D1; Fri, 29 Jul 2011 21:53:07 +0300 (EEST) Message-ID: <4E330192.9000506@nomadiclab.com> Date: Fri, 29 Jul 2011 14:53:06 -0400 From: Ari Keranen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Mark Andrews References: <4E2F124D.1080706@nomadiclab.com> <20110727020904.CF46A123200A@drugs.dv.isc.org> In-Reply-To: <20110727020904.CF46A123200A@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments for draft-keranen-ipv6day-measurements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 18:53:17 -0000 Hi Mark, On 26.7.2011 22:09, Mark Andrews wrote: > What we need is Radware, F5 and other load balancer vendors to send > out instructions to their customer on how to correctly configure > their load balancers to serve A records at the top of a zone rather > that one label deep in a zone. This misconfiguration is responsible > for +90% of AAAA lookup failures. This sounds interesting (and disturbing). Is the "+90%" your personal estimate or are there actual measurements done with this? Any publications? Cheers, Ari > Lots of load balancers are delegated to as "www.example.com" but > the load balancer is configured to serve "example.com" rather than > the zone that is *actually* delegated to it. This results in invalid > negative responses being sent (the SOA record returned in the > negative response is for "example.com" rather than "www.example.com") > which is then rejected by the recursive nameserver. > > Radware and F5 are mention because I've chased down actual failures, > in the last 3 months, and these were the reported products involved. > I'm sure there will be other vendor that also have similar issues. > > Mark From fred@cisco.com Fri Jul 29 12:49:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DFF5E8021; Fri, 29 Jul 2011 12:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.745 X-Spam-Level: X-Spam-Status: No, score=-102.745 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5dFwVEvqIZu; Fri, 29 Jul 2011 12:49:07 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6EADB5E801D; Fri, 29 Jul 2011 12:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=607; q=dns/txt; s=iport; t=1311968947; x=1313178547; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=7R858yQmbmMDtEeBFj/eOeQsl6oXchtuDEL4uY+8OO0=; b=URVlEv74cLbfY7QmRTE/VYFAyORbANazyB+ojvrqK99kltRQRy7/pxT+ ZgLhq+Y6gt8g+i87a2SzQDShnk5Iej0rbEUcC0VwvAEbGIBe05TNiDyH0 ofAH/Cgh+Uwroe+yXTWs/Sf4ruhzbEF+ihpCSRATdZrRsQhjdVSbEvBws 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkHAFgOM06rRDoI/2dsb2JhbABPAStFgQOBFpg5jxV3iQChIJ4xhWJfBJJ6hQaLeQ X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="7900591" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-5.cisco.com with ESMTP; 29 Jul 2011 19:49:01 +0000 Received: from dhcp-57cd.meeting.ietf.org (sjc-vpn4-862.cisco.com [10.21.83.93]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6TJn1ZN001646; Fri, 29 Jul 2011 19:49:01 GMT Received: from [127.0.0.1] by dhcp-57cd.meeting.ietf.org (PGP Universal service); Fri, 29 Jul 2011 15:49:01 -0400 X-PGP-Universal: processed; by dhcp-57cd.meeting.ietf.org on Fri, 29 Jul 2011 15:49:01 -0400 From: Fred Baker Date: Fri, 29 Jul 2011 15:48:52 -0400 Message-Id: <43A19B24-0564-4DF7-96A2-B1C091AFB0F9@cisco.com> To: privacydir@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: [v6ops] Request for Comments: draft-chown-v6ops-address-accountability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 19:49:08 -0000 v6ops heard a presentation of http://tools.ietf.org/html/draft-chown-v6ops-address-accountability "IPv6 Address Accountability Considerations", Tim Chown, 11-Jul-11 today. We have a sneaking hunch that the Privacy Directorate might have = opinions on the topic and on the recommendations developed in v6ops. We = would appreciate comments on the interaction between legitimate (and in = some cases statutory) requirements for user privacy and legitimate (and = in some cases statutory) requirements for accountability of users for = the behavior of their applications and resulting traffic.= From fred@cisco.com Fri Jul 29 13:27:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CEB5E8011 for ; Fri, 29 Jul 2011 13:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.737 X-Spam-Level: X-Spam-Status: No, score=-102.737 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zq0Bz7RWkTws for ; Fri, 29 Jul 2011 13:27:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C157F21F8A62 for ; Fri, 29 Jul 2011 13:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5739; q=dns/txt; s=iport; t=1311971256; x=1313180856; h=from:subject:date:references:to:message-id:mime-version; bh=0Qy5fisSfiucpS2utG84kPhVU5WdPY0SfaRwNd+VLYo=; b=Nu72HFn5KCP5gUJfHvd0ztOhV7uN5UKDa/1mpV2YREV9jYwBu+laAU2z HPSPcT5umJUGJP66YbYUU4Uh3qk/8lACDHrayzE/OrPFdWwGOL70BbVWR dwCLqXJlFrYcnnymBeL9o8pip9V4svcQkDMAy2f0BWDqXYhhj5mHe13n+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAEgXM06rRDoG/2dsb2JhbAA0AQEBAQIBFAF1DB0DAQI7FEcCCAcXJ58oAYgnd4h8BKEbnjWFYl8EknqFBot5 X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208,217";a="7910111" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jul 2011 20:27:21 +0000 Received: from dhcp-57cd.meeting.ietf.org (sjc-vpn4-862.cisco.com [10.21.83.93]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6TKRK6m014158 for ; Fri, 29 Jul 2011 20:27:20 GMT Received: from [127.0.0.1] by dhcp-57cd.meeting.ietf.org (PGP Universal service); Fri, 29 Jul 2011 16:27:20 -0400 X-PGP-Universal: processed; by dhcp-57cd.meeting.ietf.org on Fri, 29 Jul 2011 16:27:20 -0400 From: Fred Baker Date: Fri, 29 Jul 2011 16:27:00 -0400 References: To: "v6ops@ietf.org WG" Message-Id: <34247C24-A672-4829-B0C3-4F8985FAE5E0@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-16-804055370 Subject: [v6ops] Fwd: Request for Comments: draft-chown-v6ops-address-accountability X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 20:27:44 -0000 --Apple-Mail-16-804055370 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This seems like an appropriate response... Begin forwarded message: > From: privacydir-owner@ietf.org > Date: July 29, 2011 3:49:08 PM EDT > To: fred@cisco.com > Subject: Request for Comments: = draft-chown-v6ops-address-accountability >=20 > Only members can post to this list. >=20 >=20 > From: Fred Baker > Date: July 29, 2011 3:48:52 PM EDT > To: privacydir@ietf.org > Cc: "v6ops@ietf.org WG" > Subject: Request for Comments: = draft-chown-v6ops-address-accountability >=20 >=20 > v6ops heard a presentation of >=20 > http://tools.ietf.org/html/draft-chown-v6ops-address-accountability > "IPv6 Address Accountability Considerations", Tim Chown, 11-Jul-11 >=20 > today. We have a sneaking hunch that the Privacy Directorate might = have opinions on the topic and on the recommendations developed in = v6ops. We would appreciate comments on the interaction between = legitimate (and in some cases statutory) requirements for user privacy = and legitimate (and in some cases statutory) requirements for = accountability of users for the behavior of their applications and = resulting traffic. >=20 --Apple-Mail-16-804055370 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = seems like an appropriate response...

Begin forwarded = message:

Date: July 29, 2011 3:49:08 PM EDT
Subject: Request for = Comments: = draft-chown-v6ops-address-accountability

Only = members can post to this list.


From: Fred Baker <fred@cisco.com>
Date: = July 29, 2011 3:48:52 PM EDT
To: = privacydir@ietf.org
Subject: = Request for Comments: = draft-chown-v6ops-address-accountability


v6ops= heard a presentation of

http://tools.ietf.org/html/draft-chown-v6ops-address-accountability=
 "IPv6 Address Accountability Considerations", Tim Chown, = 11-Jul-11

today. We have a sneaking hunch that the Privacy = Directorate might have opinions on the topic and on the recommendations = developed in v6ops. We would appreciate comments on the interaction = between legitimate (and in some cases statutory) requirements for user = privacy and legitimate (and in some cases statutory) requirements for = accountability of users for the behavior of their applications and = resulting traffic.


= --Apple-Mail-16-804055370-- From marka@isc.org Fri Jul 29 18:16:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4432B21F8BF6; Fri, 29 Jul 2011 18:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=4.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVlXJCDWlsUy; Fri, 29 Jul 2011 18:16:34 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2937D21F8BF3; Fri, 29 Jul 2011 18:16:33 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 997965F98E9; Sat, 30 Jul 2011 01:14:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id EC7C2216C84; Sat, 30 Jul 2011 01:14:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 05D3212542D0; Sat, 30 Jul 2011 11:06:25 +1000 (EST) To: Jeroen Massar From: Mark Andrews References: <13205C286662DE4387D9AF3AC30EF456D3F431D11F@EMBX01-WF.jnpr.net> <4E2DE4EC.1030109@gmail.com> <4E2E2FBA.1030304@gmail.com> <13205C286662DE4387D9AF3AC30EF456D3F44833C5@EMBX01-WF.jnpr.net> <4E2EDF23.3060804@gmail.com> <4E2F4491.30102@gmail.com> <20110727023833.5C72D1232958@drugs.dv.isc.org> <968F0B1C-D082-4A59-8213-FD58C74AF89D@nominum.com> <20110727151517.CF9371235D70@drugs.dv.isc.org> <999C3229-649D-4242-BB0F-2BB494EDF1D9@network-heretics.com> <4E305E3E.2040607@unfix.org> <20110727233634.406021238970@drugs.dv.isc.org> <4E3127F1.2030708@unfix.org> In-reply-to: Your message of "Thu, 28 Jul 2011 11:12:17 +0200." <4E3127F1.2030708@unfix.org> Date: Sat, 30 Jul 2011 11:06:25 +1000 Message-Id: <20110730010626.05D3212542D0@drugs.dv.isc.org> Cc: IPv6 Operations , Keith Moore , IETF Discussion Subject: Re: [v6ops] 6to4v2 (as in ripv2)? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 01:16:44 -0000 In message <4E3127F1.2030708@unfix.org>, Jeroen Massar writes: > On 2011-07-28 01:36 , Mark Andrews wrote: > [..] > > Is there *one* tunnel management protocol that they all support or > > does a cpe vendor have to implement multiple ones to reach them > > all? I'm pretty sure I know the answer to this question but I'd > > love to be proved wrong. > > There is no 'one' solution to the problems that they are solving. > > As such there tend to be a combo of: > - static proto-41 tunnel > - 6to4 > - 6rd > - TSP => dynamic NATted addresses > - proto-41 + heartbeat + TIC => dynamic public addresses > - AYIYA + TIC => dynamic NATted addresses I was more thinking about commonality with tunnel brokers. 6rd is not a replacement for 6to4 as it requires ISP involment or someone to create a registry of 3rd party 6rd providers along with associated parameters sets similar non anycast 6to4. static proto-41 tunnel is also not a viable replacement as it doesn't handle address reassignment at the CPE end. > TSP conveys configurartion information inline with the UDP packets. > TIC is solely for configuration information and does not do tunneling > but can be used for all proto-41/heartbeat/AYIYA protocols (and for > instance AVM chose to only do proto-41 + heartbeat as their devices > always have public IPv4 IPs). > > Teredo is only for a single host thus is not useful for CPEs and thus > not included in them. > > > One of the advantages of 6to4 anycast is that it is just needs a > > check box to turn on and off. Everybody speaks the same thing. > > Except that it does not work behind a NAT and most people do sit behind > a NAT. > > Next to that those anycasts are even rarer around the world and on top > of that it is hard to figure out issues when they are there (although > some people have tricks to apparently debug them, the anycast on both > IPv4 and IPv6 requires one to contact a lot of folks). > > The big advantage over a known tunnel endpoint is the known behavior of > that endpoint and the simple way of complaining when something is > broken. And people fortunately do complain when stuff is broken, > unfortunately not always with the proper details though, but I am to > blame for not finishing that program up... > > > Another advantage of 6to4 is it doesn't require manual intervention > > on renumber events. Manual tunnel don't pass muster. > > I guess you are one of the lucky people to get a public static IPv4 > address prefix at home that never renumbers? Guess what, most of the > world does not have that luxury, they get 1 dynamic address and for > instance in Germany they get a disconnect/force-renumber every 24 hours > (according to the ISPs because of 'accounting' reasons...) > > Do realize that when you have that public IPv4 address, when it changes > you are renumbering your 2002:::/48 prefix everywhere. Fun... > (I hope you also like asking 6to4.nro.net everytime to change your reverse) > > The tunnels above all have ISP-supplied prefixes and tend to be static > (I think TSP anonymous tunnels rotate addresses, but the majority just > keeps on returning the same static allocation, in the case of SixXS you > really get a fixed address, much easier on the PoP side and we can do > whois and store it in the relevant RIR registry) > > > Another advantage of 6to4 is you don't have to register. For most of > > the tunnel brokers you have to register. > > I guess you also where able to anonymously sign up to your IPv4 ISP!? :) > Especially that static IPv4 address must be wonderful to get that way. > > Note that Freenet6 offers 'anonymous' tunnels, thus that is just a TSP away. > > Something with the amounts of abuse made us (SixXS) require that we > require valid address data. Next to that it is a RIPE requirement to > register /48 prefixes. Other Tunnelbrokers just started blocking things > like IRC and NNTP because there was too much abuse or traffic.... > We kill off accounts of people when they abuse, google my name and you > will find various people who where caught in the act and are quite mad > that they can't have funny vhosts on IRC anymore and attract 500mbit > DoSses and other such nonsense which are not the goal of providing IPv6. > > Also, the registration means that people can just type in their > username/password (and optionally which tunnel they want to use out of > the multiple tunnels they might have) in their CPE and the CPE then uses > TIC or TSP to fetch this configuration and set it all up, and it will > just work(tm). > > As a nice example see http://www.sixxs.net/wiki/images/FritzboxHowto.jpg > and > http://www.sixxs.net/wiki/Fritz!Box_7270 > > Next to that knowing where the user is and more importantly their > endpoint allows one to select a proper PoP for that user close to their > endpoint causing low latency and generally high throughput. > > With anycast you are just hoping that that all will work. > > Greets, > Jeroen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From john_brzozowski@cable.comcast.com Fri Jul 29 21:33:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2899521F8C9D for ; Fri, 29 Jul 2011 21:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoA70jvygZH4 for ; Fri, 29 Jul 2011 21:33:50 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 444F921F8CA1 for ; Fri, 29 Jul 2011 21:33:47 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46805493; Fri, 29 Jul 2011 22:38:35 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Sat, 30 Jul 2011 00:33:43 -0400 From: "Brzozowski, John" To: Joel Jaeggli , Lorenzo Colitti Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMTTzrYQ4f7+JsMUusl+Ald1vnPZUEDaeA Date: Sat, 30 Jul 2011 04:33:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 04:33:51 -0000 Why would it have to if the guest network or other LAN side network is simply a subset of a larger allocated prefix? On 7/28/11 11:42 AM, "Joel Jaeggli" wrote: > > >Can such a default be extensible to exchange different types of >information than just reachability? For example, can it propagate >information such as "this is a guest network and this is an internal >network" or "this is a prefix that I have tentatively assigned but do not >own yet"? If not, then perhaps something more flexible like IS-IS would >be better. > > > > >If the routing protocol were not dependent on the ip layer having already >been bootstrapped that might the ease the complexity and depedancy graph >during setup... From john_brzozowski@cable.comcast.com Fri Jul 29 21:34:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2823621F8CB2 for ; Fri, 29 Jul 2011 21:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g24MxXlhG+Vx for ; Fri, 29 Jul 2011 21:34:51 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4C60C21F8CA0 for ; Fri, 29 Jul 2011 21:34:50 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46805526; Fri, 29 Jul 2011 22:39:30 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Sat, 30 Jul 2011 00:34:44 -0400 From: "Brzozowski, John" To: Lorenzo Colitti , Joel Jaeggli Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMTTmsYQ4f7+JsMUusl+Ald1vnPZUCgEUAgAGPloA= Date: Sat, 30 Jul 2011 04:34:43 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B53AD7BFA6B694F8DFA105BE3E70F79@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 04:34:52 -0000 On 7/28/11 5:18 PM, "Lorenzo Colitti" wrote: >I would add: > >* can distribute information beyond IP reachability; for example, "this >prefix belongs to a guest network" or "this is a prefix that I have >tentatively assigned to my interface, not a prefix that is already in >use". This would be useful for autoconfiguration. [jjmb] as I emailed before why would this be required of the LAN side network is part of an already delegated prefix? Am I missing something? > >It might also be good if the protocol supported authentication so that >unrelated devices could not join the network. [jjmb] not sure this is a might, if this were to be used authentication would be required. > >Personally, I think preventing interaction with the ISP's IGP is the >ISP's business, not the device's. An ISP that listens to routing protocol >advertisements from home users with no prior agreement with them deserves >what it gets. That said, you could use different authentication keys to >prevent interaction, even if the protocol is the same. Others have asked >to use a different protocol because some implementations can't run, e.g., >multiple OSPF processes or multiple IS-IS processes, but it doesn't seem >that this is an unsolvable technical problem. [jjmb] agreed. It seems to me that specifying the use of an IGP like OSPF or ISIS is overkill for a home scenario. For a business or SOHO perhaps this would be ok, not to reiterate what others have said about resource constraints and complexity of setup for some types of users. From john_brzozowski@cable.comcast.com Fri Jul 29 21:48:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647F621F8CB7 for ; Fri, 29 Jul 2011 21:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.419 X-Spam-Level: X-Spam-Status: No, score=-101.419 tagged_above=-999 required=5 tests=[AWL=-1.484, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_62=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54DUR2BQ3auH for ; Fri, 29 Jul 2011 21:48:56 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 95E8021F8CB1 for ; Fri, 29 Jul 2011 21:48:56 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46805494; Fri, 29 Jul 2011 22:38:37 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Sat, 30 Jul 2011 00:33:45 -0400 From: "Brzozowski, John" To: Shishio Tsuchiya , Joel Jaeggli Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMTTmsYQ4f7+JsMUusl+Ald1vnPZUCWDsAgAG2BQA= Date: Sat, 30 Jul 2011 04:33:44 +0000 Message-ID: In-Reply-To: <4E31B074.4060000@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 04:48:57 -0000 These seem like reasonable, basic recommendations. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 7/28/11 2:54 PM, "Shishio Tsuchiya" wrote: >Just for your information, >We considered about routing protocol on LAN and WAN. >http://www.v6pc.jp/pdf/v6hgw_Guideline_1_0-English.pdf >I listed our consensus in below >-Routing Control on WAN-side >1.Static route =20 >2.Automatic Configuration of Default Route Using RA >Both requirement as mandatory[MUST]. > >-Route Control to LAN-side >1.RIPng [RFC 2080] >2.More-Specific Route [RFC 4191] >Both requirement as Optional[May]. > >We thought this is typical case for our countries. >Of course,we are watching ietf homenet discussion. >If the requirement would be acceptable in our environment too,we will >modify our guideline. > >Regards, >-Shishio > > >Joel Jaeggli wrote: >>=20 >> On Jul 27, 2011, at 2:21 PM, Shishio Tsuchiya wrote: >>=20 >>> Mikael >>> Mikael Abrahamsson wrote: >>>> On Wed, 27 Jul 2011, Shishio Tsuchiya wrote: >>>> >>>>> I think OSPFv3 is not acceptable as default routing protocol on CPE >>>>>router. >>>> >>>> Care to elaborate on that? >>>> >>> >>> Most of home gateway supports only RIPv1/v2 as IPv4 routing protocol. >>> The reasons are.. >>> -OSPF consumes CPU/memory than RIP. >>> -OSPF operetaion is needed more knowledge compare with RIP. >>> The character of these protocol does not change on IPv6 >>>environment,too. >>> So we thought RIPng would be acceptable routing protocol for IPv6 CPE >>>router,also. >>=20 >> So, if one is working with requirements rather than working backwards >>from a selected protocol one would suppose that some of the requirements >>might look something like: >>=20 >> * can be used with acceptable defaults (e.g. no configuration) >> * has sensive safeguards to prevent interaction with isp IGP. >> * can distinguish between the desirability of a path on the basis of >>something other than hop count. e.g. just because I happen to have >>connected an 802.5.14 network to two largely ethernet devices doesn't >>mean traffic to other parts of the network should traverse the former >>when it happens to be the best path. >>=20 >>> Regards, >>> -Shishio >>> _______________________________________________ >>> 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 marka@isc.org Fri Jul 29 22:36:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483DA21F8CBC for ; Fri, 29 Jul 2011 22:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.636 X-Spam-Level: X-Spam-Status: No, score=-6.636 tagged_above=-999 required=5 tests=[AWL=3.963, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA8ysfJlCkI3 for ; Fri, 29 Jul 2011 22:35:56 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0CABF21F8CA3 for ; Fri, 29 Jul 2011 22:35:51 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 227775F98BF; Sat, 30 Jul 2011 05:34:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 331D2216C84; Sat, 30 Jul 2011 05:34:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C984E12551F3; Sat, 30 Jul 2011 15:34:17 +1000 (EST) To: Ari Keranen From: Mark Andrews References: <4E2F124D.1080706@nomadiclab.com> <20110727020904.CF46A123200A@drugs.dv.isc.org> <4E330192.9000506@nomadiclab.com> In-reply-to: Your message of "Fri, 29 Jul 2011 14:53:06 -0400." <4E330192.9000506@nomadiclab.com> Date: Sat, 30 Jul 2011 15:34:17 +1000 Message-Id: <20110730053417.C984E12551F3@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments for draft-keranen-ipv6day-measurements-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 05:36:01 -0000 In message <4E330192.9000506@nomadiclab.com>, Ari Keranen writes: > Hi Mark, > > On 26.7.2011 22:09, Mark Andrews wrote: > > What we need is Radware, F5 and other load balancer vendors to send > > out instructions to their customer on how to correctly configure > > their load balancers to serve A records at the top of a zone rather > > that one label deep in a zone. This misconfiguration is responsible > > for +90% of AAAA lookup failures. > > This sounds interesting (and disturbing). Is the "+90%" your personal > estimate or are there actual measurements done with this? Any publications? Go look at the Alexa top million sites. The is a couple of percent failure rate on AAAA lookup. Then examine those failures. > Cheers, > Ari > > Lots of load balancers are delegated to as "www.example.com" but > > the load balancer is configured to serve "example.com" rather than > > the zone that is *actually* delegated to it. This results in invalid > > negative responses being sent (the SOA record returned in the > > negative response is for "example.com" rather than "www.example.com") > > which is then rejected by the recursive nameserver. > > > > Radware and F5 are mention because I've chased down actual failures, > > in the last 3 months, and these were the reported products involved. > > I'm sure there will be other vendor that also have similar issues. > > > > Mark > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ichiroumakino@gmail.com Sat Jul 30 05:35:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A2821F8891 for ; Sat, 30 Jul 2011 05:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGEmfUIBcPQx for ; Sat, 30 Jul 2011 05:35:17 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3E13E21F8751 for ; Sat, 30 Jul 2011 05:35:17 -0700 (PDT) Received: by pzk6 with SMTP id 6so7528269pzk.26 for ; Sat, 30 Jul 2011 05:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=KRnkCYxQgjt9caIpimdaNXEAAZf3bhq2kYc7gnKul6o=; b=kq56y0HwY1RJ2Yt1tcfQOS3/i+C9hBkuJ7R+VJKn2EJ+lumi0MMaUVUVnbDsVaNEFn mJxc8GqiicZYSojXoBzTl4k0fh2QrJSlNBsr8hHLSbyX7bjTKbZ5/gvALiUXGyY/O9GB YE6Mkbw8hxO115fdmve2F7P5+9t/Dru9cZHHM= Received: by 10.68.54.42 with SMTP id g10mr326011pbp.31.1312029317550; Sat, 30 Jul 2011 05:35:17 -0700 (PDT) Received: from [10.21.78.54] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id p7sm3211579pbn.65.2011.07.30.05.35.14 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jul 2011 05:35:16 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Sat, 30 Jul 2011 08:35:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Brzozowski, John" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 12:35:17 -0000 John, > [jjmb] agreed. It seems to me that specifying the use of an IGP like = OSPF > or ISIS is overkill for a home scenario. For a business or SOHO = perhaps > this would be ok, not to reiterate what others have said about = resource > constraints and complexity of setup for some types of users. two ideas in prefix assignment space: - use zOSPF (border routers advertise a site prefix in a new LSA, = internal routers randomly pick a subnet id and does collision detection for each of their links) - use a DHCP "God server" with SPF topology. each internal router = requests a /64 for its downstream links, as the DHCP server is part of the topology, it can make sure that each link only = gets a single prefix even if multiple routers are connected to it. both ideas require something different than RIP. let's give homenet a little time to figure out what they like to do = before making a decision. cheers, Ole= From xing@cernet.edu.cn Sat Jul 30 07:13:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6860C21F8AEE for ; Sat, 30 Jul 2011 07:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.171 X-Spam-Level: X-Spam-Status: No, score=-99.171 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1uAHcPX2uRK for ; Sat, 30 Jul 2011 07:13:29 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id A9B7B21F8678 for ; Sat, 30 Jul 2011 07:13:28 -0700 (PDT) Received: from [127.0.0.1]([70.25.120.2]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm1f4e344f27; Sat, 30 Jul 2011 22:13:22 +0800 Message-ID: <4E34113A.9070508@cernet.edu.cn> Date: Sat, 30 Jul 2011 22:12:10 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ray Hunter References: <4E3071B6.3060807@globis.net> <851D47FA-41FB-4845-A2A4-A259CCE77D39@cisco.com> <4E30CF01.9000705@globis.net> <4E31B4DA.1030700@cernet.edu.cn> <4E31C1E9.1050706@globis.net> In-Reply-To: <4E31C1E9.1050706@globis.net> Content-Type: multipart/alternative; boundary="------------020809000009050903070408" X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: c4GSKn0B Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 14:13:33 -0000 This is a multi-part message in MIME format. --------------020809000009050903070408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ? 2011/7/29 4:09, Ray Hunter ??: > Following all IMVHO. > > Sorry I'm not convinced. It isn't just packet firewalls that are going > to need/want to drop these packets. > > Imagine I'm acting as the responsible owner of an AS. Under this > proposal I have all downside and no upside. Let me explain..... > > If this range is going to be used for sourcing DDOS traffic (and I > strongly suspect it will), and it isn't going to be possible to easily > isolate or debug which upstream AS or site or network interface or > customer device was the source of that bad traffic, then the packets > need to get dropped at the AS border and every other uncontrolled > entry point on the network that connects to third party managed > devices. I don't want untraceable packets sourced by someone else > floating around in my network and potentially causing trouble tickets > / problems that cost my staff's and my management time. > > Equally, if I'm acting as a responsible network operator, I don't want > to act as a transit on a potential DDOS attack to other AS'es to avoid > hurting my own good reputation (the downstream AS will have no idea if > the DDOS attack originated in my AS, or another upstream AS, and my AS > was just acting as a transit). Either way I'd look daft, and the DDOS > attack would be difficult or impossible to trace: which is precisely > one reason why ingress filters were recommended in the first place. > > So all ingress and egress filters will probably end up dropping the > new special range, and no one will be any the wiser. > > In which case, using the special /24 shared range is actually less > useful compared to just using a locally significant and existing > RFC1918 range of addresses for each translator in my network for the > translation of IMCPv6 messages sourced behind my own IPv6/IPv4 > translator(s) IMHO. At least then I and my staff would know exactly > which translator the ICMP message came from in my AS if there was more > than one translator present, and I'd be able to take corrective action > if necessary. Plus I'd know for certain if I saw such RFC1918 sourced > ICMP traffic in my AS that they weren't sourced from someone else's > translator in another AS that I don't even manage. And yes packets > with RFC1918 source-addresses would also be dropped at the AS border, > as today. Actually they are the configuration choices (1) If the network owner of the translator(s) has enough public IPv4 address, he/she can configure the translator(s) using the public IPv4 for it. However, for many networks, they cannot afford to do so due to the IPv4 address depletion. (2) The network owner can use RFC1918 for this. However, if the network has already use RFC1918 addresses, careful network plan is needed. In addition, this cannot be used to identify the IPv4/IPv6 translation. (3) The special /24 can be thought as a "new block of RFC1918" in this sense, i.e. the routing behavior is similar. However, this block is targeting the IPv4/IPv6 translation, and can be configured specifically for it. This provides more control for the network administrator. The drawback for this method is that the network administrators needs to update the acl list for this special block. However, we believe it is worth the effort for the transition. For your reference, there were some discussions in the earlier version of this draft, see http://tools.ietf.org/html/draft-xli-behave-icmp-address-02 If people think we need more discussion like this, we can put the discussion in the appendix of this document. Regards, xing > > regards, > RayH > > > Xing Li wrote: >> Hi, Ray, >> >> ? 2011/7/28 10:52, Ray Hunter ??: >>> The concern would be that the special /24 is creating a new range that: >>> >>> - carries ICMP control messages, which could also be used to attempt >>> to alter a senders' behavior >>> - is shared between multiple providers >>> - is not traceable >> >> When the special /24 is used, it can identify that the ICMP messages >> are generated in IPv6. >>> - should not be filtered at AS boundaries >>> >>> which could grant an attacker a perfect set of source addresses for >>> mounting a DDOS attack. >>> >>> Yes the range isn't routable as a destination, but that possibly >>> makes it even worse, as the target of any DDOS sourced from this >>> range would have absolutely no idea who was sending them the huge >>> volume of junk packets, except by incoming interface at the AS >>> boundary. I see no reason why a network operator would want to >>> accept such a packet from another AS into their network, so they'll >>> basically get filtered everywhere after the very first attack IMHO. >> >> As partially discussed in previous mail. This will not introduce new >> issues compared with using RFC1918 space. In Section 6 of this draft says >> >> 6. Security Considerations >> >> The use of an address for source addresses in ICMP packets is >> considered "safe" in so far as ICMP packets are not intended to >> generate responses directed to the source address. >> >> However it is possible to use this address as a means of gaining >> anonymity when launching a denial of service attacks by using this >> address as the source address for other forms of malicious traffic. >> Packet firewall filters should be configured to treat addresses in >> the IANA-assigned /24 network as martian addresses by discarding all >> non-ICMP packets that use the IANA-assigned /24 network as a source >> address, and all packets that use the IANA-assigned /24 network as a >> destination address. >> >> Regards, >> >> xing >> >> >> >>> regards, >>> RayH >>> >>> Fred Baker wrote: >>>> On Jul 27, 2011, at 4:14 PM, Ray Hunter wrote: >>>> >>>>> Am I permitted to ask some dumb questions about this draft since >>>>> it seems to be urgent? >>>> >>>> Certainly. I will ask the authors to respond to them. >>>> >>>>> The draft talks about translating IPv6 ICMPv6 responses back to a >>>>> special shared /24 public IPv4 source range where responses are >>>>> not 1:1 IPv6 source - IPv4 source mappable (presumably because >>>>> network links and equipment on the IPv6 side are using IPv6 space >>>>> from outside the mapped range). >>>>> >>>>> Don't we have this situation already when traversing multiple IPv4 >>>>> networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN >>>>> links? >>>>> >>>>> In that case doesn't ICMP just have to live with an RFC1918 source >>>>> address, and no one seems to have complained too bitterly so far? >>>>> >>>>> What's so special about this new IPv6 mapped situation that is >>>>> different to the existing situation of overlapping RFC 1918 >>>>> addresses used by multiple providers, where it's already unclear >>>>> which unique node on the path generated the ICMP message, and >>>>> where uRPF filters would already be an issue? >>>>> >>>>> i.e. why should the ICMP messages just not be dropped in this case >>>>> at the AS border, or be sent with RFC 1918 source addresses within >>>>> an AS, or be sent using a source address from a globally unique >>>>> (/24) sub-range of the existing provider IPv4 space assigned to >>>>> the translator if they are so important? >>>>> >>>>> I'm sorry, and maybe it's me being totally dumb, but I just don't >>>>> see the added value of a "special" /24 shared amongst multiple >>>>> providers, especially if there are possibly multiple translators >>>>> and multiple providers on a path. It just doesn't seem to give any >>>>> significant extra information to the intended recipient, and if >>>>> anything may lead to more confusion. 128 into 32 doesn't go. End >>>>> of story. >>>>> >>>>> regards, >>>>> RayH >>>>> >>>>>> Subject: >>>>>> [v6ops] Fwd: Request for WG Adoption of >>>>>> draft-xli-v6ops-ivi-icmp-address-00 >>>>>> From: >>>>>> Fred Baker >>>>>> Date: >>>>>> Wed, 27 Jul 2011 14:40:59 -0400 >>>>>> >>>>>> To: >>>>>> IPv6 Operations >>>>>> >>>>>> Content-Transfer-Encoding: >>>>>> quoted-printable >>>>>> Precedence: >>>>>> list >>>>>> MIME-Version: >>>>>> 1.0 (Apple Message framework v1084) >>>>>> References: >>>>>> <4E2ED0F0.1070301@cernet.edu.cn> >>>>>> Message-ID: >>>>>> >>>>>> Content-Type: >>>>>> text/plain; charset=us-ascii >>>>>> Message: >>>>>> 6 >>>>>> >>>>>> >>>>>> Folks: the chairs are in receipt of this note. Please read the draft and comment. >>>>>> >>>>>> In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment. >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>> >>>>>>> > From: Xing Li >>>>>>> > Date: July 26, 2011 10:36:32 AM EDT >>>>>>> > To:v6ops-chairs@tools.ietf.org >>>>>>> > Cc:v6ops@ietf.org,draft-xli-v6ops-ivi-icmp-address@tools.ietf.org >>>>>>> > Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 >>>>>>> > >>>>>>> > Hi V6ops Chairs, >>>>>>> > >>>>>>> > The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption. >>>>>>> > >>>>>>> > The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4. >>>>>>> > >>>>>>> > The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list. >>>>>>> > >>>>>>> > regards, >>>>>>> > >>>>>>> > Xing Li >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > --------------020809000009050903070408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 于 2011/7/29 4:09, Ray Hunter 写道:
Following all IMVHO.

Sorry I'm not convinced. It isn't just packet firewalls that are going to need/want to drop these packets.

Imagine I'm acting as the responsible owner of an AS. Under this proposal I have all downside and no upside. Let me explain.....

If this range is going to be used for sourcing DDOS traffic (and I strongly suspect it will), and it isn't going to be possible to easily isolate or debug which upstream AS or site or network interface or customer device was the source of that bad traffic, then the packets need to get dropped at the AS border and every other uncontrolled entry point on the network that connects to third party managed devices. I don't want untraceable packets sourced by someone else floating around in my network and potentially causing trouble tickets / problems that cost my staff's and my management time.

Equally, if I'm acting as a responsible network operator, I don't want to act as a transit on a potential DDOS attack to other AS'es to avoid hurting my own good reputation (the downstream AS will have no idea if the DDOS attack originated in my AS, or another upstream AS, and my AS was just acting as a transit). Either way I'd look daft, and the DDOS attack would be difficult or impossible to trace: which is precisely one reason why ingress filters were recommended in the first place.

So all ingress and egress filters will probably end up dropping the new special range, and no one will be any the wiser.

In which case, using the special /24 shared range is actually less useful compared to just using a locally significant and existing  RFC1918 range of addresses for each translator in my network for the translation of IMCPv6 messages sourced behind my own IPv6/IPv4 translator(s) IMHO. At least then I and my staff would know exactly which translator the ICMP message came from in my AS if there was more than one translator present, and I'd be able to take corrective action if necessary.  Plus I'd know for certain if I saw such RFC1918 sourced ICMP traffic in my AS that they weren't sourced from someone else's translator in another AS that I don't even manage. And yes packets with RFC1918 source-addresses would also be dropped at the AS border, as today.

Actually they are the configuration choices
(1)    If the network owner of the translator(s) has enough public IPv4 address, he/she can configure the translator(s) using the public IPv4 for it. However, for many networks, they cannot afford to do so due to the IPv4 address depletion.
(2)    The network owner can use RFC1918 for this. However, if the network has already use RFC1918 addresses, careful network plan is needed. In addition, this cannot be used to identify the IPv4/IPv6 translation.
(3)    The special /24 can be thought as a "new block of RFC1918" in this sense, i.e. the routing behavior is similar. However, this block is targeting the IPv4/IPv6 translation, and can be configured specifically for it. This provides more control for the network administrator. The drawback for this method is that the network administrators needs to update the acl list for this special block. However, we believe it is worth the effort for the transition.

For your reference, there were some discussions in the earlier version of this draft, see  http://tools.ietf.org/html/draft-xli-behave-icmp-address-02 If people think we need more discussion like this, we can put the discussion in the appendix of this document.

Regards,

xing




regards,
RayH


Xing Li wrote:
Hi, Ray,

于 2011/7/28 10:52, Ray Hunter 写道:
The concern would be that the special /24 is creating a new range that:

- carries ICMP control messages, which could also be used to attempt to alter a senders' behavior
- is shared between multiple providers
- is not traceable

When the special /24 is used, it can identify that the ICMP messages are generated in IPv6.
- should not be filtered at AS boundaries

which could grant an attacker a perfect set of source addresses for mounting a DDOS attack.

Yes the range isn't routable as a destination, but that possibly makes it even worse, as the target of any DDOS sourced from this range would have absolutely no idea who was sending them the huge volume of junk packets, except by incoming interface at the AS boundary. I see no reason why a network operator would want to accept such a packet from another AS into their network, so they'll basically get filtered everywhere after the very first attack IMHO.

As partially discussed in previous mail. This will not introduce new issues compared with using RFC1918 space. In Section 6 of this draft says

6.  Security Considerations

   The use of an address for source addresses in ICMP packets is
   considered "safe" in so far as ICMP packets are not intended to
   generate responses directed to the source address.

   However it is possible to use this address as a means of gaining
   anonymity when launching a denial of service attacks by using this
   address as the source address for other forms of malicious traffic.
   Packet firewall filters should be configured to treat addresses in
   the IANA-assigned /24 network as martian addresses by discarding all
   non-ICMP packets that use the IANA-assigned /24 network as a source
   address, and all packets that use the IANA-assigned /24 network as a
   destination address.

Regards,

xing

regards,
RayH

Fred Baker wrote:
On Jul 27, 2011, at 4:14 PM, Ray Hunter wrote:

Am I permitted to ask some dumb questions about this draft since it seems to be urgent?

Certainly. I will ask the authors to respond to them.

The draft talks about translating IPv6 ICMPv6 responses back to a special shared /24 public IPv4 source range where responses are not 1:1 IPv6 source - IPv4 source mappable (presumably because network links and equipment on the IPv6 side are using IPv6 space from outside the mapped range).

Don't we have this situation already when traversing multiple IPv4 networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN links?

In that case doesn't ICMP just have to live with an RFC1918 source address, and no one seems to have complained too bitterly so far?

What's so special about this new IPv6 mapped situation that is different to the existing situation of overlapping RFC 1918 addresses used by multiple providers, where it's already unclear which unique node on the path generated the ICMP message, and where uRPF filters would already be an issue?

i.e. why should the ICMP messages just not be dropped in this case at the AS border, or be sent with RFC 1918 source addresses within an AS, or be sent using a source address from a globally unique (/24) sub-range of the existing provider IPv4 space assigned to the translator if they are so important?

I'm sorry, and maybe it's me being totally dumb, but I just don't see the added value of a "special" /24 shared amongst multiple providers, especially if there are possibly multiple translators and multiple providers on a path. It just doesn't seem to give any significant extra information to the intended recipient, and if anything may lead to more confusion. 128 into 32 doesn't go. End of story.

regards,
RayH

Subject:
[v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
From:
Fred Baker <fred@cisco.com>
Date:
Wed, 27 Jul 2011 14:40:59 -0400
To:
IPv6 Operations <v6ops@ietf.org>
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1084)
References:
<4E2ED0F0.1070301@cernet.edu.cn>
Message-ID:
<FEA206CA-692A-443E-A2C5-8C437D0AB42A@cisco.com>
Content-Type:
text/plain; charset=us-ascii
Message:
6		 

Folks: the chairs are in receipt of this note. Please read the draft and comment.

In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment.

Begin forwarded message:

  
> From: Xing Li <xing@cernet.edu.cn>
> Date: July 26, 2011 10:36:32 AM EDT
> To: v6ops-chairs@tools.ietf.org
> Cc: v6ops@ietf.org, draft-xli-v6ops-ivi-icmp-address@tools.ietf.org
> Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
> 
> Hi V6ops Chairs,
> 
> The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption.
> 
> The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4.
> 
> The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list.
> 
> regards,
> 
> Xing Li
> 
> 
> 
> 
    


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


--------------020809000009050903070408-- From xing@cernet.edu.cn Sat Jul 30 07:16:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED7421F8AFF for ; Sat, 30 Jul 2011 07:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.719 X-Spam-Level: X-Spam-Status: No, score=-99.719 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ixl+46pouc3V for ; Sat, 30 Jul 2011 07:16:56 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 30AE421F8AF9 for ; Sat, 30 Jul 2011 07:16:55 -0700 (PDT) Received: from [127.0.0.1]([70.25.120.2]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb4e344ffd; Sat, 30 Jul 2011 22:16:55 +0800 Message-ID: <4E341250.80803@cernet.edu.cn> Date: Sat, 30 Jul 2011 22:16:48 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: David Farmer References: <4E3071B6.3060807@globis.net> <851D47FA-41FB-4845-A2A4-A259CCE77D39@cisco.com> <4E30CF01.9000705@globis.net> <4E31B4DA.1030700@cernet.edu.cn> <4E320F8E.7040809@umn.edu> In-Reply-To: <4E320F8E.7040809@umn.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: cc7VKn0B Cc: Ray Hunter , "v6ops@ietf.org WG" Subject: Re: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 14:16:57 -0000 Hi, David, 于 2011/7/29 9:40, David Farmer 写道: > On 7/28/11 14:13 CDT, Xing Li wrote: >> Hi, Ray, >> >> 于 2011/7/28 10:52, Ray Hunter 写道: >>> The concern would be that the special /24 is creating a new range that: >>> >>> - carries ICMP control messages, which could also be used to attempt >>> to alter a senders' behavior >>> - is shared between multiple providers >>> - is not traceable >> >> When the special /24 is used, it can identify that the ICMP messages are >> generated in IPv6. >>> - should not be filtered at AS boundaries >>> >>> which could grant an attacker a perfect set of source addresses for >>> mounting a DDOS attack. >>> >>> Yes the range isn't routable as a destination, but that possibly makes >>> it even worse, as the target of any DDOS sourced from this range would >>> have absolutely no idea who was sending them the huge volume of junk >>> packets, except by incoming interface at the AS boundary. I see no >>> reason why a network operator would want to accept such a packet from >>> another AS into their network, so they'll basically get filtered >>> everywhere after the very first attack IMHO. >> >> As partially discussed in previous mail. This will not introduce new >> issues compared with using RFC1918 space. In Section 6 of this draft >> says >> >> 6. Security Considerations >> >> The use of an address for source addresses in ICMP packets is >> considered "safe" in so far as ICMP packets are not intended to >> generate responses directed to the source address. >> >> However it is possible to use this address as a means of gaining >> anonymity when launching a denial of service attacks by using this >> address as the source address for other forms of malicious traffic. >> Packet firewall filters should be configured to treat addresses in >> the IANA-assigned /24 network as martian addresses by discarding all >> non-ICMP packets that use the IANA-assigned /24 network as a source >> address, and all packets that use the IANA-assigned /24 network as a >> destination address. > > If this draft goes forward, beyond the above, I would like to see > recommendations of both filtering to an appropriate list of ICMP types > and probably an overall rate limiting of traffic from the prefix as > additional countermeasure against abuse of this prefix. > > Given the stated intended use I believe ICMP type 3 - Destination > Unreachable, ICMP type 11 - Time Exceeded, and maybe ICMP type 12 - > Parameter Problem, and I'm not sure this last one is needed, are the > only ICMP messages that SHOULD be allowed to be sourced from this > prefix. Additionally, this prefix SHOULD NOT be allowed to source any > of the various ICMP request messages, as the response would > necessarily have an destination address that is a martian address by > even the current Security Considerations statement. > Thanks, we can add the recommendations for acl and rate limiting for this special /24 in the document. > Ray is correct that this needs to apply not just to firewall filters > but probably most AS border filters as well. He is also correct, that > many operators will just filter the prefix completely. > > However, I see an advantage to assigning a well-known prefix in that > it simplifies coordination of like minded operators allowing the > appropriate ICMP messages to pass through their AS borders if they > find it advantageous, even if many or most operators do not and block > all packets sourced or destined to the prefix. Trying to coordinate > the use of an RFC 1918 prefix for this purpose across even a limited > number of like minded operators is almost an impossible task. Agree. The special /24 is well defined and can be make the life of the operators easier. > > Finally, some consideration for Reverse DNS for this prefix should be > given. This is probably one of the best arguments for assigning a > well-known prefix, then some kind of human readable Reverse DNS can be > provided, to help mortal Internet users when they traceroute through > an IPv6/v4 translator. This probably belongs in the IANA > considerations section, or a separate section discussing Reverse DNS. Agree. We will try add this section. Thanks. Regards, xing From lorenzo@google.com Sat Jul 30 11:42:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAC321F8700 for ; Sat, 30 Jul 2011 11:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.826 X-Spam-Level: X-Spam-Status: No, score=-105.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov2jjlVC6WQv for ; Sat, 30 Jul 2011 11:42:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8170D21F8669 for ; Sat, 30 Jul 2011 11:42:03 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p6UIg3gu005348 for ; Sat, 30 Jul 2011 11:42:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312051324; bh=69baQM8tPUoY5s9CHa0bxzqw94s=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=bUJdWK3An6yV9y9V18GAOLPfzKTV2ec4fxCmEjxsqkdEiKrAbvaP9H1+x+32b+BI1 4k4rFOEsKElZqWrlI5QKA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=ldIwybTyN0k6wIEhRtvNGC9h8ljB2hPxN3kGmv4H0qiFLYz45JvX0oWXRb6YKDoNz NKFIn+OMRcZ5Wuh+1S6RQ== Received: from ywm21 (ywm21.prod.google.com [10.192.13.21]) by hpaq2.eem.corp.google.com with ESMTP id p6UIg1TP029166 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 30 Jul 2011 11:42:02 -0700 Received: by ywm21 with SMTP id 21so311590ywm.31 for ; Sat, 30 Jul 2011 11:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LScy+ye8BTA/uhB/1aKaZWpOtCmzuOiW59g6A8KbnCg=; b=dMCnRlCKr7QHjCtoHLWH7ZdZn/RCOuokvqpYaxUPSFmIH40WerexYhQ2yGiqzCra96 n14YTSliB+GXgqcQxNww== Received: by 10.151.50.15 with SMTP id c15mr240636ybk.285.1312051321293; Sat, 30 Jul 2011 11:42:01 -0700 (PDT) Received: by 10.151.50.15 with SMTP id c15mr240629ybk.285.1312051321109; Sat, 30 Jul 2011 11:42:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.133.15 with HTTP; Sat, 30 Jul 2011 11:41:41 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Sat, 30 Jul 2011 14:41:41 -0400 Message-ID: To: "Brzozowski, John" Content-Type: multipart/alternative; boundary=001517570906ebfe8904a94dc095 X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 18:42:04 -0000 --001517570906ebfe8904a94dc095 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jul 30, 2011 at 00:34, Brzozowski, John < John_Brzozowski@cable.comcast.com> wrote: > >* can distribute information beyond IP reachability; for example, "this > >prefix belongs to a guest network" or "this is a prefix that I have > >tentatively assigned to my interface, not a prefix that is already in > >use". This would be useful for autoconfiguration. > [jjmb] as I emailed before why would this be required of the LAN side > network is part of an already delegated prefix? Am I missing something? > In a routed home network, you want guest networks and non-guest networks to be routed, but not talk to each other. Carrying in the IGP the information about whether each /64 assigned to an interface is for a guest network or a non-guest network allows the routers to apply the appropriate firewalls between the guest network and the non-guest network, while still routing both guest and non-guest prefixes. It's a bit like having two VRFs or an MPLS VPN. As regards the "tentative" tag, that might be useful when doing autoconfiguration. As Ole says, a CE could pick one random /64 out of the aggregate for each of its interfaces and do collision detection to see if it's unique. If the IGP carries a flag saying "this prefix is tentative" that might make it easier. Of course, these are just examples of why a protocol that can carry additional information beyond just "this prefix lives here with this metric" can be useful: it allows the network to do stuff that we haven't thought of yet. Cheers, Lorenzo --001517570906ebfe8904a94dc095 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 30, 2011 at 00:34, Brzozowski, John = <= John_Brzozowski@cable.comcast.com> wrote:
>* can distribute information beyond IP reachability; = for example, "this
>prefix belongs to a guest network" or "this is a prefix that = I have
>tentatively assigned to my interface, not a prefix that is already in >use". This would be useful for autoconfiguration.
[jjmb] as I emailed before why would this be required of the LAN side=
network is part of an already delegated prefix? =A0Am I missing something?<= br>

In a routed home network, you want gues= t networks and non-guest networks to be routed, but not talk to each other.= Carrying in the IGP the information about whether each /64 assigned to an = interface is for a guest network or a non-guest network allows the routers = to apply the appropriate firewalls between the guest network and the non-gu= est network, while still routing both guest and non-guest prefixes. It'= s a bit like having two VRFs or an MPLS VPN.

As regards the "tentative" tag, that might be= useful when doing autoconfiguration. As Ole says, a CE could pick one rand= om /64 out of the aggregate for each of its interfaces and do collision det= ection to see if it's unique. If the IGP carries a flag saying "th= is prefix is tentative" that might make it easier.

Of course, these are just examples of why a protocol th= at can carry additional information beyond just "this prefix lives her= e with this metric" can be useful: it allows the network to do stuff t= hat we haven't thought of yet.

Cheers,
Lorenzo
--001517570906ebfe8904a94dc095-- From fred@cisco.com Sat Jul 30 16:33:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C594F21F85CE for ; Sat, 30 Jul 2011 16:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.017 X-Spam-Level: X-Spam-Status: No, score=-103.017 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhMEfHUIt1Pc for ; Sat, 30 Jul 2011 16:33:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2A91B21F8586 for ; Sat, 30 Jul 2011 16:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=709; q=dns/txt; s=iport; t=1312068812; x=1313278412; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=iaLIhWIYCebudwIDQIoaI81nnor8xw8b3vZYRGbfMlI=; b=UtA0bF1/zq+HL7ddT1EkgyhzdIarz6CunLnfPhTAyiDbkY3Pp3fA9vhn U+NPOxj7QyasH1wLP0fj5Zwi1L7WecFcU0vq/28dgKFIQap0mVAnfd5F2 bi4IB6yZxwLw4/efhAlMPkEqQUfKXUgI3KMajq+tiOEP/30Jp3r0y4C/L M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAM6TNE6rRDoJ/2dsb2JhbABBp2R3gVkBJ4F9NYdOn26BIwGdQYVjXwSHWoshhQeLfQ X-IronPort-AV: E=Sophos;i="4.67,293,1309737600"; d="scan'208";a="8118794" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-9.cisco.com with ESMTP; 30 Jul 2011 23:33:31 +0000 Received: from Freds-Computer.local (sjc-vpn7-760.cisco.com [10.21.146.248]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6UNXSrs009806 for ; Sat, 30 Jul 2011 23:33:31 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sat, 30 Jul 2011 16:33:30 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Sat, 30 Jul 2011 16:33:30 -0700 From: Fred Baker Date: Sat, 30 Jul 2011 14:37:41 -0700 Message-Id: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 23:33:30 -0000 Pursuant to our discussion Tuesday, I'd be interested in working group = comment on http://tools.ietf.org/html/draft-keranen-ipv6day-measurements "Some Measurements on World IPv6 Day from End-User Perspective", Ari Keranen, Jari Arkko, 11-Jul-11 I could imagine not publishing as RFC (it has already served its = purpose), sending to the IESG as an individual submission for = informational status, or adopting as a working group item and eventually = sending as that to the IESG for informational status. Up to you guys... What would you like to do? - do you want to adopt it? - separate question, do you want to publish it? - if you want to publish it, do you have any comments?= From moore@network-heretics.com Sat Jul 30 21:37:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D2B21F85B2 for ; Sat, 30 Jul 2011 21:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ID365g0d3Ieb for ; Sat, 30 Jul 2011 21:37:47 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 209B021F84F1 for ; Sat, 30 Jul 2011 21:37:44 -0700 (PDT) Received: from [65.16.145.177] (helo=host65-16-145-177.birch.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QnNmc-00030I-8e; Sun, 31 Jul 2011 00:37:46 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> Date: Sun, 31 Jul 2011 00:37:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D1D055D-6043-42F8-91F8-84C317267F21@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 867ef52fd101ecb3d6dd28457998182d7e972de0d01da940484aa65030dff4d58f8c9fda62e2e595350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 65.16.145.177 Cc: IPv6 Operations Subject: Re: [v6ops] draft-keranen-ipv6day-measurements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 04:37:47 -0000 My $.02: If these measurements are not being reported elsewhere, = request publication as an individual submission. This doesn't seem = like something that the working group needs to approve. Of course, the = authors might appreciate requests and suggestions for clarification and = other reviewer comments, but those shouldn't need group discussion. Keith On Jul 30, 2011, at 5:37 PM, Fred Baker wrote: > Pursuant to our discussion Tuesday, I'd be interested in working group = comment on > http://tools.ietf.org/html/draft-keranen-ipv6day-measurements > "Some Measurements on World IPv6 Day from End-User Perspective", Ari > Keranen, Jari Arkko, 11-Jul-11 >=20 > I could imagine not publishing as RFC (it has already served its = purpose), sending to the IESG as an individual submission for = informational status, or adopting as a working group item and eventually = sending as that to the IESG for informational status. Up to you guys... >=20 > What would you like to do? > - do you want to adopt it? > - separate question, do you want to publish it? > - if you want to publish it, do you have any comments? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sm@resistor.net Sun Jul 31 00:40:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8A721F885E for ; Sun, 31 Jul 2011 00:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfemwGl2ngHD for ; Sun, 31 Jul 2011 00:40:30 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AF721F87D9 for ; Sun, 31 Jul 2011 00:40:30 -0700 (PDT) Received: from sm-THINK.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p6V7eP1N018525; Sun, 31 Jul 2011 00:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1312098029; bh=L5RywRIShWOJJjUiPCcL8lRCr6lFB4qS+aEQdXO5ZCk=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=xRe9Idl1gnQmHGhzp7wjCM5QxFknWbhF5p5BUeWp5sIr3ZRqGynTfXlqRSRg5+tgu j+7tU06HWRFCRYA5a1v1gofJ5e6VUjg8WrJbtOIWAiNPXQEZPElvh71WA6mV61d4qo bZHeyeROhGik+a9hYN+AOOWWhD3XMenJhCYupizk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1312098029; bh=L5RywRIShWOJJjUiPCcL8lRCr6lFB4qS+aEQdXO5ZCk=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=wVTdV6v+HhU1Q3XrRqLADxxCdjf9D8xvCsMWhWxJki5fK6Uc7G5fD7MfrjrQQe3K2 kyiOAvmztC/TbASpmIAAHORUK4T/k+/W1P3ivHUuM/z9ZbTqiLfwCjRIedhtcBytzG 8Uj1BG4850MRlSyaKaURAqaFfEyiRskUygG1/Aeg= Message-Id: <6.2.5.6.2.20110730220517.078897c0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 31 Jul 2011 00:21:30 -0700 To: Heather Lord , "Michael O'Reirdan" , Jordan Rosenwald From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org Subject: [v6ops] Comments on draft-oreirdan-rosenwald-ipv6mail-transition-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 07:40:35 -0000 Hello, I have a few comments about draft-oreirdan-rosenwald-ipv6mail-transition-00. I am copying this message to the V6OPS mailing list as this draft has been discussed here previously. I don't think that the V6OPS WG is a best fit for this document. Its charter mentions groups or areas who have primary responsibility for specific protocols. You could see whether APPSAWG would take up this draft. The draft attempts to cover several angles. The inbound mail abuse angle (Section 11 and 12) could end up being controversial. I suggest keep it separate from the other angles. In an email context, you can have: Inbound mail (SMTP) Outbound mail (SMTP) Message submission (SUBMIT) Message store access (IMAP, POP3) In Section 1.4, the reference for SMTP should be RFC 5321. Section 1.5 should use "POP3" instead of "POP". The draft does not have any mention of IMAP. It does not make any distinction between SMTP and SUBMIT. draft-ietf-yam-rfc4409bis-02 mentions that message submission has been split from message relay allowing each service to operate according to its own rules. That document designates port 587 for mail submission but also allow sites to use port 25. From Section 12 of draft-oreirdan-rosenwald-ipv6mail-transition-00: "Submitting of unauthenticated port 25 mail to outbound IPv6 email servers MUST be prohibited." I suggest referencing draft-ietf-yam-rfc4409bis-02 or RFC 4409 instead putting in such a prohibition. I am aware of the long and inconclusive discussions about port 25. I'll stay out of that. Given that there are already several inbound mail servers accessible over IPv6, outbound mail can be sent over IPv6. To receive (inbound) mail over IPv6, it is a matter of the SMTP client locating a MX which resolves to a DNS AAAA record. Obviously, the client SMTP and MX will require IPv6 connectivity between them. Sites would have to review their mail infrastructure (e.g. mail filters) and see whether that they can implement existing local policies in an IPv6 environment. Message submission should be fairly straight-forward as MUAs fallback to IPv6 if the submission server is not accessible over IPv6. I'll ignore IPv6 transport issues as it would be better to discuss about that in a separate document. Message store access and message submission would face the legacy issue as MUAs are not updated that often. That is less of a problem for Webmail. BTW, the draft has references to RFC 4472 and RFC 6186. These RFCs discuss about two different ways to locate the MSA and the message store. The text in Section 5 about the phases for the transition uses RFC 2119 key words. I suggest removing the requirement language. Instead of trying to set dates for a transition, you could look at the topic from a different perspective, i.e. an email service provider's plan to support IPv6 and how it expects to tackle the various issues. Regards, -sm From ek@google.com Sun Jul 31 01:39:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FFC21F8802 for ; Sun, 31 Jul 2011 01:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJOuGnaokolC for ; Sun, 31 Jul 2011 01:39:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1D04221F87C3 for ; Sun, 31 Jul 2011 01:39:28 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p6V8dVxK025692 for ; Sun, 31 Jul 2011 01:39:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312101571; bh=8nyzVZF8f4fVpLqWuwqbeM8+ikQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=V2+aeEaOOzWb763sUPDYeOsVDmx1nUHjiDl3qzBso9aytv4cRI2cec+j6MWSzd2Nv 3dmwU1uSSwbf2W69A6Xfw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=uyuP7GWjvfYqSfIReIz+7dSSclrSx/F/AKNjS/ikgyeteUSKPa+HMImvNFUNMTV5o hnkfk3aIeCyfDN9AKFTBQ== Received: from qwh5 (qwh5.prod.google.com [10.241.194.197]) by wpaz24.hot.corp.google.com with ESMTP id p6V8dU8W014436 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 31 Jul 2011 01:39:30 -0700 Received: by qwh5 with SMTP id 5so3326116qwh.34 for ; Sun, 31 Jul 2011 01:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mt1TwgEJE0F01m6PDGNQZ41Jb5uJ6ZiWEkdqwsQ7QF8=; b=jLb+iKJHxZlZnBuMNtIhuoLWKc5Cq62kbMQGL4lLs4R9z2nsmDw86OeDDVLR231NTV 4KQADYhG3AoC+eCnYPXw== Received: by 10.229.214.202 with SMTP id hb10mr2324325qcb.141.1312101570276; Sun, 31 Jul 2011 01:39:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.214.202 with SMTP id hb10mr2324320qcb.141.1312101570160; Sun, 31 Jul 2011 01:39:30 -0700 (PDT) Received: by 10.229.136.66 with HTTP; Sun, 31 Jul 2011 01:39:29 -0700 (PDT) In-Reply-To: References: Date: Sun, 31 Jul 2011 08:39:29 +0000 Message-ID: From: Erik Kline To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 08:39:29 -0000 > Of course, these are just examples of why a protocol that can carry > additional information beyond just "this prefix lives here with this metric" > can be useful: it allows the network to do stuff that we haven't thought of > yet. Like advertise future standardized "this *service* is reachable via this path" sorts of things. The routing protocol could aid in service discovery this way. From satoru.matsushima@gmail.com Sun Jul 31 02:08:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE8521F8841 for ; Sun, 31 Jul 2011 02:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy3t0nxN1RVR for ; Sun, 31 Jul 2011 02:08:29 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8F121F8834 for ; Sun, 31 Jul 2011 02:08:29 -0700 (PDT) Received: by pzk6 with SMTP id 6so8793408pzk.26 for ; Sun, 31 Jul 2011 02:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=LGdt0CPRLjo/chQ9XPCjrY0/QTqfHho1VMlT7O8aR+4=; b=gVrZzcVRW2n4Pyhnu/Ipz3h3yWD45c8YPOSzg28ZjW5NhQCXnYVCV+tEEpsTzeFlh5 o+qthg1S+TZRnlq2JmadqdeD1VAYlXrhzVUQYVzxy4hyqRQd3OalE1fqR/uE1AKNu1Jx TPFWh2ZlYsedMWd4xgT7AXfPvL/89QhZqaMZs= Received: by 10.68.10.69 with SMTP id g5mr5875758pbb.444.1312103311039; Sun, 31 Jul 2011 02:08:31 -0700 (PDT) Received: from [192.168.10.60] (softbank221038132005.bbtec.net [221.38.132.5]) by mx.google.com with ESMTPS id d1sm4185415pbj.8.2011.07.31.02.08.28 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 31 Jul 2011 02:08:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Sun, 31 Jul 2011 18:08:26 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <76D3E260-5F2E-4E1D-8F33-8B24F9E27EB7@gmail.com> References: To: v6ops@ietf.org X-Mailer: Apple Mail (2.1244.3) Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 09:08:31 -0000 On 2011/07/31, at 17:39, Erik Kline wrote: >> Of course, these are just examples of why a protocol that can carry >> additional information beyond just "this prefix lives here with this = metric" >> can be useful: it allows the network to do stuff that we haven't = thought of >> yet. >=20 > Like advertise future standardized "this *service* is reachable via > this path" sorts of things. The routing protocol could aid in service > discovery this way. I think it would be a good point. A crazy idea come up me like opaque-lsa for advertise beyond advertising = just prefix, and a flavor of bgp community to import/export to manage = connectivity among routing instances. cheers, --satoru From ek@google.com Sun Jul 31 03:10:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DAA21F87F9 for ; Sun, 31 Jul 2011 03:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxQJ7NOTqOV5 for ; Sun, 31 Jul 2011 03:10:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 59CE421F85B2 for ; Sun, 31 Jul 2011 03:10:23 -0700 (PDT) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p6VAAPGr032282 for ; Sun, 31 Jul 2011 03:10:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312107026; bh=xaXtm0+PCzwUo2nLNN/t6HP51eY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=apbSRbRiKPcwIx2hfHcMqgTaN3dhBB27EZzJspmJmQ+TigSxucZVqIyiVSTZCI0ZL 7H4srXnIC8FJy+/Q0+j5Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=uWiOiM8gmjS64UsDo95GIEtDbJHna/3nwvnrFz81PW3EDJq/l86LipgIimjtGQAMv loRUHTTy8wiKTEnCWPzcg== Received: from qyk4 (qyk4.prod.google.com [10.241.83.132]) by kpbe11.cbf.corp.google.com with ESMTP id p6VAAO6I022215 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 31 Jul 2011 03:10:24 -0700 Received: by qyk4 with SMTP id 4so3008915qyk.7 for ; Sun, 31 Jul 2011 03:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gzmUdEDVilHh7+67rub/QSqgfLWQfGr8c8TauFvfjZI=; b=mRnTl7b/DNuCpTF7QHF3gIpkiQZ9UTJWtLlxH+ZRscicHIWmPHyNet4A3TjA7bqM50 kUBhLwltBZppGDgIdo2g== Received: by 10.229.227.76 with SMTP id iz12mr29125qcb.255.1312107024360; Sun, 31 Jul 2011 03:10:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.227.76 with SMTP id iz12mr29122qcb.255.1312107024224; Sun, 31 Jul 2011 03:10:24 -0700 (PDT) Received: by 10.229.136.66 with HTTP; Sun, 31 Jul 2011 03:10:24 -0700 (PDT) In-Reply-To: <76D3E260-5F2E-4E1D-8F33-8B24F9E27EB7@gmail.com> References: <76D3E260-5F2E-4E1D-8F33-8B24F9E27EB7@gmail.com> Date: Sun, 31 Jul 2011 10:10:24 +0000 Message-ID: From: Erik Kline To: Satoru Matsushima Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: v6ops@ietf.org Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 10:10:24 -0000 On 31 July 2011 09:08, Satoru Matsushima wrot= e: > On 2011/07/31, at 17:39, Erik Kline wrote: > >>> Of course, these are just examples of why a protocol that can carry >>> additional information beyond just "this prefix lives here with this me= tric" >>> can be useful: it allows the network to do stuff that we haven't though= t of >>> yet. >> >> Like advertise future standardized "this *service* is reachable via >> this path" sorts of things. =C2=A0The routing protocol could aid in serv= ice >> discovery this way. > > I think it would be a good point. > A crazy idea come up me like opaque-lsa for advertise beyond advertising = just prefix, and a flavor of bgp community to import/export to manage conne= ctivity among routing instances. Hehe. On the plane ride back I was thinking of something like ES-IS advertising service things to IS-IS routers, which could choose to propagate them. Of course, I also though to redo IS-IS without OSI numbering and just use link-local addresses...somehow. =3D) From john_brzozowski@cable.comcast.com Sun Jul 31 07:38:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511E221F8745 for ; Sun, 31 Jul 2011 07:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.196 X-Spam-Level: X-Spam-Status: No, score=-102.196 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p561F2B5aDBZ for ; Sun, 31 Jul 2011 07:38:07 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id BE52821F86DE for ; Sun, 31 Jul 2011 07:38:07 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46880146; Sun, 31 Jul 2011 08:43:00 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Sun, 31 Jul 2011 10:38:05 -0400 From: "Brzozowski, John" To: Ole Troan Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMTTmsYQ4f7+JsMUusl+Ald1vnPZUCgEUAgAGPloCAAQL+gIABcZuA Date: Sun, 31 Jul 2011 14:38:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 14:38:08 -0000 On 7/30/11 8:35 AM, "Ole Troan" wrote: >John, > >> [jjmb] agreed. It seems to me that specifying the use of an IGP like >>OSPF >> or ISIS is overkill for a home scenario. For a business or SOHO perhaps >> this would be ok, not to reiterate what others have said about resource >> constraints and complexity of setup for some types of users. > >two ideas in prefix assignment space: > - use zOSPF (border routers advertise a site prefix in a new LSA, >internal routers randomly pick a subnet id and does > collision detection for each of their links) [jjmb] advertisement to the ISP? Subnet-id selection is for IPv4 and IPv6? For IPv6 DHCPv6 could be used which would allow for collision avoidance, this is in part similar to the below (I think). > - use a DHCP "God server" with SPF topology. each internal router >requests a /64 for its downstream links, as the DHCP server is > part of the topology, it can make sure that each link only >gets a single prefix even if multiple routers are connected to > it. [jjmb] this is something I have been thinking about as a viable option. The outer most router supports DHCPv6 PD (LAN side). It would have to be seeded with adequate address space to serve up IA_PD (and possibly IA_NA) for downstream routers. Based on conversations to date I assume there would be interest in downstream routers also support and being able to delegate prefixes? > >both ideas require something different than RIP. [jjmb] perhaps...=10I have to ponder this some more. I believe one of our goals (regardless of the WG venue) should be to simply how such deployments work. >let's give homenet a little time to figure out what they like to do >before making a decision. [jjmb] I would rather help HOMENET by participating/driving some of these discussions. > >cheers, >Ole From john_brzozowski@cable.comcast.com Sun Jul 31 07:45:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D827C21F8753 for ; Sun, 31 Jul 2011 07:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.524 X-Spam-Level: X-Spam-Status: No, score=-105.524 tagged_above=-999 required=5 tests=[AWL=2.939, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZOPkCRmZTCi for ; Sun, 31 Jul 2011 07:45:35 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id C81E921F8749 for ; Sun, 31 Jul 2011 07:45:34 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.135717624; Sun, 31 Jul 2011 10:45:30 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Sun, 31 Jul 2011 10:45:31 -0400 From: "Brzozowski, John" To: Lorenzo Colitti Thread-Topic: [v6ops] default LAN routing protocol for IPv6 CE router Thread-Index: AQHMTTmsYQ4f7+JsMUusl+Ald1vnPZUCgEUAgAGPloCAAWlkgIABDUcA Date: Sun, 31 Jul 2011 14:45:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <534FB0372C80E247835D12736406487D@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] default LAN routing protocol for IPv6 CE router X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 14:45:36 -0000 On 7/30/11 2:41 PM, "Lorenzo Colitti" wrote: >On Sat, Jul 30, 2011 at 00:34, Brzozowski, John > wrote: > >>* can distribute information beyond IP reachability; for example, "this >>prefix belongs to a guest network" or "this is a prefix that I have >>tentatively assigned to my interface, not a prefix that is already in >>use". This would be useful for autoconfiguration. > >[jjmb] as I emailed before why would this be required of the LAN side >network is part of an already delegated prefix? Am I missing something? > > > >In a routed home network, you want guest networks and non-guest networks >to be routed, but not talk to each other. Carrying in the IGP the >information about whether each /64 assigned to an interface is for a >guest network or a non-guest network allows the routers to apply the >appropriate firewalls between the guest network and the non-guest >network, while still routing both guest and non-guest prefixes. It's a >bit like having two VRFs or an MPLS VPN. [jjmb] an IGP is not required to prevent two LANs from interacting with one another. The vision I have for at least one scenario is a delegated prefix of something shorter than 64 with /64 allocations to separate LANs, some of which may communicate with others while others do not. Requiring advertising or requesting separate prefixes is not necessarily useful or beneficial. > >As regards the "tentative" tag, that might be useful when doing >autoconfiguration. As Ole says, a CE could pick one random /64 out of the >aggregate for each of its interfaces and do collision detection to see if >it's unique. If the IGP carries a flag saying "this prefix is tentative" >that might make it easier. [jjmb] Ok, we should vet this out some more. The notion of "tentative" could be useful for collision detection/avoidance. > >Of course, these are just examples of why a protocol that can carry >additional information beyond just "this prefix lives here with this >metric" can be useful: it allows the network to do stuff that we haven't >thought of yet. [jjmb] while I do not disagree regarding future needs we need to make sure folks who have yet to deploy IPv6 at all can do so starting with the basic models allowing for evolution over time. > >Cheers, >Lorenzo > From randy@psg.com Sun Jul 31 10:10:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E322021F87F9 for ; Sun, 31 Jul 2011 10:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOOFmt0+GC9P for ; Sun, 31 Jul 2011 10:10:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5864B21F87E2 for ; Sun, 31 Jul 2011 10:10:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QnZWH-000Pya-6E; Sun, 31 Jul 2011 17:09:41 +0000 Date: Mon, 01 Aug 2011 02:09:40 +0900 Message-ID: From: Randy Bush To: "George, Wesley" In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0BDC33FF@PRVPEXVS04.corp.twcable.com> References: <987EEA6D-59F9-4D6F-9FFE-6DD2DE3C71D1@cisco.com> <34E4F50CAFA10349A41E0756550084FB0BDC33FF@PRVPEXVS04.corp.twcable.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] A question: Interim meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 17:10:10 -0000 > [WEG] a week is not long enough in advance virtual, a month maybe real, much longer randy From ggm+ietf@apnic.net Sun Jul 31 18:20:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2FD21F85F7 for ; Sun, 31 Jul 2011 18:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.423 X-Spam-Level: X-Spam-Status: No, score=-101.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bg5t7qbKm38o for ; Sun, 31 Jul 2011 18:20:03 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 8958F21F85F6 for ; Sun, 31 Jul 2011 18:20:03 -0700 (PDT) Received: from [192.168.1.2] (ppp118-208-71-71.lns20.bne4.internode.on.net [118.208.71.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 341BEB67ED for ; Mon, 1 Aug 2011 11:20:07 +1000 (EST) From: George Michaelson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Aug 2011 11:20:02 +1000 Message-Id: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 01:20:04 -0000 I had a moment in time to test a Snow Leopard, and Lion OSX setup @home, = before completing my upgrade to Lion on all boxes. I tested http://www.apnic.net/ http://ipv6actnow.org/ and = http://www.ripe.net/ All three connect on IPv6 for Snow Leopard. All three connect on IPv4 for Lion. The ping6/ping delay differences: IPv6 IPV4 www.apnic.net: 29.668/ 30.224/ 30.511/ 0.305 ms 27.484/ 33.900/ = 55.400/ 9.697 ms=20 www.ripe.net: 384.082/427.672/474.278/32.085 ms = 345.837/379.814/450.711/37.940 ms ipv6actnow.org: 371.395/409.083/457.154/29.726 ms = 346.257/384.443/434.757/30.477 ms I think that from a difference/variance point of view, all three sites = were rationally 'better' on IPv4 So, in that sense "it worked". -The selection alg as encoded in Lion, is = doing a reasonable job. -George= From dr@cluenet.de Sun Jul 31 22:37:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F05221F85A1 for ; Sun, 31 Jul 2011 22:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acAPDBNQPqXZ for ; Sun, 31 Jul 2011 22:37:19 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id C90A721F8588 for ; Sun, 31 Jul 2011 22:37:18 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id B4FFD10809D; Mon, 1 Aug 2011 07:37:19 +0200 (CEST) Date: Mon, 1 Aug 2011 07:37:19 +0200 From: Daniel Roesen To: IPv6 Operations Message-ID: <20110801053719.GA10524@srv03.cluenet.de> Mail-Followup-To: IPv6 Operations References: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0D324E27-DB0C-4496-9E3D-EF01CEC2778E@apnic.net> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] Lion/Snow Leaopard side-by-side on an IPv6 enabled ADSL2+ home line.. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 05:37:19 -0000 On Mon, Aug 01, 2011 at 11:20:02AM +1000, George Michaelson wrote: > All three connect on IPv6 for Snow Leopard. > All three connect on IPv4 for Lion. Excellent, so operators have to make sure that their LSN setups will artificially introduce some delay to bias clients to use IPv6 to offload the expensive NATs. We shall raise feature requests with the vendors. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0