From pch-b6B5344D9@u-1.phicoh.com Sun May 1 01:18: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 AB579E0655 for ; Sun, 1 May 2011 01:18:56 -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=[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 Gj-q-U+xTg1E for ; Sun, 1 May 2011 01:18:55 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 13CCDE0651 for ; Sun, 1 May 2011 01:18:54 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #39) id m1QGRrg-0001MXC; Sun, 1 May 2011 10:18 +0200 Message-Id: To: Dmitry Anipko From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> , , <1304195712.19431.107.camel@shakira.millnert.se> In-reply-to: Your message of "Sat, 30 Apr 2011 16:36:42 -0700 ." Date: Sun, 01 May 2011 10:18:41 +0200 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 08:18:56 -0000 In your letter dated Sat, 30 Apr 2011 16:36:42 -0700 you wrote: >So, the point 9 is about affect on IPv6 roll out, and not about how 6to4 is no >t great. Do you agree with definition of point 9? If you do, then on point 9, >let me quote the data sources you pointed to. Dmitry, May I ask you what you are trying to achieve here? Not specificly with point 9 but with 6to4 in general? After all your messages I sort of lost track of that. My personal opinion is that I like the simplicity of 6to4 very much. As well as how it allows users to enable 6to4 independent of their ISPs. But numerous studies have shown that it simply doesn't work in practice. And more NAT is simply going to make it worse. So, I would say that if you have a protocol targeted at end-users and it is very hard for them to get it to work, then we (as IETF) have to get rid of it. And make a clear statement that unfortunately the protocol doesn't work. Whether that is really described accurately to the last detail in an RFC I don't really care. As long as the message is clear: don't do it. Now you seem to argue against declaring 6to4 as historic even though you also seem to admit that it is broken. So I'm wondering what you really want. From ichiroumakino@gmail.com Sun May 1 02: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 AAE88E06A4 for ; Sun, 1 May 2011 02:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[AWL=-0.247, 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 fkfQqn6HD7cA for ; Sun, 1 May 2011 02:35:33 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E733E0682 for ; Sun, 1 May 2011 02:35:32 -0700 (PDT) Received: by eye13 with SMTP id 13so1840481eye.31 for ; Sun, 01 May 2011 02:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=tPrXRhzr/Rkx4O+U42DfZ5OYmE4eD2ZdgF3GSEWGwbc=; b=GmBTpuxSeibdH8bs6aOQHYKgdQ3/prLobYVv5LG4Bu3BeV5NTZTy336O+3AXqYZh8y KInqq3RqN1kpN4bKenYKe7JV4kP4A2thRuD3W9fj/6Z5zstrkpzV01nQx2nhNT3CDNRY psgnBeXJzEv02ASuNvFI4OgVWpkueZBygD5LM= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=AqdNSi1Dv1dlHdRdFb4XBCP9TCiFnQ/o9/h7XAWImk//C0y6zmIxo/70E5eY+iD97l 8iNI8RqU1qfhVTJ1lSCIHkhXQu3ddSvFtzzNu4eb0/CYCZOta34ZcHPEXXDcXRLeeYoe dW7qC1XvCiu6NKpl36daJGOpzHw0iltgjJYSs= Received: by 10.213.112.134 with SMTP id w6mr492899ebp.12.1304242530795; Sun, 01 May 2011 02:35:30 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id c14sm1992035eeb.25.2011.05.01.02.35.29 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2011 02:35:29 -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: Sun, 1 May 2011 11:35:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dmitry Anipko X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 09:35:33 -0000 Dmitry, >>> Does the working group agree with the summarization of the concern?=20= >=20 > I agree with the summarization of the concern. >=20 >>> Do we agree with the proposed (in)action? >=20 > I disagree with the proposed action. I suggest to either remove the = problem from the list of 6to4 problems, since as currently worded this = is not a 6to4 problem, but protocol 41 problem, and this draft, in its = current form, doesn't seem to have any intentions to deal with general = protocol 41, or to add text illustrating why this problem is 6to4 = specific and other uses of protocol 41 on the Internet do not have this = problem or how that problem is/can be mitigated for them. there are aspects of this that are unique to 6to4 (as an unmanaged = tunnel mechanisms). e.g. a bi-directional configured tunnel between two = nodes within a single network is quite different from a unmanaged tunnel = spanning the Internet. other uses of protocol 41 (including the managed one in 3056) does have = mechanisms to detect black holes (routing protocol running on top of the = tunnel). > Also, if it is shown how this problem is 6to4 specific, RFC 3484bis = recommendation would mitigate the problem and hence, in my opinion, this = problem cannot be used as a justification for declaring RFC 3056 = historic - in that case I suggest to remove the "historic" = recommendation and instead add a reference to RFC 3484bis. while rfc3484bis may mitigate the problem, it only does so by making = sure 6to4 isn't used. we have empirical evidence that 6to4 has problems with = filters/firewalls. I haven't seen similar evidence for other mechanisms = using protocol 41. doesn't mean they don't have the same issue = obviously, but I don't think that's a good argument for not including = this text about 6to4. o 6to4 has no specified mechanism to handle the case where the protocol (41) is blocked in intermediate firewalls. It can not be expected that path MTU discovery across the Internet works reliably; ICMP messages may be blocked and in any case an IPv4 ICMP message rarely has enough of the original packet in it to be useful to proxy back to the IPv6 sender. on reflection I do agree with part of the objection. the current text = implies that any overlay protocol should be able to bypass firewalls. = what about something like: o 6to4 may black hole traffic in the case where protocol (41) is blocked in intermediate firewalls. Even if the = firewall sent an ICMP message unreachable back, an IPv4 ICMP message rarely contains enough of the original = IPv6 packet so that it can be relayed back to the IPv6 sender. That makes this problem hard to detect = and react upon by the sender of the packet. o It can not be expected that path MTU discovery across the Internet = works reliably; ICMP messages may be blocked and in any case an IPv4 ICMP message rarely has enough of the original packet in it to be useful to proxy back to the IPv6 sender. cheers, Ole >=20 >=20 > ________________________________________ > From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of = Fred Baker [fred@cisco.com] > Sent: Wednesday, April 27, 2011 1:17 PM > To: v6ops@ietf.org WG > Subject: [v6ops] 6to4-historic summary point: 2. "protocol 41" >=20 >> 2. "protocol 41" >> ---------------- >> - Specifically, the issue (A) states that "6to4 has no specified = mechanism to handle the case where >> protocol 41 is blocked...". Do other tunneling mechanisms using = protocol 41 have such mechanism? >> If they don't, then should usage of protocol 41 be moved to = historic, because the stated filtering/PMTUD >> problems are then not specific to RFC 3056? If they do, then = having a brief overview of those and how/why >> they don't apply to 6to4 would help to strengthen the statement. >>=20 >> Action: None >=20 > Does the working group agree with the summarization of the concern? Do = we agree with the proposed (in)action? >=20 > Reply if the answer is "no", and give a better suggestion. > _______________________________________________ > 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 ichiroumakino@gmail.com Sun May 1 02:45: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 54B0EE06B0 for ; Sun, 1 May 2011 02:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[AWL=-0.186, 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 5z3naKd9uf8B for ; Sun, 1 May 2011 02:45:53 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66E50E0682 for ; Sun, 1 May 2011 02:45:53 -0700 (PDT) Received: by eye13 with SMTP id 13so1841829eye.31 for ; Sun, 01 May 2011 02:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=0OcHZyhffui0oaO3WWjTLUkDTxu0jFOQ0SL7jg3TWyE=; b=vmtyj9aR2/QPzGhyXYbJXsBxLFcV4C03Np0hRaTvILodmPRzY2JH8wfB9jSpgn1j7D wjCdQRNmZeaicvgN1lfrl5+VRU/lbs+4zKaeqYCbqPNk6ZaqfGpTSyIs+gDo8CAeyif4 VhMbYDcWRieXYsF5MGIxlXq5nx+HvlcnxGm30= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=IFoUUyi8sMXvUaqc7lkfNG6o3JADNaITFaQ0VhyNz33EXhJHFQdlWtwPeYtAGjG5W7 nGBEPdn31yj/8R2qTF2yfV1sC74g2XKAbxLm2d65pMHmJHBgq4HqWl/7Rse/LZK+GNwx sMpTv/UjUbVHYsXPzRIdO2hIwqNRvhU1rJQD4= Received: by 10.14.10.137 with SMTP id 9mr2827765eev.244.1304243151302; Sun, 01 May 2011 02:45:51 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id s50sm3308702eeh.15.2011.05.01.02.45.49 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2011 02:45:50 -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: Sun, 1 May 2011 11:45:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6464744E-8507-497A-8AF5-693C74BB6795@cisco.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 5. "Clarifications" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 09:45:54 -0000 Dmitry, > I agree with the recommendations 1-2-3 in the section 4 in the draft = version dated April 27 and I think those are sufficient, hence I suggest = to remove wording regarding deprecation of RFC 3056 and prefix = 2002::/16. the deployed part of rfc3056 have the same problem that rfc3068. i.e. = the return relay, filtering and so on. you have argued that 6to4 provide some benefits in that it allows for = "globally scoped" IPv6 address assignment independently of an ISP and = that it can be used for tunneling in "private" networks, e.g. on top of = other tunnels like DirectAccess. I don't think it is feasible to deprecate section x,y,z of 3056 and not = section n,m and o. I would suggest you wrote a new draft of a peer to peer only 6to4 = version. cheers, Ole > ________________________________________ > From: Fred Baker [fred@cisco.com] > Sent: Wednesday, April 27, 2011 1:17 PM > To: Tore Anderson; Dmitry Anipko > Cc: v6ops@ietf.org WG > Subject: 6to4-historic summary point: 5. "Clarifications" >=20 >> 5. "Clarifications" >> ------------------- >>=20 >>> The approach that's most likely to get widespread support is: >>>=20 >>> 1. make it not be on by default >>> 2. make noise about it being A Bad Thing >>> 3. deprioritise 2002::/16 addresses in resolver libs >>> 4. then make the option hard to find on operating systems / CPEs >>> 5. then remove the option on operating systems >>> 6. then slowly decommission 6to4 relays over many years >>>=20 >>> draft-ietf-v6ops-6to4-to-historic deals with steps 1-3. >>=20 >> I do think it would be useful to elaborate on the arguments Tore = just >> provided to Dmitry for deprecation of 3056 in the draft, as a form = of >> history writing for the archives. >>=20 >> Actions: Proposed text? >=20 > Tore and Dmitry, this appears to be directed to you. Could you please = work with Ole on proposed text? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ichiroumakino@gmail.com Sun May 1 02:49: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 649CBE069E for ; Sun, 1 May 2011 02:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 He3BAaxRmqYI for ; Sun, 1 May 2011 02:49:49 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4496E0682 for ; Sun, 1 May 2011 02:49:49 -0700 (PDT) Received: by ewy19 with SMTP id 19so1838099ewy.31 for ; Sun, 01 May 2011 02:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=rtw7Eubdi1VTI1sZmbyzlX6vbipSoYa5g0pDTJzs1/o=; b=k1FHKi/oPxiVLZ/hXqexrt4M2zsLHL7fjL+4xoU15HG3ofmUXxo0UGuJFOdG/zYE2y TLvzxzWYI+8JVxh6l0OZbb48VSB4fMj59L9zzK1OR5qZFFN8cMa+5BMuqs78AolAVXW0 kvq5Te7e9Sbi34JqdIhme3T+pHNDq1goq+K+4= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=VqTLM+bDnf8LmAsGX2s2Sxh76Wg4da0EScV9mYjl+t3YnCbVntwhUKKJtS/lOg4gAd lI4z+zdPtblMwEb2QMC0A6NRRzR0IpcrnBkB25tS650CJNzlJh08sEFlY7ryPLmcMhuK BfdGlnEyvBa+cyLXoVrjMEtFcKcpI/TDKDxi0= Received: by 10.213.34.12 with SMTP id j12mr1148151ebd.80.1304243388576; Sun, 01 May 2011 02:49:48 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id g1sm1717404een.3.2011.05.01.02.49.47 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2011 02:49:47 -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: Sun, 1 May 2011 11:49:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <011CD3B0-3F46-4CA5-959B-E400EA13E0EE@cisco.com> To: Dmitry Anipko X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 3. "non-RFC1918 addresses" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 09:49:50 -0000 Dmitry, >>> Does the working group agree with the summarization of the concern?=20= >=20 > I agree the concern was summarized correctly. >=20 >>> Do we agree with the proposed action? >=20 > As I said in the quoted feedback, I don't think the action draft = proposes is necessary to address the problem quoted, for the reasons = listed below in the feedback summary. So I agree with the proposed = action to change the text and I propose: to remove all the references = about moving RFC 3056 to historic status from the draft, since in my = opinion the draft doesn't state sufficient reasons for moving RFC 3056 = to historic. Those of the listed problems, which are specific to 6to4, = are addressed by the companion advisory and RFC 3484bis. Those which are = not specific to 6to4, in my opinion, shall not be in the draft. how does the advisory or rfc3484 address these problems: >> Reply: Current text states: >> - Not deployed >> - Same problems as 3068 for the reverse path >> - Same problem with filtering >> - Not working with non-1918 addresses with topologically = limited span cheers, Ole= From pch-b6B5344D9@u-1.phicoh.com Sun May 1 02:57: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 A7F4BE06D8 for ; Sun, 1 May 2011 02:57:10 -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=[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 3X4l7YY5gKSJ for ; Sun, 1 May 2011 02:57:05 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id CE0DEE0682 for ; Sun, 1 May 2011 02:57:03 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #39) id m1QGTOd-0001k0C; Sun, 1 May 2011 11:56 +0200 Message-Id: To: Ole Troan From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <6464744E-8507-497A-8AF5-693C74BB6795@cisco.com> In-reply-to: Your message of "Sun, 1 May 2011 11:45:48 +0200 ." Date: Sun, 01 May 2011 11:56:47 +0200 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 5. "Clarifications" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 09:57:10 -0000 In your letter dated Sun, 1 May 2011 11:45:48 +0200 you wrote: >I would suggest you wrote a new draft of a peer to peer only 6to4 version. Is that realistic? (anyone can author an informational RFC, so not that part). 6to4 has a lot of problems with NAT. And the place where peer-to-peer has most problems is in systems with lots of NAT, in particular carrier-grade NAT. So presenting a protocol that has lots of problems with carrier-grade NAT as a solution to a problem mostly caused by carrier-grade NAT strikes me as a bad idea. From ichiroumakino@gmail.com Sun May 1 03:03: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 40A7CE06C9 for ; Sun, 1 May 2011 03:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[AWL=1.126, 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 P3zwSE-EYmr6 for ; Sun, 1 May 2011 03:03:27 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB47E0682 for ; Sun, 1 May 2011 03:03:27 -0700 (PDT) Received: by eye13 with SMTP id 13so1844241eye.31 for ; Sun, 01 May 2011 03:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=NKazJbm/ehKDmhjT+7tU/JsVFyqjNf0xr+41QmLO5Vo=; b=o9fxeHbT0bMqxto7yBt27K70dR7kzY9UoCaHtG9Mz4DOBEGmmM3GIqV6T1aOpsv/m9 STTAFy65WSrbdATaNWJ3DNP6qitx8V8SfGdRjo1p5YIodTdYs2L9Ynru76+08oUzqNjM fbIvdvoNpwzMm9PcNIu/yDHJxaZoJhyOHxRrg= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Vq+bfGd90lqkpLEtVxyVRfm4bIdoHQIOoKXYvaS2LDGqBSRckn25ejKhTtupWxRco6 doZlpNKeR3kQH7/4l6NCqm5Kp+X5pcoxmF4+7YP5TzXy3GgKhZCEFD5pNYisCI4Rt8+o z4GfYOxpRHx1mYIzV032JLXL9QSHcBrKMlMd4= Received: by 10.213.16.140 with SMTP id o12mr2761827eba.27.1304244206630; Sun, 01 May 2011 03:03:26 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id u16sm3318396eei.9.2011.05.01.03.03.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2011 03:03:26 -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: Sun, 1 May 2011 12:03:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <93AC18CB-D38E-40BF-9472-4A7BEC859199@employees.org> References: <6464744E-8507-497A-8AF5-693C74BB6795@cisco.com> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 5. "Clarifications" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 10:03:28 -0000 Ole, > In your letter dated Sun, 1 May 2011 11:45:48 +0200 you wrote: >> I would suggest you wrote a new draft of a peer to peer only 6to4 = version. >=20 > Is that realistic? (anyone can author an informational RFC, so not = that part). probably not ;-) > 6to4 has a lot of problems with NAT. And the place where peer-to-peer = has > most problems is in systems with lots of NAT, in particular = carrier-grade NAT. >=20 > So presenting a protocol that has lots of problems with carrier-grade = NAT > as a solution to a problem mostly caused by carrier-grade NAT strikes = me > as a bad idea. iff the argument was to keep some aspects of 6to4 to use it in a private = network context, then I think a new draft would be better, than to try to deprecate only half of 3056. only retaining the 'managed' = part of 3056. I'm suggesting that as a way out to avoid this discussion on private use = 6to4, derailing the effort to fix the mistakes with did with 6to4 in the = Internet. cheers, Ole= From tore.anderson@redpill-linpro.com Sun May 1 08: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 1A2EDE0738 for ; Sun, 1 May 2011 08:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, 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 tIo2Sa8Bf5sP for ; Sun, 1 May 2011 08:08:56 -0700 (PDT) Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD74E0733 for ; Sun, 1 May 2011 08:08:55 -0700 (PDT) Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 0478ACC60C; Sun, 1 May 2011 17:08:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at linpro.no Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id DadKV1fqwVxa; Sun, 1 May 2011 17:08:52 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Sun, 1 May 2011 17:08:52 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 79BB5170C00B; Sun, 1 May 2011 17:08:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WltF4yD9umpj; Sun, 1 May 2011 17:08:48 +0200 (CEST) Received: from envy.fud.no (unknown [77.40.198.54]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id C5B3A170C00A; Sun, 1 May 2011 17:08:44 +0200 (CEST) Message-ID: <4DBD777A.20109@redpill-linpro.com> Date: Sun, 01 May 2011 17:08:42 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Dmitry Anipko References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> , , <1304195712.19431.107.camel@shakira.millnert.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 15:08:57 -0000 Dmitry, > Tore: [quote] >>> Any remaining problems is really hard to distinguish from >>> statistical noise at this point. [/quote] I was unable to spot anything in the aggregate data, no. 6to4 was the big one. However after we deployed, I got in touch with several «broken» end users and when helping them solve their problem I discovered some other problems. I've documented them all here: http://getipv6.info/index.php/Customer_problems_that_could_occur (This is not relevant to the 6to4-to-historic discussion, but I thought you might find it interesting anyway.) > However it is unclear to me why proponents of the "historic" draft > think that declaring "historic" status would actually help to solve > the point 9 problem impacting some versions of that particular OS in > any short timeframe: I think consumers are quite unlikely to go and > buy new IGDs over night, or upgrade software on the IGDs, nor > typically IGDs can upgrade themselves. There's two things we can do to solve the point 9 problem: 1) Make 6to4 not be used at all. See: RFC 3484, I-D.ietf-6man-rfc3484-revise (section 2.4), and I-D.ietf-v6ops-6to4-to-historic (section 4). However, let's be realistic here: There's currently no patch for Mac OS X Tiger and Leopard, nor for Windows ICS. That's certainly tens of millions of affected end users. Even if those patches were to materialise tomorrow, how long before every end user have upgraded? Years, surely. And how many applications and devices are out there that do not do resolving in a RFC3484-compliant manner? Nobody knows... 2) Make 6to4 work as reliably as native (IPv4/IPv6) connectivity. See: I-D.ietf-v6ops-6to4-advisory. Let's be realistic here too: There's tens of millions of users using bogon/unrouted public address space behind CGNAT systems, and these are likely to increase in number now that IPv4 is depleted. There must be thousands of enterprises and similar that filter away all protocol 41. How are we going to reach out to them all and convince them to change their configs? How many firewall products must be updated to allow protocol 41 by default? How many poorly maintained anycast relays must be fixed or withdrawn from the DFZ, how are we going to identify them? How many new relays must be deployed in how many locations in order to prevent 6to4 users world-wide from experiencing routing trampolines? I am not saying that both of the approaches above aren't worth while pursuing. Quite the contrary: They will certainly provide some pain relief, and that's a good thing for everyone involved. However, don't let us fool ourselves: Pain relief is not a cure! There is simply *no cure* for 6to4's operational problems that can be universally deployed across the entire internet in a reasonably short time frame; 6to4 is broken beyond repair. Moving it to «Historic» is simply an admission of that fact, as well as sending a clear message to everyone that the protocol has no future and that it is time to move on. Hopefully, that message will also help persuading vendors to implement pain relief approach #1. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From lorenzo@google.com Sun May 1 09:43: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 246D3E074B for ; Sun, 1 May 2011 09:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.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, 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 cADtEKBKWXWi for ; Sun, 1 May 2011 09:43:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 53358E0746 for ; Sun, 1 May 2011 09:43:41 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p41GhdQF013361 for ; Sun, 1 May 2011 09:43:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304268220; bh=JLE05WUxzgeY/eHySiPRbKwgPP4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=SxnDBLFkkf7EiHOLgn5zfvjugNYi6qmrSZLAU9FYVZ4GFkrxr1IrcKuM9rsTqyNTY ltuk2P5FR6BD1pI9z9P0g== Received: from yxd5 (yxd5.prod.google.com [10.190.1.197]) by wpaz13.hot.corp.google.com with ESMTP id p41Ghcu0008709 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 1 May 2011 09:43:38 -0700 Received: by yxd5 with SMTP id 5so2316771yxd.7 for ; Sun, 01 May 2011 09:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wWdUCX3wpWBf0QZNx4zMUgsbsh3zi66Hqig/oAvY3Ps=; b=sVaa0VA+UE0PpF+WLV7p1V4LVJH5JJTnBCHtjLffKrhPmBp9/MQsupYV2e9tbyUy6v unCpTeuixqDHzWGx2A4A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Xg3Y64NfCCPkB3GipdImf0QmhB+9ck75xheN8i9IarvC9cbf33dCgHOOT/BvAOLG85 nNsfkjgyJXK/qT4D6uEQ== Received: by 10.150.91.10 with SMTP id o10mr5880086ybb.264.1304268218204; Sun, 01 May 2011 09:43:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Sun, 1 May 2011 09:43:18 -0700 (PDT) In-Reply-To: <4DBD777A.20109@redpill-linpro.com> References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> <1304195712.19431.107.camel@shakira.millnert.se> <4DBD777A.20109@redpill-linpro.com> From: Lorenzo Colitti Date: Sun, 1 May 2011 09:43:18 -0700 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=000e0cd47d06d6841804a2399b4c X-System-Of-Record: true Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 16:43:42 -0000 --000e0cd47d06d6841804a2399b4c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, May 1, 2011 at 8:08 AM, Tore Anderson < tore.anderson@redpill-linpro.com> wrote: > 6to4 is broken beyond repair. Moving it to =ABHistoric=BB is > simply an admission of that fact, as well as sending a clear message to > everyone that the protocol has no future and that it is time to move on. > You hit the nail on the head. 6to4 can't be fixed, and it will only get worse over time as CGN is deployed (ISPs assigning bogon addresses; broken home gateways that turn on 6to4 even with private addresses). We need to acknowledge that fact, and send a clear message to the industry that 6to4 i= s not worth pursuing. --000e0cd47d06d6841804a2399b4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, May 1, 2011 at 8:08 AM, Tore Anderson <tor= e.anderson@redpill-linpro.com> wrote:
6to4 is broken beyond repair. Moving it to =ABHistoric=BB is
simply an admission of that fact, as well as sending a clear message to
everyone that the protocol has no future and that it is time to move on.

You hit the nail on the head.=A06to4 can&= #39;t be fixed, and it will only get worse over time as CGN is deployed (IS= Ps assigning bogon addresses; broken home gateways that turn on 6to4 even w= ith private addresses).=A0We need to acknowledge that fact, and send a clea= r message to the industry that 6to4 is not worth pursuing.
--000e0cd47d06d6841804a2399b4c-- From fred@cisco.com Sun May 1 11:00: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 43E51E0693 for ; Sun, 1 May 2011 11:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.581 X-Spam-Level: X-Spam-Status: No, score=-110.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XGCWlWVeHQRG for ; Sun, 1 May 2011 11:00:30 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 99FECE0676 for ; Sun, 1 May 2011 11:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2205; q=dns/txt; s=iport; t=1304272830; x=1305482430; h=from:subject:date:message-id:cc:to:mime-version; bh=HDjEHpCosh4xS2o5Sl0o7UPXhFH7WOje5GslYjlsZyM=; b=bQL01Y0qncpxwQNBcF9JL7fKgD2ymBInP4It9jgrhnNhBDOi7e6b8TWw djAA+aO+yrXNhMzSgrG8mhQE14xuC6UKroliTkD5Gb8GTGwZs7QPvHsbz ZhSnw1VGW/GxMxsSCJJrHYamVlYY9rSpsbJK17KrBtmkvk2Ih0DCQUYxi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsIAI2evU2rRDoG/2dsb2JhbACCYpVzjUd3pkWbNYYABIYOiGuEGYop X-IronPort-AV: E=Sophos;i="4.64,298,1301875200"; d="scan'208,217";a="306046794" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 01 May 2011 18:00:30 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p41I0JgU018493; Sun, 1 May 2011 18:00:30 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Sun, 01 May 2011 11:00:30 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Sun, 01 May 2011 11:00:30 -0700 From: Fred Baker Date: Sun, 1 May 2011 11:00:06 -0700 Message-Id: <5F8FA59F-A660-4EAD-8CFF-1D2BE442B37D@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4--451907929 Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] draft-chown-v6ops-call-to-arms WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 18:00:31 -0000 --Apple-Mail-4--451907929 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is to initiate a two week working group last call of = draft-chown-v6ops-call-to-arms. Please read it now. If you find nits = (spelling errors, minor suggested wording changes, etc), comment to the = authors; if you find greater issues, such as disagreeing with a = statement or finding additional issues that need to be addressed, please = post your comments to the list. We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make.= --Apple-Mail-4--451907929 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is to initiate a two week working = group last call of draft-chown-v6ops-call-to-arms. Please read it now. = If you find nits (spelling errors, minor suggested wording changes, = etc), comment to the authors; if you find greater issues, such as = disagreeing with a statement or finding additional issues that need to = be addressed, please post your comments to = the list.

We are looking specifically for comments on the = importance of the document as well as its content. If you have read the = document and believe it to be of operational utility, that is also = an important comment to make.
= --Apple-Mail-4--451907929-- From fred@cisco.com Sun May 1 11:00: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 2FD49E0727 for ; Sun, 1 May 2011 11:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.582 X-Spam-Level: X-Spam-Status: No, score=-110.582 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EIvd6gKKu5+b for ; Sun, 1 May 2011 11:00:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id B2D6AE0725 for ; Sun, 1 May 2011 11:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2054; q=dns/txt; s=iport; t=1304272833; x=1305482433; h=from:subject:date:message-id:cc:to:mime-version; bh=gbSCRiqDd/2axsEVWLxyUoJGCzsBmApU9UrIsAs4T/U=; b=Edf2n31w5aDqZP7/eJohXvfwJi6ajj7QPmF2YtRntC84Slu2Y/GTvVB7 5YHxgrMx7/zrbXQx+eCGIb1kSM7r15gmS2oTYNlO0t1mUUKKBpPoIynzW 99k5oiH/COJIJuzdDkOjB3ptpaTnyFcMO/AcTWheMSi3yN1ewMtVC/dPU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAWfvU2rRDoG/2dsb2JhbACCYqM6d6ZGmzWGAASGDohrhBmKKQ X-IronPort-AV: E=Sophos;i="4.64,298,1301875200"; d="scan'208,217";a="348205081" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 01 May 2011 18:00:33 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p41I0JgY018493; Sun, 1 May 2011 18:00:32 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Sun, 01 May 2011 11:00:33 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Sun, 01 May 2011 11:00:33 -0700 From: Fred Baker Date: Sun, 1 May 2011 11:00:10 -0700 Message-Id: <850CD890-511A-4D48-AC95-A6314060F91E@cisco.com> To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6--451903467 Cc: Ron Bonica Subject: [v6ops] Regarding draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 18:00:34 -0000 --Apple-Mail-6--451903467 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Today is the last day of the announced WGLC on this draft. Ole posted an = updated version last Wednesday and a list of issues. As near as I can = tell, the WG feels that his proposed resolutions for issues 2, 3, 7, 8, = and 10 are correct, and the other issues have proposed text or at least = concepts for that text proposed. I have asked Ole to post a new version = incorporating those changes. We will continue this WGLC through 8 May to = let people comment on the revised version, which I expect will reach = rough consensus. We have at least two people that would really like to = NOT see 6to4 declared historic, Keith Moore and Jordi Palet Martinez, = and I do not expect them to change their views.= --Apple-Mail-6--451903467 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Today is the last day of the announced = WGLC on this draft. Ole posted an updated version last Wednesday and a = list of issues. As near as I can tell, the WG feels that his = proposed resolutions for issues 2, 3, 7, 8, and 10 are correct, and the = other issues have proposed text or at least concepts for that text = proposed. I have asked Ole to post a new version incorporating those = changes. We will continue this WGLC through 8 May to let people comment = on the revised version, which I expect will reach rough consensus. We = have at least two people that would really like to NOT see 6to4 declared = historic, Keith Moore and Jordi Palet Martinez, and I do not expect them = to change their views. = --Apple-Mail-6--451903467-- From brian.e.carpenter@gmail.com Sun May 1 14:29: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 09779E06AC for ; Sun, 1 May 2011 14:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.358 X-Spam-Level: X-Spam-Status: No, score=-104.358 tagged_above=-999 required=5 tests=[AWL=1.241, BAYES_00=-2.599, GB_I_LETTER=-2, 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 O1uSWNavLM2a for ; Sun, 1 May 2011 14:29:50 -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 0080BE0697 for ; Sun, 1 May 2011 14:29:17 -0700 (PDT) Received: by pvh1 with SMTP id 1so3704489pvh.31 for ; Sun, 01 May 2011 14:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+3L4lt03LrfCm0Wmx0zU/D7MVQi0/h0u8RLGaBb6sIA=; b=VBNFTIxvqqTCtV2yn3bNhx/WUOP2nPGyoJV8luOssgui/K/CUHRox4tMhN8suN6KcY EnHJEd1SDys5cLbKXgkMeuiy8UHeGQRgmitqf3EH8ocPKDPHNvNcoyRTG4tuv3aDSDyj v876dqZN2zoDJ2VZ93wYqZ2K0NxCtSt7J7qwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=ditXKmgWPbRX4BVAvsVbA4rVwKUECWtkJirC85UNFEhh0K71WQE9gLfaEkKAxOwkIC kr2tA9c+XekChHpWs9EyOQZDaltB1uREm0Vf/ftl6+JQ+k+V748YOeHnUHEMalsxtc4z 19LdKCb9pf9WWMQR6+RNd7D5Ids0sR9QgcrCY= Received: by 10.68.54.102 with SMTP id i6mr6747465pbp.111.1304285357689; Sun, 01 May 2011 14:29:17 -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 t4sm3365544pbl.45.2011.05.01.14.29.14 (version=SSLv3 cipher=OTHER); Sun, 01 May 2011 14:29:16 -0700 (PDT) Message-ID: <4DBDD0A9.4030501@gmail.com> Date: Mon, 02 May 2011 09:29:13 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ole Troan References: <6464744E-8507-497A-8AF5-693C74BB6795@cisco.com> <93AC18CB-D38E-40BF-9472-4A7BEC859199@employees.org> In-Reply-To: <93AC18CB-D38E-40BF-9472-4A7BEC859199@employees.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 5. "Clarifications" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 21:29:51 -0000 On 2011-05-01 22:03, Ole Troan wrote: > Ole, > >> In your letter dated Sun, 1 May 2011 11:45:48 +0200 you wrote: >>> I would suggest you wrote a new draft of a peer to peer only 6to4 version. >> Is that realistic? (anyone can author an informational RFC, so not that part). > > probably not ;-) > >> 6to4 has a lot of problems with NAT. And the place where peer-to-peer has >> most problems is in systems with lots of NAT, in particular carrier-grade NAT. >> >> So presenting a protocol that has lots of problems with carrier-grade NAT >> as a solution to a problem mostly caused by carrier-grade NAT strikes me >> as a bad idea. > > iff the argument was to keep some aspects of 6to4 to use it in a private network context, then I think a new draft would be better, > than to try to deprecate only half of 3056. only retaining the 'managed' part of 3056. > > I'm suggesting that as a way out to avoid this discussion on private use 6to4, derailing the effort to fix the mistakes with did with 6to4 in the Internet. But there's nothing in the act of marking RFC 3056 as Historic that prevents such use; that's my difficulty in understanding Dmitry's objections. However, this is why I am dead against the proposal for a sunset date and against advice to operators to filter 2002::/16 unconditionally. That would break successful use of 6to4 for no reason. Nature will take its course: IPv4 runout is what will finally break 6to4; it does not work in a fragmented IPv4 network (which is what CGN creates). That is clearly stated in RFC 3056, by the way, although we didn't anticipate CGN specifically. Brian From tjc@ecs.soton.ac.uk Sun May 1 14:43: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 EE793E06D3 for ; Sun, 1 May 2011 14:43:57 -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 rRd+b2FY1qm4 for ; Sun, 1 May 2011 14:43:57 -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 C17C0E06CC for ; Sun, 1 May 2011 14:43:55 -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 p41Lhq0S018534 for ; Sun, 1 May 2011 22:43:52 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p41Lhq0S018534 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1304286232; bh=1FrnuNLz5JFxYIDSU6IfUbARX38=; h=From:Mime-Version:Subject:Date:In-Reply-To:To:References; b=bGVDkJxSYMqQfa9ooiMEThj3qSirudC1YMIqBMXR9QW7KSFEhEEdeCJlpNw8ljzGq toHjiyOF3HzV1ouEoTk6YTM90cRIg9eGh3AkMzKHjIQJMfM7E1ZVyPAXedshfByO86 XFnFweyUmipYlQDT0MU8sM/5a9iA2xK497hOH7dE= 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 n40Mhq0035600225yi ret-id none; Sun, 01 May 2011 22:43:52 +0100 Received: from [192.168.1.17] (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 p41Lhl43031320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 1 May 2011 22:43:48 +0100 From: Tim Chown Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-24--438486700 Date: Sun, 1 May 2011 22:43:47 +0100 In-Reply-To: To: "v6ops@ietf.org WG" References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> <1304195712.19431.107.camel@shakira.millnert.se> <4DBD777A.20109@redpill-linpro.c! om> <12D841F5-205B-47E5-800C-2FC8777DF876@ecs.soton.ac.uk> Message-ID: X-Mailer: Apple Mail (2.1082) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n40Mhq003560022500; tid=n40Mhq0035600225yi; 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: p41Lhq0S018534 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 21:43:58 -0000 --Apple-Mail-24--438486700 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 1 May 2011, at 17:43, Lorenzo Colitti wrote: > On Sun, May 1, 2011 at 8:08 AM, Tore Anderson = wrote: > 6to4 is broken beyond repair. Moving it to =ABHistoric=BB is > simply an admission of that fact, as well as sending a clear message = to > everyone that the protocol has no future and that it is time to move = on. >=20 > You hit the nail on the head. 6to4 can't be fixed, and it will only = get worse over time as CGN is deployed (ISPs assigning bogon addresses; = broken home gateways that turn on 6to4 even with private addresses). We = need to acknowledge that fact, and send a clear message to the industry = that 6to4 is not worth pursuing. We have various public services made available dual stack. In terms of = external IPv6 traffic hitting our main web site, our peak IPv6 transport = volume was just under 2% of all traffic a couple of months ago. Of that = 2%, less than 1% was via 6to4, and that's with our ISP (JANET) running a = 6to4 relay. I suspect we see rather less 6to4 than other sites because = a lot of our IPv6 traffic comes from other academic sites that have = native IPv6 connectivity. So the removal of 6to4 wouldn't be an issue = for us. We would very much like to see various Internet connection services (not = just Windows) cease to use 6to4 when connection sharing is enabled. = Every one of the rogue RAs we've seen at our site in the past 12 months = has been due to connection sharing software, and (unchecked) we would = have a rogue 6to4 RA about 60% of the time somewhere on our wireless = network. Accelerating publication of RFC3484-bis (and the DHCPv6 policy = distribution method) would be very welcome. I am more than happy to = offer editing cycles on that if required. As long as the message to avoid 6to4 is clear enough, I don't have = strong views on the specifics. I understand why some may want to see a = 6to4 version of RFC 3701, but avoiding 6to4 on by default, or being = turned on unintentionally, is certainly a minimum step. =20 Tim --Apple-Mail-24--438486700 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Sun, May 1, 2011 at 8:08 AM, Tore Anderson = <tore.anderson@redpill-lin= pro.com> wrote:
6to4 is broken beyond repair. Moving it to =ABHistoric=BB is
simply an admission of that fact, as well as sending a clear message = to
everyone that the protocol has no future and that it is time to move = on.

You hit the nail on the = head. 6to4 can't be fixed, and it will only get worse over time as = CGN is deployed (ISPs assigning bogon addresses; broken home gateways = that turn on 6to4 even with private addresses). We need to = acknowledge that fact, and send a clear message to the industry that = 6to4 is not worth pursuing.

We = have various public services made available dual stack.   In terms = of external IPv6 traffic hitting our main web site, our peak IPv6 = transport volume was just under 2% of all traffic a couple of months = ago.  Of that 2%, less than 1% was via 6to4, and that's with our = ISP (JANET) running a 6to4 relay.  I suspect we see rather less = 6to4 than other sites because a lot of our IPv6 traffic comes from other = academic sites that have native IPv6 connectivity.  So the removal = of 6to4 wouldn't be an issue for us.

We would = very much like to see various Internet connection services (not just = Windows) cease to use 6to4 when connection sharing is enabled. =  Every one of the rogue RAs we've seen at our site in the past 12 = months has been due to connection sharing software, and (unchecked) we = would have a rogue 6to4 RA about 60% of the time somewhere on our = wireless network.

Accelerating publication of = RFC3484-bis (and the DHCPv6 policy distribution method) would be very = welcome.  I am more than happy to offer editing cycles on that if = required.

As long as the message to avoid 6to4 = is clear enough, I don't have strong views on the specifics.  I = understand why some may want to see a 6to4 version of RFC 3701, but = avoiding 6to4 on by default, or being turned on unintentionally, is = certainly a minimum = step.
 
Tim

= --Apple-Mail-24--438486700-- From jhw@apple.com Sun May 1 15:06: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 ED17BE06D3 for ; Sun, 1 May 2011 15:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.691 X-Spam-Level: X-Spam-Status: No, score=-106.691 tagged_above=-999 required=5 tests=[AWL=-0.092, 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 rycyBY3HbhR3 for ; Sun, 1 May 2011 15:06:10 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id ED0CBE06CC for ; Sun, 1 May 2011 15:06:10 -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 <0LKJ00B1WEQ7GPT0@mail-out.apple.com> for v6ops@ietf.org; Sun, 01 May 2011 15:06:09 -0700 (PDT) X-AuditID: 11807134-b7c00ae0000074fb-e9-4dbdd950d06b 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 relay14.apple.com (Apple SCV relay) with SMTP id C5.9F.29947.059DDBD4; Sun, 01 May 2011 15:06:09 -0700 (PDT) Received: from [172.16.1.2] (adit.conjury.org [75.101.54.88]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LKJ00K47EQ816B0@cardamom.apple.com> for v6ops@ietf.org; Sun, 01 May 2011 15:06:08 -0700 (PDT) From: james woodyatt In-reply-to: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> Date: Sun, 01 May 2011 15:06:09 -0700 Message-id: <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1222) X-Brightmail-Tracker: AAAAAA== Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 22:06:12 -0000 On Apr 27, 2011, at 1:17 PM, Fred Baker wrote: >> ------------------- >> - Now that we have an official WGLC, I'm going to repeat what I wrote in a previous thread: this draft should >> not published in its current form because it sets no standard for network operations without 6to4. >> A phaseout plan for RFC 3056 and RFC 3068 would be required before I could drop my objections to this draft. >> >> Action: None. Having failed to persuade anyone that a phaseout plan is necessary for this draft to be meaningful, I have refined my position on this point. I could support this draft if it were amended to make an explicit statement that operators are REQUIRED to route the 2002::/16 prefix and protocol 41 on the 192.88.99/24 prefixes to/from the default free zone so long as IPv4 remains in widespread use. Operating 6to4 relays is RECOMMENDED. -- james woodyatt member of technical staff, core os networking From brian.e.carpenter@gmail.com Sun May 1 15:32: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 A0A78E0718 for ; Sun, 1 May 2011 15:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.14 X-Spam-Level: X-Spam-Status: No, score=-103.14 tagged_above=-999 required=5 tests=[AWL=-0.141, 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 vLrvp4sI+SZ4 for ; Sun, 1 May 2011 15:32:46 -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 3327FE06D3 for ; Sun, 1 May 2011 15:32:46 -0700 (PDT) Received: by pvh1 with SMTP id 1so3718052pvh.31 for ; Sun, 01 May 2011 15:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EE30/uCEPYl0oEr51TjPU4hyiBP8sn+UswHSuwBc0WA=; b=kNBNs9x1M7i/SxJmC0gC2I3qXXIZINDm84khFYfAEZ+7OI/UMHuO0M0lh/Wfwtcf70 Rs250ustv3ilwO/v1fb2cNHwEXbPAvtFN39irsNiJdvdJG22YIPDvKU0AY3GwWyaoToP kl9eJcObqW5gZLUrgGQN2c8mFpvYdsQGxP+BA= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=K4HhppPzu3T9yAJfOT0QodWPvEka2xUn46QXGOQ7OoJI49cHm8tuQVEVSLU7RJfCux VE3I5wFTiP/bnNT5/QdQev7pzjtUOdethvdv886vpDdL+Y2ZJ2xTEaQzw8UcnWOyhChF GnGrAjmMcMWM7GAIEocSUFi9f8IsZUQEEZHtI= Received: by 10.68.7.7 with SMTP id f7mr7567683pba.262.1304289165912; Sun, 01 May 2011 15:32:45 -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 a4sm3395972pbs.25.2011.05.01.15.32.43 (version=SSLv3 cipher=OTHER); Sun, 01 May 2011 15:32:44 -0700 (PDT) Message-ID: <4DBDDF89.80907@gmail.com> Date: Mon, 02 May 2011 10:32:41 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> In-Reply-To: <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 22:32:46 -0000 On 2011-05-02 10:06, james woodyatt wrote: > On Apr 27, 2011, at 1:17 PM, Fred Baker wrote: > >>> ------------------- - Now that we have an official WGLC, >>> I'm going to repeat what I wrote in a previous thread: >>> this draft should not published in its current form >>> because it sets no standard for network operations >>> without 6to4. A phaseout plan for RFC 3056 and RFC 3068 >>> would be required before I could drop my objections to >>> this draft. >>> >>> Action: None. > > Having failed to persuade anyone that a phaseout plan is > necessary for this draft to be meaningful, I have refined my > position on this point. > > I could support this draft if it were amended to make an > explicit statement that operators are REQUIRED to route the > 2002::/16 prefix and protocol 41 on the 192.88.99/24 prefixes > to/from the default free zone so long as IPv4 remains in > widespread use. Please no. The advice is much more subtle than that and depends on which operator and what their objective is. Since I wrote a whole draft about it, I will stop there. > Operating 6to4 relays is RECOMMENDED. Again, it's more subtle than that, depending on the operator. Brian > > > -- james woodyatt member of technical staff, > core os networking > > > > _______________________________________________ v6ops mailing > list v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From aservin@lacnic.net Sun May 1 15:49: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 666EAE0664 for ; Sun, 1 May 2011 15:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.055 X-Spam-Level: * X-Spam-Status: No, score=1.055 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, J_CHICKENPOX_13=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 i5g7b0GHA+jV for ; Sun, 1 May 2011 15:49:20 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 456F2E0737 for ; Sun, 1 May 2011 15:49:18 -0700 (PDT) Received: from [192.168.1.102] (r186-48-197-161.dialup.adsl.anteldata.net.uy [186.48.197.161]) by mail.lacnic.net.uy (Postfix) with ESMTP id 0D8AD3084DF for ; Sun, 1 May 2011 19:49:12 -0300 (UYT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Arturo Servin In-Reply-To: <20110429034458.4F74DE540FF@drugs.dv.isc.org> Date: Sun, 1 May 2011 19:49:04 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2E945CE4-9718-4B68-9B15-A2F4CB1E4106@lacnic.net> References: <20110429034458.4F74DE540FF@drugs.dv.isc.org> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [v6ops] Signaling shared addressing and 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 22:49:20 -0000 6to4 + CGNs, mmmm, no thanks. I like the idea but for a more general or different purpose, not = only (or justified) for 6to4. Regards, -as On 29 Apr 2011, at 00:44, Mark Andrews wrote: >=20 > Currently in front of ARIN there is a proposal for a /10 > which would be shared be network operators for assigning > IPv4 addresses to customers behing CGNs. This address block > and any other non-RFC 1918 address block used for address > sharing will cause operational problems for 6to4 users. >=20 > It would be useful for ISP's to be able to signal when a > address returned by DHCP or PPP is to be shared so that > 6to4 and other functionality that depends on unshared > public IPv4 addresses can be disabled. >=20 > It would also be useful for a ISP's clients to be able to > signal that they need a unshared public IPv4 address when > there is a mix of shared and unshared IPv4 addresses available > to assign to a customer. >=20 > I propose the we allocate DHCP and PPP code points that the > client can set if they desire a unshared address or have > enables a feature that requires a unshared address. The > default would be to say a shared address is acceptable. > The ISP would set the status of the address in the reply. > The client would then take whatever corrective action > required if they can't get the designed type of address. >=20 > Mark > --=20 > 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 From marka@isc.org Sun May 1 15:59: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 005DCE06EF for ; Sun, 1 May 2011 15:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.061 X-Spam-Level: X-Spam-Status: No, score=0.061 tagged_above=-999 required=5 tests=[AWL=-2.540, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_FREE=2.3, MANGLED_TOOL=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 mQ2hGg4dcW6F for ; Sun, 1 May 2011 15:59:07 -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 C2117E0664 for ; Sun, 1 May 2011 15:59:06 -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 BB41B5F983B; Sun, 1 May 2011 22:58:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 BED96216C22; Sun, 1 May 2011 22:58:48 +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 24B52E5EE92; Mon, 2 May 2011 08:59:06 +1000 (EST) To: "George, Wes E [NTK]" From: Mark Andrews References: <20110429034458.4F74DE540FF@drugs.dv.isc.org> <4DBA5164.1000700@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8C0F5@PDAWM12B.ad.sprint.com> In-reply-to: Your message of "Fri, 29 Apr 2011 16:03:44 GMT." <54E900DC635DAB4DB7A6D799B3C4CD8E10C8C0F5@PDAWM12B.ad.sprint.com> Date: Mon, 02 May 2011 08:59:06 +1000 Message-Id: <20110501225906.24B52E5EE92@drugs.dv.isc.org> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Signaling shared addressing and 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 22:59:08 -0000 In message <54E900DC635DAB4DB7A6D799B3C4CD8E10C8C0F5@PDAWM12B.ad.sprint.com>, " George, Wes E [NTK]" writes: > ------=_NextPart_000_0087_01CC0665.7E631CF0 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Bri > an E Carpenter > Sent: Friday, April 29, 2011 1:49 AM > To: Mark Andrews > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Signaling shared addressing and 6to4 > > On 2011-04-29 15:44, Mark Andrews wrote: > > Currently in front of ARIN there is a proposal for a /10 > > which would be shared be network operators for assigning > > IPv4 addresses to customers behing CGNs. This address block > > and any other non-RFC 1918 address block used for address > > sharing will cause operational problems for 6to4 users. > > I sincerely hope ARIN will have the common sense to reject this awful idea, b > ut that is not a v6ops discussion. > > [WEG] PPML is an open list, and the policy is currently in last call. Feel fr > ee to join the fun. > http://lists.arin.net/pipermail/arin-ppml/2011-April/020808.html. > > > I certainly think that ISPs should tell their customers that they aren't actu > ally providing Internet service - see RFC 4084. > [WEG] So in addition to the debacle around "4G" wireless service vs the ITU's > standard, now we're going to try our hands at managing > the marketing about what is and is not Internet service? It's simply not that > black-and-white post IPv4 exhaustion. I would bet that > most customers would prefer being NATed to being told - "sorry, the (IPv4) in > ternet is full, go away (or go IPv6-only). Oh and by > the way, replace all of the kit in your house that doesn't support IPv6." Which is a gross exageration. You can run dual stack internally. The only parts that need to be upgraded is those that need to talk the global Internet. > > It would also be useful for a ISP's clients to be able to > > signal that they need a unshared public IPv4 address when > > there is a mix of shared and unshared IPv4 addresses available > > to assign to a customer. > > That would be for ISPs incapable of supporting IPv6? > [WEG] You (wrongly) assume that this is completely the ISP's fault (and not c > ustomer owned CPE), and that simply having IPv6 will > eliminate the need for supporting IPv4 at all. > I will note however that I'm convinced that the brokenness of NAT444 is likel > y to be IPv6's killer app, so while operationally it'd > be nice to have a way to manage that brokenness, it's probably better to just > get it over with. Also, I think there's no way to > balance those who believe that they "need" a public IP vs those who *actually > * do vs the available IPv4 resources - to your later > point about the "wrong" default. Sure, I'd like to get it over with and have been asking my ISP about IPv6 for the last 8 years. > That said, Mark, I think this is one more idea to add to the "good, but too l > ittle too late" pile. I can't see it having wide enough > deployment in a reasonable period of time to matter as far as fixing IPv4 or > IPv6 brokenness, and if it does get widely deployed, > the time to develop and implement it probably should have been spent on more > pressing issues (like the underlying brokenness). I suspect that most ISP's will still be running IPv4 in 10 years time. It will still be useful for the host/router device to know if it is on a shared address or not. You say it is a good idea. Only time will tell if it is too late or will get used. > Wes George -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Sun May 1 16:20: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 F2B8FE0685 for ; Sun, 1 May 2011 16:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.184 X-Spam-Level: X-Spam-Status: No, score=0.184 tagged_above=-999 required=5 tests=[AWL=-1.817, BAYES_00=-2.599, MANGLED_GOOD=2.3, MANGLED_TEXT=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 Xbw8V0MGaxvt for ; Sun, 1 May 2011 16:20:50 -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 22E6FE062A for ; Sun, 1 May 2011 16:20:50 -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 EB9F55F983B; Sun, 1 May 2011 23:20:33 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 91922216C33; Sun, 1 May 2011 23:20:31 +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 1561FE5F11E; Mon, 2 May 2011 09:20:49 +1000 (EST) To: Ole Troan From: Mark Andrews References: In-reply-to: Your message of "Sun, 01 May 2011 11:35:27 +0200." Date: Mon, 02 May 2011 09:20:49 +1000 Message-Id: <20110501232049.1561FE5F11E@drugs.dv.isc.org> Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 May 2011 23:20:51 -0000 In message , Ole Troan writ es: > Dmitry, > > >>> Does the working group agree with the summarization of the concern? > > > > I agree with the summarization of the concern. > > > >>> Do we agree with the proposed (in)action? > > > > I disagree with the proposed action. I suggest to either remove the problem > from the list of 6to4 problems, since as currently worded this is not a 6to4 > problem, but protocol 41 problem, and this draft, in its current form, doesn > 't seem to have any intentions to deal with general protocol 41, or to add te > xt illustrating why this problem is 6to4 specific and other uses of protocol > 41 on the Internet do not have this problem or how that problem is/can be mit > igated for them. > > there are aspects of this that are unique to 6to4 (as an unmanaged tunnel mec > hanisms). e.g. a bi-directional configured tunnel between two nodes within a > single network is quite different from a unmanaged tunnel spanning the Intern > et. > > other uses of protocol 41 (including the managed one in 3056) does have mecha > nisms to detect black holes (routing protocol running on top of the tunnel). > > > Also, if it is shown how this problem is 6to4 specific, RFC 3484bis recomme > ndation would mitigate the problem and hence, in my opinion, this problem can > not be used as a justification for declaring RFC 3056 historic - in that case > I suggest to remove the "historic" recommendation and instead add a referenc > e to RFC 3484bis. > > while rfc3484bis may mitigate the problem, it only does so by making sure 6to > 4 isn't used. > > we have empirical evidence that 6to4 has problems with filters/firewalls. I h > aven't seen similar evidence for other mechanisms using protocol 41. doesn't > mean they don't have the same issue obviously, but I don't think that's a goo > d argument for not including this text about 6to4. > > > o 6to4 has no specified mechanism to handle the case where the > protocol (41) is blocked in intermediate firewalls. It can not be > expected that path MTU discovery across the Internet works > reliably; ICMP messages may be blocked and in any case an IPv4 > ICMP message rarely has enough of the original packet in it to be > useful to proxy back to the IPv6 sender. PMTUD should be *off* on the encapsulating packets. PMTUD should only be enabled for TCP by default. Unfortunately Linux and Solaris boxes get this wrong and turn it on for all protocols. Oracle/Sun have acknowledged this is a bug with their stack. This misbehaviour causes problems for DNS/UDP. 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 Sun May 1 17:43: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 47EE2E0664 for ; Sun, 1 May 2011 17:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, 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 3N4-Boa-ccNy for ; Sun, 1 May 2011 17:43:16 -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 A60DFE062A for ; Sun, 1 May 2011 17:43:15 -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 20FA15F983B; Mon, 2 May 2011 00:42:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 EBCEB216C22; Mon, 2 May 2011 00:42:57 +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 F1774E61D74; Mon, 2 May 2011 10:43:13 +1000 (EST) To: Arturo Servin From: Mark Andrews References: <20110429034458.4F74DE540FF@drugs.dv.isc.org> <2E945CE4-9718-4B68-9B15-A2F4CB1E4106@lacnic.net> In-reply-to: Your message of "Sun, 01 May 2011 19:49:04 -0300." <2E945CE4-9718-4B68-9B15-A2F4CB1E4106@lacnic.net> Date: Mon, 02 May 2011 10:43:13 +1000 Message-Id: <20110502004313.F1774E61D74@drugs.dv.isc.org> Cc: IPv6 Operations Subject: Re: [v6ops] Signaling shared addressing and 6to4 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 00:43:17 -0000 In message <2E945CE4-9718-4B68-9B15-A2F4CB1E4106@lacnic.net>, Arturo Servin wri tes: > 6to4 + CGNs, mmmm, no thanks. > > I like the idea but for a more general or different purpose, not only ( > or justified) for 6to4. > > Regards, > -as I'm sure that there are plenty of senarios, 6to4 is just one. I've got a voip phone where I need a reasonably stable external public address. The phone gets reconfigured whenever the external IPv4 address changes (via dhclient-exit-hooks). I've also got a tunnel to HE for IPv6 which again needs a reasonably stable external public address. The tunnel gets reconfigured whenever the external IPv4 address changes (via dhclient-exit-hooks). I send traffic destined to 6to4 addressess directly though I don't use a 6to4 address. This works today. This may or may not work with a CGN. Changing the source address of these packets won't hurt. However this needs to be tested when/if I'm behind a CGN and it would be useful to know when that happens. I have no idea when my ISP will be forced to turn on CGN or when they will deliver IPv6 (native or via 6rd). I do know that one doesn't have to put everyone behind a CGN and that having a standard method can only help. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jhw@apple.com Sun May 1 17: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 324E3E062A for ; Sun, 1 May 2011 17:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.678 X-Spam-Level: X-Spam-Status: No, score=-106.678 tagged_above=-999 required=5 tests=[AWL=-0.079, 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 liktOWv1WW8z for ; Sun, 1 May 2011 17:51:24 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 621C8E0664 for ; Sun, 1 May 2011 17:51:24 -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 <0LKJ00CWGMDK1SC0@mail-out.apple.com> for v6ops@ietf.org; Sun, 01 May 2011 17:51:23 -0700 (PDT) X-AuditID: 11807134-b7c00ae0000074fb-07-4dbe000bc81e 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 17.2D.29947.B000EBD4; Sun, 01 May 2011 17:51:23 -0700 (PDT) Received: from [172.16.1.2] (adit.conjury.org [75.101.54.88]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LKJ004IJMDM7X90@cardamom.apple.com> for v6ops@ietf.org; Sun, 01 May 2011 17:51:23 -0700 (PDT) From: james woodyatt In-reply-to: <4DBDDF89.80907@gmail.com> Date: Sun, 01 May 2011 17:51:24 -0700 Message-id: <1DBBD26D-0AC8-40C6-8FDD-4AD63751C4ED@apple.com> References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBDDF89.80907@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1222) X-Brightmail-Tracker: AAAAAA== Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 00:51:25 -0000 On May 1, 2011, at 3:32 PM, Brian E Carpenter wrote: > > Since I wrote a whole draft about it, I will stop there. I would be very happy with just that whole other draft. It's *this* draft that I'm all spun up about. -- james woodyatt member of technical staff, core os networking From pekkas@netcore.fi Mon May 2 00: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 E314DE06CF for ; Mon, 2 May 2011 00:25:16 -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 KDuwzGrTPTe2 for ; Mon, 2 May 2011 00:25:16 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id 794A8E068B for ; Mon, 2 May 2011 00:25:15 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p427OpFx007754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 May 2011 10:24:51 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p427OoRq007751; Mon, 2 May 2011 10:24:50 +0300 Date: Mon, 2 May 2011 10:24:50 +0300 (EEST) From: Pekka Savola To: Geoff Huston In-Reply-To: Message-ID: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi X-Virus-Status: Clean Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 07:25:17 -0000 On Fri, 29 Apr 2011, Geoff Huston wrote: > Speaking personally, the major reason for me to deprecate 6to4 is > its shocking connection failure rate. I have observed in the packet > capture that I've been performing > (http://www.potaroo.net/ispcol/2010-12/6to4fail.html) is that > between 10% to 20% of 6to4 hosts that can successfully emit a SYN > fail to emit the followup SYN/ACK in the TCP initial handshake. The > predominate reason, as far as I can tell, is inbound protocol 41 > filters close to the client, rather than use of non-routed addresses > in the embedded IPv4 address of the 6to4 packet. For me this exposes > a basic flaw in the auto-tunnelling concept - namely that of > unintentional consequences, where a firewall filter set adopts a > conservative position with respect to incoming packets, including, > presumably, blocking all IP protocols except TCP. UDP and ICMP. > Then, in the "inside" someone deploys an out of the box host that > will use 6to4 under certain conditions. The result is messy, given > that the unit typically waits for > a protracted period of resend attempts before ultimately giving up. Geoff, do the return relays in your measurements emit packets from src=192.88.99.1 or some other IP? I assume that has significant implications on failure rate, with src=192.88.99.1 having fewer failures. I don't think I've seen this part of the methology stated anywhere. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From gih@apnic.net Mon May 2 00: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 A9138E06AD for ; Mon, 2 May 2011 00:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.101 X-Spam-Level: X-Spam-Status: No, score=-101.101 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, 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 a76gQexHl+De for ; Mon, 2 May 2011 00:57:41 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 26D0DE06CF for ; Mon, 2 May 2011 00:57:35 -0700 (PDT) Received: from dhcp-27-178.ripemtg.ripe.net (dhcp-27-178.ripemtg.ripe.net [193.0.27.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id C8EB5B681F; Mon, 2 May 2011 17:57:27 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Mon, 2 May 2011 17:57:15 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <72AF826C-1E79-465C-B43C-AD4B199DC883@cisco.com> <4DB9781E.8020107@redpill-linpro.com> <4DB9AD7D.2020102@redpill-linpro.com> <753308A7-382A-48F8-ADEB-FB2AB761F96B@apnic.net> <4DB9D5E8.4080703@redpill-linpro.com> To: Pekka Savola X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 07:57:41 -0000 On 02/05/2011, at 5:24 PM, Pekka Savola wrote: > On Fri, 29 Apr 2011, Geoff Huston wrote: >> Speaking personally, the major reason for me to deprecate 6to4 is its = shocking connection failure rate. I have observed in the packet capture = that I've been performing = (http://www.potaroo.net/ispcol/2010-12/6to4fail.html) is that between = 10% to 20% of 6to4 hosts that can successfully emit a SYN fail to emit = the followup SYN/ACK in the TCP initial handshake. The predominate = reason, as far as I can tell, is inbound protocol 41 filters close to = the client, rather than use of non-routed addresses in the embedded IPv4 = address of the 6to4 packet. For me this exposes a basic flaw in the = auto-tunnelling concept - namely that of unintentional consequences, = where a firewall filter set adopts a conservative position with respect = to incoming packets, including, presumably, blocking all IP protocols = except TCP. UDP and ICMP. Then, in the "inside" someone deploys an out = of the box host that will use 6to4 under certain conditions. The result = is messy, given that the unit typically waits for >> a protracted period of resend attempts before ultimately giving up. >=20 > Geoff, do the return relays in your measurements emit packets from = src=3D192.88.99.1 or some other IP? both I have two systems - one emits return packets from 192.88.99.1 and the = other uses its local Ipv4 unicast address. > I assume that has significant implications on failure rate, with = src=3D192.88.99.1 having fewer failures. I don't think I've seen this = part of the methology stated anywhere. In a set of experiments I tested a set of clients using BOTH systems. On = weekends the local unicast address using 6to4 generated a failure rate = of 13 - 15% while the anycast-using 6to4 relay generated a failure rate = of 10% to 11%. On weekdays the difference is higher - 15% failure using = the anycast address and 20% failure using a local unicast address regards, Geoff From rbarnes@bbn.com Mon May 2 07:32: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 74705E0675; Mon, 2 May 2011 07:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 qNNHCFpvu3Le; Mon, 2 May 2011 07:32:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id F0803E0678; Mon, 2 May 2011 07:32:33 -0700 (PDT) Received: from [128.89.253.173] (port=56137 helo=dhcp-27-1.ripemtg.ripe.net) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QGuAo-0008fq-T7; Mon, 02 May 2011 10:32:33 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4DBB4A83.7010408@dcrocker.net> Date: Mon, 2 May 2011 16:32:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> References: <4DBB4A83.7010408@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Mon, 02 May 2011 07:51:39 -0700 Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 14:32:37 -0000 I disagree that "whitelisting" is a reserved trademark of the anti-abuse = community. It's a general term for a list of things that are granted = something. Likewise with "blacklist" and "deny". Which means it's = perfectly appropriate for this document. On Apr 30, 2011, at 1:32 AM, Dave CROCKER wrote: >=20 > Review: >=20 > Title: IPv6 AAAA DNS Whitelisting Implications > I-D: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 >=20 > By: D. Crocker > Date: 29 April 2011 >=20 >=20 > Summary: >=20 > This draft is a discussion of a technique for resolving a dual-stack = problem between IPv4 and IPv6, through the use of special DNS records. >=20 > The document appears to continue a recent use of the term = 'whitelisting' that strongly conflicts with long-standing use of the = term by the anti-abuse community. >=20 > The document needs to do a more careful job of introducing the problem = it is solving and the explaining the way the 'whitelisting' mechanism = works. >=20 > I also very strongly encourage finding a different term. >=20 > d/ >=20 >=20 >> Abstract >>=20 >> The objective of this document is to describe what the whitelisting >> of DNS AAAA resource records is, hereafter referred to as DNS >=20 > RRs are whitelisted? Isn't it the addresses and not the records that = are whitelisted? >=20 > Does this mean putting whitelisting records into the DNS or does it = mean something else? >=20 > Comcast's own considerable expertise notwithstanding, has this doc = been vetted with a range of organizations that actually DO whitelisting? = Has it been circulated through MAAWG and APWG? Any comments from = Spamhaus? The Acknowledgements list does not seem to indicate a range = of whitelist ops folks whose names I know. (But then, I only know a = few...) >=20 >=20 >> whitelisting, as well as the implications of this emerging practice >> and what alternatives may exist. The audience for this document is >> the Internet community generally, including the IETF and IPv6 >> implementers. >=20 > I suspect that product marketers won't have much interest in this. I = suspect that the target for this is anti-abuse technical and operations = staff. >=20 >=20 >> Status of this Memo >>=20 >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >>=20 >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF). Note that other groups may also distribute >> working documents as Internet-Drafts. The list of current = Internet- >> Drafts is at http://datatracker.ietf.org/drafts/current/. >>=20 >> Internet-Drafts are draft documents valid for a maximum of six = months >> and may be updated, replaced, or obsoleted by other documents at = any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >>=20 >> This Internet-Draft will expire on August 26, 2011. >>=20 >> Copyright Notice >>=20 >> Copyright (c) 2011 IETF Trust and the persons identified as the >> document authors. All rights reserved. >>=20 >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with = respect >> to this document. Code Components extracted from this document = must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >>=20 >>=20 >>=20 >> Livingood Expires August 26, 2011 [Page = 1] >>=20 >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February = 2011 >>=20 >>=20 >> described in the Simplified BSD License. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Livingood Expires August 26, 2011 [Page = 2] >>=20 >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February = 2011 >>=20 >>=20 >> Table of Contents >>=20 >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 5 >> 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . = 6 >> 2.1. Description of the Operation of DNS Whitelisting . . . . . = 7 >> 3. What Problems Are Implementers Trying To Solve? . . . . . . . = 8 >> 4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . = 9 >> 5. Similarities to Other DNS Operations . . . . . . . . . . . . . = 12 >> 5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . = 12 >> 5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . = 12 >> 6. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . = 13 >> 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . = 13 >> 6.2. Deploying DNS Whitelisting Universally . . . . . . . . . . = 14 >> 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . = 15 >> 7.1. Architectural Implications . . . . . . . . . . . . . . . . = 15 >> 7.2. Public IPv6 Address Reachability Implications . . . . . . = 16 >> 7.3. Operational Implications . . . . . . . . . . . . . . . . . = 17 >> 7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . = 17 >> 7.3.2. Authoritative DNS Server Operational Implications . . = 17 >> 7.3.3. DNS Recursive Resolver Server Operational >> Implications . . . . . . . . . . . . . . . . . . . . . = 18 >> 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . = 19 >> 7.3.5. Implications of Operational Momentum . . . . . . . . . = 19 >> 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . = 20 >> 7.3.7. Additional Implications If Deployed On An Ad Hoc >> Basis . . . . . . . . . . . . . . . . . . . . . . . . = 20 >> 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . = 20 >> 7.5. Technology Policy Implications . . . . . . . . . . . . . . = 21 >> 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . = 22 >> 8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . = 23 >> 8.1. Implement DNS Whitelisting Universally . . . . . . . . . . = 23 >> 8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . = 23 >> 8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . = 23 >> 8.3.1. Solving Current End User IPv6 Impairments . . . . . . = 24 >> 8.3.2. Gain Experience Using IPv6 Transition Names . . . . . = 24 >> 9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . = 24 >> 10. Security Considerations . . . . . . . . . . . . . . . . . . . = 25 >> 10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . = 25 >> 10.2. Authoritative DNS Response Consistency Considerations . . = 26 >> 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . = 26 >> 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 27 >> 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . = 27 >> 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 27 >> 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . = 28 >> 15.1. Normative References . . . . . . . . . . . . . . . . . . . = 28 >> 15.2. Informative References . . . . . . . . . . . . . . . . . . = 29 >> Appendix A. Document Change Log . . . . . . . . . . . . . . . . . = 31 >> Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . = 32 >>=20 >>=20 >>=20 >> Livingood Expires August 26, 2011 [Page = 3] >>=20 >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February = 2011 >>=20 >>=20 >> Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . = 32 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Livingood Expires August 26, 2011 [Page = 4] >>=20 >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February = 2011 >>=20 >>=20 >> 1. Introduction >>=20 >> This document describes the emerging practice of whitelisting of = DNS >> AAAA resource records (RRs), which contain IPv6 addresses, = hereafter >> referred to as DNS whitelisting. The document explores the >> implications of this emerging practice are and what alternatives = may >> exist. >>=20 >> The practice of DNS whitelisting appears to have first been used by >> major web content sites (sometimes described herein as "highly- >=20 > Really? Not for email first? >=20 >=20 >> trafficked domains" or "major domains"). These web site operators, >> or domain operators, observed that when they added AAAA resource >> records to their authoritative DNS servers in order to support IPv6 >=20 > Oh. You mean /IPv6/ whitelisting. >=20 >=20 >> access to their content that a small fraction of end users had slow >> or otherwise impaired access to a given web site with both AAAA and = A >> resource records. The fraction of users with such impaired access >> has been estimated to be roughly 0.078% of total Internet users >> [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6 >> Brokenness]. Thus, in an example Internet Service Provider (ISP) >> network of 10 million users, approximately 7,800 of those users may >> experience such impaired access. >=20 > At a minimum, these sorts of statistics need to be normalized across = IPv6 users/traffic, given how small a percentage that is in total users = and total traffice. If that's what is meant it should be stated. If it = isn't, the statistic should be recalculated. >=20 >=20 >> As a result of this impairment affecting end users of a given = domain, >> a few major domains have either implemented DNS whitelisting or are >> considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist = Operations]. >=20 > How or why does whitelisting affect slow performance for these folk? >=20 >=20 >> When implemented, DNS whitelisting in practice means that a = domain's >> authoritative DNS will return a AAAA resource record to DNS = recursive >> resolvers [RFC1035] on the whitelist, while returning no AAAA >> resource records to DNS resolvers which are not on the whitelist. = It >=20 > Oh. The whitelisting is for resolving a conflict between AAAA and A = record choices? >=20 > Normally, the term 'whitelisting' is used to refer to bypass = anti-abuse mechanisms. This appears to be for something else and it = seems odd to call it whitelisting. >=20 > Note the more typical use of the term: >=20 > >=20 > >=20 > = >=20 > It appears that some v6 folks have chosen to co-opt a distinctive and = very well established anti-abuse term for an entirely different purpose. >=20 >=20 >=20 >> is important to note that these major domains are motivated by a >> desire to maintain a high-quality user experience for all of their >> users. By engaging in DNS whitelisting, they are attempting to >> shield users with impaired access from the symptoms of those >> impairments. >>=20 >> Critics of the practice of DNS whitelisting have articulated = several >> concerns. Among these are that: >>=20 >> o DNS whitelisting is a very different behavior from the current >> practice concerning the publishing of IPv4 address resource >> records, >>=20 >> o that it may create a two-tiered Internet, >>=20 >> o that policies concerning whitelisting and de-whitelisting are >> opaque, >>=20 >>=20 >>=20 >>=20 >>=20 >> Livingood Expires August 26, 2011 [Page = 5] >>=20 >> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February = 2011 >>=20 >>=20 >> o that DNS whitelisting reduces interest in the deployment of = IPv6, >=20 > Well, it certainly suggests that there is a problem handling v4/v6 in = dual stack environments cleanly. And it certainly seems that dealing = with the underlying problem would be better. >=20 > Beyond that, this appears to be a hack that is useful but not = scalable. >=20 >=20 >>=20 >> o that new operational and management burdens are created, >=20 > well, yeah... >=20 >=20 >> o and that the costs and negative implications of DNS whitelisting >> outweigh the perceived benefits, compared to fixing underlying >> impairments. >>=20 >> This document explores the reasons and motivations for DNS >> whitelisting. It also explores the outlined concerns regarding = this >> practice. Readers will hopefully better understand what DNS >> whitelisting is, why some parties are implementing it, and what >> criticisms of the practice exist. >=20 >=20 >=20 > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From dhc2@dcrocker.net Mon May 2 08:01: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 901A2E06A3; Mon, 2 May 2011 08:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 7WYs-hqDXK+j; Mon, 2 May 2011 08:01:21 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD10E0675; Mon, 2 May 2011 08:01:21 -0700 (PDT) Received: from [192.168.1.6] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p42F14Fd012917 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 2 May 2011 08:01:09 -0700 Message-ID: <4DBEC72D.2050901@dcrocker.net> Date: Mon, 02 May 2011 08:01:01 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4DBB4A83.7010408@dcrocker.net> <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> In-Reply-To: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 02 May 2011 08:01:09 -0700 (PDT) X-Mailman-Approved-At: Mon, 02 May 2011 08:10:46 -0700 Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 15:01:21 -0000 On 5/2/2011 7:32 AM, Richard L. Barnes wrote: > I disagree that "whitelisting" is a reserved trademark of the anti-abuse community. It's a general term for a list of things that are granted something. Likewise with "blacklist" and "deny". Which means it's perfectly appropriate for this document. > > Richard, The trademark model is interesting and probably useful here. Trademarks have context. Search on "whitelist dns" Since there is long-standing practice of anti-abuse use of the term for A records there as no doubt it would be -- and indeed is -- need to use it for AAAA records. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ek@google.com Mon May 2 08:28: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 4DDD9E06C3 for ; Mon, 2 May 2011 08:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.947 X-Spam-Level: X-Spam-Status: No, score=-105.947 tagged_above=-999 required=5 tests=[AWL=0.030, 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 lWY6ImUHjE6y for ; Mon, 2 May 2011 08:28:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id B40BAE0651 for ; Mon, 2 May 2011 08:28:14 -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 p42FSDkL007246 for ; Mon, 2 May 2011 08:28:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304350093; bh=6PBa81cBLsMunyZusaoJxtqJjhU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=X/yE9KOCCAV3FiEavaUDfhIymvaq3owSYdJLQJrJVBMNMFPDllivaQVDzxMrKFnWO NoMkjVWEP8zdLt4dLQCAA== Received: from pzk9 (pzk9.prod.google.com [10.243.19.137]) by wpaz29.hot.corp.google.com with ESMTP id p42FS8L3025543 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 2 May 2011 08:28:12 -0700 Received: by pzk9 with SMTP id 9so4349808pzk.33 for ; Mon, 02 May 2011 08:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cQX/xSqtcxYf3PqFbrM5/SfOnetfkoH9fNFe9AmVRzo=; b=DO6C8rm6tMsWny3y4k2JJWmKnbK/ZNF1b0AuCy5E9/qsRgvwM3N0DPN6c1o20utgYP L3A0J66Oa+tJzUJ9abvA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=r+YM6XA5B5HpLz5t2pjMspBNE/qypufBdm5xKSPYK+fSx9PEJxu1A/z77dIPCLLy0x v3PT+UKMqYEjf/JoLFEQ== MIME-Version: 1.0 Received: by 10.143.25.22 with SMTP id c22mr3077837wfj.267.1304350092396; Mon, 02 May 2011 08:28:12 -0700 (PDT) Received: by 10.142.245.14 with HTTP; Mon, 2 May 2011 08:28:12 -0700 (PDT) In-Reply-To: <4DBEC72D.2050901@dcrocker.net> References: <4DBB4A83.7010408@dcrocker.net> <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <4DBEC72D.2050901@dcrocker.net> Date: Tue, 3 May 2011 00:28:12 +0900 Message-ID: From: Erik Kline To: dcrocker@bbiw.net Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "Richard L. Barnes" , v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 15:28:15 -0000 I'm having a hard time thinking of adequate alternatives terms (but this purely a personal failing, I'm sure). Recommendations for other words? From rbarnes@bbn.com Mon May 2 08: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 BFA4BE06CA; Mon, 2 May 2011 08:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 wyowtz9EScGz; Mon, 2 May 2011 08:46:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C1F40E0651; Mon, 2 May 2011 08:46:56 -0700 (PDT) Received: from [128.89.253.173] (port=57520 helo=dhcp-27-1.ripemtg.ripe.net) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QGvKq-0007RT-6n; Mon, 02 May 2011 11:46:56 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4DBEC72D.2050901@dcrocker.net> Date: Mon, 2 May 2011 17:46:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DBB4A83.7010408@dcrocker.net> <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <4DBEC72D.2050901@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1082) Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 15:46:58 -0000 Search on "whitelist ipv6". Results are topical. What's the conflict = here? On May 2, 2011, at 5:01 PM, Dave CROCKER wrote: >=20 >=20 > On 5/2/2011 7:32 AM, Richard L. Barnes wrote: >> I disagree that "whitelisting" is a reserved trademark of the = anti-abuse community. It's a general term for a list of things that are = granted something. Likewise with "blacklist" and "deny". Which means = it's perfectly appropriate for this document. >>=20 >> >=20 >=20 > Richard, >=20 > The trademark model is interesting and probably useful here. >=20 > Trademarks have context. >=20 > Search on "whitelist dns" >=20 > Since there is long-standing practice of anti-abuse use of the term = for A records there as no doubt it would be -- and indeed is -- need to = use it for AAAA records. >=20 > d/ >=20 > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net From lorenzo@google.com Mon May 2 09: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 3253BE06CB for ; Mon, 2 May 2011 09:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.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, 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 Z8Bfo8b8s1fB for ; Mon, 2 May 2011 09:13:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 739ECE0688 for ; Mon, 2 May 2011 09:13:47 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p42GDkcr022941 for ; Mon, 2 May 2011 09:13:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304352826; bh=VIicofOA+tqu1XY5hnSqH1L+9Fg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=A+2f6boiWx3VFY0bdveEAeLzQnCOoWC9nSlUBU6Foe/PLGNq/7CFXdD/4MW3IW3aC DJp2vZ60FLqgUuyb8k2dg== Received: from gwb1 (gwb1.prod.google.com [10.200.2.1]) by wpaz37.hot.corp.google.com with ESMTP id p42GDPoh024130 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 2 May 2011 09:13:45 -0700 Received: by gwb1 with SMTP id 1so2616544gwb.8 for ; Mon, 02 May 2011 09:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZHrj6L0PKQ31/cwPVL07/JWx+ZBSr6qajrwjcxvBbiE=; b=mb4XthkhwaqHtNEjPTziLJgCsqjOm765sDTPgHMVSVrUB/ua42l8SlG4qzTfaJiUIl U6206h3Z/efRaPBscD/w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=pc21DUHyiZKIW5Lct3C93o9w/mJMoZxx5MEq7HiigYaogr5mBs7PQFsfQ4D2qYRRi9 Z0RNnkshUJ4nBXGc2cZw== Received: by 10.150.195.18 with SMTP id s18mr6755924ybf.207.1304352825359; Mon, 02 May 2011 09:13:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Mon, 2 May 2011 09:13:25 -0700 (PDT) In-Reply-To: <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> From: Lorenzo Colitti Date: Mon, 2 May 2011 09:13:25 -0700 Message-ID: To: james woodyatt Content-Type: multipart/alternative; boundary=000e0cd4d83cd13ea704a24d4ecf X-System-Of-Record: true Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 16:13:48 -0000 --000e0cd4d83cd13ea704a24d4ecf Content-Type: text/plain; charset=ISO-8859-1 On Sun, May 1, 2011 at 3:06 PM, james woodyatt wrote: > Having failed to persuade anyone that a phaseout plan is necessary for this > draft to be meaningful, I have refined my position on this point. > I like the idea of a phase-out plan, but what form would it take? Requesting that IANA declare 2002::/16 to be reserved? Saying that implementations should not use 2002::/16 to autoconfigure addresses? --000e0cd4d83cd13ea704a24d4ecf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, May 1, 2011 at 3:06 PM, james woodyatt <= span dir=3D"ltr"><jhw@apple.com>= wrote:
Having failed to persuade anyone that a phaseout plan is necessary for this= draft to be meaningful, I have refined my position on this point.

I like the idea of a phase-out plan, but what f= orm would it take? Requesting that IANA declare 2002::/16 to be reserved? S= aying that implementations should not use 2002::/16 to autoconfigure addres= ses?
--000e0cd4d83cd13ea704a24d4ecf-- From dhc2@dcrocker.net Mon May 2 09: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 BBF08E0688; Mon, 2 May 2011 09:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 yk7VPLzEjkEM; Mon, 2 May 2011 09:17:38 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E782FE06DE; Mon, 2 May 2011 09:17:37 -0700 (PDT) Received: from [192.168.1.6] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p42GGog8014791 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 2 May 2011 09:16:56 -0700 Message-ID: <4DBED8EF.2080304@dcrocker.net> Date: Mon, 02 May 2011 09:16:47 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4DBB4A83.7010408@dcrocker.net> <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <4DBEC72D.2050901@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 02 May 2011 09:16:56 -0700 (PDT) Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 16:17:38 -0000 Richard, Oh, right. Sorry, I thought the reference to AAAA had to do with the DNS. Clearly, since it will only be used in the context of v6, it won't cause any confusion. My own having mistaken the title of the document as being the longstanding use of the term for DNS Whitelisting of anti-abuse-related addresses was merely an exception. d/ On 5/2/2011 8:46 AM, Richard L. Barnes wrote: > Search on "whitelist ipv6". Results are topical. What's the conflict here? > > On May 2, 2011, at 5:01 PM, Dave CROCKER wrote: >> On 5/2/2011 7:32 AM, Richard L. Barnes wrote: >>> I disagree that "whitelisting" is a reserved trademark of the anti-abuse community. It's a general term for a list of things that are granted something. Likewise with "blacklist" and "deny". Which means it's perfectly appropriate for this document. >>> >>> >> >> Richard, >> >> The trademark model is interesting and probably useful here. >> >> Trademarks have context. >> Search on "whitelist dns" >> Since there is long-standing practice of anti-abuse use of the term for A records there as no doubt it would be -- and indeed is -- need to use it for AAAA records. -- Dave Crocker Brandenburg InternetWorking bbiw.net From ek@google.com Mon May 2 09:18: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 3B8B0E0760 for ; Mon, 2 May 2011 09:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.133 X-Spam-Level: X-Spam-Status: No, score=-107.133 tagged_above=-999 required=5 tests=[AWL=-1.756, 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 vjkITT6ahhjP for ; Mon, 2 May 2011 09:18:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 63297E06F8 for ; Mon, 2 May 2011 09:18:21 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p42GIJLH009296 for ; Mon, 2 May 2011 09:18:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304353100; bh=6GUDevEE9l5Yq3apIIiujPYj618=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=lXFjgJYZo0TbXsgtTy2t7uB3TLOZbOR3RJstoxrvN16wXPn4lxFD0lBYhAXv3ZKGC i+g3Fr5RaFLWNBIv6xafw== Received: from pvh1 (pvh1.prod.google.com [10.241.210.193]) by kpbe18.cbf.corp.google.com with ESMTP id p42GII6U025072 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 2 May 2011 09:18:18 -0700 Received: by pvh1 with SMTP id 1so3597719pvh.3 for ; Mon, 02 May 2011 09:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=exX7J6+BWas6ll5kU3yuVwbIwg6TBZ8Mb4lrxA06jUo=; b=bI06bN1unBNrcsRDN2VYpI6YfMdzQzYsywfbaSRIHJqlvfvJ61ifOXKzT/K4r+MixX GuxwRGOZVYW9uAcZrmEg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XDk448Ohvy579Qv1MpZsafZamVzK5f3AL4QL0j3a9fyW157ndXV1guzyEEuHMM8F5C lm7hWqlc8zr/Xwf2kYNw== MIME-Version: 1.0 Received: by 10.142.224.13 with SMTP id w13mr212107wfg.39.1304353097812; Mon, 02 May 2011 09:18:17 -0700 (PDT) Received: by 10.142.245.14 with HTTP; Mon, 2 May 2011 09:18:17 -0700 (PDT) In-Reply-To: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> Date: Tue, 3 May 2011 01:18:17 +0900 Message-ID: From: Erik Kline To: Lorenzo Colitti Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 16:18:33 -0000 Can we take this two separate steps: [1] Move it to historic in this doc. [2] Propose a phase-out plan, timeline, and other mechanics in a 2nd follow-on doc (which will obviously refer to #1). Reasonable? On 3 May 2011 01:13, Lorenzo Colitti wrote: > On Sun, May 1, 2011 at 3:06 PM, james woodyatt wrote: >> >> Having failed to persuade anyone that a phaseout plan is necessary for >> this draft to be meaningful, I have refined my position on this point. > > I like the idea of a phase-out plan, but what form would it take? Requesting > that IANA declare 2002::/16 to be reserved? Saying that implementations > should not use 2002::/16 to autoconfigure addresses? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From jhw@apple.com Mon May 2 09:57: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 13A1FE06B1 for ; Mon, 2 May 2011 09:57:44 -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 20IeVPdJz0O5 for ; Mon, 2 May 2011 09:57:43 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 68668E0659 for ; Mon, 2 May 2011 09:57:43 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LKK005TCV2167B1@mail-out.apple.com> for v6ops@ietf.org; Mon, 02 May 2011 09:57:43 -0700 (PDT) X-AuditID: 11807137-b7cd4ae000003108-d0-4dbee28613dc 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 relay16.apple.com (Apple SCV relay) with SMTP id 7E.BF.12552.782EEBD4; Mon, 02 May 2011 09:57:43 -0700 (PDT) Received: from [17.193.15.152] (unknown [17.193.15.152]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LKK00I6UV46L120@cardamom.apple.com> for v6ops@ietf.org; Mon, 02 May 2011 09:57:42 -0700 (PDT) From: james woodyatt In-reply-to: Date: Mon, 02 May 2011 09:57:41 -0700 Message-id: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1222) X-Brightmail-Tracker: AAAAAA== Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 16:57:44 -0000 On May 2, 2011, at 9:13 AM, Lorenzo Colitti wrote: > On Sun, May 1, 2011 at 3:06 PM, james woodyatt wrote: >> Having failed to persuade anyone that a phaseout plan is necessary for this draft to be meaningful, I have refined my position on this point. > > I like the idea of a phase-out plan, but what form would it take? Requesting that IANA declare 2002::/16 to be reserved? Saying that implementations should not use 2002::/16 to autoconfigure addresses? As an outline, I would like to see at least *all* of the following requirements in any standards action for this purpose: + A specific date, soon, e.g. this November, on which operators are REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes in their respective default free zones. I can imagine a tweak that directs ICANN (or something like that) to operate the distinguished autonomous system for those prefixes that returns ICMP and ICMPv6 errors for packets sent into the default free zones with those destinations. + An amendment to IPv6 node requirements to say that hosts MUST NOT use stateless autoconfiguration to self-assign interface addresses with 2002::/16 prefixes, i.e. when processing router advertisements with prefix information options that have A=1 and contain prefixes in the 2002::/16 range, the A bit MUST be ignored and the prefix treated as if A=0. + A revision to to specify that routers MUST NOT advertise prefixes in the 2002::/16 range, with A=1, even when delegated with DHCPv6 prefix delegation. + A revision to to specify that routers MUST NOT forward any packets with IPv4 protocol 41 with an inner IPv6 header containing a 2002::/16 address to or from the WAN interface. Replies with ICMP error RECOMMENDED. That seems like a good start to me. Can you think of any additional requirements? -- james woodyatt member of technical staff, core os networking From Wesley.E.George@sprint.com Mon May 2 10:07: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 4D496E074A for ; Mon, 2 May 2011 10:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[AWL=1.266, 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 5C2EdLcStTfO for ; Mon, 2 May 2011 10:07:29 -0700 (PDT) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8483AE0747 for ; Mon, 2 May 2011 10:07:29 -0700 (PDT) Received: from mail8-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.8; Mon, 2 May 2011 17:07:28 +0000 Received: from mail8-tx2 (localhost.localdomain [127.0.0.1]) by mail8-tx2-R.bigfish.com (Postfix) with ESMTP id 2AA4C17F01B9; Mon, 2 May 2011 17:07:28 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371O542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI Received: from mail8-tx2 (localhost.localdomain [127.0.0.1]) by mail8-tx2 (MessageSwitch) id 1304356021470187_6823; Mon, 2 May 2011 17:07:01 +0000 (UTC) Received: from TX2EHSMHS049.bigfish.com (unknown [10.9.14.244]) by mail8-tx2.bigfish.com (Postfix) with ESMTP id 634A31740275; Mon, 2 May 2011 17:06:37 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by TX2EHSMHS049.bigfish.com (10.9.99.149) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 2 May 2011 17:06:36 +0000 Received: from PDAWEH02.ad.sprint.com (PDAWEH02.corp.sprint.com [144.226.111.42]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p42H6YEZ007057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 May 2011 12:06:36 -0500 Received: from PDAWM12B.ad.sprint.com ([fe80::64c8:fd69:1029:79b0]) by PDAWEH02.ad.sprint.com ([2002:90e2:6f2a::90e2:6f2a]) with mapi id 14.01.0270.001; Mon, 2 May 2011 12:06:35 -0500 From: "George, Wes E [NTK]" To: Dmitry Anipko , Fred Baker , "v6ops@ietf.org WG" Thread-Topic: [v6ops] 6to4-historic summary point: 2. "protocol 41" Thread-Index: AcwFGMeQjvcrs/EYS1GzUsA5Hzd3kwCfedzvAFSTs5A= Date: Mon, 2 May 2011 17:06:34 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D2DD@PDAWM12B.ad.sprint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.53] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0215_01CC08C9.C2DEC5D0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 17:07:30 -0000 ------=_NextPart_000_0215_01CC08C9.C2DEC5D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Dmitry Anipko Sent: Saturday, April 30, 2011 8:37 PM To: Fred Baker; v6ops@ietf.org WG Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41" >>Does the working group agree with the summarization of the concern? I agree with the summarization of the concern. >>Do we agree with the proposed (in)action? I disagree with the proposed action. I suggest to either remove the problem from the list of 6to4 problems, since as currently worded this is not a 6to4 problem, but protocol 41 problem, and this draft, in its current form, doesn't seem to have any intentions to deal with general protocol 41, or to add text illustrating why this problem is 6to4 specific and other uses of protocol 41 on the Internet do not have this problem or how that problem is/can be mitigated for them. _________ [WEG] I think you're conflating two issues similar to previous objector, who said basically, "if we deprecate 6to4 because it doesn't work, we have a lot of other tunneling and IPv6 transition protocols to deprecate too" and the line of logic that followed that assertion was that we therefore shouldn't deprecate any of them. IMO, there's nothing wrong with the assertion that 6to4 should be deprecated because of problems with protocol 41. The notion that we should either ignore this issue because it's not specific to 6to4 or dramatically widen the scope of what is a fairly targeted document about 6to4 to now include other implementations that use protocol 41 seems very odd to me. We want this draft to be as complete as possible when documenting our rationale for saying, "well, that's not gone well at all..." rather than picking and choosing the brokenness to only reflect the few things that are 100% specific to the implementation that we're deprecating. You're right that protocol 41 problems are not all specific to 6to4. That doesn't make 6to4 any less broken when considering the effects of protocol 41 filtering and other problems. Folks on this list have said more than once that it might make sense for there to be a companion document for Teredo, using some of the same justifications. If there are other implementations using Protocol 41 that may be similarly affected, it'd be worth evaluating their usefulness vs problems and pervasiveness of implementation as well. But we have to start somewhere, and we're unlikely to gain consensus on deprecating all of them at once, so we're breaking it into pieces. Wes George ------=_NextPart_000_0215_01CC08C9.C2DEC5D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMjE3 MDYzM1owIwYJKoZIhvcNAQkEMRYEFPfC4s1kVto3cBxLqnaeBNJSpsUiMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgKlt2jVPCnjg1aPQbRrgj9UQuYxsQ3E/tJ9oHLjuGLSdPp2DwilXveonTi9axzGDvax5 RaFOocYY+nGazV4Uaht8t2Av1DpOU/EURUDGwzJFfkdW0ml1rGoHmoistgPuPtkXRHg2DvEMd3jQ 6UzMXg4e6koKc49uhgusIRruVGiBAAAAAAAA ------=_NextPart_000_0215_01CC08C9.C2DEC5D0-- From fred@cisco.com Mon May 2 10:19: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 12579E0776 for ; Mon, 2 May 2011 10:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.279 X-Spam-Level: X-Spam-Status: No, score=-110.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 SHdf8BWjoa3i for ; Mon, 2 May 2011 10:19:56 -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 30616E06B1 for ; Mon, 2 May 2011 10:19:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1866; q=dns/txt; s=iport; t=1304356796; x=1305566396; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=M5bNmpa0SfYIFT9Amzt8W8AkkdEoNX51euB8HJSpGWI=; b=Bj9UQHoP94CnWbQiUOBMGex+kpOaRUkEGtedVWakkbAjmvGC9bqQRPY9 hX78St6JCt5qApQtS7uxc4/VMOzskE0SsCOk7ErwvtdjMLqCh+N8bR3if De0yRcHCXDO7yMfgqivd5vLdEfYDZ1fj7Q6V0fBQOq+ndlRF3yZtBiQag U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGfmvk2rRDoJ/2dsb2JhbACmHneIcZwonA6GAASGDohrhBmKKQ X-IronPort-AV: E=Sophos;i="4.64,303,1301875200"; d="scan'208";a="440219974" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 02 May 2011 17:19:56 +0000 Received: from Freds-Computer.local (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p42HJoRK017825; Mon, 2 May 2011 17:19:55 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 02 May 2011 10:19:55 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 02 May 2011 10:19:55 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 2 May 2011 10:19:38 -0700 Message-Id: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> To: Erik Kline , james woodyatt X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 17:19:57 -0000 On May 2, 2011, at 9:18 AM, Erik Kline wrote: > Can we take this two separate steps: >=20 > [1] Move it to historic in this doc. >=20 > [2] Propose a phase-out plan, timeline, and other mechanics in a > 2nd follow-on doc (which will obviously refer to #1). >=20 > Reasonable? I think it is very reasonable. I personally question the wisdom of a = documented phase-out plan, for the reasons Brian has mentioned. But in = any event, I would like to decouple that question from the more basic = question addressed in this document, which is the fundamental trajectory = of the technology. Since there are demonstrated issues with 6to4, and = the industry is moving out of the experimental phase it was designed for = into a full deployment phase, this document says "let's consider 6to4 an = evolutionary dead end". That statement we seem to generally agree with, = modulo Keith and Jordi.=20 I would encourage James, if he wants to take that route, to propose a = phase-out plan in a separate document. > On 3 May 2011 01:13, Lorenzo Colitti wrote: >> On Sun, May 1, 2011 at 3:06 PM, james woodyatt wrote: >>>=20 >>> Having failed to persuade anyone that a phaseout plan is necessary = for >>> this draft to be meaningful, I have refined my position on this = point. >>=20 >> I like the idea of a phase-out plan, but what form would it take? = Requesting >> that IANA declare 2002::/16 to be reserved? Saying that = implementations >> should not use 2002::/16 to autoconfigure addresses? >> _______________________________________________ >> 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 fred@cisco.com Mon May 2 10:25: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 4B562E06FE for ; Mon, 2 May 2011 10:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.572 X-Spam-Level: X-Spam-Status: No, score=-110.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 riDyFcUenB66 for ; Mon, 2 May 2011 10:25:57 -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 D2EEBE06C0 for ; Mon, 2 May 2011 10:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1110; q=dns/txt; s=iport; t=1304357157; x=1305566757; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=8aO3JeqTR7C5T1oG68JfHXQ47cjZFAn/JFPsRJ33jGM=; b=P7C7Nes670fn/llEWqcpfV48TnOQQoHOfE3VuPVWT9djAR+/quaphKED VywUEkmsYfsDh9XZdRhRihwGnwjPQDiV+AA+Syjv3G7j1dRi/kmfDgmId 8Grh+lBbOvfYcjFj0ptHpVbG4ZXCGp9t7uw0zQzykFeHrrNj3y6qekILZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMPovk2rRDoI/2dsb2JhbACmHneIcZw8jzUBjFyGAASGDohrhBmKKQ X-IronPort-AV: E=Sophos;i="4.64,303,1301875200"; d="scan'208";a="440223692" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 02 May 2011 17:25:57 +0000 Received: from Freds-Computer.local (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p42HPpK7019878; Mon, 2 May 2011 17:25:57 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 02 May 2011 10:25:57 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 02 May 2011 10:25:57 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <850CD890-511A-4D48-AC95-A6314060F91E@cisco.com> Date: Mon, 2 May 2011 10:25:38 -0700 Message-Id: References: <850CD890-511A-4D48-AC95-A6314060F91E@cisco.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ron Bonica Subject: Re: [v6ops] Regarding draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 17:25:58 -0000 On May 1, 2011, at 11:00 AM, Fred Baker wrote: > Today is the last day of the announced WGLC on this draft. Ole posted = an updated version last Wednesday and a list of issues. As near as I can = tell, the WG feels that his proposed resolutions for issues 2, 3, 7, 8, = and 10 are correct, and the other issues have proposed text or at least = concepts for that text proposed. I have asked Ole to post a new version = incorporating those changes. We will continue this WGLC through 8 May to = let people comment on the revised version, which I expect will reach = rough consensus. We have at least two people that would really like to = NOT see 6to4 declared historic, Keith Moore and Jordi Palet Martinez, = and I do not expect them to change their views. Ole has posted a new version. The diffs resulting from the WGLC so far = may be found at http://tinyurl.com/3c2f2cc. He did not include text = phaseout plan nor the descriptive 'clarification' point, as we don't = appear to have consensus supporting them at this point. Please read the current text before continuing to comment. From narten@us.ibm.com Mon May 2 10:46: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 86CE8E0766 for ; Mon, 2 May 2011 10:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.12 X-Spam-Level: X-Spam-Status: No, score=-106.12 tagged_above=-999 required=5 tests=[AWL=0.479, 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 EBcDeIRWyxaE for ; Mon, 2 May 2011 10:46:45 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id BA09DE0722 for ; Mon, 2 May 2011 10:46:45 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p42HUTG3000492 for ; Mon, 2 May 2011 11:30:29 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p42HkCLn062366 for ; Mon, 2 May 2011 11:46:14 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p42Hk321016076 for ; Mon, 2 May 2011 11:46:04 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-193-26.mts.ibm.com [9.65.193.26]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p42Hk2ge015994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 May 2011 11:46:03 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p42Hk1dc022646; Mon, 2 May 2011 13:46:01 -0400 Message-Id: <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> To: james woodyatt In-reply-to: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> Comments: In-reply-to james woodyatt message dated "Mon, 02 May 2011 09:57:41 -0700." Date: Mon, 02 May 2011 13:46:01 -0400 From: Thomas Narten Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 17:46:46 -0000 > + A specific date, soon, e.g. this November, on which operators are > REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes > in their respective default free zones. Please save your breath. This sort of a mandate is way out-of-scope for the IETF. Really! Operators will do what they want. We have to *persuade* them to do things via compelling arguments. The IETF is not, and has never been, the protocol police. > + An amendment to IPv6 node requirements to say that hosts MUST NOT > use stateless autoconfiguration to self-assign interface addresses > with 2002::/16 prefixes, i.e. when processing router advertisements > with prefix information options that have A=1 and contain prefixes > in the 2002::/16 range, the A bit MUST be ignored and the prefix > treated as if A=0. This would take years before it actually resulted in a meaningful fraction of nodes supporting this behavior. Waste of time. And, I'd be opposed to special-casing that prefix in generic IPv6 host/node, especially since they today do not have to do *anything* special with that prefix to start with. > + A revision to > > to specify that routers MUST NOT forward any packets with IPv4 > protocol 41 with an inner IPv6 header containing a 2002::/16 > address to or from the WAN interface. Replies with ICMP error > RECOMMENDED. So, every router will now be required to inspect the inner contents of tunneled packets they are forwarding in order to find these rogue packets? Will never happen. Way too big of a performance hit. Good example of a "wishful thinking" requirement. Me thinks you are being way too draconian and unrealistic in what is achievable in practice. Thomas From Wesley.E.George@sprint.com Mon May 2 11:40: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 4E128E0766 for ; Mon, 2 May 2011 11:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.408 X-Spam-Level: X-Spam-Status: No, score=-5.408 tagged_above=-999 required=5 tests=[AWL=1.191, 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 zs8ghbJYW+he for ; Mon, 2 May 2011 11:40:25 -0700 (PDT) Received: from VA3EHSOBE009.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 68C89E074E for ; Mon, 2 May 2011 11:40:25 -0700 (PDT) Received: from mail181-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.8; Mon, 2 May 2011 18:40:24 +0000 Received: from mail181-va3 (localhost.localdomain [127.0.0.1]) by mail181-va3-R.bigfish.com (Postfix) with ESMTP id E433E17F0289; Mon, 2 May 2011 18:40:22 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz14e0M9371O168aJ1418Mzz1202hzz1033IL8275eh8275dha1495iz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI Received: from mail181-va3 (localhost.localdomain [127.0.0.1]) by mail181-va3 (MessageSwitch) id 1304361615777862_15655; Mon, 2 May 2011 18:40:15 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.251]) by mail181-va3.bigfish.com (Postfix) with ESMTP id A20A612000C8; Mon, 2 May 2011 18:38:39 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 2 May 2011 18:38:37 +0000 Received: from PLSWEH03.ad.sprint.com (PLSWEH03.corp.sprint.com [144.226.242.132]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p42IcZan027535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 May 2011 13:38:35 -0500 Received: from PDAWM12B.ad.sprint.com ([fe80::64c8:fd69:1029:79b0]) by PLSWEH03.ad.sprint.com ([fe80::a470:17cb:6a7f:3a52%15]) with mapi id 14.01.0270.001; Mon, 2 May 2011 13:38:35 -0500 From: "George, Wes E [NTK]" To: Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-chown-v6ops-call-to-arms WGLC Thread-Index: AQHMCCm/x47sufNOVkSB09SgYACPoJR5yfIw Date: Mon, 2 May 2011 18:38:34 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D56A@PDAWM12B.ad.sprint.com> References: <5F8FA59F-A660-4EAD-8CFF-1D2BE442B37D@cisco.com> In-Reply-To: <5F8FA59F-A660-4EAD-8CFF-1D2BE442B37D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.53] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0235_01CC08D6.9CE63D60" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-chown-v6ops-call-to-arms WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 18:40:27 -0000 ------=_NextPart_000_0235_01CC08D6.9CE63D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Overall, I think that this document is quite good. My main concern is = that even between now and June, it really should be a living document rather than the static document that an IETF draft that moves = towards RFC becomes.=20 If it is meant to aggregate some of this info for the wider audience = that sometimes sees IETF drafts, I might recommend adding informative references to locations where more info is available and it = is likely to be continually updated, such as ARIN=92s getipv6.info website, RIPE=92s IPv6actnow.org, etc I=92m sure that there = are others, but I think you get the idea. Might also make sense to include a reference to any wiki that ISOC is working on in = preparation for the day as well.=20 For example, = http://getipv6.info/index.php/Customer_problems_that_could_occur has a = good set of common issues and problems that would make a nice companion to section 2. In section 3, you might want to break instrumentation up into two = categories, one for those enabling IPv6 on content sites and another for those who have IPv6-enabled networks, as the instrumentation = may be a good bit different for each, but having both types of data will be very important. Right now, the reference to = "particularly useful if your site is turning on AAAA records..." makes it seem like the operator perspective (what worked, what didn't, who = called and why) is less useful, when in reality that may turn out to be much more useful data in aggregate. I see that you briefly = cover this in 3.6, but that section is pretty light in terms of ideas on how to categorize things, the right questions to be asking, = etc. Think of it in terms of operators needing to prepare their front-line customer service techs for this date - what do they need to = know, what should they ask, track, etc? Overall, I would think that this section would be most valuable if it = proposes a minimum set of data that is important plus additional "nice to have" info, along with some format recommendations = so that eventually people can do more in-depth research and analysis of the data available across many different organizations.=20 One specific nit, sections 2.2 and 2.4: I wonder about referring to specific tunnel brokers, even as examples, = rather than making a more generic reference to something like: http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers (or = another more robust wiki that lists more than 3) in lieu of explanation as to what a tunnel broker is and does. Then in the section on PMTUD (2.4), again there=92s a specific reference = to HE and Sixxs that I=92m not sure adds value compared with saying that =93it=92s good practice for tunnel brokers to set their MTUs = to default to 1280, probably due to=85=94 Thanks Wes George From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Fred Baker Sent: Sunday, May 01, 2011 2:00 PM To: v6ops@ietf.org Cc: v6ops-chairs@tools.ietf.org; Ron Bonica Subject: [v6ops] draft-chown-v6ops-call-to-arms WGLC This is to initiate a two week working group last call of = draft-chown-v6ops-call-to-arms. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc),=A0comment to = the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, = please post your comments to the=A0list. We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and believe it to be of operational utility, that is=A0also an important = comment to make. ------=_NextPart_000_0235_01CC08D6.9CE63D60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMjE4 MzgzM1owIwYJKoZIhvcNAQkEMRYEFMLh8Ir0b/8OBFcq9yVu6uPkHdN0MFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgFQrZ8ZoXgy9N1Xt3wEF+JuPAyp3pNC0cl0qzOQiIevM9oIyvu2CU+qVA0GKlxD6+JKM YjsB2/CaGurFlyB213lKvw+4HF2WSUACwHQnGEp5VIzlizvEk5P5QB9EHWELbn9XmOzgoY2HNuQM 1L3CSFpedn/2eGDqKlJyPo7QNe9gAAAAAAAA ------=_NextPart_000_0235_01CC08D6.9CE63D60-- From jason_livingood@cable.comcast.com Mon May 2 11:50: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 496B4E06F0; Mon, 2 May 2011 11:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.135 X-Spam-Level: X-Spam-Status: No, score=-101.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 W3uwmrE2+Qn5; Mon, 2 May 2011 11:50:01 -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 D1980E0688; Mon, 2 May 2011 11:50:00 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.36566205; Mon, 02 May 2011 12:52:20 -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, 2 May 2011 14:48:33 -0400 From: "Livingood, Jason" To: "Richard L. Barnes" , Dave Crocker Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 Thread-Index: AQHMCNXYOHa2y4GkbUaLX5Den2xD2pR54WUA Date: Mon, 2 May 2011 18:48:32 +0000 Message-ID: In-Reply-To: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [147.191.227.190] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 18:50:02 -0000 In any of the various IPv6 fora (including v6ops at the IETF) "DNS Whitelisting" is how this practice is typically labeled. When writing the draft I felt this could be confusing outside of IPv6 circles and so lengthened it to "IPv6 DNS AAAA Whitelisting" in the title. In any case, "I don't like what it is called" is difficult to act on. ;-) If there are recommendations on alternatives, I'm all ears. Thanks Jason On 5/2/11 10:32 AM, "Richard L. Barnes" wrote: >I disagree that "whitelisting" is a reserved trademark of the anti-abuse >community. It's a general term for a list of things that are granted >something. Likewise with "blacklist" and "deny". Which means it's >perfectly appropriate for this document. > > > > > >On Apr 30, 2011, at 1:32 AM, Dave CROCKER wrote: > >>=20 >> Review: >>=20 >> Title: IPv6 AAAA DNS Whitelisting Implications >> I-D: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 >>=20 >> By: D. Crocker >> Date: 29 April 2011 >>=20 >>=20 >> Summary: >>=20 >> This draft is a discussion of a technique for resolving a dual-stack >>problem between IPv4 and IPv6, through the use of special DNS records. >>=20 >> The document appears to continue a recent use of the term >>'whitelisting' that strongly conflicts with long-standing use of the >>term by the anti-abuse community. >>=20 >> The document needs to do a more careful job of introducing the problem >>it is solving and the explaining the way the 'whitelisting' mechanism >>works. >>=20 >> I also very strongly encourage finding a different term. >>=20 >> d/ >>=20 >>=20 >>> Abstract >>>=20 >>> The objective of this document is to describe what the whitelisting >>> of DNS AAAA resource records is, hereafter referred to as DNS >>=20 >> RRs are whitelisted? Isn't it the addresses and not the records that >>are whitelisted? >>=20 >> Does this mean putting whitelisting records into the DNS or does it >>mean something else? >>=20 >> Comcast's own considerable expertise notwithstanding, has this doc been >>vetted with a range of organizations that actually DO whitelisting? Has >>it been circulated through MAAWG and APWG? Any comments from Spamhaus? >>The Acknowledgements list does not seem to indicate a range of whitelist >>ops folks whose names I know. (But then, I only know a few...) >>=20 >>=20 >>> whitelisting, as well as the implications of this emerging practice >>> and what alternatives may exist. The audience for this document is >>> the Internet community generally, including the IETF and IPv6 >>> implementers. >>=20 >> I suspect that product marketers won't have much interest in this. I >>suspect that the target for this is anti-abuse technical and operations >>staff. >>=20 >>=20 >>> Status of this Memo >>>=20 >>> This Internet-Draft is submitted in full conformance with the >>> provisions of BCP 78 and BCP 79. >>>=20 >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF). Note that other groups may also distribute >>> working documents as Internet-Drafts. The list of current Internet- >>> Drafts is at http://datatracker.ietf.org/drafts/current/. >>>=20 >>> Internet-Drafts are draft documents valid for a maximum of six months >>> and may be updated, replaced, or obsoleted by other documents at any >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>>=20 >>> This Internet-Draft will expire on August 26, 2011. >>>=20 >>> Copyright Notice >>>=20 >>> Copyright (c) 2011 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>>=20 >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> (http://trustee.ietf.org/license-info) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with respect >>> to this document. Code Components extracted from this document must >>> include Simplified BSD License text as described in Section 4.e of >>> the Trust Legal Provisions and are provided without warranty as >>>=20 >>>=20 >>>=20 >>> Livingood Expires August 26, 2011 [Page >>>1] >>>=20 >>> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February >>>2011 >>>=20 >>>=20 >>> described in the Simplified BSD License. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Livingood Expires August 26, 2011 [Page >>>2] >>>=20 >>> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February >>>2011 >>>=20 >>>=20 >>> Table of Contents >>>=20 >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 >>> 2. How DNS Whitelisting Works . . . . . . . . . . . . . . . . . . 6 >>> 2.1. Description of the Operation of DNS Whitelisting . . . . . 7 >>> 3. What Problems Are Implementers Trying To Solve? . . . . . . . 8 >>> 4. Concerns Regarding DNS Whitelisting . . . . . . . . . . . . . 9 >>> 5. Similarities to Other DNS Operations . . . . . . . . . . . . . 12 >>> 5.1. Similarities to Split DNS . . . . . . . . . . . . . . . . 12 >>> 5.2. Similarities to DNS Load Balancing . . . . . . . . . . . . 12 >>> 6. Likely Deployment Scenarios . . . . . . . . . . . . . . . . . 13 >>> 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis . . . . . . 13 >>> 6.2. Deploying DNS Whitelisting Universally . . . . . . . . . . 14 >>> 7. Implications of DNS Whitelisting . . . . . . . . . . . . . . . 15 >>> 7.1. Architectural Implications . . . . . . . . . . . . . . . . 15 >>> 7.2. Public IPv6 Address Reachability Implications . . . . . . 16 >>> 7.3. Operational Implications . . . . . . . . . . . . . . . . . 17 >>> 7.3.1. De-Whitelisting May Occur . . . . . . . . . . . . . . 17 >>> 7.3.2. Authoritative DNS Server Operational Implications . . 17 >>> 7.3.3. DNS Recursive Resolver Server Operational >>> Implications . . . . . . . . . . . . . . . . . . . . . 18 >>> 7.3.4. Monitoring Implications . . . . . . . . . . . . . . . 19 >>> 7.3.5. Implications of Operational Momentum . . . . . . . . . 19 >>> 7.3.6. Troubleshooting Implications . . . . . . . . . . . . . 20 >>> 7.3.7. Additional Implications If Deployed On An Ad Hoc >>> Basis . . . . . . . . . . . . . . . . . . . . . . . . 20 >>> 7.4. Homogeneity May Be Encouraged . . . . . . . . . . . . . . 20 >>> 7.5. Technology Policy Implications . . . . . . . . . . . . . . 21 >>> 7.6. IPv6 Adoption Implications . . . . . . . . . . . . . . . . 22 >>> 8. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 23 >>> 8.1. Implement DNS Whitelisting Universally . . . . . . . . . . 23 >>> 8.2. Implement DNS Whitelisting On An Ad Hoc Basis . . . . . . 23 >>> 8.3. Do Not Implement DNS Whitelisting . . . . . . . . . . . . 23 >>> 8.3.1. Solving Current End User IPv6 Impairments . . . . . . 24 >>> 8.3.2. Gain Experience Using IPv6 Transition Names . . . . . 24 >>> 9. Is DNS Whitelisting a Recommended Practice? . . . . . . . . . 24 >>> 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 >>> 10.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 25 >>> 10.2. Authoritative DNS Response Consistency Considerations . . 26 >>> 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 26 >>> 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 >>> 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 >>> 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 >>> 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 >>> 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 >>> 15.2. Informative References . . . . . . . . . . . . . . . . . . 29 >>> Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 31 >>> Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 32 >>>=20 >>>=20 >>>=20 >>> Livingood Expires August 26, 2011 [Page >>>3] >>>=20 >>> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February >>>2011 >>>=20 >>>=20 >>> Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Livingood Expires August 26, 2011 [Page >>>4] >>>=20 >>> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February >>>2011 >>>=20 >>>=20 >>> 1. Introduction >>>=20 >>> This document describes the emerging practice of whitelisting of DNS >>> AAAA resource records (RRs), which contain IPv6 addresses, hereafter >>> referred to as DNS whitelisting. The document explores the >>> implications of this emerging practice are and what alternatives may >>> exist. >>>=20 >>> The practice of DNS whitelisting appears to have first been used by >>> major web content sites (sometimes described herein as "highly- >>=20 >> Really? Not for email first? >>=20 >>=20 >>> trafficked domains" or "major domains"). These web site operators, >>> or domain operators, observed that when they added AAAA resource >>> records to their authoritative DNS servers in order to support IPv6 >>=20 >> Oh. You mean /IPv6/ whitelisting. >>=20 >>=20 >>> access to their content that a small fraction of end users had slow >>> or otherwise impaired access to a given web site with both AAAA and A >>> resource records. The fraction of users with such impaired access >>> has been estimated to be roughly 0.078% of total Internet users >>> [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6 >>> Brokenness]. Thus, in an example Internet Service Provider (ISP) >>> network of 10 million users, approximately 7,800 of those users may >>> experience such impaired access. >>=20 >> At a minimum, these sorts of statistics need to be normalized across >>IPv6 users/traffic, given how small a percentage that is in total users >>and total traffice. If that's what is meant it should be stated. If it >>isn't, the statistic should be recalculated. >>=20 >>=20 >>> As a result of this impairment affecting end users of a given domain, >>> a few major domains have either implemented DNS whitelisting or are >>> considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations]. >>=20 >> How or why does whitelisting affect slow performance for these folk? >>=20 >>=20 >>> When implemented, DNS whitelisting in practice means that a domain's >>> authoritative DNS will return a AAAA resource record to DNS recursive >>> resolvers [RFC1035] on the whitelist, while returning no AAAA >>> resource records to DNS resolvers which are not on the whitelist. It >>=20 >> Oh. The whitelisting is for resolving a conflict between AAAA and A >>record choices? >>=20 >> Normally, the term 'whitelisting' is used to refer to bypass anti-abuse >>mechanisms. This appears to be for something else and it seems odd to >>call it whitelisting. >>=20 >> Note the more typical use of the term: >>=20 >> >>=20 >> >>=20 >>=20 >>>om.ibm.help.domino.admin.doc/DOC/H_USING_DNS_whitelists_OVER.html> >>=20 >> It appears that some v6 folks have chosen to co-opt a distinctive and >>very well established anti-abuse term for an entirely different purpose. >>=20 >>=20 >>=20 >>> is important to note that these major domains are motivated by a >>> desire to maintain a high-quality user experience for all of their >>> users. By engaging in DNS whitelisting, they are attempting to >>> shield users with impaired access from the symptoms of those >>> impairments. >>>=20 >>> Critics of the practice of DNS whitelisting have articulated several >>> concerns. Among these are that: >>>=20 >>> o DNS whitelisting is a very different behavior from the current >>> practice concerning the publishing of IPv4 address resource >>> records, >>>=20 >>> o that it may create a two-tiered Internet, >>>=20 >>> o that policies concerning whitelisting and de-whitelisting are >>> opaque, >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Livingood Expires August 26, 2011 [Page >>>5] >>>=20 >>> Internet-Draft IPv6 AAAA DNS Whitelisting Implications February >>>2011 >>>=20 >>>=20 >>> o that DNS whitelisting reduces interest in the deployment of IPv6, >>=20 >> Well, it certainly suggests that there is a problem handling v4/v6 in >>dual stack environments cleanly. And it certainly seems that dealing >>with the underlying problem would be better. >>=20 >> Beyond that, this appears to be a hack that is useful but not scalable. >>=20 >>=20 >>>=20 >>> o that new operational and management burdens are created, >>=20 >> well, yeah... >>=20 >>=20 >>> o and that the costs and negative implications of DNS whitelisting >>> outweigh the perceived benefits, compared to fixing underlying >>> impairments. >>>=20 >>> This document explores the reasons and motivations for DNS >>> whitelisting. It also explores the outlined concerns regarding this >>> practice. Readers will hopefully better understand what DNS >>> whitelisting is, why some parties are implementing it, and what >>> criticisms of the practice exist. >>=20 >>=20 >>=20 >> --=20 >>=20 >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> _______________________________________________ >> 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 From jason_livingood@cable.comcast.com Mon May 2 11:56: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 8EF52E069B; Mon, 2 May 2011 11:56:20 -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.299, 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 ImHPwLAX-IY3; Mon, 2 May 2011 11:56:20 -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 E063AE0688; Mon, 2 May 2011 11:56:19 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.36567661; Mon, 02 May 2011 12:58:53 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Mon, 2 May 2011 14:55:06 -0400 From: "Livingood, Jason" To: John Leslie , "Richard L. Barnes" , Dave CROCKER Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 Thread-Index: AQHMCOv6mKPvFhmqvkGMTGM1myPoTpR54w2A Date: Mon, 2 May 2011 18:55:04 +0000 Message-ID: In-Reply-To: <20110502170838.GW10460@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [147.191.227.190] Content-Type: multipart/alternative; boundary="_000_C9E4737824ABDjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , IETF Discussion Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 18:56:20 -0000 --_000_C9E4737824ABDjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As I read it, this says that certain DNS servers will be configured to _not_ return AAAA records to AAAA queries by default. This strikes me as a really-strange transition mechanism. Depends on a number of factors for a content provider. The more traffic a d= omain receives the more likely they are to consider this practice as a tran= sition mechanism from what I have observed. This practice can give a large = domain some level of control in turning on IPv6 access to their content, wh= ereas they would lack this since they would turn it on for everyone when pu= blishing the AAAA RR in the DNS. Once a comfort level and operational stabi= lity is achieved I would expect most domains to move away from the practice= , but that is TBD. Certainly what happens on World IPv6 Day will bear on th= is question in important ways (when AAAA RRs are published without the use = of DNS whitelisting). Color me thoroghly confused. Hopefully that's more over the practice than the document; if you wish to s= ee improvements in the I-D just say so. Thanks Jason --_000_C9E4737824ABDjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
   As I read it, this says that certain DNS servers will be = configured
to _not_ return AAAA records to AAAA queries by default.

   This strikes me as a really-strange transition mechanism.=

Depends on a number of factors for a content provider. The more traffi= c a domain receives the more likely they are to consider this practice as a= transition mechanism from what I have observed. This practice can give a l= arge domain some level of control in turning on IPv6 access to their content, whereas they would lack this s= ince they would turn it on for everyone when publishing the AAAA RR in the = DNS. Once a comfort level and operational stability is achieved I would exp= ect most domains to move away from the practice, but that is TBD. Certainly what happens on World IPv6 Day wi= ll bear on this question in important ways (when AAAA RRs are published wit= hout the use of DNS whitelisting).

   Color me thoroghly confused.

Hopefully that's more over the practice than the document; if you wish= to see improvements in the I-D just say so.

Thanks
Jason


--_000_C9E4737824ABDjasonlivingoodcablecomcastcom_-- From tena@huawei.com Mon May 2 12:03: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 85747E067E; Mon, 2 May 2011 12:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.666, 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 jvGRChAL7oFT; Mon, 2 May 2011 12:03:48 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1A02CE0676; Mon, 2 May 2011 12:03:48 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKL00BY00YB3I@usaga02-in.huawei.com>; Mon, 02 May 2011 12:03:47 -0700 (PDT) Received: from TingZousc1 ([10.193.34.188]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKL000BV0Y9YG@usaga02-in.huawei.com>; Mon, 02 May 2011 12:03:47 -0700 (PDT) Date: Mon, 02 May 2011 12:03:52 -0700 From: Tina Tsou In-reply-to: To: "'Livingood, Jason'" , 'John Leslie' , "'Richard L. Barnes'" , 'Dave CROCKER' Message-id: <01ab01cc08fb$ae153260$0a3f9720$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_7wvv30bcc7hio7xDtWcoWQ)" Content-language: en-us Thread-index: AQHMCOv6mKPvFhmqvkGMTGM1myPoTpR54w2AgAAB12A= References: <20110502170838.GW10460@verdi> Cc: v6ops@ietf.org, 'IETF Discussion' Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 19:03:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_7wvv30bcc7hio7xDtWcoWQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Jason, Perhaps an experience for preparing for World IPv6 Day could be added as appendix. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Livingood, Jason Sent: Monday, May 02, 2011 11:55 AM To: John Leslie; Richard L. Barnes; Dave CROCKER Cc: v6ops@ietf.org; IETF Discussion Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 As I read it, this says that certain DNS servers will be configured to _not_ return AAAA records to AAAA queries by default. This strikes me as a really-strange transition mechanism. Depends on a number of factors for a content provider. The more traffic a domain receives the more likely they are to consider this practice as a transition mechanism from what I have observed. This practice can give a large domain some level of control in turning on IPv6 access to their content, whereas they would lack this since they would turn it on for everyone when publishing the AAAA RR in the DNS. Once a comfort level and operational stability is achieved I would expect most domains to move away from the practice, but that is TBD. Certainly what happens on World IPv6 Day will bear on this question in important ways (when AAAA RRs are published without the use of DNS whitelisting). Color me thoroghly confused. Hopefully that's more over the practice than the document; if you wish to see improvements in the I-D just say so. Thanks Jason --Boundary_(ID_7wvv30bcc7hio7xDtWcoWQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Jason,

Perhaps an experience for preparing for World IPv6 Day could be added as appendix.

 

 

style='font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-font-family:"Times New Roman";color:#1F497D;mso-no-proof:yes'>We keep our promises with one another – no matter what!

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Livingood, Jason
Sent: Monday, May 02, 2011 11:55 AM
To: John Leslie; Richard L. Barnes; Dave CROCKER
Cc: v6ops@ietf.org; IETF Discussion
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

 

   As I read it, this says that certain DNS servers will be configured

to _not_ return AAAA records to AAAA queries by default.

 

   This strikes me as a really-strange transition mechanism.

 

span style='font-family:"Calibri","sans-serif";mso-fareast-font-family:"Times New Roman";color:black'>Depends on a number of factors for a content provider. The more traffic a domain receives the more likely they are to consider this practice as a transition mechanism from what I have observed. This practice can give a large domain some level of control in turning on IPv6 access to their content, whereas they would lack this since they would turn it on for everyone when publishing the AAAA RR in the DNS. Once a comfort level and operational stability is achieved I would expect most domains to move away from the practice, but that is TBD. Certainly what happens on World IPv6 Day will bear on this question in important ways (when AAAA RRs are published without the use of DNS whitelisting).

 

   Color me thoroghly confused.

 

Hopefully that's more over the practice than the document; if you wish to see improvements in the I-D just say so.

 

Thanks

Jason

 

 

--Boundary_(ID_7wvv30bcc7hio7xDtWcoWQ)-- From brian.e.carpenter@gmail.com Mon May 2 14:33: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 649F6E06EE for ; Mon, 2 May 2011 14:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.441 X-Spam-Level: X-Spam-Status: No, score=-103.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 Wk8B9tIG+52F for ; Mon, 2 May 2011 14:33:54 -0700 (PDT) Received: from mail-px0-f170.google.com (mail-px0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4E4E069F for ; Mon, 2 May 2011 14:33:51 -0700 (PDT) Received: by pxi19 with SMTP id 19so3251839pxi.15 for ; Mon, 02 May 2011 14:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OrFL2Eyg9/E4rGqA3PYkCGHunR3UWU24Y8l3FBZRRCo=; b=srepD+gs6/AcvwbKZvkim0+C6eLHFiDz060/k1gJYiRRGeQwK41uFkH0As0LhgXCoj fkCi//h9LAhZAET+XTrfHUaYaBHNLOqvgB4xwScfRigl4rAN5qMpFxB64QFyhiifWllr /u6HjfuLh7CYSV+YqA4kpIwv5WdQbIz3xhmao= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=YKHd/6nFqXPAbsP6ROBhNdFh3sQUOcIqY/iYa41Z6BrUD5Qsw29dOiU2FY3VXDNRpk +PCWQC9V/SkX9ChO2u0qz7hby7CWZ73QIxnx5AcbxyeE8mHHGO1QMo+L1gWXfknJs6Fr GaYi/UL9ZfyIv07mjS76QEiwsckOB8ShyHFdE= Received: by 10.142.135.4 with SMTP id i4mr3435881wfd.99.1304372030752; Mon, 02 May 2011 14:33:50 -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 y5sm4045802pbq.57.2011.05.02.14.33.45 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 14:33:49 -0700 (PDT) Message-ID: <4DBF2336.8040502@gmail.com> Date: Tue, 03 May 2011 09:33:42 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten , IPv6 Operations References: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> In-Reply-To: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jarno Rajahalme Subject: Re: [v6ops] 6MAN WG Last Call: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 21:33:55 -0000 On 2011-04-06 05:40, Thomas Narten wrote: > Here are my detailed comments on the document. I did chat with Brian > directly in Prague about these points as well. Overall, I support this > document. But I think the wording in places needs another round of > revision. > > A flow is a sequence of packets sent from a particular source to a > particular unicast, anycast, or multicast destination that a node > desires to label as a flow. A flow could consist of all packets in a > > This is a circular definition. Somewhat intentionally: a flow is whatever the source chooses to label as a flow. We'll take Bob's reply as cancelling your comment out, except for a small clarification in the text. > I think it would be useful to give two > definitions, something like the following: > > A Flow is a sequence of packets originating from a particular > application that should be treated "the same" by the network as > they are forwarded along to their ultimate destination. Packets > within a flow should not be reordered, should not be given > dissimilar QOS treatment, etc. What constitutes a Flow can only be > defined by the application itself. > > At the network level, routers need to be able to identify packets > belonging to the same Flow in order to process them > consistently. At the same time, it may be beneficial to process > packets between the same src/destination pairs (but from different > application flows) differently, e.g., to support ECMP or other > types of load splitting. > > Then: > > Traditionally, flow classifiers have been based on the 5-tuple of the > source and destination addresses, ports, and the transport > protocol > > add "flow classifiers at the network layer" Well, using the transport information makes it a layer violation. Do we really want to open that discussion? > > The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a > node to label packets of a flow. A Flow Label of zero is used to > indicate packets not part of any flow. Packet classifiers can use > > reword to say "that have not been labeled" (Packets will almost always > be part of some Flow). OK > > specification. However, any node that sets flow label values > according to a stateful scheme MUST ensure that packets conform to > Section 3 of the present specification if they are sent outside the > network domain using the stateful scheme. > > The above wording regarding "sent outside the network domain" is > problematic. It hints that maybe you can do things with the Flow Label > within a domain so long as you don't send such packets outside the > domain. We shouldn't even hint that that is acceptable. I'd suggest > removing all references to the "stateful" flow label scheme to one > section. And that section could be very short. We agree that this all belongs together in one short paragraph (see below). But we don't agree to remove the "MUST ensure...". We believe this is a mandatory constraint on all hypothetical stateful schemes. > > 1. Implementers are advised that forwarding nodes, especially those > acting as domain border devices, might nevertheless be configured > to change the flow label value in packets. This is undetectable, > unless some future version of IPsec authentication [RFC4302] > protects the flow label value. > > Remove this. Again, the Flow Label is not allowed to be modified > accept when zero. That is all that needs to be said. We've been assured several times that firewalls will do this. However, we think this belongs in the security considerations. The phrase about IPsec also needed rephrasing - as you pointed out in Prague, there is no likelihood of a future version of IPsec authentication. > > if the packet will leave their domain. If it is known to a > border router that flow labels originated within the domain are > not uniformly distributed, it will need to set outgoing flow > labels in the same manner as described for forwarding nodes in > Section 3. > > Remove this. It agains suggests border routers will be resetting Flow > Label values. In fact we took the whole paragraph out, but retained some of it in the rationale document in a different form. We certainly don't want to enourage this. > > o Implementers should be aware that the flow label is an unprotected > field that could have been accidentally or intentionally changed > en route. Implementations MUST take appropriate steps to protect > themselves from being vulnerable to denial of service and other > types of attack that could result (see Section 6.1). > > Can we just move this advice to the Security Considerations section? > IMO, we are giving it too much weight by having it in the main text. OK > > o Forwarding nodes such as routers and load balancers MUST NOT > depend only on Flow Label values being uniformly distributed. In > any usage such as a hash key for load distribution, the Flow Label > bits MUST be combined at least with bits from other sources within > the packet, so as to produce a constant hash value for each flow > and a suitable distribution of hash values across flows. > > > Can't we just come out and say that routers should: > > 1) use the src/dest/flow/port numbers? this is the most prefered. > > 2) if you can't use the port numbers, hash on the 3 tuple. > > 3) you could also say hash on teh src/dest alone as a last resort, but > why the Flow Label RFC would suggest that isn't immediately obvious to > me. :-) Indeed. We added a succinct version of the above (referring to the 5-tuple). > > The use of the Flow Label field does not necessarily signal any > requirement on packet reordering. Especially, the zero label does > not imply that significant reordering is acceptable. > > The first sentence above isn't right. One SHOULD NOT reorder packets > from the same flow. Period. Agreed, rewritten. > > An IPv6 node that does not set the flow label to a non-zero value, or > make use of it in any way, MUST ignore it when receiving or > forwarding a packet. > > I don't understand why this wording is in here. For the stateless > case, nodes should simply ignore the received Flow Label value. We > should probably just say that. We concluded that the sentence is a no-op and deleted it. > > It is desirable that flow label values should be uniformly > distributed to assist load distribution. It is therefore RECOMMENDED > that source hosts support the flow label by setting the flow label > field for all packets of a given flow to the same uniformly > distributed pseudo-random value. Both stateful and stateless methods > of assigning a pseudo-random value could be used, but it is outside > the scope of this specification to mandate an algorithm. In a > stateless mechanism, the algorithm SHOULD ensure that the resulting > flow label values are unique with high probability. > > I think we need to specify some recommended algorithms. They can be > SHOULDs (rather than MUST), but saying nothing leaves things too > unclear. In particular, if we think just doing a simple hash based on > the port numbers (or something) is good enough, we should recommend > that. We're reluctant to use a normative SHOULD in fact - in the end it's an implementation choice - but yes, we should give clear suggestions - see new text. > > Also, this document should not be requiring (or even use SHOULD) to > say pseudo randomness is necessary. This document has not made the > case for that. We need to be clearer that *variability* of the values is necessary. We've added unguessability as a requirement, which explains why sequential flow values are a bad idea. There are quite a lot of resulting text changes. In fact tidying this up (here and in the rationale document) led us to look into the formal definition, both in statistics texts and at: http://en.wikipedia.org/wiki/Discrete_uniform_distribution > > An OPTIONAL algorithm for generating such a pseudo-random value is > described in [I-D.gont-6man-flowlabel-security]. > > [[ NOTE TO RFC EDITOR: The preceding sentence should be deleted, and > the reference should be changed to Informative, if the cited draft is > not on the standards track at the time of publication. ]] > > I'd prefer that this document provide a suggested algorithm. The reference is gone anyway because that draft isn't moving. > > A source node which does not otherwise set the flow label MUST set > its value to zero. > > Better: just say that the default value should be zero, unless set > explicitely. Er, isn't that exactly what the sentence says? > > A node that forwards a flow whose flow label value in arriving > packets is zero MAY set the flow label value. In that case, it is > > s/MAY set/MAY change/ OK > A node that sets the flow label MAY also take part in a flow state > establishment method that results in assigning specific treatments to > specific flows, possibly including signaling. Any such method MUST > NOT disturb nodes taking part in the stateless model just described. > Further details are not discussed in this document. > > I don't understand what does this is really intended to mean. IMO, > just say the first sentence, and then say the details of stateful are > out of scope for this document. This is where we want to relocate the "MUST ensure..." sentence mentioned above. It means that stateful mechanisms mustn't mess up the stateless model, and we don't care and don't say how they achieve that. > > would cause a stateful mechanism to behave incorrectly. For this > reason, stateless mechanisms should not use the flow label alone to > control load distribution, and stateful mechanisms should include > > s/stateless mechanisms/stateless classifiers/ OK Brian, for the authors From brian.e.carpenter@gmail.com Mon May 2 14:35: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 D5CBCE07A6 for ; Mon, 2 May 2011 14:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.458 X-Spam-Level: X-Spam-Status: No, score=-103.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 91ain865duxk for ; Mon, 2 May 2011 14:35:26 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6305E06EE for ; Mon, 2 May 2011 14:35:24 -0700 (PDT) Received: by pwi5 with SMTP id 5so3585256pwi.31 for ; Mon, 02 May 2011 14:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6BU0HW8jYNQAUnFL7k38RucoRnasrGUqHE8zV5rh490=; b=SfQJpE17PNsVJ+tysxeXYmCGh5yaEuGJRUmNxCipuaOpV9r8zAo1rrhCSB6s4jI0Q1 SSD5bROnzGwxp8B9isO49GQ3fqY9E3jrKYSCdDgZpDjtJ5ikoFjl7fmhk+//8VRWo81I p+zzoveUy5HkrAYj3ZwjmHc7f+gcIaCFTwCz4= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=tJnjlTEvwJr26Hno74mOSd1lGUQpoBAKq56xT9qVwbGvnAQybMBtePOlkBzuZeH1LP pIs1v3z4srmDq491TNsUhBzrgLKZISjoa7YJyqdmab2YheYMMnr7zWmx5VNiboVCLP32 k6PPNLJQzfhed7JL7c8qz1ie9wXa+K4O6HLsk= Received: by 10.68.50.72 with SMTP id a8mr7501455pbo.364.1304372124418; Mon, 02 May 2011 14:35:24 -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 u1sm4048294pbm.41.2011.05.02.14.35.22 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 14:35:23 -0700 (PDT) Message-ID: <4DBF2399.3090708@gmail.com> Date: Tue, 03 May 2011 09:35:21 +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: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> <4DBF2336.8040502@gmail.com> In-Reply-To: <4DBF2336.8040502@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] Sorry, please ignore [Re: 6MAN WG Last Call: ] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 21:35:26 -0000 AARGH, I sent that to the wrong list, sorry sorry sorry. Regards Brian Carpenter From wbeebee@cisco.com Mon May 2 14: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 70673E07CB for ; Mon, 2 May 2011 14:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mw6sj4CjRLFG for ; Mon, 2 May 2011 14:35:57 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id BC407E07CA for ; Mon, 2 May 2011 14:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=492; q=dns/txt; s=iport; t=1304372156; x=1305581756; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=lkxnxPXmAWzIEPestcHGoAZpCv1DHw6DmmY54lZUl4Y=; b=Bvh7Mc7NfEKRzZqc5ZzNbQQlB+XlLw+ZuSDTmWVZrKaXX2+xwmgmiwq9 5TupQlIYjq+3SSh6P7utuW/DXxa4xTESzauzZfs7zvEg/c6GksXR4/H5C adoEvkHdvXP3RVcOS2Oxt4smmebp5LUopeLZulX7P9xkTjMtZ9k8n9Z0o Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIFAOQiv02tJV2d/2dsb2JhbACmCwJ3iHGeOpwvhgAEjnmEIoY2g2Y X-IronPort-AV: E=Sophos;i="4.64,305,1301875200"; d="scan'208";a="231679589" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 02 May 2011 21:35:55 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p42LZt8I030327; Mon, 2 May 2011 21:35:55 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 May 2011 16:35:54 -0500 Received: from 161.44.183.79 ([161.44.183.79]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Mon, 2 May 2011 21:35:54 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 02 May 2011 17:35:53 -0400 From: Wes Beebee To: Thomas Narten , james woodyatt Message-ID: Thread-Topic: [v6ops] 6to4-historic summary point: 4. "Phase out plan" Thread-Index: AcwJEOmWl+ofOlca3UKckPJbLoyElQ== In-Reply-To: <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 May 2011 21:35:54.0820 (UTC) FILETIME=[EAAC7840:01CC0910] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 21:35:57 -0000 > So, every router will now be required to inspect the inner contents of > tunneled packets they are forwarding in order to find these rogue > packets? Will never happen. Way too big of a performance hit. Good > example of a "wishful thinking" requirement. And they already implement a full stateful firewall capable of supporting a multitude of ALG's that inspect every packet already. This requirement is not really that much of a performance hog compared to a firewall. - Wes From narten@us.ibm.com Mon May 2 14:42: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 5722CE07A6 for ; Mon, 2 May 2011 14:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.14 X-Spam-Level: X-Spam-Status: No, score=-106.14 tagged_above=-999 required=5 tests=[AWL=0.459, 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 i1FPPuKP1uKs for ; Mon, 2 May 2011 14:42:53 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8A3E072D for ; Mon, 2 May 2011 14:42:53 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p42LVwqD031889 for ; Mon, 2 May 2011 17:31:59 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p42Lgqhv079518 for ; Mon, 2 May 2011 17:42:52 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p42LgpAL018571 for ; Mon, 2 May 2011 17:42:52 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-193-26.mts.ibm.com [9.65.193.26]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p42LgoIO018539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 May 2011 17:42:51 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p42Lgn96024618; Mon, 2 May 2011 17:42:49 -0400 Message-Id: <201105022142.p42Lgn96024618@cichlid.raleigh.ibm.com> To: Wes Beebee In-reply-to: References: Comments: In-reply-to Wes Beebee message dated "Mon, 02 May 2011 17:35:53 -0400." Date: Mon, 02 May 2011 17:42:49 -0400 From: Thomas Narten Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 21:42:54 -0000 Wes Beebee writes: > > So, every router will now be required to inspect the inner contents of > > tunneled packets they are forwarding in order to find these rogue > > packets? Will never happen. Way too big of a performance hit. Good > > example of a "wishful thinking" requirement. > And they already implement a full stateful firewall capable of supporting a > multitude of ALG's that inspect every packet already. This requirement is > not really that much of a performance hog compared to a firewall. Huh? Every single router, including those in the DFZ/core are firewalls inspecting every packet? And of course doing this at line rates... News to me.... :-) Thomas From graham@apolix.co.za Mon May 2 14:46: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 DC939E0785 for ; Mon, 2 May 2011 14:46:26 -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 L3YPYvuc4ukj for ; Mon, 2 May 2011 14:46:26 -0700 (PDT) Received: from oryx.apolix.co.za (oryx.apolix.co.za [41.73.36.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0931EE0618 for ; Mon, 2 May 2011 14:46:26 -0700 (PDT) Received: from wbs-41-208-231-194.wbs.co.za ([41.208.231.194] helo=[192.168.1.131]) by oryx.apolix.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QH0tX-0000R9-Q2 for v6ops@ietf.org; Mon, 02 May 2011 23:43:08 +0200 Message-ID: <4DBF2569.4070509@apolix.co.za> Date: Mon, 02 May 2011 23:43:05 +0200 From: Graham Beneke User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: v6ops@ietf.org References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AuthenticatedID: graham@apolix.co.za X-Report-Abuse-To: abuse@apolix.co.za X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - oryx.apolix.co.za X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - apolix.co.za Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 21:46:27 -0000 On 02/05/2011 18:57, james woodyatt wrote: > + A specific date, soon, e.g. this November, on which operators are REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes in their respective default free zones. I can imagine a tweak that directs ICANN (or something like that) to operate the distinguished autonomous system for those prefixes that returns ICMP and ICMPv6 errors for packets sent into the default free zones with those destinations. While I accept that there are grave concerns about 6to4, I feel that completely scrapping it leaves us with the following problem: How to IPv4-only hosts reach IPv6-only content? 'IPv6-only' has up to now only been something that I've seen discussed in experimental environments but with the APNIC address pool exhaustion it is quickly becoming a reality. If we remove 6to4 from the protocol bouquet then what do we point users to with this predicament? -- Graham Beneke From jhw@apple.com Mon May 2 14:47: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 BB6D8E07C7 for ; Mon, 2 May 2011 14:47:53 -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 qsRs1+p2x6dr for ; Mon, 2 May 2011 14:47:52 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id E9C26E07AE for ; Mon, 2 May 2011 14:47:52 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LKL008J98JI5G51@mail-out.apple.com> for v6ops@ietf.org; Mon, 02 May 2011 14:47:52 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-75-4dbf268796f5 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 relay15.apple.com (Apple SCV relay) with SMTP id C6.61.18996.8862FBD4; Mon, 02 May 2011 14:47:52 -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 <0LKL00EJB8JRBX10@koseret.apple.com> for v6ops@ietf.org; Mon, 02 May 2011 14:47:51 -0700 (PDT) From: james woodyatt In-reply-to: <201105022142.p42Lgn96024618@cichlid.raleigh.ibm.com> Date: Mon, 02 May 2011 14:47:51 -0700 Message-id: <69993833-1F27-4927-9418-A469E4E69951@apple.com> References: <201105022142.p42Lgn96024618@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1222) X-Brightmail-Tracker: AAAAAA== Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 21:47:53 -0000 On May 2, 2011, at 14:42 , Thomas Narten wrote: > Huh? Every single router, including those in the DFZ/core are > firewalls inspecting every packet? And of course doing this at line > rates... I see what you did there. The original context of this idea was this: >> + A revision to to specify that routers MUST NOT forward... Did the ambit of that document expand to include DFZ/core routers while I wasn't paying attention? -- james woodyatt member of technical staff, core os networking From brian.e.carpenter@gmail.com Mon May 2 14: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 26F93E078C for ; Mon, 2 May 2011 14:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.177 X-Spam-Level: X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=-0.178, 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 O3UBGf63VLzn for ; Mon, 2 May 2011 14:55:12 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B483E0674 for ; Mon, 2 May 2011 14:55:12 -0700 (PDT) Received: by pwi5 with SMTP id 5so3592687pwi.31 for ; Mon, 02 May 2011 14:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NtkNzPKTvgZQGVZB2lRRbTWPT0Ugd1oCgTMAwnFsFa0=; b=xDQmxkwS8mwHp/lMt0Gat9c88zSqa0Uk0hUxFiTEN0Yp/YrHY5UhN1MBC7b87n06FZ zJrfeO5XZ7V8RUj+d69lZ0SyL7dHecWxi22VuiFrp7br5mvmYbfq4rfUk0He8RX7kLi/ naR+row4P3OckA4Fl2qxXUzoar1V0WYI/c4v4= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=FjXpSN70b0eqk3vrGXQL5mm1MPFmXGaMsESR+8XHewtvrEbNBnMiDE9PuH+TwLx4WP iiMRzcEunTqSdYiXeTMagNjgk1r6AyittyCJm1KaTHGOs32Cdpt5aXyEVE5mHPNlmCjK 3iNbGdBM6nDKQk6ShHdGv987y6Ft8amcylnlw= Received: by 10.68.34.7 with SMTP id v7mr9357679pbi.371.1304373311992; Mon, 02 May 2011 14:55:11 -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 f4sm713663pbs.36.2011.05.02.14.55.09 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 14:55:10 -0700 (PDT) Message-ID: <4DBF283A.2040109@gmail.com> Date: Tue, 03 May 2011 09:55:06 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 21:55:13 -0000 +1 Regards Brian Carpenter On 2011-05-03 05:19, Fred Baker wrote: > On May 2, 2011, at 9:18 AM, Erik Kline wrote: > >> Can we take this two separate steps: >> >> [1] Move it to historic in this doc. >> >> [2] Propose a phase-out plan, timeline, and other mechanics in a >> 2nd follow-on doc (which will obviously refer to #1). >> >> Reasonable? > > I think it is very reasonable. I personally question the wisdom of a documented phase-out plan, for the reasons Brian has mentioned. But in any event, I would like to decouple that question from the more basic question addressed in this document, which is the fundamental trajectory of the technology. Since there are demonstrated issues with 6to4, and the industry is moving out of the experimental phase it was designed for into a full deployment phase, this document says "let's consider 6to4 an evolutionary dead end". That statement we seem to generally agree with, modulo Keith and Jordi. > > I would encourage James, if he wants to take that route, to propose a phase-out plan in a separate document. > >> On 3 May 2011 01:13, Lorenzo Colitti wrote: >>> On Sun, May 1, 2011 at 3:06 PM, james woodyatt wrote: >>>> Having failed to persuade anyone that a phaseout plan is necessary for >>>> this draft to be meaningful, I have refined my position on this point. >>> I like the idea of a phase-out plan, but what form would it take? Requesting >>> that IANA declare 2002::/16 to be reserved? Saying that implementations >>> should not use 2002::/16 to autoconfigure addresses? >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Mon May 2 14: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 034F6E07B8 for ; Mon, 2 May 2011 14:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.469 X-Spam-Level: X-Spam-Status: No, score=-103.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 g92z4F6vMgKI for ; Mon, 2 May 2011 14:58:57 -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 31F11E07C6 for ; Mon, 2 May 2011 14:58:57 -0700 (PDT) Received: by pvh1 with SMTP id 1so4198786pvh.31 for ; Mon, 02 May 2011 14:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NvduN+hSpV3XuJ5ONVzgwrY04Fn0TlYmN/LF+D3+z2o=; b=B7zPHWB/d9+mLkA03CMF1eOfWIav/vBxLvN2qT2+H28+cAtxJ0FdSb0VCr7pvd0Huh rwsrfQVkzzBAkfoyEt73B+fGmNHnJpTrqexmrBvQwfkHCqSMjB6V7dNCgTfQdcF/pylg DEWRwngl1HwrlIm4o4SYRA7DN6yQ+/Q1c+HuM= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=cIO4skirqymTbHO0Zf82tmKGrXIMEDV5SAWkCbfKG8OA+RPrjJuq/cPlDcr4ryx5dv 7D44vMvD33NnDfcC0l1t8x89zEGt+V44EEqT7PdPyltVysi2iCWdktsivQHF062Hm9ZG IC4Y8iNyAXM/hQd33O2NKR7WcvU6q3xIIN+jE= Received: by 10.68.36.170 with SMTP id r10mr503058pbj.504.1304373536947; Mon, 02 May 2011 14:58: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 f3sm4031975pbq.58.2011.05.02.14.58.54 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 14:58:56 -0700 (PDT) Message-ID: <4DBF291C.2080406@gmail.com> Date: Tue, 03 May 2011 09:58:52 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Wes Beebee References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 21:58:58 -0000 On 2011-05-03 09:35, Wes Beebee wrote: >> So, every router will now be required to inspect the inner contents of >> tunneled packets they are forwarding in order to find these rogue >> packets? Will never happen. Way too big of a performance hit. Good >> example of a "wishful thinking" requirement. > > And they already implement a full stateful firewall capable of supporting a > multitude of ALG's that inspect every packet already. This requirement is > not really that much of a performance hog compared to a firewall. Sure, but you don't put firewalls on 40Gb lines, which is what "every router" includes. Enterprise firewalls are already capable of stopping IPv6-in-IPv4 tunnels of any kind. There's little point in adding cruft for this elsewhere, since it would damage at least as many users as it would help. As Fred said - let's just stop debating this until there is a draft to debate. Brian From brian.e.carpenter@gmail.com Mon May 2 15:02: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 BA891E07C6 for ; Mon, 2 May 2011 15:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.175 X-Spam-Level: X-Spam-Status: No, score=-103.175 tagged_above=-999 required=5 tests=[AWL=-0.176, 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 4NSU5j0oXsUB for ; Mon, 2 May 2011 15:02:11 -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 3574CE0797 for ; Mon, 2 May 2011 15:02:11 -0700 (PDT) Received: by iyn15 with SMTP id 15so6418884iyn.31 for ; Mon, 02 May 2011 15:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8cY1Yi1VrAVzf8g+5iYaI0N1nmKY400/bmK1FTjVKcs=; b=wpXcAskkhQm9XFP/MuAaczYGrfHqxurPKt39mh0j/zd0um/24nvheRuuYNYrFyZg0S xjZoG65XMd3zW7yHTIKVCbMn4b4S9q4g2gBst6ynthj27jbuswJHqO2kbIWpgOtHk+qP urGJWz8lNCrM6172cCCa9gGq/BNutKvjivZgE= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=vZ5qHLbZUx6HZKcwhpo9Ni3mEodhhHo5LiF7YoU9kUimvrmdj7Cva2JC1XPOymc0By Z+TajFggaf17IWZIhKr4V3xjkaRoNQV4eBDQUdYYr0LoJXHNqkKC0HYlZxt6016sZhW/ N4dJZlh+OZVRrII05Hmnb2yYCeArwFmO5RX8s= Received: by 10.43.131.130 with SMTP id hq2mr9479336icc.90.1304373730626; Mon, 02 May 2011 15:02:10 -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 c1sm2482927ibe.51.2011.05.02.15.02.08 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 15:02:10 -0700 (PDT) Message-ID: <4DBF29DE.4020401@gmail.com> Date: Tue, 03 May 2011 10:02:06 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <850CD890-511A-4D48-AC95-A6314060F91E@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , Ron Bonica Subject: Re: [v6ops] Regarding draft-ietf-v6ops-6to4-to-historic WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 22:02:11 -0000 I believe this version is ready for the IESG. We manifestly have no consensus on the other issues and will not get it on a reasonable timescale. So we should move on with what we have. Regards Brian Carpenter On 2011-05-03 05:25, Fred Baker wrote: > On May 1, 2011, at 11:00 AM, Fred Baker wrote: > >> Today is the last day of the announced WGLC on this draft. Ole posted an updated version last Wednesday and a list of issues. As near as I can tell, the WG feels that his proposed resolutions for issues 2, 3, 7, 8, and 10 are correct, and the other issues have proposed text or at least concepts for that text proposed. I have asked Ole to post a new version incorporating those changes. We will continue this WGLC through 8 May to let people comment on the revised version, which I expect will reach rough consensus. We have at least two people that would really like to NOT see 6to4 declared historic, Keith Moore and Jordi Palet Martinez, and I do not expect them to change their views. > > Ole has posted a new version. The diffs resulting from the WGLC so far may be found at http://tinyurl.com/3c2f2cc. He did not include text phaseout plan nor the descriptive 'clarification' point, as we don't appear to have consensus supporting them at this point. > > Please read the current text before continuing to comment. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From narten@us.ibm.com Mon May 2 15:03: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 9A5A7E07D9 for ; Mon, 2 May 2011 15:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.158 X-Spam-Level: X-Spam-Status: No, score=-106.158 tagged_above=-999 required=5 tests=[AWL=0.441, 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 H7Zlqix3M2hH for ; Mon, 2 May 2011 15:03:01 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC04E07D4 for ; Mon, 2 May 2011 15:03:01 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p42LtpUF022700 for ; Mon, 2 May 2011 15:55:51 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p42M2Xm3093982 for ; Mon, 2 May 2011 16:02:38 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p42M2Sal018130 for ; Mon, 2 May 2011 16:02:29 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-193-26.mts.ibm.com [9.65.193.26]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p42M2Q36018033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 May 2011 16:02:28 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p42M2PUx024814; Mon, 2 May 2011 18:02:25 -0400 Message-Id: <201105022202.p42M2PUx024814@cichlid.raleigh.ibm.com> To: james woodyatt In-reply-to: <69993833-1F27-4927-9418-A469E4E69951@apple.com> References: <201105022142.p42Lgn96024618@cichlid.raleigh.ibm.com> <69993833-1F27-4927-9418-A469E4E69951@apple.com> Comments: In-reply-to james woodyatt message dated "Mon, 02 May 2011 14:47:51 -0700." Date: Mon, 02 May 2011 18:02:25 -0400 From: Thomas Narten Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 22:03:01 -0000 > >> + A revision to > >> > >> to specify that routers MUST NOT forward... > Did the ambit of that document expand to include DFZ/core routers > while I wasn't paying attention? Ah, my bad. Sorry 'bout that. You are scoping the MUST NOT to just the CPE routers. That's more bearable. (Maybe.) But I'm not sure why you want to do that. I.e., why would CPEs be *forwarding* such packets? Aren't they the 6to4 Border Routers that participate in the encap/decap of 6to4? I.e, so if you want to stop them from doing Bad Things w.r.t. to 6to4, isn't the key thing that they shouldn't enable it by default? If they are *forwarding* such packets, the problem is elsewhere, not on the CPE. Thomas From Dmitry.Anipko@microsoft.com Mon May 2 15:06: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 7C020E07EC for ; Mon, 2 May 2011 15:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.508 X-Spam-Level: X-Spam-Status: No, score=-10.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 wOGcnZwP4YeZ for ; Mon, 2 May 2011 15:06:06 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 01B62E07D9 for ; Mon, 2 May 2011 15:06:05 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 2 May 2011 15:06:05 -0700 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 2 May 2011 15:06:05 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Mon, 2 May 2011 15:06:05 -0700 From: Dmitry Anipko To: Ole Troan Date: Mon, 2 May 2011 15:06:03 -0700 Thread-Topic: [v6ops] 6to4-historic summary point: 3. "non-RFC1918 addresses" Thread-Index: AcwH5R4cBDQ3n5WYRzmBHKy31C+vgABL4Llg Message-ID: References: <011CD3B0-3F46-4CA5-959B-E400EA13E0EE@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 3. "non-RFC1918 addresses" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 22:06:06 -0000 Hello Ole, rfc3484 addresses them by making 6to4 one of the last resort interfaces. Ad= visory addresses by saying clearly it should not be on by default - so if s= omeone enables 6to4, one has to assume they know what they are doing and wh= at they are using it for. Thanks, Dmitry -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Sunday, May 01, 2011 2:50 AM To: Dmitry Anipko Cc: Fred Baker; v6ops@ietf.org WG Subject: Re: [v6ops] 6to4-historic summary point: 3. "non-RFC1918 addresses= " Dmitry, >>> Does the working group agree with the summarization of the concern?=20 >=20 > I agree the concern was summarized correctly. >=20 >>> Do we agree with the proposed action? >=20 > As I said in the quoted feedback, I don't think the action draft proposes= is necessary to address the problem quoted, for the reasons listed below i= n the feedback summary. So I agree with the proposed action to change the t= ext and I propose: to remove all the references about moving RFC 3056 to hi= storic status from the draft, since in my opinion the draft doesn't state s= ufficient reasons for moving RFC 3056 to historic. Those of the listed prob= lems, which are specific to 6to4, are addressed by the companion advisory a= nd RFC 3484bis. Those which are not specific to 6to4, in my opinion, shall = not be in the draft. how does the advisory or rfc3484 address these problems: >> Reply: Current text states: >> - Not deployed >> - Same problems as 3068 for the reverse path >> - Same problem with filtering >> - Not working with non-1918 addresses with topologically limited s= pan cheers, Ole From martin@millnert.se Mon May 2 15:18: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 178B9E07F3 for ; Mon, 2 May 2011 15:18: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=[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 hHFMqtQ0sTfd for ; Mon, 2 May 2011 15:18:45 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8AEE07F1 for ; Mon, 2 May 2011 15:18:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id A0C7A7758; Tue, 3 May 2011 00:35:09 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnBqH4QWHhN7; Tue, 3 May 2011 00:35:09 +0200 (CEST) Received: from [IPv6:2a02:9a0:100:2300::6] (shakira-work.us.millnert.se [IPv6:2a02:9a0:100:2300::6]) by ncis.csbnet.se (Postfix) with ESMTPSA id 7E06B78B; Tue, 3 May 2011 00:35:07 +0200 (CEST) From: Martin Millnert To: Graham Beneke In-Reply-To: <4DBF2569.4070509@apolix.co.za> References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> Content-Type: text/plain; charset="UTF-8" Date: Mon, 02 May 2011 18:17:56 -0400 Message-ID: <1304374676.3125.9.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 22:18:46 -0000 Graham, On Mon, 2011-05-02 at 23:43 +0200, Graham Beneke wrote: > On 02/05/2011 18:57, james woodyatt wrote: > > + A specific date, soon, e.g. this November, on which operators are REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes in their respective default free zones. I can imagine a tweak that directs ICANN (or something like that) to operate the distinguished autonomous system for those prefixes that returns ICMP and ICMPv6 errors for packets sent into the default free zones with those destinations. > > While I accept that there are grave concerns about 6to4, I feel that > completely scrapping it leaves us with the following problem: How to > IPv4-only hosts reach IPv6-only content? > > 'IPv6-only' has up to now only been something that I've seen discussed > in experimental environments but with the APNIC address pool exhaustion > it is quickly becoming a reality. If we remove 6to4 from the protocol > bouquet then what do we point users to with this predicament? I think part of the rationale for removing unsuccessful v4->v6 transition mechanisms is an idea that it will increase market demand for proper native IPv6. Having that said, there are a few best-effort tunnel-providers out there. Cheers, Martin From brian.e.carpenter@gmail.com Mon May 2 15:19: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 BCF8AE07F1 for ; Mon, 2 May 2011 15:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.468 X-Spam-Level: X-Spam-Status: No, score=-103.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 zO5O3VptYIXR for ; Mon, 2 May 2011 15:19:30 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3B75E07E6 for ; Mon, 2 May 2011 15:19:30 -0700 (PDT) Received: by pwi5 with SMTP id 5so3602013pwi.31 for ; Mon, 02 May 2011 15:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R9vqIfrWthh7aXZbYS4C9+jdOL/8XULXfisMZmtQyWs=; b=vYxHfQavVC2E9DR+ks05JHkkmITAAGRlA3Veau6q+4o3ApziMME+0StljVaPCWa3FB nkm3UqBs0HlYvDaPleuRGNEpTDlQ9P6ZfvldVmwxwABeZD3jG5omTqy0lKfpSodROSp/ hc+M0Q50vqRac34kH20h3O7zh+uT5eWNMLGCM= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=RFz4iWVUxUnhpAaF7mfzHiZ1DC+5XJ/xMFqGKoHPUPvwpJyM04dGcAw1cT1INEWCvy rRZtDAsGxbPawr0gEHIwbNTPdNct4mimVktc+0t/WVjpJGmhgrCJlF9CeDheJo9OHsT1 1aniDPTLTGLzZh22fVdBmzZs0yvkpEmzciZ4s= Received: by 10.142.4.24 with SMTP id 24mr3326792wfd.103.1304374768613; Mon, 02 May 2011 15:19:28 -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 p40sm7583214wfc.19.2011.05.02.15.19.26 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 15:19:28 -0700 (PDT) Message-ID: <4DBF2DEC.7060500@gmail.com> Date: Tue, 03 May 2011 10:19:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten References: <201105022142.p42Lgn96024618@cichlid.raleigh.ibm.com> <69993833-1F27-4927-9418-A469E4E69951@apple.com> <201105022202.p42M2PUx024814@cichlid.raleigh.ibm.com> In-Reply-To: <201105022202.p42M2PUx024814@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 22:19:34 -0000 On 2011-05-03 10:02, Thomas Narten wrote: >>>> + A revision to >>>> >>>> to specify that routers MUST NOT forward... > > >> Did the ambit of that document expand to include DFZ/core routers >> while I wasn't paying attention? > > Ah, my bad. Sorry 'bout that. > > You are scoping the MUST NOT to just the CPE routers. That's more > bearable. (Maybe.) > > But I'm not sure why you want to do that. > > I.e., why would CPEs be *forwarding* such packets? Aren't they the > 6to4 Border Routers that participate in the encap/decap of 6to4? I.e, > so if you want to stop them from doing Bad Things w.r.t. to 6to4, > isn't the key thing that they shouldn't enable it by default? > > If they are *forwarding* such packets, the problem is elsewhere, not > on the CPE. Or there is no problem at all because they are successfully using 6to4. This whole phase-out discussion fails to take account of the fact that according to the published measurements, at least 80% of connections using 6to4 are successful. We have every reason to try to get rid of the 20% that fail, but we have no reason and no right to damage the successful use. Brian From brian.e.carpenter@gmail.com Mon May 2 15:29: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 42126E07FD for ; Mon, 2 May 2011 15:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.473 X-Spam-Level: X-Spam-Status: No, score=-103.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 CN1wQUflFQON for ; Mon, 2 May 2011 15:29:28 -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 A6F40E06FF for ; Mon, 2 May 2011 15:29:28 -0700 (PDT) Received: by pzk5 with SMTP id 5so4019854pzk.31 for ; Mon, 02 May 2011 15:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=iTkhC5d/AT3q8Qdy5DjdnVaH87oS3X1atfBh/oqGXzY=; b=DhHrvoatEVWzDoW1Qe5EYc/llDT1cqwz4rknzwCc92O4p9TAvHXXE5JFXTaelIfO0k lbje881V7+pY/yKPDxs4s7ckzcE9nZu8GN2x7dv8bai9LQ8posqWh7EhXLB5ZYxBGGQC xQsa16GIlWbPi7sLCXOyk+FyLmb/6KvXLPDHg= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=nvzdOXkTHh9XpCD5BIC6/vuMHgSe2P/UWCWcOW1Thb00n7X8ikCtpqYig/Xy7wD2jI uQj7E0H8FdFTwfYi43vBoNrxnFA4Z3cNKnWTOojoMwgGzqWpqwK3mJ8rvegbGfA0VRN7 sVqsZNKVvivUgyy8dbAIFtzlOouJv7jHxi9cA= Received: by 10.68.55.133 with SMTP id s5mr2259076pbp.56.1304375368056; Mon, 02 May 2011 15:29:28 -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 k10sm4071707pbl.76.2011.05.02.15.29.25 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 15:29:27 -0700 (PDT) Message-ID: <4DBF3043.7050905@gmail.com> Date: Tue, 03 May 2011 10:29:23 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: james woodyatt References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 22:29:29 -0000 I'm sorry to repeat myself, but... On 2011-05-03 04:57, james woodyatt wrote: > On May 2, 2011, at 9:13 AM, Lorenzo Colitti wrote: >> On Sun, May 1, 2011 at 3:06 PM, james woodyatt wrote: >>> Having failed to persuade anyone that a phaseout plan is necessary for this draft to be meaningful, I have refined my position on this point. >> I like the idea of a phase-out plan, but what form would it take? Requesting that IANA declare 2002::/16 to be reserved? Saying that implementations should not use 2002::/16 to autoconfigure addresses? > > As an outline, I would like to see at least *all* of the following requirements in any standards action for this purpose: > > + A specific date, soon, e.g. this November, on which operators are REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes in their respective default free zones. I can imagine a tweak that directs ICANN (or something like that) to operate the distinguished autonomous system for those prefixes that returns ICMP and ICMPv6 errors for packets sent into the default free zones with those destinations. The advice is much more subtle than that and depends on which operator and what their objective is. In any case, the concept of the DFZ is so fuzzy that I have no idea what such a practice would mean. What operators should do (now, not in November) is verify that if they are accepting routes to 2002::/16 and 192.88.99.0/24, those routes lead to working relays. If not, they should reject those routes. Actually, they should have been doing this for ever. > + An amendment to IPv6 node requirements to say that hosts MUST NOT use stateless autoconfiguration to self-assign interface addresses with 2002::/16 prefixes, i.e. when processing router advertisements with prefix information options that have A=1 and contain prefixes in the 2002::/16 range, the A bit MUST be ignored and the prefix treated as if A=0. That would be totally wrong because it would break successful use of 6to4. It is not the IETF's job to break stuff. > + A revision to to specify that routers MUST NOT advertise prefixes in the 2002::/16 range, with A=1, even when delegated with DHCPv6 prefix delegation. Equally wrong for the same reason. > + A revision to to specify that routers MUST NOT forward any packets with IPv4 protocol 41 with an inner IPv6 header containing a 2002::/16 address to or from the WAN interface. Replies with ICMP error RECOMMENDED. Equally wrong for the same reason. Brian From john.mann@monash.edu Mon May 2 16:06: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 5DE87E07B4 for ; Mon, 2 May 2011 16:06:14 -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 3OTLFMqMclQO for ; Mon, 2 May 2011 16:06:13 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 70A87E07A6 for ; Mon, 2 May 2011 16:06:13 -0700 (PDT) Received: from mail-vw0-f46.google.com ([209.85.212.46]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTb845NOy+gVLnXhYpWLMjer9owjDSmCD@postini.com; Mon, 02 May 2011 16:06:13 PDT Received: by mail-vw0-f46.google.com with SMTP id 1so4613034vws.19 for ; Mon, 02 May 2011 16:06:12 -0700 (PDT) Received: by 10.52.69.65 with SMTP id c1mr736575vdu.301.1304377572143; Mon, 02 May 2011 16:06:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.108.134 with HTTP; Mon, 2 May 2011 16:05:52 -0700 (PDT) In-Reply-To: <4DBF2569.4070509@apolix.co.za> References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> From: "John Mann (ITS)" Date: Tue, 3 May 2011 09:05:52 +1000 Message-ID: To: Graham Beneke Content-Type: multipart/alternative; boundary=20cf307cfc18d732ed04a25311f5 Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 23:06:14 -0000 --20cf307cfc18d732ed04a25311f5 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 3 May 2011 07:43, Graham Beneke wrote: > On 02/05/2011 18:57, james woodyatt wrote: > >> + A specific date, soon, e.g. this November, on which operators are >> REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes in >> their respective default free zones. I can imagine a tweak that directs >> ICANN (or something like that) to operate the distinguished autonomous >> system for those prefixes that returns ICMP and ICMPv6 errors for packets >> sent into the default free zones with those destinations. > > I am for deprecating IPv6, but am against breaking it where it is working. > While I accept that there are grave concerns about 6to4, I feel that > completely scrapping it leaves us with the following problem: How to > IPv4-only hosts reach IPv6-only content? > > 'IPv6-only' has up to now only been something that I've seen discussed in > experimental environments but with the APNIC address pool exhaustion it is > quickly becoming a reality. If we remove 6to4 from the protocol bouquet then > what do we point users to with this predicament? > I think the key messages in our advice to IPv4-only users should be - don't use un-managed tunnels, and - "no IPv6" is better than "flaky IPv6". For example recommend: If they are within an enterprise, use ISATAP or VPN. If they have a lone/roaming device, use Teredo. If they want a /64 or /48 for redistribution, use a tunnel broker, or get their ISP to support 6rd. I acknowledge that my suggestions above aren't things that a user can just configure in isolation, like they can just tick "enable 6to4 gateway", but I think that raising the bar is a small and necessary price to pay for a more-reliable IPv6 service. And once users/admins have spent some time/money/effort for a working but not optimal tunneled IPv6 service, they may be prepared to do a little bit more for a native service. Thanks, John --20cf307cfc18d732ed04a25311f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 3 May 2011 07:43, Graham Beneke <graham@apolix.co= .za> wrote:
On 02/05/2011 18:57, james woodyatt wrote:
+ A specific date, soon, e.g. this November, on which operators are REQUIRE= D to stop advertising the 2002::/16 and 192.88.99/24 prefixes in their resp= ective default free zones. =A0I can imagine a tweak that directs ICANN (or = something like that) to operate the distinguished autonomous system for tho= se prefixes that returns ICMP and ICMPv6 errors for packets sent into the d= efault free zones with those destinations.

I am for deprecating IPv6, but am ag= ainst breaking it where it is working.
=A0
While I accept that there are grave concerns about 6to4, I feel that comple= tely scrapping it leaves us with the following problem: How to IPv4-only ho= sts reach IPv6-only content?

'IPv6-only' has up to now only been something that I've seen di= scussed in experimental environments but with the APNIC address pool exhaus= tion it is quickly becoming a reality. If we remove 6to4 from the protocol = bouquet then what do we point users to with this predicament?

I think the key messages in our advice to = IPv4-only users should be=A0
- don't use un-managed tunnels, = and
- "no IPv6" is better than "flaky IPv6".<= /div>

For example recommend:
If they are within an = enterprise, use ISATAP or VPN.
If they have a lone/roaming device= , use Teredo.
If they want a /64 or /48 for redistribution, use a= tunnel broker, or get their ISP to support 6rd.

I=A0acknowledge=A0that my suggestions above aren't = things that a user can just configure in isolation, like they can just tick= "enable 6to4 gateway",
but I think that raising the ba= r is a small and necessary price to pay for a more-reliable IPv6 service.

And once users/admins have spent some time/money/effort= for a working but not optimal tunneled IPv6 service, they may be prepared = to do a little bit more for a native service.

Thanks,
=A0 =A0 John
--20cf307cfc18d732ed04a25311f5-- From john.mann@monash.edu Mon May 2 16:50: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 BC19FE07F4 for ; Mon, 2 May 2011 16:50:43 -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 B68Obc05fFVk for ; Mon, 2 May 2011 16:50:42 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5050FE0618 for ; Mon, 2 May 2011 16:50:42 -0700 (PDT) Received: from mail-vw0-f45.google.com ([209.85.212.45]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTb9DUKG/Uc+6FEsEJrKTZ76exl4UNGJj@postini.com; Mon, 02 May 2011 16:50:42 PDT Received: by mail-vw0-f45.google.com with SMTP id 17so5393971vws.4 for ; Mon, 02 May 2011 16:50:40 -0700 (PDT) Received: by 10.52.98.5 with SMTP id ee5mr1178486vdb.200.1304380239192; Mon, 02 May 2011 16:50:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.108.134 with HTTP; Mon, 2 May 2011 16:50:19 -0700 (PDT) In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D2DD@PDAWM12B.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D2DD@PDAWM12B.ad.sprint.com> From: "John Mann (ITS)" Date: Tue, 3 May 2011 09:50:19 +1000 Message-ID: To: "George, Wes E [NTK]" Content-Type: multipart/alternative; boundary=20cf307f34a6cf226604a253b02f Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 May 2011 23:50:43 -0000 --20cf307f34a6cf226604a253b02f Content-Type: text/plain; charset=ISO-8859-1 Hi, On 3 May 2011 03:06, George, Wes E [NTK] wrote: > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Dmitry Anipko > Sent: Saturday, April 30, 2011 8:37 PM > To: Fred Baker; v6ops@ietf.org WG > Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41" > > >>Does the working group agree with the summarization of the concern? > > I agree with the summarization of the concern. > > >>Do we agree with the proposed (in)action? > > I disagree with the proposed action. I suggest to either remove the problem > from the list of 6to4 problems, since as currently > worded this is not a 6to4 problem, but protocol 41 problem, and this draft, > in its current form, doesn't seem to have any intentions > to deal with general protocol 41, or to add text illustrating why this > problem is 6to4 specific and other uses of protocol 41 on the > Internet do not have this problem or how that problem is/can be mitigated > for them. > _________ > [WEG] I think you're conflating two issues similar to previous objector, > who said basically, "if we deprecate 6to4 because it > doesn't work, we have a lot of other tunneling and IPv6 transition > protocols to deprecate too" and the line of logic that followed > that assertion was that we therefore shouldn't deprecate any of them. > IMO, there's nothing wrong with the assertion that 6to4 should be > deprecated because of problems with protocol 41. The notion that > we should either ignore this issue because it's not specific to 6to4 or > dramatically widen the scope of what is a fairly targeted > document about 6to4 to now include other implementations that use protocol > 41 seems very odd to me. We want this draft to be as > complete as possible when documenting our rationale for saying, "well, > that's not gone well at all..." rather than picking and > choosing the brokenness to only reflect the few things that are 100% > specific to the implementation that we're deprecating. > You're right that protocol 41 problems are not all specific to 6to4. That > doesn't make 6to4 any less broken when considering the > effects of protocol 41 filtering and other problems. > Folks on this list have said more than once that it might make sense for > there to be a companion document for Teredo, using some of > the same justifications. If there are other implementations using Protocol > 41 that may be similarly affected, it'd be worth > evaluating their usefulness vs problems and pervasiveness of implementation > as well. But we have to start somewhere, and we're > unlikely to gain consensus on deprecating all of them at once, so we're > breaking it into pieces. +1 [ And the text has been changed already. ] Anyway, what _are_ the other protocol-41 tunnel mechanisms that people are concerned about? ISATAP http://tools.ietf.org/html/rfc5214 - requires RS / RA packet exchange tunneled in protocol-41 before the node knows its IPv6 prefix and default router. Single endpoint-only protocol -- there are no other downstream devices that could be impacted by a protocol-41 failure. Tunnel reliability also improved by: 7.2. Handling ICMPv4 Errors 8.4. Neighbor Unreachability Detection ISATAP is also likely to be implemented as a "managed" service by/inside an enterprise, which should improve its tunnel reliability. Also an ISATAP subnet is likely to be "inside" an enterprise and so should not / must not cross the enterprise border firewall - blocking protocol-41 is a feature, not a failing! 6rd http://tools.ietf.org/html/rfc5969 Increased reliability because "managed" by the ISP. Has some stuff like 5. Troubleshooting and Traceability 8. Neighbor Unreachability Detection [ I am no expert on 6rd. ] http://tools.ietf.org/html/rfc4213 ? is this "6over4" ? "Configured Tunneling" is "managed" with explicit configuration at each end. Also 3.8. Neighbor Discovery over Tunnels - NUD - use an alternate path - routing protocol running over the tunnel Teredo http://tools.ietf.org/html/rfc4380 "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)" Uses UDP encapsulation, not protocol-41. GRE tunnels not protocol-41 VPNs or various flavours not protocol-41 Anything else? Thanks, John --20cf307f34a6cf226604a253b02f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 3 May 2011 03:06, George, Wes E [N= TK] <Wes= ley.E.George@sprint.com> wrote:
-----Original Message-----
From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of Dmitry Anipko
Sent: Saturday, April 30, 2011 8:37 PM
To: Fred Baker; v6ops@ietf.org WG
Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41"= ;

>>Does the working group agree with the summarization of the concern?=

I agree with the summarization of the concern.

>>Do we agree with the proposed (in)action?

I disagree with the proposed action. I suggest to either remove the problem= from the list of 6to4 problems, since as currently
worded this is not a 6to4 problem, but protocol 41 problem, and this draft,= in its current form, doesn't seem to have any intentions
to deal with general protocol 41, or to add text illustrating why this prob= lem is 6to4 specific and other uses of protocol 41 on the
Internet do not have this problem or how that problem is/can be mitigated f= or them.
_________
[WEG] I think you're conflating two issues similar to previous objector= , who said basically, "if we deprecate 6to4 because it
doesn't work, we have a lot of other tunneling and IPv6 transition prot= ocols to deprecate too" and the line of logic that followed
that assertion was that we therefore shouldn't deprecate any of them. IMO, there's nothing wrong with the assertion that 6to4 should be depre= cated because of problems with protocol 41. The notion that
we should either ignore this issue because it's not specific to 6to4 or= dramatically widen the scope of what is a fairly targeted
document about 6to4 to now include other implementations that use protocol = 41 seems very odd to me. We want this draft to be as
complete as possible when documenting our rationale for saying, "well,= that's not gone well at all..." rather than picking and
choosing the brokenness to only reflect the few things that are 100% specif= ic to the implementation that we're deprecating.
You're right that protocol 41 problems are not all specific to 6to4. Th= at doesn't make 6to4 any less broken when considering the
effects of protocol 41 filtering and other problems.
Folks on this list have said more than once that it might make sense for th= ere to be a companion document for Teredo, using some of
the same justifications. If there are other implementations using Protocol = 41 that may be similarly affected, it'd be worth
evaluating their usefulness vs problems and pervasiveness of implementation= as well. But we have to start somewhere, and we're
unlikely to gain consensus on deprecating all of them at once, so we're= breaking it into pieces.

+1 =A0[ And the t= ext has been changed already. ]

Anyway, what _are_= the other protocol-41=A0tunnel mechanisms that people are concerned about?=

- requires RS / RA packet e= xchange tunneled in protocol-41 before the node knows its IPv6 prefix and d= efault router.
Single endpoint-only protocol -- there are no other downstream devices= that could be impacted by a protocol-41 failure.
Tunnel reliabil= ity also improved by:
7.2. Handling ICMPv4 Errors
8.4. Neighbor Unreachability Detection
ISATAP is also likely to be implemented as a "managed" servi= ce by/inside an enterprise,
which should improve its tunnel relia= bility.
Also an ISATAP subnet is likely to be "inside" = an enterprise and so should not / must not cross the enterprise border fire= wall - blocking protocol-41 is a feature, not a failing!=A0

Increased reliabili= ty because "managed" by the ISP.
Has some stuff like
5. =A0Troubleshooting and Traceability
8. = =A0Neighbor Unreachability Detection
[ I am no expert on 6r= d. ]

? is this "6over4" ?
"Configured Tunneling&qu= ot; is "managed" with explicit configuration at each end.
Also
3.8. =A0Neighbor Discovery over Tunnels
- NUD -=A0=A0use an alternate path
- routing protocol runnin= g over the tunnel

"Teredo: Tunneling IPv6 over UDP=A0through Network Address Translation= s (NATs)"
Uses UDP encapsulation, not protocol-41.

GRE tunnels
not protocol-41

VPNs or va= rious flavours
not protocol-41

Anything = else?

Thanks,
=A0 =A0 John
--20cf307f34a6cf226604a253b02f-- From brian.e.carpenter@gmail.com Mon May 2 17:29: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 311D4E06F5 for ; Mon, 2 May 2011 17:29:45 -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.117, 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 rX3EX1kvkaeV for ; Mon, 2 May 2011 17:29:44 -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 D447BE06AC for ; Mon, 2 May 2011 17:29:42 -0700 (PDT) Received: by pzk5 with SMTP id 5so4062306pzk.31 for ; Mon, 02 May 2011 17:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yfijjllUSdHrYHUBZX98FQH/TrhtGQt8O40mGk5nZvU=; b=KATaDdBC9ttPRBAtelpK9ZHjq+pE/IThkyMAuEgdEzMt88oEDzB/GQMaED7mDe5j8e Iaq+A1/EPWZOT5qAHSS3ve2eUZIJvZwDtlSW6AqiN5ycT7iWF2QfCasIJDPRwsyb3mMe C1dakGPfxcvCoskZZx84cOupXKy9WI8UfL6gg= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=OrwAyAiI+EvbR8yn9DE5EnLpWcTHLiMuoHhBx8XH3ki/UjrfeVlTlYD1XkvFDUASvH eHG9B7dx9YTkbpsz6kS/260D1A+irE4ON/BRw9Tss7b3TQUdKftG3gUnoFu9rXfkIfvs TC5bNDZXxtOsm0nlDQqmlu8/9ANNwn7TNn6U8= Received: by 10.142.180.3 with SMTP id c3mr914850wff.282.1304382582225; Mon, 02 May 2011 17:29:42 -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 x11sm7703111wfd.1.2011.05.02.17.29.40 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 17:29:41 -0700 (PDT) Message-ID: <4DBF4C71.70609@gmail.com> Date: Tue, 03 May 2011 12:29:37 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "John Mann (ITS)" References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D2DD@PDAWM12B.ad.sprint.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 00:29:45 -0000 John, On 2011-05-03 11:50, John Mann (ITS) wrote: ... > > http://tools.ietf.org/html/rfc4213 > ? is this "6over4" ? No. 6over4 is RFC 2529 and not really an active solution today. > "Configured Tunneling" is "managed" with explicit configuration at each end. Exactly. In widespread use until we get native everywhere, and the main reason that a blanket policy for Protocol 41 isn't a good idea. Brian From marka@isc.org Mon May 2 17:34: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 27A51E06F5 for ; Mon, 2 May 2011 17:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 xV-rMOECHge5 for ; Mon, 2 May 2011 17:34:20 -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 52E72E06AC for ; Mon, 2 May 2011 17:34: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 0AA165F983B; Tue, 3 May 2011 00:34:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 E2067216C1E; Tue, 3 May 2011 00:34:02 +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 36EA1E68B4F; Tue, 3 May 2011 10:34:20 +1000 (EST) To: "John Mann (ITS)" From: Mark Andrews References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> In-reply-to: Your message of "Tue, 03 May 2011 09:05:52 +1000." Date: Tue, 03 May 2011 10:34:20 +1000 Message-Id: <20110503003420.36EA1E68B4F@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 00:34:21 -0000 I actually thinks declaring 6to4 historic is way too early and that 6to4 traffic is yet to peak. Most of the current problems with 6to4 are really minor annoyances that will be corrected as more IPv6 services become available. There are very few cases where when you are connecting to a dual stack service you won't fall back eventually to IPv4 and any client that does not fallback is not RFC 1123 compliant. We are yet to see any significant amounts of IPv6 only services. When these start to appear in reasonable numbers then IPv6 connectivity will be required and in many cases the only viable solution will be to deploy 6to4 and it will be deployed properly as people will have a incentive to test it. If we don't want this to occur we need to encourage alternate deployment of alternate solutions. We need to get 6rd added to the OS's and CPE devices that currently support 6to4 as part of their maintenance programs. Yes, this has development costs associated with it that will not be recovered but in many cases this will just be a back port of what is added to the new products so only it ends up only being the porting costs. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From graham@apolix.co.za Mon May 2 22:55: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 D5649E0755 for ; Mon, 2 May 2011 22:55: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 m38zY9+R3ocA for ; Mon, 2 May 2011 22:54:51 -0700 (PDT) Received: from oryx.apolix.co.za (oryx.apolix.co.za [41.73.36.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDDDE0739 for ; Mon, 2 May 2011 22:54:49 -0700 (PDT) Received: from wbs-41-208-231-194.wbs.co.za ([41.208.231.194] helo=[192.168.1.131]) by oryx.apolix.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QH8W8-0006Um-OM; Tue, 03 May 2011 07:51:29 +0200 Message-ID: <4DBF97DC.9090900@apolix.co.za> Date: Tue, 03 May 2011 07:51:24 +0200 From: Graham Beneke User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Martin Millnert References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <1304374676.3125.9.camel@shakira.millnert.se> In-Reply-To: <1304374676.3125.9.camel@shakira.millnert.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AuthenticatedID: graham@apolix.co.za X-Report-Abuse-To: abuse@apolix.co.za X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - oryx.apolix.co.za X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - apolix.co.za Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 05:55:01 -0000 Martin, On 03/05/2011 00:17, Martin Millnert wrote: > I think part of the rationale for removing unsuccessful v4->v6 > transition mechanisms is an idea that it will increase market demand for > proper native IPv6. I would argue the opposite. The use of a transition mechanism makes the path to native IPv6 far less daunting. > Having that said, there are a few best-effort tunnel-providers out > there. There are. I would say that I have had (on average) the same amount of pain and suffering using tunnel brokers as I have had with 6to4 tunnels. I think that I have used all the major ones and there have been sign-up problems, technical challenges and broken infrastructure at some stage with all of them. -- Graham Beneke graham@apolix.co.za | Apolix Internet Services Tel : +27-87-550-1010 | http://www.apolix.co.za/ Cell: +27-82-432-1873 | PO Box 1120 Skype: grbeneke | Melville, 2109 From graham@apolix.co.za Mon May 2 23: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 6D2AAE073E for ; Mon, 2 May 2011 23:05: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 iikoE2KBQ4Rp for ; Mon, 2 May 2011 23:05:26 -0700 (PDT) Received: from oryx.apolix.co.za (oryx.apolix.co.za [41.73.36.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3E695E0739 for ; Mon, 2 May 2011 23:05:25 -0700 (PDT) Received: from wbs-41-208-231-194.wbs.co.za ([41.208.231.194] helo=[192.168.1.131]) by oryx.apolix.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QH8jL-0006r7-LL; Tue, 03 May 2011 08:05:08 +0200 Message-ID: <4DBF9B10.4050705@apolix.co.za> Date: Tue, 03 May 2011 08:05:04 +0200 From: Graham Beneke User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Mark Andrews References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> In-Reply-To: <20110503003420.36EA1E68B4F@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AuthenticatedID: graham@apolix.co.za X-Report-Abuse-To: abuse@apolix.co.za X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - oryx.apolix.co.za X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - apolix.co.za Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 06:05:27 -0000 On 03/05/2011 02:34, Mark Andrews wrote: > I actually thinks declaring 6to4 historic is way too early and that > 6to4 traffic is yet to peak. Most of the current problems with > 6to4 are really minor annoyances that will be corrected as more > IPv6 services become available. I agree. The failure rates are far to high but this is an operational issue. IPv6 has for a long time been considered the bastard child of the Internet and been ignored as both a native and a tunnelled protocol. We are yet to see the critical mass. When this happens there will be 'real customers' shouting real loud at a NOC near you to get these things fixed. In much the same way they do when they can reach their favourite IPv4 service. > We are yet to see any significant amounts of IPv6 only services. > When these start to appear in reasonable numbers then IPv6 connectivity > will be required and in many cases the only viable solution will > be to deploy 6to4 and it will be deployed properly as people will > have a incentive to test it. When the next important cloud based business application arrives as IPv6 only, we are not going to see people patiently waiting for their provider to roll out native IPv6. -- Graham Beneke From marka@isc.org Mon May 2 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 BB575E073E for ; Mon, 2 May 2011 23:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, 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 cABJlRq00JIh for ; Mon, 2 May 2011 23:41:47 -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 23530E06E1 for ; Mon, 2 May 2011 23:41:47 -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 25F6F5F983B; Tue, 3 May 2011 06:41:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 33615216C31; Tue, 3 May 2011 06:41:29 +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 727A0E6C7A0; Tue, 3 May 2011 16:41:46 +1000 (EST) To: Graham Beneke From: Mark Andrews References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <1304374676.3125.9.camel@shakira.millnert.se> <4DBF97DC.9090900@apolix.co.za> In-reply-to: Your message of "Tue, 03 May 2011 07:51:24 +0200." <4DBF97DC.9090900@apolix.co.za> Date: Tue, 03 May 2011 16:41:46 +1000 Message-Id: <20110503064146.727A0E6C7A0@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 06:41:47 -0000 In message <4DBF97DC.9090900@apolix.co.za>, Graham Beneke writes: > Martin, > > On 03/05/2011 00:17, Martin Millnert wrote: > > I think part of the rationale for removing unsuccessful v4->v6 > > transition mechanisms is an idea that it will increase market demand for > > proper native IPv6. > > I would argue the opposite. The use of a transition mechanism makes the > path to native IPv6 far less daunting. > > > Having that said, there are a few best-effort tunnel-providers out > > there. > > There are. I would say that I have had (on average) the same amount of > pain and suffering using tunnel brokers as I have had with 6to4 tunnels. > I think that I have used all the major ones and there have been sign-up > problems, technical challenges and broken infrastructure at some stage > with all of them. But none of these are automatically established. The problem isn't so much with 6to4, which works fine once you get it working. The problem is equipement using 6to4 without explictly being told to use it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From john.mann@monash.edu Tue May 3 00:42: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 6FF14E06E2; Tue, 3 May 2011 00:42:08 -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, 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 Mrnqqo1UWLWr; Tue, 3 May 2011 00:42:07 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 69C34E06D0; Tue, 3 May 2011 00:42:07 -0700 (PDT) Received: from mail-yi0-f47.google.com ([209.85.218.47]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTb+xzqNNF2551iKAChE9lkzqbNAt9bGV@postini.com; Tue, 03 May 2011 00:42:07 PDT Received: by mail-yi0-f47.google.com with SMTP id 13so2649672yia.20 for ; Tue, 03 May 2011 00:42:06 -0700 (PDT) Received: by 10.91.150.18 with SMTP id c18mr7747823ago.135.1304408526127; Tue, 03 May 2011 00:42:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.98.7 with HTTP; Tue, 3 May 2011 00:41:46 -0700 (PDT) In-Reply-To: References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> From: "John Mann (ITS)" Date: Tue, 3 May 2011 17:41:46 +1000 Message-ID: To: "Livingood, Jason" Content-Type: multipart/alternative; boundary=0016e64652dad7810d04a25a4686 Cc: "Richard L. Barnes" , "v6ops@ietf.org" , Dave Crocker , IETF Discussion Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 07:42:08 -0000 --0016e64652dad7810d04a25a4686 Content-Type: text/plain; charset=ISO-8859-1 On 3 May 2011 04:48, Livingood, Jason wrote: > In any of the various IPv6 fora (including v6ops at the IETF) "DNS > Whitelisting" is how this practice is typically labeled. When writing the > draft I felt this could be confusing outside of IPv6 circles and so > lengthened it to "IPv6 DNS AAAA Whitelisting" in the title. > > In any case, "I don't like what it is called" is difficult to act on. ;-) > If there are recommendations on alternatives, I'm all ears. > I would prefer a name that indicated that it was the resolvers that are whitelisted. >From the draft: >>> When implemented, DNS whitelisting in practice means that a domain's > >>> authoritative DNS will return a AAAA resource record to DNS recursive > >>> resolvers [RFC1035] on the whitelist, while returning no AAAA > >>> resource records to DNS resolvers which are not on the whitelist. > ... > The AAAA records aren't thr things being whitelisted. How about "IPv6 DNS Resolver Whitelisting" or "IPv6 AAAA DNS Resolver Whitelisting" John --0016e64652dad7810d04a25a4686 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 3 May 2011 04:48, Livingood, Jason <Ja= son_Livingood@cable.comcast.com> wrote:
In any of the various IPv6 fora (including v6ops at the IETF) "DNS
Whitelisting" is how this practice is typically labeled. When writing = the
draft I felt this could be confusing outside of IPv6 circles and so
lengthened it to "IPv6 DNS AAAA Whitelisting" in the title.

In any case, "I don't like what it is called" is difficult to= act on. ;-)
If there are recommendations on alternatives, I'm all ears.


I would prefer a name that indicate= d that it was the resolvers that are whitelisted.
From the draft:=

>&= gt;> =A0 When implemented, DNS whitelisting in practice means that a dom= ain's
>>> =A0 authoritative DNS will return a AAAA resource record to DN= S recursive
>>> =A0 resolvers [RFC1035] on the whitelist, while returning no A= AAA
>>> =A0 resource records to DNS resolvers which are not on the whi= telist. =A0...

The AAAA rec= ords aren't thr things being whitelisted.

How = about "IPv6 DNS Resolver Whitelisting"
or "IPv6 AAAA DNS Resolver Whitelisting"

=A0 =A0 John=A0
--0016e64652dad7810d04a25a4686-- From pch-b6B5344D9@u-1.phicoh.com Tue May 3 00:54: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 84069E06D0 for ; Tue, 3 May 2011 00:54:46 -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=2.000, 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 p+LoFHryprCk for ; Tue, 3 May 2011 00:54:46 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 53444E068B for ; Tue, 3 May 2011 00:54:44 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #39) id m1QHARF-0001jAC; Tue, 3 May 2011 09:54 +0200 Message-Id: To: Graham Beneke From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> In-reply-to: Your message of "Tue, 03 May 2011 08:05:04 +0200 ." <4DBF9B10.4050705@apolix.co.za> Date: Tue, 03 May 2011 09:54:29 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 07:54:46 -0000 In your letter dated Tue, 03 May 2011 08:05:04 +0200 you wrote: >We are yet to see the critical mass. When this happens there will be >'real customers' shouting real loud at a NOC near you to get these >things fixed. In much the same way they do when they can reach their >favourite IPv4 service. > >When the next important cloud based business application arrives as IPv6 >only, we are not going to see people patiently waiting for their >provider to roll out native IPv6. There are a couple of alternatives you may want to consider: - Teredo. This has the advantage that it runs over UDP and actively probes NAT. The disadvantages of anycast routing are still there. And it seems to be as unreliable as 6to4. But it is essentially a drop-in replacement for 6to4. - Alternatively, there is 6rd. Works a lot like 6to4 but doesn't rely on anycast addresses and doesn't need global IPv4 address, so it much more compatible with carrier grade NAT. 6rd has be provided by your ISP, but I guess that by the time IPv6 becomes essential, all ISPs will do some kind of IPv6. And of course, you can get tunnels from HE or SIXXS now. From v6ops@globis.net Tue May 3 00:55: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 E7912E06DB for ; Tue, 3 May 2011 00:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.224, 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 t8Rk8M7A8jNZ for ; Tue, 3 May 2011 00:55:37 -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 13ED8E0780 for ; Tue, 3 May 2011 00:55:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id CECE987006A; Tue, 3 May 2011 09:55:34 +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 SDTwGYtVpFyf; Tue, 3 May 2011 09:55:29 +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 83696870002; Tue, 3 May 2011 09:55:29 +0200 (CEST) Message-ID: <4DBFB4E7.5010806@globis.net> Date: Tue, 03 May 2011 09:55:19 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: john.mann@monash.edu, "v6ops@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 07:55:38 -0000 Warning: this is danger of me taking this off topic from 6to4, but John asked the question and made some statements about ISATAP. IHMO [please please correct me/ improve this information if I'm wrong] ISATAP (RFC5214) runs over Protocol 41 tunnels. ISATAP does not have "configured tunneling" i.e. end to end tunnels where both ends are configured manually: it is also an automatic tunneling mechanism. ISATAP is enabled by default in Windows 7 but can be disabled in the registry (Services\tcpip6\Parameters\DisabledComponents to 0x4.) Anyone who can place "isatap" in DNS or WINS can activate ISATAP for ALL hosts on a Windows 7 enterprise network at next reboot. ISATAP also suffers from reliability issues within a corporate environment that includes firewalls (because of its use of protocol 41 and automatic tunnels to an "unknown" endpoint). Microsoft don't recommend "large" deployments of ISATAP as it is not scalable (to the best of my knowledge. I'm repeating advice from a Microsoft bod here and don't have a direct reference source) IPv6 over ISATAP over IPv4 is preferred over native IPv4 as far as I understand from the current RFC3484. [and at least according to Microsoft's book Understanding IPv6 v2 p219-221] ISATAP will still be preferred over native IPv4 in RFC3484 bis, even though Teredo and 6to4 aren't [I've already mailed the authors about this] As ISATAP is based on well-known node identifiers (and not a well-known network prefix) it does not fit neatly into the RFC3484 IPv6-prefix-based policy table, so a network manager can't effectively enable ISATAP, but force it to be less preferred than native IPv4. IMVHO in other words, it's potentially a very nasty accident waiting to happen in a corporate environment. But I have no evidence of current problems. - all of this is clearly way outside the scope of the 6to4 discussion, but should not be forgotten if anyone feels like "improving" this situation, especially giving network operations managers the ability to configure preferring native IPv4 over ISATAP, because AFAIK no-one is covering this item in v6ops or 6man at the moment. regards, RayH From lorenzo@google.com Tue May 3 01: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 EA8CDE07B5 for ; Tue, 3 May 2011 01:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.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, 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 BmS7CzqeeTsU for ; Tue, 3 May 2011 01:07:55 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D8D25E07B3 for ; Tue, 3 May 2011 01:07:54 -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 p4387q6L013832 for ; Tue, 3 May 2011 01:07:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304410073; bh=Wf0JdLtU2JkHqm9fSGaD+89hay4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dgQx+XEHPp19yMPylBCkSt9UsQZFJa+rRBcUyvGv6PFi1HyeWcQrK8qgXiQMgzXC4 tFdf35znnyWqQC4vLPmGw== Received: from yib19 (yib19.prod.google.com [10.243.65.83]) by wpaz24.hot.corp.google.com with ESMTP id p4386qYf032441 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 3 May 2011 01:07:51 -0700 Received: by yib19 with SMTP id 19so2815489yib.18 for ; Tue, 03 May 2011 01:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Xx1NjxJiBinC0Bw11uC7GiFXzA7oSp5j63gHHAVq6zo=; b=bn01WFtmgtmVvSijSNBPL3fjlNrp3QzDwPKQVQ9XgsPQVV6GN9w5w0wsqlMeb4by/g v6xpQkP90eyEIqGdiQ6w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=ogJMpUMvNh2goTuLCkqG0nQIbZxuN+m2cBFkVjFCAWSoHimpuUESjwgfghIWOmlAgR kIrzvK+wCo0qjr5R/aoA== Received: by 10.151.86.3 with SMTP id o3mr715120ybl.150.1304410071099; Tue, 03 May 2011 01:07:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Tue, 3 May 2011 01:07:31 -0700 (PDT) In-Reply-To: <4DBF2569.4070509@apolix.co.za> References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> From: Lorenzo Colitti Date: Tue, 3 May 2011 10:07:31 +0200 Message-ID: To: Graham Beneke Content-Type: multipart/alternative; boundary=000e0cd28feeedeb4a04a25aa269 X-System-Of-Record: true Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 08:07:56 -0000 --000e0cd28feeedeb4a04a25aa269 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 2, 2011 at 11:43 PM, Graham Beneke wrote: > 'IPv6-only' has up to now only been something that I've seen discussed in > experimental environments but with the APNIC address pool exhaustion it is > quickly becoming a reality. If we remove 6to4 from the protocol bouquet then > what do we point users to with this predicament? > I don't think this is a concern. First, there is no real problem to solve at the moment. Before reachability to IPv6-only hosts can become a problem, IPv6 deployment needs to be well on its way, and as long as 6to4 is around we can't get IPv6 deployment well on its way. Second, even when it becomes a problem to solve, 6to4 is not an useful solution, given that it simply fails 10-20% of the time. --000e0cd28feeedeb4a04a25aa269 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 2, 2011 at 11:43 PM, Graham Beneke <= span dir=3D"ltr"><graham@apolix.co.za> wrote:
'IPv6-only' has up to now only been something that I've se= en discussed in experimental environments but with the APNIC address pool e= xhaustion it is quickly becoming a reality. If we remove 6to4 from the prot= ocol bouquet then what do we point users to with this predicament?

I don't think this is a concern.
=

First, there is no real problem to solve at the moment.= =A0Before reachability to IPv6-only hosts can become a problem, IPv6 deploy= ment needs to be well on its way, and as long as 6to4 is around we can'= t get IPv6 deployment well on its way.

Second, even when it becomes a problem to solve, 6to4 i= s not an useful solution, given that it simply fails 10-20% of the time.
--000e0cd28feeedeb4a04a25aa269-- From mohacsi@niif.hu Tue May 3 01:22: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 AE227E0688 for ; Tue, 3 May 2011 01:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, 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 pZBUEVRm1VJ7 for ; Tue, 3 May 2011 01:22:20 -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 3A170E068B for ; Tue, 3 May 2011 01:22:20 -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 460A087499; Tue, 3 May 2011 10:22:18 +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 b2pozgF1WYPs; Tue, 3 May 2011 10:22:02 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id A7B4287496; Tue, 3 May 2011 10:22:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id A38C787492; Tue, 3 May 2011 10:22:02 +0200 (CEST) Date: Tue, 3 May 2011 10:22:02 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Philip Homburg In-Reply-To: Message-ID: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> 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 Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 08:22:21 -0000 On Tue, 3 May 2011, Philip Homburg wrote: > In your letter dated Tue, 03 May 2011 08:05:04 +0200 you wrote: >> We are yet to see the critical mass. When this happens there will be >> 'real customers' shouting real loud at a NOC near you to get these >> things fixed. In much the same way they do when they can reach their >> favourite IPv4 service. >> >> When the next important cloud based business application arrives as IPv6 >> only, we are not going to see people patiently waiting for their >> provider to roll out native IPv6. > > There are a couple of alternatives you may want to consider: > - Teredo. This has the advantage that it runs over UDP and actively probes > NAT. The disadvantages of anycast routing are still there. And it seems to > be as unreliable as 6to4. But it is essentially a drop-in replacement for > 6to4. According to the analysis of Geoff Huston Teredo is stranger and similarly unreliable protocol to 6to4: http://labs.ripe.net/Members/gih/testing-teredo while in 6to4 you can attribute the most of failure to 41 protocol filtering and broken routing, in Teredo you cannot distinguish broken NATs, filtering, or broken implementation. I agree with Geoff Huston: Teredo must be off by default. If someone want to experiement he or she will switch on. > - Alternatively, there is 6rd. Works a lot like 6to4 but doesn't rely on > anycast addresses and doesn't need global IPv4 address, so it much more > compatible with carrier grade NAT. 6rd has be provided by your ISP, but > I guess that by the time IPv6 becomes essential, all ISPs will do some > kind of IPv6. 6rd is basically a 6to4 relying on a IPv4 autotunnel with a ISP managed IPv4 infrastructure. Not much difference. The key advantage is here, that ISP is taking care of the tunnel. I think that providing services with carrier grade NAT will not be easy: Will you put in your service aggremeent, that your user can not use your favourite private address space used in CGN e.g. 10.0.0.0/8? If you customer is using same portion of this address, will you assist renumbering their network? Why not assist to deploy IPv6? Biggest problem of 6rd deployment however, lack of widespread 6rd implementation in CPEs. Much less implemenetation than 6to4. > > And of course, you can get tunnels from HE or SIXXS now. Yes, the managed tunnels is the most reliable approach. Best Regards, Janos Mohacsi > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From sm@resistor.net Tue May 3 01:44: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 F22CFE0708; Tue, 3 May 2011 01:44:12 -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 Stq2tb4nHhjE; Tue, 3 May 2011 01:44:12 -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 8A521E06F9; Tue, 3 May 2011 01:44:11 -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 p438i0pG009037; Tue, 3 May 2011 01:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1304412247; bh=ZMG3Jbs9lcvyDyzFT0OqqWeeklQjEOnLHI0xYEiK8sc=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=mrM1QXElWZJjpTcATEL753wMVfeRjCNztV/LzRbGQ7o09o5gwXNuBFGv4vxltdby5 IEXvluclmngt/Ul3qeQgU+9SJI+nXyIuAXH85S/EItvrUVRH7FWTjyuGdqj1I725c9 n+RSyh4zcpE0sk5XP4FKZSrkYPttx0WF1bVlb7fs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1304412247; bh=ZMG3Jbs9lcvyDyzFT0OqqWeeklQjEOnLHI0xYEiK8sc=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=FJdPw0ED1ExMWtztQUSmQmYuyS3VEQUnZ/FCcVo/FNR8C9uq3Kux/Gq06gxY6Tw5E ZxOMf4hoZydYDN9NI1PejhBb4MepUHZS5AydjVn6ukALd9BGGYu96xCL3ZJf+XBIY7 vZIsedlm+a9EcBh+ZMAMAN+j9cXUvPjTZCMvdZqc= Message-Id: <6.2.5.6.2.20110502215922.05513e20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 May 2011 01:43:10 -0700 To: "Livingood, Jason" From: SM In-Reply-To: References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: v6ops@ietf.org, IETF Discussion Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 08:44:13 -0000 Hi Jason, At 11:48 02-05-2011, Livingood, Jason wrote: >In any of the various IPv6 fora (including v6ops at the IETF) "DNS >Whitelisting" is how this practice is typically labeled. When writing the >draft I felt this could be confusing outside of IPv6 circles and so >lengthened it to "IPv6 DNS AAAA Whitelisting" in the title. > >In any case, "I don't like what it is called" is difficult to act on. ;-) >If there are recommendations on alternatives, I'm all ears. Repurposing a sentence from the draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03: "By engaging in a DNS tradeoff, they are attempting to shield users with impaired access from the symptoms of those impairments." Web content providers use a DNS tradeoff to avoid losing quality and money as most ISPs are reluctant to pour money into IPv6. At least Comcast has a plan to provide each of their users with 18,446,744,073,709,551,616 IPv6 addresses. Given that draft-ietf-v6ops-v6-aaaa-whitelisting-implications has been reviewed by DNSOP and v6ops, and that the intended status is Informational, it is difficult to give it a "DNP". RFC 3901 mentions "Policy Based Avoidance of Name Space Fragmentation". The DNS technique used in the draft (split-view) contributes to name space fragmentation. If you wanted to argue for "DNP", you could have the following text from the v6ops Charter at the bottom of the list: "IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops WG may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems." If you want to argue against "DNP", you can always say that you are merely documenting the stupid things people have to do get IPv6 deployed. I am stupid but I am not that stupid to go and argue about a draft that has been blessed by DNSOP and v6ops. :-) Andrew Sullivan mentioned WCP [1]. That RFC sub-series does not exist yet. The best fit is FYI. As a comment that will not be considered as part of the Last Call, I would have given the draft a DNP if I had to review it. I don't have to say that as the draft already got a five DISCUSS rating. That won't prevent a well-known search engine from deploying the mechanism described in this draft. Someone might come to me and say that "well-known search does this, why can't you do it; it's even a RFC". I'll read the Mathematical Principles of Natural Philosophy to see whether I can find an answer to that. :-) On an unrelated note, there was a mistake in the message I posted previously [2]. The last sentence should be read as: As I do not meet the religious requirements, I cannot take a position on this draft. Regards, -sm 1. http://www.ietf.org/mail-archive/web/ietf/current/msg66311.html 2. http://www.ietf.org/mail-archive/web/ietf/current/msg66203.html From pch-b6B5344D9@u-1.phicoh.com Tue May 3 02:54: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 A684DE0790 for ; Tue, 3 May 2011 02:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.266 X-Spam-Level: X-Spam-Status: No, score=-7.266 tagged_above=-999 required=5 tests=[AWL=1.333, 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 jUSH0K7d8aXT for ; Tue, 3 May 2011 02:54:01 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id E0A95E0719 for ; Tue, 3 May 2011 02:53:59 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #39) id m1QHCIX-0001rTC; Tue, 3 May 2011 11:53 +0200 Message-Id: To: Mohacsi Janos From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> In-reply-to: Your message of "Tue, 3 May 2011 10:22:02 +0200 (CEST) ." Date: Tue, 03 May 2011 11:53:38 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 09:54:06 -0000 In your letter dated Tue, 3 May 2011 10:22:02 +0200 (CEST) you wrote: >According to the analysis of Geoff Huston Teredo is stranger and similarly >unreliable protocol to 6to4: > >I agree with Geoff Huston: Teredo must be off by default. If someone want >to experiement he or she will switch on. An unmanaged protocol that is essentially unused, no wonder it doesn't work. But yes, making sure it is turned off by default is important. >> - Alternatively, there is 6rd. Works a lot like 6to4 but doesn't rely on >> anycast addresses and doesn't need global IPv4 address, so it much more >> compatible with carrier grade NAT. 6rd has be provided by your ISP, but >> I guess that by the time IPv6 becomes essential, all ISPs will do some >> kind of IPv6. > >6rd is basically a 6to4 relying on a IPv4 autotunnel with a ISP managed >IPv4 infrastructure. Not much difference. The key advantage is here, that >ISP is taking care of the tunnel. I think that is a very important difference. Certainly when the CPE is also provided by the ISP, there is a much greater chance that it will actually work. >I think that providing services with carrier grade NAT will not be easy: >Will you put in your service aggremeent, that your user can not use your >favourite private address space used in CGN e.g. 10.0.0.0/8? If you >customer is using same portion of this address, will you assist >renumbering their network? Why not assist to deploy IPv6? Most setups I have seen in recent years default to 192.168.0.0/16. Assuming CGN will be used for new connections, then the ISP will have no problems telling customers to just avoid 10.0.0.0/8 or get a modem that can handle this. I guess that if the customer uses 10.a.b.0/24 and the ISP advertises provides the customer with 10.x.y.z/24 then it should not be hard for the modem to keep those ranges apart. From sander@steffann.nl Tue May 3 03:01: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 CB22FE07CC for ; Tue, 3 May 2011 03:01:49 -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=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.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 cWyEwhgaZ+t9 for ; Tue, 3 May 2011 03:01:49 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 94DFFE07C3 for ; Tue, 3 May 2011 03:01:48 -0700 (PDT) Received: from dhcp-26-116.ripemtg.ripe.net (dhcp-26-116.ripemtg.ripe.net [193.0.26.116]) by mail.sintact.nl (Postfix) with ESMTP id 1C236204C; Tue, 3 May 2011 12:01:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: Date: Tue, 3 May 2011 12:01:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 10:01:49 -0000 Hi, > In your letter dated Tue, 3 May 2011 10:22:02 +0200 (CEST) you wrote: >> According to the analysis of Geoff Huston Teredo is stranger and = similarly=20 >> unreliable protocol to 6to4: >>=20 >> I agree with Geoff Huston: Teredo must be off by default. If someone = want=20 >> to experiement he or she will switch on. >=20 > An unmanaged protocol that is essentially unused, no wonder it doesn't = work. >=20 > But yes, making sure it is turned off by default is important. I don't really like Teredo, but: why? The end-node uses Teredo only when = it is IPv4-only and it needs to reach an IPv6-only destination. Without = Teredo it will certainly not work. With Teredo enabled it might work. = It's not perfect, but better than certain failure... >> 6rd is basically a 6to4 relying on a IPv4 autotunnel with a ISP = managed=20 >> IPv4 infrastructure. Not much difference. The key advantage is here, = that=20 >> ISP is taking care of the tunnel. >=20 > I think that is a very important difference. Certainly when the CPE is = also > provided by the ISP, there is a much greater chance that it will = actually work. Usually the ISP offers this as a service, and will make sure it works. = Their support center will suffer otherwise, which costs money :) - Sander From mohacsi@niif.hu Tue May 3 03:19: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 79B7DE07CF for ; Tue, 3 May 2011 03:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 92gqcHmzYUAf for ; Tue, 3 May 2011 03:19:03 -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 80DEFE07C2 for ; Tue, 3 May 2011 03:19:03 -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 C01F78748E; Tue, 3 May 2011 12:19:01 +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 97n150UE6aS4; Tue, 3 May 2011 12:18:46 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 16ED087481; Tue, 3 May 2011 12:18:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 14425871D9; Tue, 3 May 2011 12:18:46 +0200 (CEST) Date: Tue, 3 May 2011 12:18:45 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Philip Homburg In-Reply-To: Message-ID: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> 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 Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 10:19:04 -0000 On Tue, 3 May 2011, Philip Homburg wrote: >> 6rd is basically a 6to4 relying on a IPv4 autotunnel with a ISP managed >> IPv4 infrastructure. Not much difference. The key advantage is here, that >> ISP is taking care of the tunnel. > > I think that is a very important difference. Certainly when the CPE is also > provided by the ISP, there is a much greater chance that it will actually work. In the actual 6rd deployments yes. But it should be designed to be universal - where users will buy the CPEs. I see only one vendor claiming to support 6rd, but they working on it and actually will be rather unversal: http://labs.ripe.net/Members/mirjam/ipv6-cpe-survey-updated-january-2011 > >> I think that providing services with carrier grade NAT will not be easy: >> Will you put in your service aggremeent, that your user can not use your >> favourite private address space used in CGN e.g. 10.0.0.0/8? If you >> customer is using same portion of this address, will you assist >> renumbering their network? Why not assist to deploy IPv6? > > Most setups I have seen in recent years default to 192.168.0.0/16. Assuming > CGN will be used for new connections, then the ISP will have no problems > telling customers to just avoid 10.0.0.0/8 or get a modem that can handle > this. 192.168.0.0/16 used mostly only in off the shelf SOHO routers for home users. But CGN is not only for these customers, but enterprise customers also: Most of the enterprise users I meet using at least two of RFC 1918 address space - two address sapce for two purpose... > I guess that if the customer uses 10.a.b.0/24 and the ISP advertises > provides the customer with 10.x.y.z/24 then it should not be hard for the modem > to keep those ranges apart. Uh!ohh! Are your really able to keep up to date thousands of such an address space? Good luck! Best Regards, Janos Mohacsi From pch-b6B5344D9@u-1.phicoh.com Tue May 3 03:57: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 A2A34E07C5 for ; Tue, 3 May 2011 03:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 ueXT2MRrAQcr for ; Tue, 3 May 2011 03:57:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 786F0E073F for ; Tue, 3 May 2011 03:57:55 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #39) id m1QHDIg-0001jwC; Tue, 3 May 2011 12:57 +0200 Message-Id: To: Sander Steffann From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> In-reply-to: Your message of "Tue, 3 May 2011 12:01:46 +0200 ." Date: Tue, 03 May 2011 12:57:34 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 10:57:57 -0000 In your letter dated Tue, 3 May 2011 12:01:46 +0200 you wrote: >I don't really like Teredo, but: why? The end-node uses Teredo only when = >it is IPv4-only and it needs to reach an IPv6-only destination. Without = >Teredo it will certainly not work. With Teredo enabled it might work. = >It's not perfect, but better than certain failure... Is it that simple? There are lots of protocols that embed IP addresses. For example, peer to peer or sip. Do you want to patch all software to avoid teredo addresses? The Internet is complex enough, and with CGN and IPv6 it only gets way more complex. If you also tunneling protocols often don't work, then it may just become an unmanagable chaos. From pch-b6B5344D9@u-1.phicoh.com Tue May 3 04:17: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 1E718E073D for ; Tue, 3 May 2011 04:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.799 X-Spam-Level: X-Spam-Status: No, score=-7.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 mg6izin2Gk2W for ; Tue, 3 May 2011 04:17:01 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 66BF6E06A6 for ; Tue, 3 May 2011 04:16:59 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #39) id m1QHDav-0001jbC; Tue, 3 May 2011 13:16 +0200 Message-Id: To: Mohacsi Janos From: Philip Homburg Sender: pch-b6B5344D9@u-1.phicoh.com References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> In-reply-to: Your message of "Tue, 3 May 2011 12:18:45 +0200 (CEST) ." Date: Tue, 03 May 2011 13:16:44 +0200 Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 11:17:02 -0000 In your letter dated Tue, 3 May 2011 12:18:45 +0200 (CEST) you wrote: >192.168.0.0/16 used mostly only in off the shelf SOHO routers for home >users. But CGN is not only for these customers, but enterprise customers >also: Most of the enterprise users I meet using at least two of RFC 1918 >address space - two address sapce for two purpose... In most markets, enterprise customers pay enough that you can pay somebody to figure out the best solution. I don't think there is any technical limitation why you would not be able to NAT between two identical netblocks. Alternatively, there are many other netblocks that can be hijacked if you make sure the fact that you do it doesn't leak out. From ichiroumakino@gmail.com Tue May 3 04:20: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 0E348E07AB for ; Tue, 3 May 2011 04:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.907 X-Spam-Level: X-Spam-Status: No, score=-3.907 tagged_above=-999 required=5 tests=[AWL=1.092, BAYES_00=-2.599, GB_I_LETTER=-2, 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 A7TH33Wd-2Ug for ; Tue, 3 May 2011 04:20:30 -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 C6889E073D for ; Tue, 3 May 2011 04:20:29 -0700 (PDT) Received: by wwa36 with SMTP id 36so4917863wwa.13 for ; Tue, 03 May 2011 04:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=cHQYI/4uclMeVUsWFeH0ainRbBYdy57Ozt86fUyPh04=; b=OQ9uDNxl4JRbO4jd0mMYUamchmc0eQfsI9iUCtYT4SafqTMfJw6VGeWtTAURLQmbG5 jgx/f7iezBzgGxByqfBLA4sG1tqiN4uPu4CvSbpnQuNgvhiVcM/poYbED/OTJz4N8Qd4 gsg1ief48qoxqZkAKtOT5+VGIHZ2AJTBktbOg= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=WbQ8m5qAQeQxyAmaDQu6sUTBdEE5OwZcFJEFX7OWFDpdYDwXeZuuxVR6uYIWFImvzr 5EZDy6/STyiYgzoHPjhSG7YP4yJwstDPCHOFr0NNn/Tuf2MRu6YC6zcv/FVqzQ9X/1Iy bd4/vwOzjo8YzpwsJtHmCfbzn21/Is4IUSdYY= Received: by 10.216.144.166 with SMTP id n38mr3520564wej.75.1304421628845; Tue, 03 May 2011 04:20:28 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-245.cisco.com ([64.103.53.245]) by mx.google.com with ESMTPS id e13sm3943071wbi.57.2011.05.03.04.20.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2011 04:20:27 -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: Tue, 3 May 2011 13:20:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <270C92B8-380E-41EE-B376-B6ACD20BA457@employees.org> References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 11:20:31 -0000 I take the latest discussions in the 6to4-historic threads to indicate = that there are no further comments on the revision-02 text? cheers, Ole On May 3, 2011, at 13:16 , Philip Homburg wrote: > In your letter dated Tue, 3 May 2011 12:18:45 +0200 (CEST) you wrote: >> 192.168.0.0/16 used mostly only in off the shelf SOHO routers for = home=20 >> users. But CGN is not only for these customers, but enterprise = customers=20 >> also: Most of the enterprise users I meet using at least two of RFC = 1918=20 >> address space - two address sapce for two purpose... >=20 > In most markets, enterprise customers pay enough that you can pay = somebody > to figure out the best solution. I don't think there is any technical > limitation why you would not be able to NAT between two identical = netblocks. > Alternatively, there are many other netblocks that can be hijacked if = you > make sure the fact that you do it doesn't leak out. >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sander@steffann.nl Tue May 3 05: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 4BA19E07F4 for ; Tue, 3 May 2011 05:19:59 -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=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.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 tNeEJa4jJxvX for ; Tue, 3 May 2011 05:19:58 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 43807E06A4 for ; Tue, 3 May 2011 05:19:58 -0700 (PDT) Received: from dhcp-26-116.ripemtg.ripe.net (dhcp-26-116.ripemtg.ripe.net [193.0.26.116]) by mail.sintact.nl (Postfix) with ESMTP id 6A6EE204C; Tue, 3 May 2011 14:19:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Sander Steffann In-Reply-To: Date: Tue, 3 May 2011 14:19:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 12:19:59 -0000 Hi, > In your letter dated Tue, 3 May 2011 12:01:46 +0200 you wrote: >> I don't really like Teredo, but: why? The end-node uses Teredo only = when =3D >> it is IPv4-only and it needs to reach an IPv6-only destination. = Without =3D >> Teredo it will certainly not work. With Teredo enabled it might work. = =3D >> It's not perfect, but better than certain failure... >=20 > Is it that simple? There are lots of protocols that embed IP = addresses.=20 > For example, peer to peer or sip. Do you want to patch all software to = avoid > teredo addresses?=20 So: if a protocol embeds an IPv6 address and you don't have Teredo then = the address will be useless and the protocol won't work for certain... = If you use name/DNS based references then the OS shouldn't use Teredo as = long as there is another way to connect. If Teredo/Miredo is deployed/implemented in a different way then I agree = with you: that will cause more harm than it's worth... Sander From john.mann@monash.edu Tue May 3 05:23: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 1110BE073D for ; Tue, 3 May 2011 05:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.576 X-Spam-Level: X-Spam-Status: No, score=-5.576 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 11oS6uHD8D1i for ; Tue, 3 May 2011 05:23:45 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id F1D68E07F4 for ; Tue, 3 May 2011 05:23:44 -0700 (PDT) Received: from mail-vw0-f49.google.com ([209.85.212.49]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTb/z0D7v2k1w3+w14hsqCtDS4PVgGIlO@postini.com; Tue, 03 May 2011 05:23:45 PDT Received: by mail-vw0-f49.google.com with SMTP id 8so8917vws.8 for ; Tue, 03 May 2011 05:23:44 -0700 (PDT) Received: by 10.52.74.97 with SMTP id s1mr1954089vdv.40.1304425424095; Tue, 03 May 2011 05:23:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.108.134 with HTTP; Tue, 3 May 2011 05:23:24 -0700 (PDT) In-Reply-To: <4DBFB4E7.5010806@globis.net> References: <4DBFB4E7.5010806@globis.net> From: "John Mann (ITS)" Date: Tue, 3 May 2011 22:23:24 +1000 Message-ID: To: Ray Hunter Content-Type: multipart/alternative; boundary=bcaec501669d0a08db04a25e360c Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 12:23:52 -0000 --bcaec501669d0a08db04a25e360c Content-Type: text/plain; charset=ISO-8859-1 Hi, On 3 May 2011 17:55, Ray Hunter wrote: > Warning: this is danger of me taking this off topic from 6to4, but John > asked the question and made some statements about ISATAP. > > IHMO [please please correct me/ improve this information if I'm wrong] > > ISATAP (RFC5214) runs over Protocol 41 tunnels. > > ISATAP does not have "configured tunneling" i.e. end to end tunnels where > both ends are configured manually: it is also an automatic tunneling > mechanism. > > ISATAP is enabled by default in Windows 7 but can be disabled in the > registry (Services\tcpip6\Parameters\DisabledComponents to 0x4.) > > Anyone who can place "isatap" in DNS or WINS can activate ISATAP for ALL > hosts on a Windows 7 enterprise network at next reboot. > > ISATAP also suffers from reliability issues within a corporate environment > that includes firewalls (because of its use of protocol 41 and automatic > tunnels to an "unknown" endpoint). > You see "reliability issues", I see "flexibility" and "control points". There can be selective enablement using a hierarchy of DNS names - isatap.eng.example.com and isatap.prod.example.com, but no isatap.admin.example.com nor isatap.example.com For reliability, the "isatap" DNS RRs can provide a list of ISATAP router addresses, and the ISATAP router addresses can be anycast - there is no gateway or flow -specific state like 6to4, Teredo or NAT44. A client will periodically poll for a working ISATAP gateway. Client routing over ISATAP doesn't come up unless the RS / RA packet exchange can be completed over protocol-41. The ISATAP up or not decision is not made per-flow. Inside the enterprise, I can filter protocol-41 such that clients on subnets with native IPv6 can't get to any ISATAP router. Some corners of my network don't have native IPv6 (e.g. Cisco WISM wireless VLANs using AAA-override). Using router lists and ACLs, I plan to let IPv4-only staff subnets get to one set of ISATAP routers, and student/guest subnets get to another set - putting staff and students on separate ISATAP subnets. > Microsoft don't recommend "large" deployments of ISATAP as it is not > scalable (to the best of my knowledge. I'm repeating advice from a Microsoft > bod here and don't have a direct reference source) > > IPv6 over ISATAP over IPv4 is preferred over native IPv4 as far as I > understand from the current RFC3484. [and at least according to Microsoft's > book Understanding IPv6 v2 p219-221] > > ISATAP will still be preferred over native IPv4 in RFC3484 bis, even though > Teredo and 6to4 aren't [I've already mailed the authors about this] > > As ISATAP is based on well-known node identifiers (and not a well-known > network prefix) it does not fit neatly into the RFC3484 IPv6-prefix-based > policy table, so a network manager can't effectively enable ISATAP, but > force it to be less preferred than native IPv4. > > IMVHO in other words, it's potentially a very nasty accident waiting to > happen in a corporate environment. But I have no evidence of current > problems. > The worst behaviour I have seen is the occasional client that gets tangled and sends out *thousands* of DNS queries per second looking for isatap.* names that don't exist. > - all of this is clearly way outside the scope of the 6to4 discussion, but > should not be forgotten if anyone feels like "improving" this situation, > especially giving network operations managers the ability to configure > preferring native IPv4 over ISATAP, because AFAIK no-one is covering this > item in v6ops or 6man at the moment. > > regards, > RayH > John --bcaec501669d0a08db04a25e360c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 3 May 2011 17:55, Ray Hunter <v6ops@globis.net&g= t; wrote:
Warning: this is danger of me taking this off topic from 6to4, but John ask= ed the question and made some statements about ISATAP.

IHMO [please please correct me/ improve this information if I'm wrong]<= br>
ISATAP (RFC5214) =A0runs over Protocol 41 tunnels.

ISATAP does not have "configured tunneling" i.e. end to end tunne= ls where both ends are configured manually: it is also an automatic tunneli= ng mechanism.

ISATAP is enabled by default in Windows 7 but can be disabled in the regist= ry (Services\tcpip6\Parameters\DisabledComponents to 0x4.)

Anyone who can place "isatap" in DNS or WINS can activate ISATAP = for ALL hosts on a Windows 7 enterprise network at next reboot.

ISATAP also suffers from reliability issues within a corporate environment = that includes firewalls (because of its use of protocol 41 and automatic tu= nnels to an "unknown" endpoint).

You see "reliability issues", I see "flexibility" = and "control points".

There can be selec= tive enablement using a=A0hierarchy=A0of DNS names - isatap.eng.example.com and isatap.prod.example.com, but no isatap.admin.example.com nor isatap.example.com

For reliability, the "isatap" DNS RRs can pro= vide a list of ISATAP router addresses, and the ISATAP router addresses can= be anycast - there is no gateway or flow -specific state like 6to4, Teredo= or NAT44.

A client will periodically poll for a working ISATAP ga= teway.
Client routing over ISATAP doesn't come up unless= the RS / RA packet exchange can be completed over protocol-41.
The ISATAP up or not decision is not made per-flow.

Inside the enterprise, I can filter protocol-41 such that clients on= subnets with native IPv6 can't get to any ISATAP router.
Some corners of my network don't have native IPv6 (e.g. Cisco WISM wire= less VLANs using AAA-override). =A0
Using router lists and ACLs, = I plan to let IPv4-only staff subnets get to one set of ISATAP routers, and= student/guest subnets get to another set - putting staff and students on s= eparate ISATAP subnets.
=A0
Microsoft don't recommend "large" deployments of ISATAP as it= is not scalable (to the best of my knowledge. I'm repeating advice fro= m a Microsoft bod here and don't have a direct reference source)

IPv6 over ISATAP over IPv4 is preferred over native IPv4 as far as I unders= tand from the current RFC3484. [and at least according to Microsoft's b= ook Understanding IPv6 v2 p219-221]

ISATAP will still be preferred over native IPv4 in RFC3484 bis, even though= Teredo and 6to4 aren't [I've already mailed the authors about this= ]

As ISATAP is based on well-known node identifiers (and not a well-known net= work prefix) it does not fit neatly into the RFC3484 IPv6-prefix-based poli= cy table, so a network manager can't effectively enable ISATAP, but for= ce it to be less preferred than native IPv4.

IMVHO in other words, it's potentially a very nasty accident waiting to= happen in a corporate environment. But I have no evidence of current probl= ems.

The worst behaviour I have seen is= the occasional client that gets tangled and sends out *thousands* of DNS q= ueries per second looking for isatap.* names that don't exist.
=A0
- all of this is clearly way outside the scope of the 6to4 discussion, but = should not be forgotten if anyone feels like "improving" this sit= uation, especially giving network operations managers the ability to config= ure preferring native IPv4 over ISATAP, because AFAIK no-one is covering th= is item in v6ops or 6man at the moment.

regards,
RayH

=A0 =A0 John=A0

--bcaec501669d0a08db04a25e360c-- From wbeebee@cisco.com Tue May 3 05:30: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 866BAE0805 for ; Tue, 3 May 2011 05:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlNPqLCfOwtQ for ; Tue, 3 May 2011 05:30:48 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id DD1E0E07CD for ; Tue, 3 May 2011 05:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=737; q=dns/txt; s=iport; t=1304425848; x=1305635448; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=qaVGkBSFXqGck8OyN+G7+0e73jf6OqHaaGeUR+g65wo=; b=RzhVa1UwbsDGyNtAj3LoHBKIDQbusmmkbo2UbrkKb7pI0AkPzSZR4TmQ cFuwqAVjBBzZ3iHJUeAvP/WTth6+jtpYEV+wSACfwsLRn4Q6nQ9hY7tys w909zsVSJyJymjQz9CPwur4tJDVQosexadjcGdb2oF7B1EVhoTIcSusT7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0FAKv0v02tJV2b/2dsb2JhbACmCQJ3iHKgM5xnhgIEjxiEI4ZEg2c X-IronPort-AV: E=Sophos;i="4.64,309,1301875200"; d="scan'208";a="349316766" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-2.cisco.com with ESMTP; 03 May 2011 12:30:48 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p43CUmj0016395; Tue, 3 May 2011 12:30:48 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 May 2011 07:30:47 -0500 Received: from 161.44.175.134 ([161.44.175.134]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Tue, 3 May 2011 12:30:47 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Tue, 03 May 2011 08:30:46 -0400 From: Wes Beebee To: Thomas Narten Message-ID: Thread-Topic: [v6ops] 6to4-historic summary point: 4. "Phase out plan" Thread-Index: AcwJje0cfw22XlAFM0qd/lPkSfTBBA== In-Reply-To: <201105022142.p42Lgn96024618@cichlid.raleigh.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 May 2011 12:30:47.0530 (UTC) FILETIME=[EE05D4A0:01CC098D] Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 12:30:49 -0000 >>> So, every router will now be required to inspect the inner contents of >>> tunneled packets they are forwarding in order to find these rogue >>> packets? Will never happen. Way too big of a performance hit. Good >>> example of a "wishful thinking" requirement. > >> And they already implement a full stateful firewall capable of supporting a >> multitude of ALG's that inspect every packet already. This requirement is >> not really that much of a performance hog compared to a firewall. > > Huh? Every single router, including those in the DFZ/core are > firewalls inspecting every packet? And of course doing this at line > rates... I was under the impression that this was a *CPE router* requirement... - Wes From Wesley.E.George@sprint.com Tue May 3 06:47: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 2AE17E0694 for ; Tue, 3 May 2011 06:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 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 AZpfFUXzQ5aX for ; Tue, 3 May 2011 06:47:04 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 202E1E0680 for ; Tue, 3 May 2011 06:47:03 -0700 (PDT) Received: from mail122-ch1-R.bigfish.com (216.32.181.171) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.8; Tue, 3 May 2011 13:47:03 +0000 Received: from mail122-ch1 (localhost.localdomain [127.0.0.1]) by mail122-ch1-R.bigfish.com (Postfix) with ESMTP id 352A515A812B; Tue, 3 May 2011 13:47:03 +0000 (UTC) X-SpamScore: -32 X-BigFish: VS-32(zz9371O542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI Received: from mail122-ch1 (localhost.localdomain [127.0.0.1]) by mail122-ch1 (MessageSwitch) id 1304430416490150_9038; Tue, 3 May 2011 13:46:56 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243]) by mail122-ch1.bigfish.com (Postfix) with ESMTP id BC784E101A6; Tue, 3 May 2011 13:46:21 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 3 May 2011 13:46:18 +0000 Received: from PDAWEH01.ad.sprint.com (PDAWEH01.corp.sprint.com [144.226.110.69]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p43DkH9d023239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 May 2011 08:46:17 -0500 Received: from PDAWM12B.ad.sprint.com ([fe80::64c8:fd69:1029:79b0]) by PDAWEH01.ad.sprint.com ([2002:90e2:6e45::90e2:6e45]) with mapi id 14.01.0270.001; Tue, 3 May 2011 08:46:17 -0500 From: "George, Wes E [NTK]" To: Graham Beneke , "v6ops@ietf.org" Thread-Topic: [v6ops] 6to4-historic summary point: 4. "Phase out plan" Thread-Index: AQHMCRHrl+ofOlca3UKckPJbLoyElZR7GleQ Date: Tue, 3 May 2011 13:46:16 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8E27B@PDAWM12B.ad.sprint.com> References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> In-Reply-To: <4DBF2569.4070509@apolix.co.za> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.69] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002F_01CC0976.F1A1DE90" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 13:47:05 -0000 ------=_NextPart_000_002F_01CC0976.F1A1DE90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Graham Beneke Sent: Monday, May 02, 2011 5:43 PM To: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" While I accept that there are grave concerns about 6to4, I feel that completely scrapping it leaves us with the following problem: How to IPv4-only hosts reach IPv6-only content? ____________ [WEG] Perhaps I'm being overly literal in my interpretation of your comment, but I hope that you realize that 6to4 is not a method to interwork IPv4-only *hosts* and IPv6-only *hosts*. An IPv4-only host by definition cannot even use 6to4. 6to4 is simply a way to tunnel IPv6 traffic from an IPv6-capable (usually dual-stack) host across some amount of IPv4 only *network* elements to another IPv6-capable host. It's a transition technology, but it's for transitioning your transport, not your applications. 'IPv6-only' has up to now only been something that I've seen discussed in experimental environments but with the APNIC address pool exhaustion it is quickly becoming a reality. If we remove 6to4 from the protocol bouquet then what do we point users to with this predicament? ____________ [WEG] well, at first, the onus is going to be on those who have IPv6-only networks/hosts to put in the proper app layer gateway/translation devices (such as NAT64) if they want their IPv6-only stuff to be able to talk to IPv4. At some point, enough of the planet is dual-stack, then it switches and the gateway moves to sit in front of the pockets of IPv4-only devices still remaining. Wes George ------=_NextPart_000_002F_01CC0976.F1A1DE90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwMzEz NDYxNVowIwYJKoZIhvcNAQkEMRYEFKDE3fKoFs55fZjQdzkG3sAi8G4YMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgD/BDS+fnBq5nGKKKxi4rL7m9jEGaq2QyJClT4qYXlX4LTg3TSqUV3BnagTSP+MzRbW0 kx4cgKihf6uX0n6MG9E3apWxw2qSpv9guS2880VLaIq9LI+PpyEy8DWCmLsqebXsOe6Ik1DBMLSs wH+wQshMoi1Ny9f145oLhaicAzm2AAAAAAAA ------=_NextPart_000_002F_01CC0976.F1A1DE90-- From bs7652@att.com Tue May 3 07:18: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 2D819E06B6 for ; Tue, 3 May 2011 07:18:02 -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 zoIm4Epqfmpo for ; Tue, 3 May 2011 07:18:01 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9A157E06A8 for ; Tue, 3 May 2011 07:18:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1304432280!15713968!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 13602 invoked from network); 3 May 2011 14:18:00 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2011 14:18:00 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p43EGuXZ010594; Tue, 3 May 2011 10:16:57 -0400 Received: from 01GAF5142010622.AD.BLS.COM (01GAF5142010622.ad.bls.com [139.76.131.83]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with SMTP id p43EGmx5010370; Tue, 3 May 2011 10:16:48 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 May 2011 10:17:30 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 May 2011 10:17:29 -0400 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, 3 May 2011 10:17:49 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 Thread-Index: AcwJZZr228xB7yvrR9ad1S9eV1cGEgANdXRw References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> From: "STARK, BARBARA H (ATTSI)" To: "John Mann (ITS)" , "Livingood, Jason" X-OriginalArrivalTime: 03 May 2011 14:17:29.0800 (UTC) FILETIME=[D612B480:01CC099C] Cc: "Richard L. Barnes" , v6ops@ietf.org, Dave Crocker Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 14:18:02 -0000 > How about "IPv6 DNS Resolver Whitelisting" > or "IPv6 AAAA DNS Resolver Whitelisting" Well, I guess if we're going to discuss changing the name from what it had been (which I was fine with), then it should be to something that accurately reflects what is being discussed. The whitelisting is of DNS Resolvers that are using DNSv4 protocol, and not "IPv6 DNS" Resolvers or "IPv6 AAAA DNS" Resolvers. The purpose of the whitelisting is to determine which DNSv4 Resolvers are sent AAAA records in a response. So, maybe "DNSv4 Resolver Whitelisting" (short name) or "DNSv4 Resolver Whitelisting for Inclusion of AAAA Record in Response" (longer name) Barbara From gert@space.net Tue May 3 07:20: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 A8AB9E06A8 for ; Tue, 3 May 2011 07:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 hF8YuS7QMHVE for ; Tue, 3 May 2011 07:20:38 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id BCDA6E0684 for ; Tue, 3 May 2011 07:20:37 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 2F338F8189 for ; Tue, 3 May 2011 16:20:36 +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 141E2F8111 for ; Tue, 3 May 2011 16:20:36 +0200 (CEST) Received: (qmail 51963 invoked by uid 1007); 3 May 2011 16:20:35 +0200 Date: Tue, 3 May 2011 16:20:35 +0200 From: Gert Doering To: Graham Beneke Message-ID: <20110503142035.GF30227@Space.Net> References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DBF2569.4070509@apolix.co.za> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 14:20:38 -0000 Hi, On Mon, May 02, 2011 at 11:43:05PM +0200, Graham Beneke wrote: > While I accept that there are grave concerns about 6to4, I feel that > IPv4-only hosts reach IPv6-only content? Have you seen any IPv6-only content recently? Seriously: content will need to be available on IPv4 for a very long time, so I don't expect to see IPv6-only content in the next years. 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 ek@google.com Tue May 3 07:34: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 9582CE06C9 for ; Tue, 3 May 2011 07:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.957 X-Spam-Level: X-Spam-Status: No, score=-106.957 tagged_above=-999 required=5 tests=[AWL=-1.580, 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 LtQ53DhD51RA for ; Tue, 3 May 2011 07:34: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 CD48FE0684 for ; Tue, 3 May 2011 07:34:26 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p43EYOC0025350 for ; Tue, 3 May 2011 07:34:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304433265; bh=3Iyps1FuJC+tbIrRRjfEuz/6jWI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=NIAbtFCWknPn6EPlu4KZthr9mMIxRwZ4nO2lTzfzjaYwExxqVcQ/6FPPsxrbwdRED J4f0Vn2jz6el2F6EfZmWQ== Received: from pzk6 (pzk6.prod.google.com [10.243.19.134]) by kpbe17.cbf.corp.google.com with ESMTP id p43EYMX2030955 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 3 May 2011 07:34:23 -0700 Received: by pzk6 with SMTP id 6so74768pzk.40 for ; Tue, 03 May 2011 07:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VEp8dsk4hZFP9+vD/XdKx8h39faFtFL+a/4X0rW/EqA=; b=Dkna3WnBrqqpTWDn9KjQBtsi6sxu5m5G9LudnTfhtoXf3yGPk9iNqms2RWZlsAM5MT R8finsolLoVU2nsHosfg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BXWqsgyltN4eqb5Fr4XZ5+VSvF6dJtVxIw8i7TqAHFpTlBG7/eKB9b1W8bNO8nCCVh 29oKMDq5SbPwYxnjTEnQ== MIME-Version: 1.0 Received: by 10.142.250.2 with SMTP id x2mr3729255wfh.381.1304433261751; Tue, 03 May 2011 07:34:21 -0700 (PDT) Received: by 10.142.245.14 with HTTP; Tue, 3 May 2011 07:34:21 -0700 (PDT) In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> Date: Tue, 3 May 2011 23:34:21 +0900 Message-ID: From: Erik Kline To: "STARK, BARBARA H (ATTSI)" Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "Richard L. Barnes" , v6ops@ietf.org, Dave Crocker Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 14:34:27 -0000 DNSv6 is theoretically in scope as well. (i.e. we would include IPv6 prefixes in our resolver ACLs if [and when] we serve authoritative DNS over v6) On 3 May 2011 23:17, STARK, BARBARA H (ATTSI) wrote: >> How about "IPv6 DNS Resolver Whitelisting" >> or "IPv6 AAAA DNS Resolver Whitelisting" > > Well, I guess if we're going to discuss changing the name from what it > had been (which I was fine with), then it should be to something that > accurately reflects what is being discussed. The whitelisting is of DNS > Resolvers that are using DNSv4 protocol, and not "IPv6 DNS" Resolvers or > "IPv6 AAAA DNS" Resolvers. The purpose of the whitelisting is to > determine which DNSv4 Resolvers are sent AAAA records in a response. > > So, maybe "DNSv4 Resolver Whitelisting" (short name) or "DNSv4 Resolver > Whitelisting for Inclusion of AAAA Record in Response" (longer name) > > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From graham@apolix.co.za Tue May 3 07:36: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 2D8B0E0820 for ; Tue, 3 May 2011 07:36:42 -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 NY+Zj-fAVy3G for ; Tue, 3 May 2011 07:36:41 -0700 (PDT) Received: from oryx.apolix.co.za (oryx.apolix.co.za [41.73.36.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6F72DE06C9 for ; Tue, 3 May 2011 07:36:41 -0700 (PDT) Received: from wbs-41-208-231-194.wbs.co.za ([41.208.231.194] helo=[192.168.1.131]) by oryx.apolix.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QHGfB-0000ae-N4; Tue, 03 May 2011 16:33:22 +0200 Message-ID: <4DC0122F.7020904@apolix.co.za> Date: Tue, 03 May 2011 16:33:19 +0200 From: Graham Beneke User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: "George, Wes E [NTK]" References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8E27B@PDAWM12B.ad.sprint.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8E27B@PDAWM12B.ad.sprint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AuthenticatedID: graham@apolix.co.za X-Report-Abuse-To: abuse@apolix.co.za X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - oryx.apolix.co.za X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - apolix.co.za Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 14:36:42 -0000 On 03/05/2011 15:46, George, Wes E [NTK] wrote: > [WEG] well, at first, the onus is going to be on those who have IPv6-only networks/hosts to put in the proper app layer > gateway/translation devices (such as NAT64) if they want their IPv6-only stuff to be able to talk to IPv4. At some point, enough of > the planet is dual-stack, then it switches and the gateway moves to sit in front of the pockets of IPv4-only devices still > remaining. NAT64 only provides a mechanism for clients on IPv6-only clouds to connect to services on IPv4-only clouds. It does not provide translation in the other direction. v6 aware/v4 connected clients need a way of reaching the IPv6-only services when these become more prevalent. -- Graham Beneke From lorenzo@google.com Tue May 3 08:08: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 B6AECE0841 for ; Tue, 3 May 2011 08:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.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, 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 BQsd-az2cJzR for ; Tue, 3 May 2011 08:08:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAFFE083D for ; Tue, 3 May 2011 08:08:01 -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 p43EYmPK031068 for ; Tue, 3 May 2011 07:34:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304433289; bh=hfrszDbuaQr0F9kq7f/GWZap6AA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=RsvdBXonpiQwngEyndJelyceVXUgg92al5IC9R/qffLo1OsS33LRoA0XsgaMMDvXO rzSLzCtfeoCN3Weoq4NXA== Received: from gwj21 (gwj21.prod.google.com [10.200.10.21]) by hpaq11.eem.corp.google.com with ESMTP id p43EWwcw027631 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 3 May 2011 07:34:47 -0700 Received: by gwj21 with SMTP id 21so63142gwj.2 for ; Tue, 03 May 2011 07:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RsXTReQ9UufcQYt3uZzbBe6FMDhtdabTnzJErZXZSto=; b=qryccygQXlS3DAIS8QbTXn0MwbRcK4/o6UJsCD4bSHdaO1f9c7SMb2LaReO4UaW8wl kyyYXHDZ1PSUySa3DC2Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=WgWnUCA2qT5bVHcdjTBZWKIF6f9+cSjqVh8p3dKv8v+xST1DsFQmNc/jrAHzrvZD8E JPo/TYArePufuKK9vkeg== Received: by 10.150.7.15 with SMTP id 15mr15355ybg.378.1304433287176; Tue, 03 May 2011 07:34:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Tue, 3 May 2011 07:34:27 -0700 (PDT) In-Reply-To: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> From: Lorenzo Colitti Date: Tue, 3 May 2011 16:34:27 +0200 Message-ID: To: Fred Baker Content-Type: multipart/alternative; boundary=000e0cd28788b7249204a2600a35 X-System-Of-Record: true Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 15:08:02 -0000 --000e0cd28788b7249204a2600a35 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 2, 2011 at 7:19 PM, Fred Baker wrote: > I think it is very reasonable. I personally question the wisdom of a > documented phase-out plan, for the reasons Brian has mentioned. > How about changing "existing implementations and deployments MAY continue to use 6to4" from MAY to something that says "SHOULD not"? --000e0cd28788b7249204a2600a35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 2, 2011 at 7:19 PM, Fred Baker <fred@cisco.com> wrote:
I think it is very reasonable. I personally question the = wisdom of a documented phase-out plan, for the reasons Brian has mentioned.=

How about changing "existing im= plementations and deployments MAY continue to use 6to4" from MAY to so= mething that says "SHOULD not"?=A0
--000e0cd28788b7249204a2600a35-- From gvandeve@cisco.com Tue May 3 08:12: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 20D6AE0771 for ; Tue, 3 May 2011 08:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.394 X-Spam-Level: X-Spam-Status: No, score=-9.394 tagged_above=-999 required=5 tests=[AWL=2.605, BAYES_00=-2.599, GB_I_LETTER=-2, 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 CShOn9Skd0l8 for ; Tue, 3 May 2011 08:12: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 DC168E06CF for ; Tue, 3 May 2011 08:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=2266; q=dns/txt; s=iport; t=1304435575; x=1305645175; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ABhB42AYpmw1AGBO7V81m/J8cWxzzQQljyqBa5f3Efc=; b=D4dbcd0EVl8fY8Htr+e8ehl2vi+Vcb9NVU63Uukm9mz/iv3yqPcDk1cM DvfjOH64p0pMgKdNTaKv9pJATfAHbkE1BUEBLwS6lY+QSO0Z5bHYrjFgy mBLQOktL8rY/1UOGzhZCWZ9gR65AEOKnRrfQvJjxrcKXXndDPgmKAyb6J w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAEAOoawE2Q/khMgWdsb2JhbACmHBQBARYmJYhyn0qce4YCBJM7ihE X-IronPort-AV: E=Sophos;i="4.64,309,1301875200"; d="scan'208";a="28465556" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 03 May 2011 15:12:54 +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 p43FCsUY004994; Tue, 3 May 2011 15:12:54 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); Tue, 3 May 2011 17:12:54 +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: Tue, 3 May 2011 17:12:52 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E503940EE7@XMB-AMS-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6to4-historic summary point: 4. "Phase out plan" Thread-Index: AcwJeS2tNOa8Or6YToCh3EXsFQtI5QAKxlFg References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com><2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com><4DBF2569.4070509@apolix.co.za><20110503003420.36EA1E68B4F@drugs.dv.isc.org><4DBF9B10.4050705@apolix.co.za> From: "Gunter Van de Velde (gvandeve)" To: "Sander Steffann" , "Philip Homburg" X-OriginalArrivalTime: 03 May 2011 15:12:54.0231 (UTC) FILETIME=[93969E70:01CC09A4] Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 15:12:57 -0000 >> But yes, making sure it is turned off by default is important. > I don't really like Teredo, but: why? The end-node uses Teredo only when it is IPv4-only and it needs to reach an > IPv6-only destination. Without Teredo it will certainly not work. With Teredo enabled it might work. It's not=20 > perfect, but better than certain failure... I think from an individual home-user that may be what one wants and could be acceptable, however if I am an Enterprise IT manager, that is not what I want as I do not want to see tunneled traffic that bypasses my firewall. G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Sander Steffann Sent: 03 May 2011 03:02 To: Philip Homburg Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" Hi, > In your letter dated Tue, 3 May 2011 10:22:02 +0200 (CEST) you wrote: >> According to the analysis of Geoff Huston Teredo is stranger and similarly=20 >> unreliable protocol to 6to4: >>=20 >> I agree with Geoff Huston: Teredo must be off by default. If someone want=20 >> to experiement he or she will switch on. >=20 > An unmanaged protocol that is essentially unused, no wonder it doesn't work. >=20 > But yes, making sure it is turned off by default is important. I don't really like Teredo, but: why? The end-node uses Teredo only when it is IPv4-only and it needs to reach an IPv6-only destination. Without Teredo it will certainly not work. With Teredo enabled it might work. It's not perfect, but better than certain failure... >> 6rd is basically a 6to4 relying on a IPv4 autotunnel with a ISP managed=20 >> IPv4 infrastructure. Not much difference. The key advantage is here, that=20 >> ISP is taking care of the tunnel. >=20 > I think that is a very important difference. Certainly when the CPE is also > provided by the ISP, there is a much greater chance that it will actually work. Usually the ISP offers this as a service, and will make sure it works. Their support center will suffer otherwise, which costs money :) - Sander _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From bs7652@att.com Tue May 3 08:16: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 12897E06B5 for ; Tue, 3 May 2011 08:16:07 -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 nX3eouF3oHhg for ; Tue, 3 May 2011 08:16:06 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 57B80E0695 for ; Tue, 3 May 2011 08:16:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1304435765!15764557!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 32538 invoked from network); 3 May 2011 15:16:05 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2011 15:16:05 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p43FEvMO027763; Tue, 3 May 2011 11:14:57 -0400 Received: from 01GAF5142010624.AD.BLS.COM (01GAF5142010624.ad.bls.com [139.76.131.91]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with SMTP id p43FEoLM027584; Tue, 3 May 2011 11:14:50 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 May 2011 11:15:32 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 May 2011 11:15:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 3 May 2011 11:15:51 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6DF9@crexc50p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 Thread-Index: AcwJny2oGO1jBNzGTBuJK4FuRW/b2AAAOl7Q References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com><750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> From: "STARK, BARBARA H (ATTSI)" To: "Erik Kline" X-OriginalArrivalTime: 03 May 2011 15:15:32.0084 (UTC) FILETIME=[F1AD1340:01CC09A4] Cc: "Richard L. Barnes" , v6ops@ietf.org, Dave Crocker Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 15:16:07 -0000 PiBETlN2NiBpcyB0aGVvcmV0aWNhbGx5IGluIHNjb3BlIGFzIHdlbGwuICAoaS5lLiB3ZSB3b3Vs ZCBpbmNsdWRlIElQdjYNCj4gcHJlZml4ZXMgaW4gb3VyIHJlc29sdmVyIEFDTHMgaWYgW2FuZCB3 aGVuXSB3ZSBzZXJ2ZSBhdXRob3JpdGF0aXZlIEROUw0KPiBvdmVyIHY2KQ0KDQpUaGF0J3MgaW50 ZXJlc3RpbmcuIEkgZG9uJ3QgdGhpbmsgdGhlIGN1cnJlbnQgZHJhZnQgcmVhbGx5IGNvdmVycyB0 aGF0IGNhc2UuIFdvdWxkIHRoaXMgc3RpbGwgYmUgZm9yIHRoZSBwdXJwb3NlIG9mIGRldGVybWlu aW5nIHdoZXRoZXIgb3Igbm90IHRvIHNlbmQgQUFBQSByZWNvcmRzPw0KDQpJIGRvbid0IHRoaW5r IHRoYXQgdGhlIGp1c3RpZmljYXRpb25zIGxpc3RlZCBpbiB0aGUgZHJhZnQgYXJlIHN1ZmZpY2ll bnQgdG8gZXhwbGFpbiB3aHkgSVB2NiBwcmVmaXhlcyBtaWdodCBiZSBpbmNsdWRlZCBpbiB0aGUg d2hpdGVsaXN0LiBUaGUganVzdGlmaWNhdGlvbnMgY3VycmVudGx5IHNlZW0gdG8gY2VudGVyIGFy b3VuZCAiYnJva2VuIElQdjYgaW1wbGVtZW50YXRpb25zIiB0aGF0IGNhdXNlIGJhZCB1c2VyIGV4 cGVyaWVuY2Ugd2hlbiBjbGllbnQgZGV2aWNlcyB0cnkgdG8gdXNlIEFBQUEgcmVjb3JkcyBiZWNh dXNlIHRoZXkgdGhpbmsgdGhleSBoYXZlIElQdjYgY29ubmVjdGl2aXR5IGJ1dCB0aGV5IHJlYWxs eSBkb24ndDsgYW5kIElTUHMgdGhhdCB3YW50IHRvIGxpbWl0IElQdjYgdHJhZmZpYyB3aGVuIHRo ZXkgdHVybiB1cCBJUHY2LCBzbyB0aGV5IGxpa2UgdGhlIGZhY3QgdGhhdCBBQUFBIHJlY29yZHMg YXJlbid0IHJldHVybmVkIGluIG1hbnkgY2FzZXMuIEkgaGF2ZW4ndCBoZWFyZCBhbnlvbmUgZGVz Y3JpYmUgSVB2NiBicm9rZW5uZXNzIGluIHRoZSBjb250ZXh0IG9mIGNsaWVudHMgdGhhdCBzdWNj ZXNzZnVsbHkgdXNlIEROU3Y2ICh3aGVyZSBjdXJyZW50bHkgdGhlcmUgc2VlbXMgdG8gYmUgYSBn b29kIGNvcnJlbGF0aW9uIGJldHdlZW4gdGhlIGFiaWxpdHkgdG8gZG8gRE5TdjYgYW5kIHRvIG1h a2UgZ29vZCB1c2Ugb2YgQUFBQSByZWNvcmRzKS4gSSBhbHNvIGRvbid0IHRoaW5rIHRoYXQgSVB2 NiBhZGRyZXNzZXMgZm9yIEROUyByZXNvbHZlcnMgYXJlIGdvaW5nIHRvIGJlIHNvbWV0aGluZyBk ZXBsb3llZCBlYXJseSBvbiBieSBJU1BzIHdobyBmZWVsIHRoZSBuZWVkIHRvIGxpbWl0IElQdjYg dHJhZmZpYy4gVGhlcmUgYXJlIHN0aWxsIHNvIG1hbnkgY2xpZW50cyB0aGF0IGFyZSB1bmFibGUg dG8gYmUgYXV0b21hdGljYWxseSBnaXZlbiBJUHY2IGFkZHJlc3NlcyBmb3IgZG9pbmcgRE5TLCB0 aGF0IGl0IGp1c3QgaXNuJ3QgYSBwcmlvcml0eS4gQ291bGQgeW91IGV4cGxhaW4gdGhlIGp1c3Rp ZmljYXRpb25zIGZvciBJUHY2IHByZWZpeGVzIGluIHRoZXNlIEROUyByZXNvbHZlciB3aGl0ZWxp c3RzPyBBbmQgd291bGQgdGhpcyBiZSBwYXJ0IG9mIGEgbG9uZy1saXZlZCB3aGl0ZWxpc3Rpbmcg c3RyYXRlZ3k/IFRoZSBjdXJyZW50IGRvY3VtZW50IHNlZW1zIHRvIHN1Z2dlc3QgdGhlIG5lZWQg Zm9yIHRoZXNlIHdoaXRlbGlzdHMgbWlnaHQgZGllIG91dCBvbmNlIGdvb2Qtd29ya2luZyBJUHY2 IGNvbm5lY3Rpdml0eSBiZWNvbWVzIHRoZSBub3JtLiBCdXQgaWYgSVB2NiBwcmVmaXhlcyBhcmUg aW5jbHVkZWQsIHRoZW4gdGhhdCBtYXkgbm90IGJlIHJpZ2h0Lg0KDQpTbyBJIGd1ZXNzIHRoaXMg YWxsIGJyaW5ncyB1cCB0aGUgZm9sbG93aW5nIHF1ZXN0aW9ucyBpbiBteSBtaW5kOg0KMS4gSXMg dGhlcmUgYSBuZWVkIHRvIGV4cGFuZCB0aGUgZHJhZnQgdG8gaW5jbHVkZSB3aGl0ZWxpc3Rpbmcg b2YgRE5TIHJlc29sdmVycyBmb3IgcHVycG9zZXMgb3RoZXIgdGhhbiB3aGV0aGVyIG9yIG5vdCB0 byBpbmNsdWRlIEFBQUEgcmVjb3JkcyBpbiB0aGUgcmVzcG9uc2U/DQoyLiBJcyB0aGVyZSBhIG5l ZWQgdG8gZXhwYW5kIHRoZSBkcmFmdCB0byBpbmNsdWRlIGV4cGxpY2l0IGRpc2N1c3Npb24gKGp1 c3RpZmljYXRpb24sIGV0Yy4pIGZvciB3aGl0ZWxpc3Rpbmcgb2YgSVB2NiBwcmVmaXhlcyBvZiBE TlMgcmVzb2x2ZXJzPw0KDQpCYXJiYXJhDQo= From lorenzo@google.com Tue May 3 08: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 8F8F4E0695 for ; Tue, 3 May 2011 08:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.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, 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 56BgqByuleMg for ; Tue, 3 May 2011 08:20:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 681D1E062A for ; Tue, 3 May 2011 08:20:49 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p43FKY7k010646 for ; Tue, 3 May 2011 08:20:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304436048; bh=B4jrugh4qF3fKJyVxM9f7CVfiKc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=SYgoRxoESS/e1SKPd77w5oCoad/uRJhpuoqxoZh2LSDg0UA1CYsaJUzpng+hCQXlz 9dmeeZiuBLVS7DdRgPRGQ== Received: from ywf9 (ywf9.prod.google.com [10.192.6.9]) by kpbe14.cbf.corp.google.com with ESMTP id p43FJCSg013899 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 3 May 2011 08:20:33 -0700 Received: by ywf9 with SMTP id 9so88067ywf.8 for ; Tue, 03 May 2011 08:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VeDYLQqIa2M7EoRM2PRbnc1GincfPgaGI+okUysiadg=; b=mmb7zIpYFKkOaE1vUTHVBgaXZr7yvixm8GTMO3tV5j6Mo/pgOKqML2KygXhGKhIYLV Bmhxd+3MQpR9FVjL33WQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=X1ELa+1ZT61KrtNBx6nUu72jhQpwYgr0/qoTFeQrepFL00S6G/1jE8PZWTZzwGx1Bj sSS6PWIHs7/Rpuvw18Vw== Received: by 10.151.86.3 with SMTP id o3mr94706ybl.150.1304436033167; Tue, 03 May 2011 08:20:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Tue, 3 May 2011 08:20:12 -0700 (PDT) In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6DF9@crexc50p> References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6DF9@crexc50p> From: Lorenzo Colitti Date: Tue, 3 May 2011 17:20:12 +0200 Message-ID: To: "STARK, BARBARA H (ATTSI)" Content-Type: multipart/alternative; boundary=000e0cd28fee63a10204a260aef1 X-System-Of-Record: true Cc: v6ops@ietf.org, Dave Crocker , "Richard L. Barnes" Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 15:20:59 -0000 --000e0cd28fee63a10204a260aef1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 3, 2011 at 5:15 PM, STARK, BARBARA H (ATTSI) wrote: > I haven't heard anyone describe IPv6 brokenness in the context of clients > that successfully use DNSv6 (where currently there seems to be a good > correlation between the ability to do DNSv6 and to make good use of AAAA > records). > A client could use DNSv4 to talk to a recursive resolver which would then send the query to the auth server over IPv6. That would be broken. --000e0cd28fee63a10204a260aef1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 3, 2011 at 5:15 PM, STARK, BARBARA H= (ATTSI) <bs7652@att= .com> wrote:
I haven't heard anyone describe IPv6 brokenness in th= e context of clients that successfully use DNSv6 (where currently there see= ms to be a good correlation between the ability to do DNSv6 and to make goo= d use of AAAA records).

A client could use DNSv4 to talk to a recu= rsive resolver which would then send the query to the auth server over IPv6= . That would be broken.
--000e0cd28fee63a10204a260aef1-- From ek@google.com Tue May 3 08:26: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 79616E0761 for ; Tue, 3 May 2011 08:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.113 X-Spam-Level: X-Spam-Status: No, score=-107.113 tagged_above=-999 required=5 tests=[AWL=-1.136, 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 vf4mnxHlZdQp for ; Tue, 3 May 2011 08:26: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 2262DE0735 for ; Tue, 3 May 2011 08:26:11 -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 p43FQBW5014073 for ; Tue, 3 May 2011 08:26:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304436371; bh=zNgBnY68/hTkXuYh+9KLYJl7i48=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=CKat+sMsQfoAaZZP1LRagWv8yWEe1RCCvG6AHysa1L99unBt4na02pnrG/+lj+IWz eum/gW23SvXLGdtqN5hLw== Received: from pxi7 (pxi7.prod.google.com [10.243.27.7]) by hpaq7.eem.corp.google.com with ESMTP id p43FQ8cK031387 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 3 May 2011 08:26:10 -0700 Received: by pxi7 with SMTP id 7so104194pxi.16 for ; Tue, 03 May 2011 08:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tz3z8wPhBulX1jLvls3T6BGNcTyk5BQM4Xp2d7bKH4Q=; b=OqJ/gV9Q0WHFU1K0/BGHUzVg8DbSf8jpCG+yCvajjhj71BIn4oeCbWraQL0JljYfuw PPJyFegi2u6ho2N016Vg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TFc8HGgFMRW5mj5O/As2eaRJvmZsdJRIoltsmgSdbW0diyRtziHc2/nXh3G22gzXDQ uzkhgw/EwVfQau6XFF3Q== MIME-Version: 1.0 Received: by 10.142.224.13 with SMTP id w13mr841354wfg.39.1304436368135; Tue, 03 May 2011 08:26:08 -0700 (PDT) Received: by 10.142.245.14 with HTTP; Tue, 3 May 2011 08:26:08 -0700 (PDT) In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6DF9@crexc50p> References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6DF9@crexc50p> Date: Wed, 4 May 2011 00:26:08 +0900 Message-ID: From: Erik Kline To: "STARK, BARBARA H (ATTSI)" Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "Richard L. Barnes" , v6ops@ietf.org, Dave Crocker Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 15:26:13 -0000 There's a lot the draft doesn't discuss. Google is the only entity actively doing this right now, though Akamai has announced that they are doing it (auto-discovering what's safe to add to a whitelist), and both Facebook and Yahoo have expressed interest in doing this (Facebook has already begun whitelisting actually). AFAIK none of use have contributed substantially to this document, nor do I have the time to fix all the things that would need fixing (I'd just write a new doc and don't even have the time to do that). IMHO, this document is not a real discussion of whitelisting mechanics and motivations. It is, rather, a harangue against its use, despite the fact that it is, and may remain for some period (which we all do want to be as short as possible), an operational reality/necessity. From Internet-Drafts@ietf.org Tue May 3 09:30: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 9C917E0651; Tue, 3 May 2011 09:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 A0L7KSFVQJRH; Tue, 3 May 2011 09:30:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5942E0856; Tue, 3 May 2011 09:30:06 -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.52 Message-ID: <20110503163006.1084.49715.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2011 09:30:06 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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: Tue, 03 May 2011 16:30:07 -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 : Advisory Guidelines for 6to4 Deployment Author(s) : B. Carpenter Filename : draft-ietf-v6ops-6to4-advisory-01.txt Pages : 20 Date : 2011-04-26 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-advisory-01.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-6to4-advisory-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-03092145.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue May 3 09:30: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 B4A04E083E; Tue, 3 May 2011 09:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 E1RIIeqblCRM; Tue, 3 May 2011 09:30:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF11AE085D; Tue, 3 May 2011 09:30:06 -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.52 Message-ID: <20110503163006.1084.8100.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2011 09:30:06 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-to-historic-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, 03 May 2011 16:30:08 -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 : Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status Author(s) : O. Troan Filename : draft-ietf-v6ops-6to4-to-historic-02.txt Pages : 7 Date : 2011-05-02 Experience with the "Connection of IPv6 Domains via IPv4 Clouds (6to4)" IPv6 transitioning mechanism has shown that the mechanism is unsuitable for widespread deployment and use in the Internet. This document requests that RFC3056 and the companion document "An Anycast Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-02.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-6to4-to-historic-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-03092228.I-D@ietf.org> --NextPart-- From lorenzo@google.com Tue May 3 09:36: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 039DAE087D for ; Tue, 3 May 2011 09:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.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, 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 XVjv+igOvoSI for ; Tue, 3 May 2011 09:36:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id A9A5CE06C3 for ; Tue, 3 May 2011 09:36:19 -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 p43GaDRW006289 for ; Tue, 3 May 2011 09:36:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304440578; bh=D52MVLYOxkJCa4etMEPldlPy2fw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=KFXmwXxNlHxklW48nXBngSW+ym1UOjj5HoPrM0VgL3eOGgLhorlyUNPS+Tjb6OKdf 2WSczTg75OengZEZOPekw== Received: from gwj21 (gwj21.prod.google.com [10.200.10.21]) by kpbe12.cbf.corp.google.com with ESMTP id p43Ga030011093 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 3 May 2011 09:36:11 -0700 Received: by gwj21 with SMTP id 21so135747gwj.16 for ; Tue, 03 May 2011 09:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/AOlZPb3MQjNBvioBfuwoJdrIGl/DEpa4jZtTRROgRg=; b=jm4W6fd0dh2UeNQCsTFVeCLgsdlMDqeG0EMVG63DiQB0LFiHWfDFJ1d7OVPUMHhIfq 0bKtftq5k9Y2qOZslFEA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=TI3zTq80NCXsfvZ3pvFXsGiIdPcglv0T+/Q1tPT+HcILyPb05ogaqoj6GCdLZd8p5V 2BCTUmt1Roc2G0WvFNww== Received: by 10.150.195.18 with SMTP id s18mr153721ybf.207.1304440571153; Tue, 03 May 2011 09:36:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Tue, 3 May 2011 09:35:51 -0700 (PDT) In-Reply-To: References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6DF9@crexc50p> From: Lorenzo Colitti Date: Tue, 3 May 2011 18:35:51 +0200 Message-ID: To: Erik Kline Content-Type: multipart/alternative; boundary=000e0cd4d83cdfcee004a261bcde X-System-Of-Record: true Cc: "Richard L. Barnes" , v6ops@ietf.org, Dave Crocker Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 16:36:21 -0000 --000e0cd4d83cdfcee004a261bcde Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 3, 2011 at 5:26 PM, Erik Kline wrote: > IMHO, this document is not a real discussion of whitelisting mechanics > and motivations. It is, rather, a harangue against its use, despite > the fact that it is, and may remain for some period (which we all do > want to be as short as possible), an operational reality/necessity. Right. For us (Google - but I think a lot of large website operators are in the same boat), whitelisting is the only possible option for IPv6 deployment, period. Subjecting hundreds of thousands of users to breakage is simply not an option, so while we don't particularly like the disadvantages of whitelisting, it's much, much better than doing nothing. We don't think that the draft is a balanced assessment of the situation, but at the same time, we don't have time to contribute to it, because we'd much rather be working on deployment, services, and operational concerns (e.g., 6to4 deprecation) rather than discussing something that for us is unavoidable. So we find ourselves in the situation that we don't really support the text but don't have time to influence it, and since we don't feel it's fair to simply attack the text without contributing, we're simply letting the document run its course. As Erik has noted, Google and Facebook are employing whitelisting, and Yahoo and Akamai have publicly announced their intention to do it. In a sense, it's just like DNS-based load-balancing. The vast majority of websites don't use it, but a lot of the very large ones do. Cheers, Lorenzo --000e0cd4d83cdfcee004a261bcde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 3, 2011 at 5:26 PM, Erik Kline <ek@google.com> wrote:
IMHO, this document is not a real discussion of whitelisting mechanics
and motivations. =A0It is, rather, a harangue against its use, despite
the fact that it is, and may remain for some period (which we all do
want to be as short as possible), an operational reality/necessity.

Right.=A0For us (Google - but I think a lot of large website = operators are in the same boat), whitelisting is the only possible option f= or IPv6 deployment, period. Subjecting hundreds of thousands of users to br= eakage is simply not an option, so while we don't particularly like the= disadvantages of whitelisting, it's much, much better than doing nothi= ng.

We don't think that the draft is a balanced assessm= ent of the situation, but at the same time, we don't have time to contr= ibute to it, because we'd much rather be working on deployment, service= s, and operational concerns (e.g., 6to4 deprecation) rather than discussing= something that for us is unavoidable.=A0So we find ourselves in the situat= ion that we don't really support the text but don't have time to in= fluence it, and since we don't feel it's fair to simply attack the = text without contributing, we're simply letting the document run its co= urse.

As Erik has noted, Google and Facebook are employing wh= itelisting, and Yahoo and Akamai have publicly announced their intention to= do it. In a sense, it's just=A0like DNS-based load-balancing. The vast= majority of websites don't use it, but a lot of the very large ones do= .

Cheers,
Lorenzo
--000e0cd4d83cdfcee004a261bcde-- From jhw@apple.com Tue May 3 10:10: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 77EADE07AE for ; Tue, 3 May 2011 10:10:04 -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 3K3H1RLFsRJG for ; Tue, 3 May 2011 10:10:04 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 05A64E0733 for ; Tue, 3 May 2011 10:10:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LKM00BXSQAF4K70@mail-out.apple.com> for v6ops@ietf.org; Tue, 03 May 2011 10:09:51 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-20-4dc036de96d9 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 relay15.apple.com (Apple SCV relay) with SMTP id 89.5A.18996.FD630CD4; Tue, 03 May 2011 10:09:51 -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 <0LKM00BFDQCE3X70@koseret.apple.com> for v6ops@ietf.org; Tue, 03 May 2011 10:09:50 -0700 (PDT) From: james woodyatt In-reply-to: <20110503003420.36EA1E68B4F@drugs.dv.isc.org> Date: Tue, 03 May 2011 10:09:50 -0700 Message-id: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1222) X-Brightmail-Tracker: AAAAAA== Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 17:10:04 -0000 On May 2, 2011, at 17:34 , Mark Andrews wrote: > > I actually think declaring 6to4 historic is way too early and that 6to4 traffic is yet to peak. For the record, I believe this too. -- james woodyatt member of technical staff, core os networking From jhw@apple.com Tue May 3 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 66B54E0827; Tue, 3 May 2011 10:21:02 -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 G9P3hX36OpES; Tue, 3 May 2011 10:21:01 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id DC4B9E0817; Tue, 3 May 2011 10:21:01 -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 <0LKM00BB1QQG4KA0@mail-out.apple.com>; Tue, 03 May 2011 10:20:52 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-f1-4dc039745224 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 05.55.29082.47930CD4; Tue, 03 May 2011 10:20:52 -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 <0LKM00KQMQURX500@koseret.apple.com>; Tue, 03 May 2011 10:20:52 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 03 May 2011 10:20:51 -0700 Message-id: References: <4DBB4A83.7010408@dcrocker.net> <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <4DBEC72D.2050901@dcrocker.net> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1222) X-Brightmail-Tracker: AAAAAA== Cc: IETF Discussion Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 17:21:02 -0000 On May 2, 2011, at 08:28 , Erik Kline wrote: > > I'm having a hard time thinking of adequate alternatives terms (but this purely a personal failing, I'm sure). Recommendations for other words? The word "enclave" springs to mind. We are talking about the use of "DNS enclaves" for serving AAAA resources rather than serving them to the public DNS horizon. -- james woodyatt member of technical staff, core os networking From pekkas@netcore.fi Tue May 3 10:24: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 3448FE0800 for ; Tue, 3 May 2011 10:24:51 -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 AS6FBOh3E9xB for ; Tue, 3 May 2011 10:24:50 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE114E0752 for ; Tue, 3 May 2011 10:24:49 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p43HO5Jo019120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 May 2011 20:24:05 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p43HO3pa019116; Tue, 3 May 2011 20:24:03 +0300 Date: Tue, 3 May 2011 20:24:03 +0300 (EEST) From: Pekka Savola To: Erik Kline In-Reply-To: Message-ID: References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi X-Virus-Status: Clean Cc: "Richard L. Barnes" , v6ops@ietf.org, Dave Crocker Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 17:24:51 -0000 On Tue, 3 May 2011, Erik Kline wrote: > DNSv6 is theoretically in scope as well. (i.e. we would include IPv6 > prefixes in our resolver ACLs if [and when] we serve authoritative DNS > over v6) I'm not sure I follow this reasoning. I may be missing something. You'd need to add AAAA glue for your authoritative DNS servers. But then DNSv6 lookups would end up being used by those recursive resolvers that are broken. So, if one employs aaaa-whitelisting, then it logically seems to follow that the authoritative servers must not have AAAA glue records. I suppose you could omit AAAA glue records from the first tier of auth servers, and have a chain of servers where the next tier could also offer AAAA and v6 records for those whitelisted, but AFAICS these should never end up in glue. > > On 3 May 2011 23:17, STARK, BARBARA H (ATTSI) wrote: >>> How about "IPv6 DNS Resolver Whitelisting" >>> or "IPv6 AAAA DNS Resolver Whitelisting" >> >> Well, I guess if we're going to discuss changing the name from what it >> had been (which I was fine with), then it should be to something that >> accurately reflects what is being discussed. The whitelisting is of DNS >> Resolvers that are using DNSv4 protocol, and not "IPv6 DNS" Resolvers or >> "IPv6 AAAA DNS" Resolvers. The purpose of the whitelisting is to >> determine which DNSv4 Resolvers are sent AAAA records in a response. >> >> So, maybe "DNSv4 Resolver Whitelisting" (short name) or "DNSv4 Resolver >> Whitelisting for Inclusion of AAAA Record in Response" (longer name) >> >> Barbara >> _______________________________________________ >> 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 > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jason_livingood@cable.comcast.com Tue May 3 10:49: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 E30A3E0700 for ; Tue, 3 May 2011 10:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.09 X-Spam-Level: X-Spam-Status: No, score=-103.09 tagged_above=-999 required=5 tests=[AWL=-1.356, 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 cQPTvY7PR4H8 for ; Tue, 3 May 2011 10:49:33 -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 E5020E06B1 for ; Tue, 3 May 2011 10:49:32 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.36740513; Tue, 03 May 2011 11:53:16 -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; Tue, 3 May 2011 13:49:27 -0400 From: "Livingood, Jason" To: "v6ops@ietf.org" Thread-Topic: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 Thread-Index: AQHMCZzqgewuui2dTEKFUhZWXW2in5R7bjWAgAALmYD//+fRAA== Date: Tue, 3 May 2011 17:49:26 +0000 Message-ID: In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6DF9@crexc50p> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [147.191.227.190] Content-Type: multipart/alternative; boundary="_000_C9E5B6C424D1Fjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 17:49:34 -0000 --_000_C9E5B6C424D1Fjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There have been a few email threads on the name of the practice described i= n the document, which bears directly on the document name. The title is currently: IPv6 AAAA DNS Whitelisting Implications Discussion here (mainly from John Mann's most recent note) have led to a su= ggestion to consider these alternatives: 1 - IPv6 DNS Resolver Whitelisting Implications 2 - IPv6 AAAA DNS Resolver Whitelisting Implications I'll take this question up with the chairs for direction. Thanks Jason --_000_C9E5B6C424D1Fjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
There have been a few email threads on the name of the practice descri= bed in the document, which bears directly on the document name. 

The title is currently:
IPv6 AAAA DNS Whitelisting Implications

Discussion here (mainly from John Mann's most recent note) have led to= a suggestion to consider these alternatives:
1 - IPv6 DNS Resolver Whitelisting Implications
2 - IPv6 AAAA DNS Resolver Whitelisting Implications

I'll take this question up with the chairs for direction.

Thanks
Jason

--_000_C9E5B6C424D1Fjasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue May 3 10: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 3D887E0837 for ; Tue, 3 May 2011 10:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.921 X-Spam-Level: X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=-1.187, 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 X3kRsENY38bH for ; Tue, 3 May 2011 10:54: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 AD7C0E0756 for ; Tue, 3 May 2011 10:54:36 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.36741394; Tue, 03 May 2011 11:57:04 -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; Tue, 3 May 2011 13:53:14 -0400 From: "Livingood, Jason" To: Erik Kline , "STARK, BARBARA H (ATTSI)" Thread-Topic: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 Thread-Index: AQHMCZzqgewuui2dTEKFUhZWXW2in5R7bjWA///0gIA= Date: Tue, 3 May 2011 17:53: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.10.0.110310 x-originating-ip: [147.191.227.190] Content-Type: multipart/alternative; boundary="_000_C9E5B8E124D2Ejasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "Richard L. Barnes" , "v6ops@ietf.org" , Dave Crocker Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 17:54:37 -0000 --_000_C9E5B8E124D2Ejasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 5/3/11 10:34 AM, "Erik Kline" > wrot= e: DNSv6 is theoretically in scope as well. (i.e. we would include IPv6 prefixes in our resolver ACLs if [and when] we serve authoritative DNS over v6) Erik is correct =96 the concept is that a resolver's IP addresses, whether = they are IPv4 or IPv6 addresses, could be on a whitelist in the authoritati= ve DNS. I will add some text to the =9604 version to make this more clear. Thanks Jason --_000_C9E5B8E124D2Ejasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2C1A257596219B428D3783CFFD5A9CB0@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
On 5/3/11 10:34 AM, "Erik Kline" <ek@google.com> wrote:

DNSv6 is theoretically in scope as well.  (i.e. we would inc= lude IPv6
prefixes in our resolver ACLs if [and when] we serve authoritative DNS=
over v6)

Erik is correct =96 the concept is that a resolver's IP addresses, whe= ther they are IPv4 or IPv6 addresses, could be on a whitelist in the author= itative DNS. I will add some text to the =9604 version to make this more cl= ear.

Thanks
Jason
--_000_C9E5B8E124D2Ejasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue May 3 11:05: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 2A995E0817 for ; Tue, 3 May 2011 11:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.789 X-Spam-Level: X-Spam-Status: No, score=-102.789 tagged_above=-999 required=5 tests=[AWL=-1.055, 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 nTkYQQ5WkWIG for ; Tue, 3 May 2011 11:05:52 -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 6AAE8E0744 for ; Tue, 3 May 2011 11:05:52 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.36744309; Tue, 03 May 2011 12:09:25 -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; Tue, 3 May 2011 14:05:39 -0400 From: "Livingood, Jason" To: Erik Kline , "v6ops@ietf.org" Thread-Topic: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 Thread-Index: AQHMCZzqgewuui2dTEKFUhZWXW2in5R7bjWAgAALmYCAAALfAP//6X4A Date: Tue, 3 May 2011 18:05:38 +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.10.0.110310 x-originating-ip: [147.191.227.190] Content-Type: multipart/alternative; boundary="_000_C9E5B97C24D33jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 18:05:53 -0000 --_000_C9E5B97C24D33jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 5/3/11 11:26 AM, "Erik Kline" > wrot= e: There's a lot the draft doesn't discuss. [JL] Feel free to note those and send them to me if you wish, for inclusion= of an upcoming version. Google is the only entity actively doing this right now, though Akamai has announced that they are doing it (auto-discovering what's safe to add to a whitelist), and both Facebook and Yahoo have expressed interest in doing this (Facebook has already begun whitelisting actually). [JL] Yes, I'd note the same companies. I think some others are in a wait an= d see mode right now, assessing whether or not they should whitelist. It is= possible that experience on World IPv6 Day will help inform the decisions = of some of those others as well (real data is always good). AFAIK none of use have contributed substantially to this document, nor do I have the time to fix all the things that would need fixing (I'd just write a new doc and don't even have the time to do that). [JL] You send written feedback to me (and maybe the list as well) and I inc= orporated that feedback into the =9601 document (as mentioned in the revisi= on notes). One of my co-workers also provided feedback that informally inco= rporated some of your views that I addressed in the =9602 version. If you h= ave additional feedback, please feel free to send it. And, as you noted, an= yone can write an Internet Draft. ;-) IMHO, this document is not a real discussion of whitelisting mechanics and motivations. It is, rather, a harangue against its use, despite the fact that it is, and may remain for some period (which we all do want to be as short as possible), an operational reality/necessity. [JL] My personal perception is not that it is a harangue; I actually took p= ains to be balanced and explain motivations and not rant and I sincerely re= gret that you may feel otherwise. If you have specific feedback on areas wh= ere more of the motivations can be explained more fully I am all ears. :-) Thanks, Jason --_000_C9E5B97C24D33jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <771196314F403B42AF8C224CAB60545A@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
On 5/3/11 11:26 AM, "Erik Kline" <ek@google.com> wrote:

There's a lot the draft doesn't discuss.

[JL] Feel free to note those and send them to me if you wish, for incl= usion of an upcoming version.

Google is the only entity actively doing this right now, though Akamai=
has announced that they are doing it (auto-discovering what's safe to<= /div>
add to a whitelist), and both Facebook and Yahoo have expressed
interest in doing this (Facebook has already begun whitelisting
actually).

[JL] Yes, I'd note the same companies. I think some others are in a wa= it and see mode right now, assessing whether or not they should whitelist. = It is possible that experience on World IPv6 Day will help inform the decis= ions of some of those others as well (real data is always good). 

AFAIK none of use have contributed substantially to this document, nor=
do I have the time to fix all the things that would need fixing (I'd
just write a new doc and don't even have the time to do that).

[JL] You send written feedback to me (and maybe the list as well) and = I incorporated that feedback into the =9601 document (as mentioned in the r= evision notes). One of my co-workers also provided feedback that informally= incorporated some of your views that I addressed in the =9602 version. If you have additional feedback, please = feel free to send it. And, as you noted, anyone can write an Internet Draft= . ;-)

IMHO, this document is not a real discussion of whitelisting mechanics=
and motivations.  It is, rather, a harangue against its use,= despite
the fact that it is, and may remain for some period (which we all do
want to be as short as possible), an operational reality/necessity.

[JL] My personal perception is not that it is a harangue; I actually t= ook pains to be balanced and explain motivations and not rant and I sincere= ly regret that you may feel otherwise. If you have specific feedback on are= as where more of the motivations can be explained more fully I am all ears. :-)

Thanks,
Jason








--_000_C9E5B97C24D33jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue May 3 11:45: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 A8475E0705 for ; Tue, 3 May 2011 11:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.047 X-Spam-Level: X-Spam-Status: No, score=-106.047 tagged_above=-999 required=5 tests=[AWL=2.415, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 vvSDdeGvjBZK for ; Tue, 3 May 2011 11:45:17 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3E766E06F6 for ; Tue, 3 May 2011 11:45:16 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.121814939; Tue, 03 May 2011 14:45:12 -0400 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; Tue, 3 May 2011 14:45:03 -0400 From: "Livingood, Jason" To: Lorenzo Colitti , "v6ops@ietf.org" Thread-Topic: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 Thread-Index: AQHMCcI2wDXfjnBlFku7H5ug7ni75w== Date: Tue, 3 May 2011 18:45:02 +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.10.0.110310 x-originating-ip: [147.191.227.190] Content-Type: multipart/alternative; boundary="_000_C9E5C37724D59jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 18:45:18 -0000 --_000_C9E5C37724D59jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 5/3/11 12:35 PM, "Lorenzo Colitti" > wrote: Right. For us (Google - but I think a lot of large website operators are in= the same boat), whitelisting is the only possible option for IPv6 deployme= nt, period. Subjecting hundreds of thousands of users to breakage is simply= not an option, so while we don't particularly like the disadvantages of wh= itelisting, it's much, much better than doing nothing. [JL] I do not disagree and have attempted to incorporate this thinking into= the most recent version of the I-D. Among other things it says what is not= ed below. Please advise if you desire additional text or some specific chan= ges to better explain this. (As I am working on the =9604 now I will contem= plate that as well.) =85In particular, some major domains view DNS whitelisting as one of the fe= w practical and low risk approaches enabling them to prepare for the transi= tion to IPv6. =85major domains may find DNS whitelisting a beneficial temporary tactic in= their transition to IPv6. Such temporary use during the transition to IPv6= is broadly accepted within the community=85 We don't think that the draft is a balanced assessment of the situation, bu= t at the same time, we don't have time to contribute to it [JL] I understand. As I'm in a similar situation, it's always challenging t= o balance time and various other work commitments. I will look again at the= text in the =9604 update and see if I can add more depth to the motivation= sections and better explain the situation that major domains like your own= face, and why this is therefore viewed as a critical transition tool. I'm = sure this will be imperfect, but I'll see what I can do (and I may run some= draft text past you privately). Regards Jason --_000_C9E5C37724D59jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2AABA4141A367046BD892DD158169751@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
On 5/3/11 12:35 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:

Right. For us (Google - but I think a lot of large website operat= ors are in the same boat), whitelisting is the only possible option for IPv= 6 deployment, period. Subjecting hundreds of thousands of users to breakage= is simply not an option, so while we don't particularly like the disadvantages of whitelisting, it's much, much= better than doing nothing.

[JL] I do not disagree and have attempted to incorporate this thinking= into the most recent version of the I-D. Among other things it says what i= s noted below. Please advise if you desire additional text or some specific= changes to better explain this. (As I am working on the =9604 now I will contemplate that as well.)
 
=85In particular, some major domains view DNS whitelisting as one o= f the few practical and low risk approaches enabling them to prepare for th= e transition to IPv6.
=85major domains may find DNS whitelisting a beneficial temporary t= actic in their transition to IPv6. Such temporary use during the transition= to IPv6 is broadly accepted within the community=85

We don't think that the draft is a balanced assessment of the situatio= n, but at the same time, we don't have time to contribute to it <snip>= ;

[JL] I understand. As I'm in a similar situation, it's always challeng= ing to balance time and various other work commitments. I will look again a= t the text in the =9604 update and see if I can add more depth to the motiv= ation sections and better explain the situation that major domains like your own face, and why this is there= fore viewed as a critical transition tool. I'm sure this will be imperfect,= but I'll see what I can do (and I may run some draft text past you private= ly). 

Regards
Jason



--_000_C9E5C37724D59jasonlivingoodcablecomcastcom_-- From dr@cluenet.de Tue May 3 12: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 705D0E0821 for ; Tue, 3 May 2011 12:13:48 -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 yfmnxDo3jf2a for ; Tue, 3 May 2011 12:13:48 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7041FE0718 for ; Tue, 3 May 2011 12:13:47 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id D796810808C; Tue, 3 May 2011 21:13:44 +0200 (CEST) Date: Tue, 3 May 2011 21:13:44 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110503191344.GA6741@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 May 2011 19:13:48 -0000 On Mon, May 02, 2011 at 01:46:01PM -0400, Thomas Narten wrote: > > + A specific date, soon, e.g. this November, on which operators are > > REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes > > in their respective default free zones. > > Please save your breath. This sort of a mandate is way out-of-scope > for the IETF. Really! For reference, that's the lingo used in RFC3701 (6bone phase-out): Thus after the 6bone phaseout date June 6, 2006, it is the intent that no 6bone 3FFE prefixes, of any size/length, be used on the Internet in any form. Network operators may filter 3FFE prefixes on their borders to ensure these prefixes are not misused. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From john.mann@monash.edu Tue May 3 18: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 91FEEE0780 for ; Tue, 3 May 2011 18:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3rowhKbI1SS for ; Tue, 3 May 2011 18:41:22 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id B6D59E0772 for ; Tue, 3 May 2011 18:41:21 -0700 (PDT) Received: from mail-vx0-f176.google.com ([209.85.220.176]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTcCuwOilaAUVdSCW7Zu3lDULcv7H6GNN@postini.com; Tue, 03 May 2011 18:41:21 PDT Received: by mail-vx0-f176.google.com with SMTP id 37so730155vxa.7 for ; Tue, 03 May 2011 18:41:20 -0700 (PDT) Received: by 10.52.74.97 with SMTP id s1mr731961vdv.40.1304473280185; Tue, 03 May 2011 18:41:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.108.134 with HTTP; Tue, 3 May 2011 18:41:00 -0700 (PDT) In-Reply-To: <4269EA985EACD24987D82DAE2FEC62E503940EE7@XMB-AMS-101.cisco.com> References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> <4269EA985EACD24987D82DAE2FEC62E503940EE7@XMB-AMS-101.cisco.com> From: "John Mann (ITS)" Date: Wed, 4 May 2011 11:41:00 +1000 Message-ID: To: "Gunter Van de Velde (gvandeve)" Content-Type: multipart/alternative; boundary=bcaec501669d7c078b04a2695ad5 Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2011 01:41:22 -0000 --bcaec501669d7c078b04a2695ad5 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 4 May 2011 01:12, Gunter Van de Velde (gvandeve) wrote: > >> But yes, making sure it is turned off by default is important. > > > I don't really like Teredo, but: why? The end-node uses Teredo only > when it is IPv4-only and it needs to reach an > > IPv6-only destination. Without Teredo it will certainly not work. With > Teredo enabled it might work. It's not > > perfect, but better than certain failure... > > I think from an individual home-user that may be what one wants and > could be acceptable, however if I am an Enterprise IT manager, that is > not what I want as I do not want to see tunneled traffic that bypasses > my firewall. > > G/ So, if you had an user on an IPv4-only subnet trying to get to an IPv6-only destination, you would dictate that they not get there v. use a lowest-preference Teredo tunnel. An Enterprise IT Manager can prevent tunneled Teredo traffic bypassing the firewall by - blocking Teredo UDP port 3544 at the firewall, or - pushing a AD Group Policy to disable Teredo (and other tunnel things), or - enabling native IPv6 inside the enterprise so clients prefer that instead of Teredo - ? run a Teredo relay inside the enterprise to de-encapsulate Teredo ? If you want to stop all tunnels, then - block UDP 500, protocol 51(IPSEC) - discover and block other VPN protocols - discover and block other wormholes like IP-over-DNS - block HTTPS to stop Microsoft DirectAccess and SSL VPNs ;-) ;-) Some tunnels are _designed_ to work around NAT or firewalls. Some are easier to block than others. Security v. Convenience v. Cost. John --bcaec501669d7c078b04a2695ad5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 4 May 2011 01:12, Gunter Van de Ve= lde (gvandeve) <= gvandeve@cisco.com> wrote:
>> But yes, making sure it is turned off by default= is important.

> I don't really like Teredo, but: why? The end-node uses Teredo onl= y
when it is IPv4-only and it needs to reach an
> IPv6-only destination. Without Teredo it will certainly not work. With=
Teredo enabled it might work. It's not
> perfect, but better than certain failure...

I think from an individual home-user that may be what one wants and could be acceptable, however if I am an Enterprise IT manager, that is
not what I want as I do not want to see tunneled traffic that bypasses
my firewall.

G/

So, if you had an user on an IPv4-only s= ubnet trying to get to an IPv6-only destination,
you would dictat= e that they not get there v. use a lowest-preference Teredo tunnel.

An Enterprise IT Manager can prevent tunneled Teredo tr= affic bypassing the firewall by
- blocking Teredo UDP port 3544 a= t the firewall, or
- pushing a AD Group Policy to disable Teredo = (and other tunnel things), or
- enabling native IPv6 inside the enterprise so clients prefer that in= stead of Teredo
- ? run a Teredo relay inside the enterprise to d= e-encapsulate Teredo ?

If you want to stop all tun= nels, then=A0
- block UDP 500, protocol 51(IPSEC)
- discover and block oth= er VPN protocols
- discover and block other wormholes like IP-ove= r-DNS
- block HTTPS to stop Microsoft DirectAccess and SSL VPNs ;= -) ;-)

Some tunnels are _designed_ to work around NAT or firew= alls.
Some are easier to block than others. Security v. Convenien= ce v. Cost.

=A0 =A0 John
--bcaec501669d7c078b04a2695ad5-- From martin@millnert.se Tue May 3 19:40: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 A184DE0693 for ; Tue, 3 May 2011 19:40:23 -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 qCta68xSqKdm for ; Tue, 3 May 2011 19:40:23 -0700 (PDT) Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfa.amsl.com (Postfix) with ESMTP id BBD97E0679 for ; Tue, 3 May 2011 19:40:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 9F0017788; Wed, 4 May 2011 04:56:55 +0200 (CEST) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW9u7YVTzDvl; Wed, 4 May 2011 04:56:55 +0200 (CEST) Received: from [192.168.124.253] (209-6-92-201.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.92.201]) by ncis.csbnet.se (Postfix) with ESMTPSA id 97CF216A; Wed, 4 May 2011 04:56:54 +0200 (CEST) From: Martin Millnert To: "John Mann (ITS)" In-Reply-To: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> <4269EA985EACD24987D82DAE2FEC62E503940EE7@XMB-AMS-101.cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 03 May 2011 22:40:13 -0400 Message-ID: <1304476813.3125.33.camel@shakira.millnert.se> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2011 02:40:23 -0000 (Ole - ack on discussion having left point 4 - phase out plan a while ago.) John, On Wed, 2011-05-04 at 11:41 +1000, John Mann (ITS) wrote: > An Enterprise IT Manager can prevent tunneled Teredo traffic bypassing > the firewall by > - blocking Teredo UDP port 3544 at the firewall, or Managed Teredo tunnels can be pointed at servers using a different port - but relays will remain a bit arbitrary, ie depending on which one you happen to use for a specific connection. Relays, too, can run on other ports. > - pushing a AD Group Policy to disable Teredo (and other tunnel > things), or I can imagine this would work (don't know AD Group Policies). > - enabling native IPv6 inside the enterprise so clients prefer that > instead of Teredo Yes, this would definitely work. > - ? run a Teredo relay inside the enterprise to de-encapsulate > Teredo ? Not very effective - Teredo connections in modes of operations involving relays "land" on the relay closest to the non-Teredo address endpoint of the v6 connection (ie, follow the path from this end-point towards 2001:0::/32, and where that leads the connection will land). Regards, Martin From sander@steffann.nl Tue May 3 22:45: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 37869E070B for ; Tue, 3 May 2011 22:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.247 X-Spam-Level: * X-Spam-Status: No, score=1.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpNDXpo559S6 for ; Tue, 3 May 2011 22:45:32 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 3E098E071B for ; Tue, 3 May 2011 22:45:32 -0700 (PDT) Received: from [192.168.2.80] (ip56585b37.direct-adsl.nl [86.88.91.55]) by mail.sintact.nl (Postfix) with ESMTP id 6E7C6200D; Wed, 4 May 2011 07:45:27 +0200 (CEST) References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> <4269EA985EACD24987D82DAE2FEC62E503940EE7@XMB-AMS-101.cisco.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8H7) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8H7) From: Sander Steffann Date: Wed, 4 May 2011 07:45:26 +0200 To: "John Mann (ITS)" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2011 05:45:33 -0000 Hi, > - pushing a AD Group Policy to disable Teredo (and other tunnel things), o= r You don't even need to do this. Teredo is automatically disabled in a manage= d/AD environment.=20 -Sander= From v6ops@globis.net Wed May 4 03:17: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 BE4ABE0725 for ; Wed, 4 May 2011 03:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, 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 5l2IvqSE1iko for ; Wed, 4 May 2011 03:17:52 -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 E703BE06A2 for ; Wed, 4 May 2011 03:17:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3B2008700BA for ; Wed, 4 May 2011 12:17:50 +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 7xufPdLT7DTk for ; Wed, 4 May 2011 12:17:45 +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 D65FB870067 for ; Wed, 4 May 2011 12:17:44 +0200 (CEST) Message-ID: <4DC127BE.2060301@globis.net> Date: Wed, 04 May 2011 12:17:34 +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="------------020605050005010704070103" Subject: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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: Wed, 04 May 2011 10:17:53 -0000 This is a multi-part message in MIME format. --------------020605050005010704070103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here are my comments. On the whole an excellent document. There's obviously been a lot of hard work put in on preparing this one so far. I think perhaps it might be even better if there was some factual list included in the introduction on the assumptions that were made when 6to4 (via anycast) was specified and implemented. It doesn't have to apportion blame or flame anyone. Just straight facts. Here's my take; I'm sure you can improve. "The 6to4 transition mechanism can create an automatic tunnel to carry IPv6 traffic over a protocol 41 tunnel terminated at an IPv4 anycast address, and this assumes that: IPv4 and IPv6 clouds within an enterprise or the public Internet are contiguous and transparent there is a single universal boundary between the IPv4 and IPv6 clouds, and the precise crossing point between the two clouds is not important the forward and reverse paths do not need to be symmetrical protocol 41 is transported and supported in an equal manner to native IPv4 and native IPv6 encapsulations the additional latency introduced by tunneling via a gateway is not operationally significant waiting for a failed IPv6 session to time out is not operationally significant any IPv6 connectivity (no matter what quality) is better than no IPv6 connectivity (as of RFC3484 and not taking into account the proposed RFC3484 bis) no need for explicit support of IPv4 NAT traversal ease of use is paramount It's easy to say with hindsight, but these assumptions do not always hold true in a number of real-world use cases, which may lead to operational difficulties. Users of 6to4 would be well-advised to check that these assumptions hold true in their particular use-case." [this last sentence pending approval of moving 6to4 to historic?] I also would like to comment on the following: "Some operators, particularly enterprise networks, silently block Protocol 41 on security grounds. Doing this on its own is bad practice, since it contributes to the problem and harms any users who are knowingly or unknowingly attempting to run 6to4. " Sure that might be considered bad practice, but maybe you should also include text saying that "allowing uncontrolled automatic tunneling across a firewall is also bad practice." Equally I see no text in the "vendor issues" covering "complete lack of support for protocol 41 in some devices", or "lack of feature equivalence in the majority of security devices, meaning that an organisation may not be able to effectively implement a similar security policy for native IPv6 and IPv6 over protocol 41 as it can for IPv4." It's not about apportioning blame, but sometimes there's little choice. There are many people I know who would love to be able to control these boundaries effectively whilst transitioning to IPv6, but they just don't have the tools to do so, so the only course of action open to them is to disable much larger sets of functionality than they really want to. This isn't always just a knee jerk reaction. These people have auditors on their backs, and users shouting in their ears. Similarly the other extreme is also true, the only way to enable protocol 41 on my home gateway (for 6in4) is to open up literally everything and forward all incoming traffic to a bastion host, and then control the traffic there. As you rightly say later on "Enterprise operators who have complete administrative control of all end-systems may choose to disable 6to4 in those systems as an integral part of their plan to deploy IPv6." I'm afraid that's the only logical choice most large enterprises have at the moment: disable all IPv6 transition mechanisms. But keeping these comments to the scope of your proposal, I'd appreciate inclusion of some text in the vendor issues section on the subject of support in security devices. Section 4.5 Page 14 "We assume that content providers and their ISPs have IPv6 connectivity, and that content servers are dual stacked." That's a big assumption. Most corporate content is accelerated by Akamai today AFAIK, either directly or indirectly. Have you tried to buy an IPv6 capable content acceleration service today? Hopefully that'll change very very soon, but again vendor support (today, as I write). What if this assumption does not hold true? What if SLB IPv6-to-IPv4 takes off instead, as it is less painful? Does that have any impact? I think I know the answer, but I think a lot of people will ask the question. There's a lot of very strong language in this section: "To avoid this, there must be a locally positioned 6to4 relay." "There must be a 2002::/16 route from the content server to the relay." "Protocol 41 must not be filtered in the ISP's IPv4 network or firewalls." page 15 "This is in fact trivial," Maybe technically speaking for someone with root access and your brain power, but not operationally speaking. Certainly it isn't trivial on a hosted web service. I know this is only an informational RFC, but putting myself in the position of a first time reader of this section, I'm not really getting what I'm supposed to do, and what happens if I don't. Can section 4.5 be made more advisory with achievable actions, and then listing the possible negative consequences of not complying? e.g. unpredictable latency, users experiencing noticeable delay as sessions fall back to IPv4. losing all your customers and going bankrupt? p16 "A blanket recommendation to block Protocol 41 is not compatible with mitigating the 6to4 problems described in this document." Suggest adding ", as it will cause operational problems for other protocols that also make use of protocol 41 tunneling and which do not suffer from the same problems as 6to4." best regards, RayH --------------020605050005010704070103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here are my comments.

On the whole an excellent document. There's obviously been a lot of hard work put in on preparing this one so far.

I think perhaps it might be even better if there was some factual list included in the introduction on the assumptions that were made when 6to4 (via anycast) was specified and implemented. It doesn't have to apportion blame or flame anyone. Just straight facts.

Here's my take; I'm sure you can improve.

"The 6to4 transition mechanism can create an automatic tunnel to carry IPv6 traffic over a protocol 41 tunnel terminated at an IPv4 anycast address, and this assumes that:
IPv4 and IPv6 clouds within an enterprise or the public Internet are contiguous and transparent
there is a single universal boundary between the IPv4 and IPv6 clouds, and the precise crossing point between the two clouds is not important
the forward and reverse paths do not need to be symmetrical
protocol 41 is transported and supported in an equal manner to native IPv4 and native IPv6 encapsulations
the additional latency introduced by tunneling via a gateway is not operationally significant
waiting for a failed IPv6 session to time out is not operationally significant
any IPv6 connectivity (no matter what quality) is better than no IPv6 connectivity (as of RFC3484 and not taking into account the proposed RFC3484 bis)
no need for explicit support of IPv4 NAT traversal
ease of use is paramount

It's easy to say with hindsight, but these assumptions do not always hold true in a number of real-world use cases, which may lead to operational difficulties. Users of 6to4 would be well-advised to check that these assumptions hold true in their particular use-case."

[this last sentence pending approval of moving 6to4 to historic?]

I also would like to comment on the following:

"Some operators, particularly enterprise networks, silently block Protocol 41 on security grounds. Doing this on its own is bad practice, since it contributes to the problem and harms any users who are knowingly or unknowingly attempting to run 6to4. "

Sure that might be considered bad practice, but maybe you should also include text saying that "allowing uncontrolled automatic tunneling across a firewall is also bad practice."

Equally I see no text in the "vendor issues" covering

"complete lack of support for protocol 41 in some devices",

or

"lack of feature equivalence in the majority of security devices, meaning that an organisation may not be able to effectively implement a similar security policy for native IPv6 and IPv6 over protocol 41 as it can for IPv4."

It's not about apportioning blame, but sometimes there's little choice. There are many people I know who would love to be able to control these boundaries effectively whilst transitioning to IPv6, but they just don't have the tools to do so, so the only course of action open to them is to disable much larger sets of functionality than they really want to. This isn't always just a knee jerk reaction. These people have auditors on their backs, and users shouting in their ears.

Similarly the other extreme is also true, the only way to enable protocol 41 on my home gateway (for 6in4) is to open up literally everything and forward all incoming traffic to a bastion host, and then control the traffic there.

As you rightly say later on "Enterprise operators who have complete administrative control of all end-systems may choose to disable 6to4 in those systems as an integral part of their plan to deploy IPv6."

I'm afraid that's the only logical choice most large enterprises have at the moment: disable all IPv6 transition mechanisms.

But keeping these comments to the scope of your proposal, I'd appreciate inclusion of some text in the vendor issues section on the subject of support in security devices.


Section 4.5 Page 14 "We assume that content providers and their ISPs have IPv6 connectivity, and that content servers are dual stacked."

That's a big assumption. Most corporate content is accelerated by Akamai today AFAIK, either directly or indirectly. Have you tried to buy an IPv6 capable content acceleration service today? Hopefully that'll change very very soon, but again vendor support (today, as I write).

What if this assumption does not hold true?

What if SLB IPv6-to-IPv4 takes off instead, as it is less painful?
Does that have any impact?
I think I know the answer, but I think a lot of people will ask the question.

There's a lot of very strong language in this section:

"To avoid this, there must be a locally positioned 6to4 relay."
"There must be a 2002::/16 route from the content server to the relay."
"Protocol 41 must not be filtered in the ISP's IPv4 network or firewalls."

page 15 "This is in fact trivial," Maybe technically speaking for someone with root access and your brain power, but not operationally speaking. Certainly it isn't trivial on a hosted web service.

I know this is only an informational RFC, but putting myself in the position of a first time reader of this section, I'm not really getting what I'm supposed to do, and what happens if I don't.

Can section 4.5 be made more advisory with achievable actions, and then listing the possible negative consequences of not complying? e.g. unpredictable latency, users experiencing noticeable delay as sessions fall back to IPv4. losing all your customers and going bankrupt?



p16 "A blanket recommendation to block Protocol 41 is not compatible with mitigating the 6to4 problems described in this document."

Suggest adding
", as it will cause operational problems for other protocols that also make use of protocol 41 tunneling and which do not suffer from the same problems as 6to4."

best regards,
RayH

--------------020605050005010704070103-- From torbjorn.eklov@interlan.se Wed May 4 03: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 AC0E9E0745 for ; Wed, 4 May 2011 03:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 fgF33p1SoFz8 for ; Wed, 4 May 2011 03:27:31 -0700 (PDT) Received: from smtp.interlan.se (smtp2.interlan.se [IPv6:2001:b48:10::225]) by ietfa.amsl.com (Postfix) with ESMTP id 7674BE067A for ; Wed, 4 May 2011 03:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interlan.se; s=dkim2010; h=received:received:from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type: content-transfer-encoding:mime-version; bh=Y/SUPRTWu1tmmzwEJnwClmtllOk6yjZJ1L5bT14c1f8=; b=YF36p7nBqYaD4DUT8t/3WNWH7NyjPDf3UCXan/hlLe161N3NZ47PJcBgR2V6oA2MNRkmA0WXjChW2 eIXqHOzVVdNXSU0CCH5JSiLSC8682N+WBvkTu3ygvmhrHIwyINoFxflXdvspuXa+s1rLgeSYIUikqg nquSOq4dQsCLSuXw= Received: from mail4.interlan.se (unknown [192.168.254.47]) by smtp2.interlan.se (Halon Mail Gateway) with ESMTPS; Wed, 4 May 2011 12:27:23 +0200 (CEST) Received: from GVLFS1.ad.interlan.se ([fe80::c96f:9912:c841:b783]) by GVLFS1.ad.interlan.se ([fe80::c96f:9912:c841:b783%11]) with mapi id 14.01.0218.012; Wed, 4 May 2011 12:27:23 +0200 From: =?iso-8859-1?Q?Torbj=F6rn_Ekl=F6v?= To: 'Sander Steffann' , "John Mann (ITS)" Thread-Topic: [v6ops] 6to4-historic summary point: 4. "Phase out plan" Thread-Index: AQHMCXf5J9CzvR20c0yTY/d9NNn38JR6vcEAgABW7ACAAK+AAIAAREsAgABuTAA= Date: Wed, 4 May 2011 10:27:21 +0000 Message-ID: <51696F35F554BC4C826E65001C41EE3A1F84B9@GVLFS1.ad.interlan.se> References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <4DBF2569.4070509@apolix.co.za> <20110503003420.36EA1E68B4F@drugs.dv.isc.org> <4DBF9B10.4050705@apolix.co.za> <4269EA985EACD24987D82DAE2FEC62E503940EE7@XMB-AMS-101.cisco.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:b48:10:2::91e3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2011 10:27:31 -0000 Hi, my first post to this list. Teredo is not turned on if a Windows Vista/7 is connected to an enterprise = network. If a Windows Vista/7 who is in a managed/AD environment for exampl= e is connected to a home network Teredo is enabled if an application want's= to use it.=20 And some good examples is torrent programs or Microsoft Direct Access so It= 's a good idea to disable it with GPO. Mvh, Torbj=F6rn Ekl=F6v Interlan Gefle AB mobil: 070 - 683 51 75 http://test-ipv6.se - Did you enable IPv6 on something today? > -----Ursprungligt meddelande----- > Fr=E5n: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] F=F6r Sand= er > Steffann > Skickat: den 4 maj 2011 07:45 > Till: John Mann (ITS) > Kopia: v6ops@ietf.org > =C4mne: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" >=20 > Hi, >=20 > > - pushing a AD Group Policy to disable Teredo (and other tunnel things)= , or >=20 > You don't even need to do this. Teredo is automatically disabled in a > managed/AD environment. >=20 > -Sander > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From narten@us.ibm.com Wed May 4 05:31: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 26C9FE073D for ; Wed, 4 May 2011 05:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.18 X-Spam-Level: X-Spam-Status: No, score=-106.18 tagged_above=-999 required=5 tests=[AWL=0.419, 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 rWX+H+EUwxQS for ; Wed, 4 May 2011 05:31:27 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9A673E0682 for ; Wed, 4 May 2011 05:31:27 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p44COMbx018312 for ; Wed, 4 May 2011 06:24:22 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p44CVKQ6134174 for ; Wed, 4 May 2011 06:31:20 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p44CVJWn031060 for ; Wed, 4 May 2011 06:31:19 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-252-167.mts.ibm.com [9.65.252.167]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p44CVIIL030984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 May 2011 06:31:19 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p44CVHF2010939 for ; Wed, 4 May 2011 08:31:17 -0400 Message-Id: <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.com> To: v6ops@ietf.org In-reply-to: <20110503191344.GA6741@srv03.cluenet.de> References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> <20110503191344.GA6741@srv03.cluenet.de> Comments: In-reply-to Daniel Roesen message dated "Tue, 03 May 2011 21:13:44 +0200." Date: Wed, 04 May 2011 08:31:17 -0400 From: Thomas Narten Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2011 12:31:28 -0000 Daniel Roesen writes: > On Mon, May 02, 2011 at 01:46:01PM -0400, Thomas Narten wrote: > > > + A specific date, soon, e.g. this November, on which operators are > > > REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes > > > in their respective default free zones. > > > > Please save your breath. This sort of a mandate is way out-of-scope > > for the IETF. Really! > For reference, that's the lingo used in RFC3701 (6bone phase-out): > Thus after the 6bone phaseout date June 6, 2006, it is the intent > that no 6bone 3FFE prefixes, of any size/length, be used on the > Internet in any form. Network operators may filter 3FFE prefixes on > their borders to ensure these prefixes are not misused. I disagree. The quoted text does not say "MUST NOT advertise ...". Rather, it says, "it is the intent". Very different words. Also, the 6bone example is not a good analogy, IMO. The 6bone was created as an temporary experiment of sorts to get around the problem that RIRs were not allocating IPv6 addresses. Once that problem got fixed, sites were expected to transition over to using proper IPv6 prefixes -- the need for continuing to operate the 6bone was gone. There was no deprecation of "technology" or deprecating "brokenness". Thomas From gert@space.net Wed May 4 08:06: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 08DD4E0783 for ; Wed, 4 May 2011 08:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 9Z0ZN36Tst9G for ; Wed, 4 May 2011 08:06:39 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id ED570E078F for ; Wed, 4 May 2011 08:06:37 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 02274F81DE for ; Wed, 4 May 2011 17:06:36 +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 D20E9F81FE for ; Wed, 4 May 2011 17:06:35 +0200 (CEST) Received: (qmail 95454 invoked by uid 1007); 4 May 2011 17:06:35 +0200 Date: Wed, 4 May 2011 17:06:35 +0200 From: Gert Doering To: Pekka Savola Message-ID: <20110504150635.GY30227@Space.Net> References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> 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, Dave Crocker , "Richard L. Barnes" Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2011 15:06:40 -0000 Hi, On Tue, May 03, 2011 at 08:24:03PM +0300, Pekka Savola wrote: > On Tue, 3 May 2011, Erik Kline wrote: > > DNSv6 is theoretically in scope as well. (i.e. we would include IPv6 > > prefixes in our resolver ACLs if [and when] we serve authoritative DNS > > over v6) > > I'm not sure I follow this reasoning. I may be missing something. > > You'd need to add AAAA glue for your authoritative DNS servers. But > then DNSv6 lookups would end up being used by those recursive > resolvers that are broken. The IPv6 connectivity or not of the recursive resolver is no indication on the brokenness of the IPv6 connectivity of the *end user* querying this resolver. > So, if one employs aaaa-whitelisting, then it logically seems to > follow that the authoritative servers must not have AAAA glue records. DNS is very good at handling the situation where certain servers out of a delegated sets cannot be reached, or cannot be reached via a certain protocol. So - I don't see why there would be any problem having AAAA glue in the first place, and then of course having IPv6 addresses in the whitelist ACLs. 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 pekkas@netcore.fi Wed May 4 10:38: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 DFD67E0688 for ; Wed, 4 May 2011 10:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 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 7VsxLcHxuZuK for ; Wed, 4 May 2011 10:38:32 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3F0E062A for ; Wed, 4 May 2011 10:38:31 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p44Hc5RM012388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 May 2011 20:38:05 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p44Hc5bw012384; Wed, 4 May 2011 20:38:05 +0300 Date: Wed, 4 May 2011 20:38:05 +0300 (EEST) From: Pekka Savola To: Gert Doering In-Reply-To: <20110504150635.GY30227@Space.Net> Message-ID: References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> <20110504150635.GY30227@Space.Net> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi X-Virus-Status: Clean Cc: v6ops@ietf.org, Dave Crocker , "Richard L. Barnes" Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2011 17:38:33 -0000 On Wed, 4 May 2011, Gert Doering wrote: > The IPv6 connectivity or not of the recursive resolver is no indication > on the brokenness of the IPv6 connectivity of the *end user* querying > this resolver. While this is true in theory, I don't think it applies in practise in this case. Whitelisting is done by whitelisting resolvers, i.e., ISPs. There is a connection between broken users and broken (IPv6) resolvers in the case that ISP's IPv6 is unreliable. Indeed, Google has requirements for the v6 connectivity of the ISP as well. In the typical case, however, you're right that the brokenness of IPv6 resolvers and IPv6 end-users are orthogonal. But that does not change the main point, i.e., that in the case the IPv6-capable resolver is broken, lots of end-users will be affected. I would be interested in seeing measurements on the brokenness of resolvers when a) IPv4 is used for AAAA queries, and b) IPv6 is used for AAAA queries. Both are known to have issues in certain cases. >> So, if one employs aaaa-whitelisting, then it logically seems to >> follow that the authoritative servers must not have AAAA glue records. > > DNS is very good at handling the situation where certain servers out > of a delegated sets cannot be reached, or cannot be reached via a certain > protocol. I have to disagree here. DNS is very slow at handling these issues -- if the answer is not in the cache or it has timed out. The timeouts take multiple seconds or even a dozen seconds. In the worst case, the resolver keeps hammering the authoritative server that's down again and again, and every lookup will time out. If the end-user has to wait even a couple of seconds or a dozen seconds, I think from Google POV that's effectively equivalent to broken end-user experience. IMO, DNS lookup induced timeouts are one of the most visible issues affecting end-user usage satisfaction. As a result, I don't see major content providers adding AAAA glue to their authoritative servers any time soon even if they had the technical capability to do so. But I'd love to see them say the opposite. (For similar reasons, I don't see them enabling DNSSEC any time soon.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From ek@google.com Wed May 4 11: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 DB868E07B3 for ; Wed, 4 May 2011 11:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.95 X-Spam-Level: X-Spam-Status: No, score=-105.95 tagged_above=-999 required=5 tests=[AWL=0.027, 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 YVRrt4auu-qs for ; Wed, 4 May 2011 11:05:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 42D74E07AE for ; Wed, 4 May 2011 11:05:52 -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 p44I5pTx016315 for ; Wed, 4 May 2011 11:05:51 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304532351; bh=n45MzdHJI/4UMnJSH0th+hrlqdA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=I6Y0D9DQgjd05lwiNmeDPK1KyYVZw2TFQ9ROCZPA8sJ0YJ54atAB5N7WbO9X+DP5g /ghUUoA/kjy6Wmys0634A== Received: from pzk10 (pzk10.prod.google.com [10.243.19.138]) by wpaz29.hot.corp.google.com with ESMTP id p44I5XQQ005117 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 4 May 2011 11:05:50 -0700 Received: by pzk10 with SMTP id 10so884214pzk.35 for ; Wed, 04 May 2011 11:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NwG60SNG3VW/PG0xMBrzbKuvLpiBvbc5KMpp+93YhQg=; b=fByCvxU6wJXxOjcd8W2aCeBVGkTs30QD71JYztHRG39LnPrkCYJA5jv+Yrp5kdoKwa gmwwPtgV9ZWYQhQhIqmg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dZ5RXGST3khz0+W5KlcgP4mO26tUmR7/vktC6Jhj/aCuy1U4Vk7O+NKbl/Vdoa5u/7 Bcps8JkXcP9EEbMBOxhA== MIME-Version: 1.0 Received: by 10.143.25.22 with SMTP id c22mr715089wfj.267.1304532349699; Wed, 04 May 2011 11:05:49 -0700 (PDT) Received: by 10.142.245.14 with HTTP; Wed, 4 May 2011 11:05:49 -0700 (PDT) In-Reply-To: References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> <20110504150635.GY30227@Space.Net> Date: Wed, 4 May 2011 20:05:49 +0200 Message-ID: From: Erik Kline To: Pekka Savola Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "Richard L. Barnes" , v6ops@ietf.org, Dave Crocker Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2011 18:05:53 -0000 > As a result, I don't see major content providers adding AAAA glue to their > authoritative servers any time soon even if they had the technical > capability to do so. But I'd love to see them say the opposite. (For similar > reasons, I don't see them enabling DNSSEC any time soon.) We have the capability to add AAAA records to nameservers, but won't be putting AAAAs into glue until the impact of doing is properly quantified and has undergone engineering review. Basically, the work up until this point has been about quantifying (and controlling) the damage for "HTTP/S applications as used by browsers". Measuring and responding to the issues that arise for adding AAAAs to MXes, adding AAAAs to NSes, etc has yet to be done (by us). From dougb@dougbarton.us Wed May 4 16:56: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 84266E082C for ; Wed, 4 May 2011 16:56:58 -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, 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 LG8U9XhlCL-3 for ; Wed, 4 May 2011 16:56:55 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 78781E07FC for ; Wed, 4 May 2011 16:56:54 -0700 (PDT) Received: (qmail 5673 invoked by uid 399); 4 May 2011 23:56:52 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 4 May 2011 23:56:52 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DC1E7C2.8010405@dougbarton.us> Date: Wed, 04 May 2011 16:56:50 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: SM References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <6.2.5.6.2.20110502215922.05513e20@resistor.net> In-Reply-To: <6.2.5.6.2.20110502215922.05513e20@resistor.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] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 May 2011 23:56:58 -0000 On 05/03/2011 01:43, SM wrote: > I am stupid but I am not that stupid to go and argue about a draft that > has been blessed by DNSOP and v6ops. "Blessed" is rather strong. There are a non-zero number of people in both groups (of which I am one) who don't like the draft, and don't agree that documenting bad ideas is its own virtue. The other reason that I personally opposed the draft is that it's not going to make 1 tiny bit of difference. The people who are going to do this are going to do it, regardless of what the IETF says about its relative merit. Thus publishing it is just a waste of everyone's time. However, the rough consensus was to move it forward, so here we are. Meanwhile, the discussion about whether or not to call this "whitelisting" is pointless. The term is already well-established. 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 marka@isc.org Wed May 4 17: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 5C118E067E for ; Wed, 4 May 2011 17:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.173, 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 lH6SR2xv6QAL for ; Wed, 4 May 2011 17: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 8A46EE06C2 for ; Wed, 4 May 2011 17: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 C9A345F984C; Thu, 5 May 2011 00:15:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 0B68A216C1E; Thu, 5 May 2011 00:15:03 +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 03D9AE7702D; Thu, 5 May 2011 10:14:59 +1000 (EST) To: Erik Kline From: Mark Andrews References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> <20110504150635.GY30227@Space.Net> In-reply-to: Your message of "Wed, 04 May 2011 20:05:49 +0200." Date: Thu, 05 May 2011 10:14:58 +1000 Message-Id: <20110505001459.03D9AE7702D@drugs.dv.isc.org> Cc: "Richard L. Barnes" , v6ops@ietf.org, Dave Crocker Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 May 2011 00:16:13 -0000 In message , Erik Kline writes: > > As a result, I don't see major content providers adding AAAA glue to their > > authoritative servers any time soon even if they had the technical > > capability to do so. But I'd love to see them say the opposite. (For similar > > reasons, I don't see them enabling DNSSEC any time soon.) > > > We have the capability to add AAAA records to nameservers, but won't > be putting AAAAs into glue until the impact of doing is properly > quantified and has undergone engineering review. > > Basically, the work up until this point has been about quantifying > (and controlling) the damage for "HTTP/S applications as used by > browsers". Measuring and responding to the issues that arise for > adding AAAAs to MXes, adding AAAAs to NSes, etc has yet to be done (by > us). > Adding IPv6 transport for DNS is a no-brainer. The recursive servers already have to deal with a unreliable transport where a reasonable percentage of servers are unreachable at any point in time and recover within the 2-3 seconds before the stub clients timeout and return a failure to the application. Recursive servers already track responses times from authoritative servers. All the sorts of methods happy eyeballs encourages have been done for decades in recursive DNS servers. With normal resolution DNS servers don't talk TCP without first being able to talk to the server over UDP. I know the nameservers we ship are often to run as recursive servers with local IPv6 connectivity, global IPv6 default route, no ICMPv6 error traffic and global IPv4 connectivity without problems on default configs. They work better if there is ICMPv6 error traffic. They work better if they are tuned to know which IPv6 addresses are reachable. > _______________________________________________ > 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 dr@cluenet.de Wed May 4 17: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 0C372E067E for ; Wed, 4 May 2011 17:21:54 -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 07VdxJdhbqXV for ; Wed, 4 May 2011 17:21:53 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 10593E06C2 for ; Wed, 4 May 2011 17:21:52 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 9CA7C1080FE; Thu, 5 May 2011 02:21:50 +0200 (CEST) Date: Thu, 5 May 2011 02:21:50 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20110505002150.GA19609@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> <20110503191344.GA6741@srv03.cluenet.de> <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 May 2011 00:21:54 -0000 On Wed, May 04, 2011 at 08:31:17AM -0400, Thomas Narten wrote: > Daniel Roesen writes: > > > On Mon, May 02, 2011 at 01:46:01PM -0400, Thomas Narten wrote: > > > > + A specific date, soon, e.g. this November, on which operators are > > > > REQUIRED to stop advertising the 2002::/16 and 192.88.99/24 prefixes > > > > in their respective default free zones. > > > > > > Please save your breath. This sort of a mandate is way out-of-scope > > > for the IETF. Really! > > > For reference, that's the lingo used in RFC3701 (6bone phase-out): > > > Thus after the 6bone phaseout date June 6, 2006, it is the intent > > that no 6bone 3FFE prefixes, of any size/length, be used on the > > Internet in any form. Network operators may filter 3FFE prefixes on > > their borders to ensure these prefixes are not misused. > > I disagree. > > The quoted text does not say "MUST NOT advertise ...". Rather, it > says, "it is the intent". Very different words. Thomas, I wasn't trying to disprove your point at all. I was just throwing the verbiage used in another phase-out IETF publication into the discussion. "additional data point". :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From prondou@gmail.com Wed May 4 18: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 BF09BE0670; Wed, 4 May 2011 18:18:11 -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 83qH2yW-FJxg; Wed, 4 May 2011 18:18:09 -0700 (PDT) Received: from mailrelay004.isp.belgacom.be (mailrelay004.isp.belgacom.be [195.238.6.170]) by ietfa.amsl.com (Postfix) with ESMTP id BCF02E0669; Wed, 4 May 2011 18:18:08 -0700 (PDT) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBAHn5wU1XQqnI/2dsb2JhbAAM3hGHTTSIY4YHBI81jjw Received: from 200.169-66-87.adsl-dyn.isp.belgacom.be (HELO [192.168.1.40]) ([87.66.169.200]) by relay.skynet.be with ESMTP; 05 May 2011 03:18:04 +0200 Message-ID: <4DC1FACC.4080204@gmail.com> Date: Thu, 05 May 2011 03:18:04 +0200 From: Pierre Rondou User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: behave@ietf.org, v6ops@ietf.org, netfilter-devel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Cyril Soldani , guy.leduc@ulg.ac.be Subject: [v6ops] Netfilter Module for NAT IVI available X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 May 2011 01:18:11 -0000 Hello everybody, I'm currently a student at the University of Liège. As part of my master thesis, I have to develop a Linux kernel module for IVI ( http://datatracker.ietf.org/doc/rfc6219/ ). I now consider my module as finished (i.e, all functionalities are implemented) and publish it. It is available on sourceforge: http://sourceforge.net/projects/nativi/ Feel free to test it and report to me any bug, bad implementation, error, ... If you believe that this module can be included is the Linux Kernel or in the Xtables-addons framework, I'll be glad and will help you in this task. I have tested my module inside the Xtables-addons framework (version 1.32) on a debian squeeze (6.0.1) linux with a 2.6.32-5 kernel (i686). Because of the lack of "EXPORT_SYMBOL" in the kernel, I had to copy-paste several functions from the kernel into the nativi_kernel_code.c file in order to use some features already available in the kernel (ip_finish_output, ip6_output, icmp_send). Documentation is provided in the source code, if you have any question don't hesitate to ask me. Regards, Pierre RONDOU From v6ops@globis.net Thu May 5 05:40: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 0F197E0724 for ; Thu, 5 May 2011 05:40:11 -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 POyA9otlhp36 for ; Thu, 5 May 2011 05:40:10 -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 5D6D6E0721 for ; Thu, 5 May 2011 05:40:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4D4F987005C for ; Thu, 5 May 2011 14:40:07 +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 WA+sdNiZturP for ; Thu, 5 May 2011 14:40: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 91C6C8700EA for ; Thu, 5 May 2011 14:40:00 +0200 (CEST) Message-ID: <4DC29A96.6020709@globis.net> Date: Thu, 05 May 2011 14:39:50 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "v6ops@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 May 2011 12:40:11 -0000 I'm guessing comments are welcome again now for input to the revised ID now that the status is "Revised ID Needed" (according to RFC6174) Or should I be waiting for the revised ID first before commenting further? I dunno. I still admit to getting confused by the status on the http://tools.ietf.org/wg/v6ops tooling page even after having read the finite state machine a couple of times. Maybe that should disqualify me from taking part in the WG ;) Anyway, firstly, I can imagine that the actions of a single aaaa whitelisting provider can have far reaching consequences for many parties on the Internet. Say "Content Provider G" adds your ISP's DNS resolvers and suddenly a huge proportion of the ISP's traffic switches to IPv6. Vice versa is also true if traffic is routed away from IPv6. It may even take a different path through the transit providers' networks (if they are not all offering dual native transport) and thus also have financial consequences. Meanwhile if you're in the ISP network, you really can't debug anything meaningfully because you might be receiving a different response to someone else who has a problem, and you have no idea why. Even if you do debug the problem correctly, and correct your local issues, you have very little control over full problem resolution (by getting the aaaa whitelist contents changed). That means my first conclusion is that I feel v6ops WG should attempt to reach some consensus on a revised I-D, and at least comment on the operational aspects, rather than just let the current draft lapse. Secondly, Is the scope and function of the document clear? That seemed to confuse some members of the IESG if I read their feedback. Is it too early to talk about Solutions? Maybe the revised I-D should simply stick to the target defined in the text already present on page 5: "This document explores the reasons and motivations for DNS whitelisting. It also explores the outlined concerns regarding this practice. Readers will hopefully better understand what DNS whitelisting is, why some parties are implementing it, and what criticisms of the practice exist." with the addition that "It is intended to address best current practice and solutions in a follow up." And then leave all discussion of "Solutions" to a BCP follow up RFC? I suspect it would probably be easier to reach consensus for an informational "description and concerns of current practice" without immediately taking the next step and marking that description as "best current practice" or proposing "solutions" to the concerns. Yes I know the first document won't change anything, but at least it is a clear problem statement for people to tackle and to generate possibly many alternative options for follow-up. Thirdly, as has already been pointed out in the description of the "current practice", the relationship between IPv6 name resolution and IPv6 connectivity appears tenuous to me, although others have commented that they have observed a causal link. Is there any hard data on this? Thinking off the top of my head: There are off site / off net back up recursive resolvers just to mention one basic level of obfuscation. There are open recursive resolvers. Here's a survey of open recursive resolvers that potentially serve people "outside" of their own network http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/latest.html 10000 of them in the latest survey. These would almost certainly break a link between resolver performance and network connectivity. Looking closer to home, my own authoritative DNS is not located on my ISP's DNS. I want to be able to change transport provider (big cost and low hassle for me) in a smooth manner, without having to change DNS provider (small cost, but big hassle for me). I also currently use a different recursive resolver for outbound requests (IPv6 capable via a tunnel) than my IPv4 transport provider (not IPv6 capable). This aaaa whitelisting practice as described appears to create a direct link between DNS recursive resolution services and IPv6 transport provider services that has not existed up until now IMHO. That should probably be noted as an architectural concern of the WG. It is hinted at within the existing text: "An additional concern is that the IP address of a recursive resolver is not a precise indicator of the IPv6 preparedness, or lack of IPv6-related impairments, of end user hosts which query (use) a particular recursive resolver." But that text does not address the concern at any architectural level whether there should be _any_ link at all between an IPv6 transport provider and DNS recursive resolver server address, never mind if it is a reliable link. RFC5358 suggest it was Best Current Practice in 2008 to avoid open recursive resolvers to avoid reflector attacks, but it does not directly link DNS resolution and transport service provision. It just says "The generic recommendation to nameserver operators is to use the means provided by the implementation of choice to provide recursive name lookup service to only the intended clients." One suggested method was IP filtering, another was DNS-tsig, which is certainly a real possibility. But the intended clients for DNS were certainly not limited to only those using a particular transport provider. Has this concern therefore been properly documented? Fourthly, moving on to possible suggestions for solutions and BCP, it is very clear that there is a real issue with the lack of transparency on the whole aaaa whitelisting process. As others have already commented, it seems very opaque. In order to facilitate troubleshooting, and to give people a chance to control their own destiny (regardless of the aaaa whitelisting technology employed) can the v6ops WG take a view that DNS server operators who employ aaaa whitelisting SHOULD: 1. publish their policy for maintaining the aaaa whitelist 2. provide details for how and where the aaaa whitelist is used 3. provide details of how to request the contents of the aaaa whitelist (taking into account privacy concerns) 4. provide details of how to request being included in the aaaa whitelist 5. provide details of how to request being excluded from the aaaa whitelist 6. provide details of how to request a review, appeal, or enter an arbitration process. 7. provide active feedback to the maintainers of DNS and IPv6 transport providers to improve overall IPv6 DNS resolution and IPv6 connectivity, in order to remove any underlying need for an aaaa whitelist, and to facilitate its complete removal at the earliest possible opportunity. I miss these operational issues being addressed at all in the previous draft in the Solutions section. They're well covered in discussion relating to other (similar) lists e.g. DNSBL So does the v6ops WG deprecate/discourage/condone/tolerate/encourage DNS whitelisting or blacklisting on the basis of "recursive resolver IP address" reachability/ reliability being linked to IPv6 transport reliability? Doubt there'll be consensus here, but I think the question should be asked again. To it seems that broken IPv6 connectivity is the real problem, not broken name resolution as far as I can see. Especially when it is possible to resolve both IPv4 and IPv6 records over either IPv4 or IPv6 transport, I really fail to see the correlation. Perhaps someone can correct my myopia with hard data. If someone has broken DNS recursive resolution for IPv6, it is going to affect the majority of the IPv6 services they are using, and should stand out like a sore thumb. They are therefore likely to be highly motivated to point their local resolver libs at a better DNS server, and which action is generally a fairly trivial act (altering one DHCP record at best and rebooting machines). If there are generally large numbers of broken IPv6 DNS resolvers out there, then there's a much bigger problem, which is certainly not going to be solved by a point solution deployed by a few content providers. In fact aaaa whitelisting is more likely to mask the problem than solve it IMHO. Again I sense a lack of hard operational data as to the root causes of the problem. Maybe that's also a basic concern to be noted: "lack of operational data regarding the root causes of the problem." Also IMHO the v6ops WG also shouldn't encourage people to mess around with DNS unless it is absolutely necessary. Breaking DNS would break an awful lot, to put it mildly. The current document notes the current practice of only deploying aaaa whitelisting on an authoritative server. Should the v6ops WG clearly state in any recommendations or bcp that 1. aaaa whitelisting MUST NOT be deployed anywhere other than on an authoritative DNS server for which the aaaa whitelist provider is directly responsible. 2. aaaa whitleisting information SHOULD NOT be traded for use in aaaa whitelisting on other authoritative DNS servers, unless the aaaa whitelist policy of the two organisations is tightly coupled. 3. the adminisatrator of the authoritative DNS SHOULD ensure that all authoritative DNS servers for a domain return a consistent set of results, regardless of which server has been queried. 4. aaaa whitelisting is a transition mechanism that MAY be useful in supporting a move towards a fully native IPv6 network, but which SHOULD only be used where, and for as long, as is essential to maintain normal operations. A few questions and issues for your consideration thus. regards, RayH From Marcus.Williams@ed.gov Thu May 5 06:26: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 F33EDE06D8 for ; Thu, 5 May 2011 06:26:11 -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 8Kx6rhTRa9VM for ; Thu, 5 May 2011 06:26:11 -0700 (PDT) Received: from exprod8og116.obsmtp.com (exprod8og116.obsmtp.com [64.18.3.32]) by ietfa.amsl.com (Postfix) with ESMTP id DA73FE0593 for ; Thu, 5 May 2011 06:25:53 -0700 (PDT) Received: from eduptcexmr04.ed.gov ([160.109.63.137]) (using TLSv1) by exprod8ob116.postini.com ([64.18.7.12]) with SMTP ID DSNKTcKlYDxxshTgJcF30a6a3e4aAqU8VaDW@postini.com; Thu, 05 May 2011 06:26:10 PDT Received: from eduptcexhb02.ed.gov (eduptcexhb02.ed.gov [165.224.52.34]) by eduptcexmr04.ed.gov (8.13.8/8.13.8) with ESMTP id p45DPp4F020658 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 5 May 2011 08:25:51 -0500 Received: from EDUPTCEXMB02.ed.gov ([165.224.52.20]) by eduptcexhb02.ed.gov ([165.224.52.34]) with mapi; Thu, 5 May 2011 08:25:51 -0500 From: "Williams, Marcus (Contractor)" To: Thomas Narten , "v6ops@ietf.org" Date: Thu, 5 May 2011 08:25:49 -0500 Thread-Topic: [v6ops] 6to4-historic summary point: 4. "Phase out plan" Thread-Index: AcwKV012kycSt3kmTTeiLrh7Zp+OfwAzcoZA Message-ID: References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com> <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> <20110503191344.GA6741@srv03.cluenet.de> <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.com> In-Reply-To: <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.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] 6to4-historic summary point: 4. "Phase out plan" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 May 2011 13:26:12 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Thomas Narten > Sent: Wednesday, May 04, 2011 8:31 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan" > Also, the 6bone example is not a good analogy, IMO. The 6bone was > created as an temporary experiment of sorts to get around the problem > that RIRs were not allocating IPv6 addresses. Once that problem got > fixed, sites were expected to transition over to using proper IPv6 > prefixes -- the need for continuing to operate the 6bone was > gone. There was no deprecation of "technology" or deprecating > "brokenness". There was in fact brokeness caused by 6bone. Operators filtered 6bone 3FFE= routes while a v6 exchange continued to use it for peering. Those v6 rou= ters at the exchange would send PMTU sourced in 3ffe . . . This sort of f= ocused shakeout improves the integrity of v6 instead of allowing problems t= o fester. Marcus Williams From ford@isoc.org Thu May 5 06: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 70310E073D for ; Thu, 5 May 2011 06:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.449 X-Spam-Level: X-Spam-Status: No, score=-104.449 tagged_above=-999 required=5 tests=[AWL=-0.850, 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 mjRc7JuRbuzQ for ; Thu, 5 May 2011 06:45:30 -0700 (PDT) Received: from smtp147.iad.emailsrvr.com (smtp147.iad.emailsrvr.com [207.97.245.147]) by ietfa.amsl.com (Postfix) with ESMTP id 50974E0773 for ; Thu, 5 May 2011 06:45:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp54.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 6062C2B0435; Thu, 5 May 2011 09:45:29 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp54.relay.iad1a.emailsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id 725782B040A; Thu, 5 May 2011 09:45:27 -0400 (EDT) From: Matthew Ford Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 5 May 2011 14:45:21 +0100 Message-Id: <1BA41BA7-C8CB-4BAB-9CC4-CD370AFF0069@isoc.org> To: draft-chown-v6ops-call-to-arms@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: [v6ops] Comments on draft-chown-v6ops-call-to-arms-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 May 2011 13:45:35 -0000 Hi, Firstly, thanks to Tim and Stig for taking the initiative to put this = together. I've reviewed the draft and have some comments, inline below. = Overall I think the document is a useful contribution, but the time to = raise awareness is now so pointers to the (revised) draft will have to = suffice I think. Regards, Mat > 1. Introduction >=20 > Despite the recent exhaustion of the available IPv4 address pool, > deployment of IPv6 remains limited. To help encourage = organisations > to trial production deployment, ISOC has declared June 8th 2011 as > World IPv6 Day [ISOC]. Organisations are encouraged to use this = day > to test IPv6 in production, either by enabling clients in their > network, or by making externally-facing services available over = IPv6. I'd prefer to have this read 'Organisations are encouraged to use this = day to test IPv6 in production by making their main, externally-facing = websites available over IPv6'. The original purpose of W6D was to measure and identify sources of = end-user brokenness to help address some content provider issues. = Nevertheless, W6D has clearly helped to move IPv6 deployment up the = agenda for ISPs and others as well. ISPs have a different set of issues = when it comes to enabling IPv6. The following text was agreed elsewhere as advice for ISPs in relation = to W6D and it might be good to include it here: "If you are planning to turn on IPv6 for access in your network in the = interest of World IPv6 Day, please ensure your adds are completed well before the = day (e.g., by May 31), and commit to leaving it active. Turning on IPv6 for only a brief period around June 8th will confuse measurements and not = give a clear idea of the world's readiness for IPv6 and IPv4 coexistence: it = is therefore not a contribution to the effort. If Service Providers want to participate in World IPv6 Day they can do = the=20 following: 1. Support IPv6 / AAAA records for all their Internet facing services = (web/mail/etc) 2. Record the impact of World IPv6 Day on their IPv4-only customers (as = described in more detail below) If, and only if, providers are ready to support production quality, = general availability=20 of IPv6, then they should be encouraged to: 3. Record the impact of World IPv6 Day on dual-stack customers" > At the current time, this would generally mean enabling dual-stack > networking with IPv4 running alongside IPv6. However, IPv6-only > networks are inevitable, and so some sites may choose to use June = 8th > to undertake some focused tests on that deployment model. >=20 I think that needs to come with a health warning along the lines of = 'please don't do anything that you can't have enabled well in advance of = World IPv6 Day, and continue to support in the long-term'. Turning up = networks for 24hrs isn't going to help. I know you have some of these = points below, but I think it's important to make clear the right way do = this on first mention of enabling IPv6 networks. > The purpose of this document is two-fold. One is to discuss common > IPv6 connectivity issues that are likely to arise on June 8th, with = a > focus on dual-stack networking (which is likely to be how the vast > majority of sites take part). Most of the issues discussed in this > text are those that would affect an end site or enterprise network > running IPv6, but may be applicable elsewhere. Highlighting the > issues should help raise awareness of those problems and possible > mitigations. The other purpose is to encourage organisations to > think about how they might get useful instrumentation in place to > observe what happens in and to/from their networks on the day, both > from the network and application perspective. Such measurement = tools > are likely to be useful in the longer term, so once deployed they > could be left in place beyond June 8th. >=20 > For most sites providing content, June 8th will be a chance to make > some public facing services available over IPv6, most likely web > content using their production domain (e.g. www.example.com) rather > than a contrived IPv6 test domain (e.g. www.ipv6.example.com). > Enabling public-facing Internet services is a reasonable first step > for any organisation deploying IPv6. Some sites or enterprises may > choose to enable IPv6 in user/client subnets, in which case the > performance of those systems and the applications they run will be = of > paramount interest. However, enabling client access for just one = day > may not be optimal; it would be much more preferable that client > subnets were enabled in advance of World IPv6 Day, using a method > that the enabling site would be happy to use indefinitely. For = some > sites enabling clients in their IT department may be appropriate; = for > educational sites enabling IPv6 on eduroam wireless networks could = be > appropriate given the underlying 802.1x authentication technology = is > IP version independent. >=20 > It should be emphasised that while World IPv6 Day is in many senses > an 'experiment' or 'test flight' for IPv6, organisations should > strongly consider deploying IPv6 in exactly the same robust way = that > they would do if they were deploying IPv6 and leaving it enabled >=20 >=20 >=20 > Chown & Venaas Expires October 21, 2011 [Page = 3] > Internet-Draft World IPv6 Day Call to Arms April = 2011 >=20 >=20 > indefinitely. Similarly, applying measures to improve IPv6 > robustness, e.g. improved ICMPv6 filtering practice, should be > considered long term benefits. That they 'affect' the experiment = is > not a problem; indeed all measures that improve the robustness of > IPv6 deployment should be seen as worthwhile. There will still be > problems found, but these can at least be recognised and work done = to > make them better. >=20 > The document also includes a brief section on tools that might be > used to test IPv6-only operation. >=20 > NB. This is still a rather rough draft of the document; feedback = is > very much welcomed. The scope of the document is purely > informational to provoke discussion. We aim to have a relatively > mature informational text ready well in advance of June. >=20 >=20 > 2. Connectivity Issues >=20 > In this section we review some common causes of IPv6 connectivity > issues, oriented towards those that end sites or enterprises may = have > some ability to influence or mitigate. Some issues, such as = transit > arrangements, are not included - currently the focus is on end = sites > (or users) who may take part in the World IPv6 Day. There is no > significance to the order in which issues are listed. >=20 > 2.1. Unmanaged Tunnels >=20 > One cause of connectivity problems is the use of unmanaged tunnels, > in particular 'automated' methods that are not provisioned by the > user's ISP. The most common example is 6to4 [RFC3056], or more > specifically the 6to4 relay approach described in [RFC3068]. A > native IPv6 host communicating with a 6to4 host will require both > hosts to have access to an appropriately capable 6to4 relay (which > may or may not be the same relay). If a host in a native IPv6 > network has no route to 2002::/16 it cannot send traffic to a 6to4 > host. Similarly, a 6to4 router that cannot reach the well-known = IPv4 > anycast relay address cannot send traffic to a native IPv6 network. > There are also potential issues with Protocol 41 filtering at site > borders close to the client. >=20 > A presentation by Geoff Huston at IETF80 [Huston2011] highlighted = the > connection failure rates with 6to4, measured in excess of 15%, as > well as the additional latency in 6to4 communications, with 6to4 > showing an average additional 1.2s latency per retrieval. >=20 > One approach to this problem is to encourage sites/ISPs to run = local > relays, as discussed in [I-D.carpenter-v6ops-6to4-teredo-advisory]. >=20 >=20 >=20 > Chown & Venaas Expires October 21, 2011 [Page = 4] > Internet-Draft World IPv6 Day Call to Arms April = 2011 >=20 >=20 > This draft discusses how to make 6to4 more robust in situations = where > there is a conscious decision to use it. The alternative to reduce > such problems is simply to move 6to4 to Historic, as proposed in > [I-D.troan-v6ops-6to4-to-historic]. This would not necessarily = kill > 6to4 completely, but it would certainly send a strong signal that > 6to4 should not be enabled by default. This paragraph seems to be talking about options for the IETF whereas I = would have expected options for network operators and sysadmins. How = about something more along these lines? Given the serious performance and reliability issues associated with = 6to4, sites that use it are strongly encouraged to run local relays, as = discussed in [I-D.carpenter-v6ops-6to4-teredo-advisory]. Alternatively, = such performance and reliability issues can be mitigated by avoiding the = use of 6to4 altogether as a means of accessing the IPv6 Internet. >=20 > There may still be some CPE routers that do enable 6to4 by default; > it is likely that devices behind such routers will experience > problems on World IPv6 Day. CPE firmware upgrades, where available, should be deployed in advance of = the day. [And here, it might be worth referencing = http://getipv6.info/index.php/Customer_problems_that_could_occur which = provides a lot of detail about specifically which CPE has known problems = and whether upgrades are available to fix them] >=20 > Connection failures and latency with the Teredo protocol [RFC4380] > were also highlighted by Geoff Huston's IETF80 presentation. = Teredo > connection failure rates were as high as 35%, with 1-3s additional > latency. One of the connection issues is reliance on the ICMPv6 > probe packet being able to reach the destination host; in practice > filters may block these. >=20 Can we draw any conclusion from that? How about: Teredo should not be considered a reliable means of accessing the IPv6 = Internet. > 2.2. Tunnel Broker first-hop delays >=20 > IPv6 tunnel brokers, such as those provided by SixXS > (http://www.sixxs.net) and Hurricane Electric > (http://tunnelbroker.net) provide a more robust, managed approach = to > IPv6-in-IPv4 tunnelled access than 6to4. Individual users = interested > in IPv6 access for World IPv6 Day, in the absence of IPv6 support > from their ISP, should consider registering to use a free tunnel > broker. It would be sensible to register for and test your broker > client well in advance of IPv6 Day, and ideally plan to keep it > available beyond that date, until your ISP provides IPv6 natively = for > you. >=20 You could reference = http://isoc.org/wp/worldipv6day/ipv6-enabled-websites/ here as a = potentially useful list of IPv6-enabled websites for tunnel broker users = to test against. The formatting for that page is about to be improved as = well. > When choosing a broker service, it is prudent to pick one with a > presence near to you that has a minimal round trip time. Providers > such as SixXS and HE have tunnel broker servers in many countries. > Beware picking a broker in another continent that may add 150ms+ to > your round trip times. >=20 > 2.3. Connection Timeouts >=20 Either right up front, or somewhere else in the section that follows = it's important to make two points clearly I think: 1. Identifying and fixing the problems that lead to these timeouts is a = major driver for World IPv6 Day 2. Because unreliable IPv6 connectivity leads to these intensely = frustrating problems for end-users, it is essential that people = motivated to deploy IPv6 connectivity, whether for themselves, or for a = larger network, only do so in a well-supported, production-quality = fashion. > Where dual-stack systems - or rather the applications running on = them > - have a choice of IPv4 or IPv6 connectivity, timeouts can occur if > there is no connectivity on the preferred protocol. For example, = if > both A and AAAA DNS records exists for a web server, and IPv6 > connectivity is broken, there is likely to be some timeout for the > browser before the connection drops back to IPv4. >=20 > A bigger problem exists if the application or OS tries IPv6 first = and > then does not fall back to IPv4. A bug in versions of Opera prior = to >=20 >=20 >=20 > Chown & Venaas Expires October 21, 2011 [Page = 5] > Internet-Draft World IPv6 Day Call to Arms April = 2011 >=20 >=20 > 10.5 caused such behaviour, which was obviously a big issue for = Opera > users trying to access dual-stack web sites with broken IPv6 > connectivity. >=20 > The author has undertaken some informal tests at his own site, = which > shows how different combinations of browsers and operating systems > behave in the event of IPv6 connections failing or when ICMP > unreachables are received. On Linux/Firefox, web connections = timeout > after 20 seconds for 'no response', but immediately for = unreachables. > In contrast, Windows Vista/IE was 20 seconds regardless of > unreachables being received. Any non-trivial delay will cause > significant user frustration. >=20 > A more complete set of tests was run by Teemu Savolainen and = reported > at IETF80 [Savolainen2011]. Although the tests were only samples, > they confirmed the results, also showing experiences across a much > broader range of platforms, and that the problems with Vista/IE are > repeated with Win 7/IE. It's thus clear that if major content > providers enable IPv6 on World IPv6 Day, and end users for some > reason try to access the content with broken IPv6 connectivity, = they > are likely to experience significant timeout issues. >=20 > This problem is probably the main reason that Google implemented a > AAAA whitelisting system for its test sites. The sites had to > demonstrate they had good IPv6 connectivity before being allowed = into > the test programme. The topic is discussed in > [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications]. For the sake = of > World IPv6 Day, it is expected that no such whitelisting is in = place > - that is, after all, the point of having a day dedicated to = testing > IPv6 in production. >=20 > An interesting suggestion to handle the problem is the 'happy > eyeballs' approach described in [I-D.ietf-v6ops-happy-eyeballs]. > This approach is now also being suggested for multiple interface > systems, as per [I-D.chen-mif-happy-eyeballs-extension]. The happy > eyeballs philosophy is to try both IPv4 and IPv6 together, and keep > the first working connection up, remembering the result for future > connection attempts. It may prefer IPv6 slightly in initial > connections rather than trying connections exactly simultaneously. > It is an interesting approach, though some people are concerned = about > the additional connection load, or that this 'workaround' is simply > masking underlying problems that should be fixed. >=20 > 2.4. PMTU Discovery >=20 > IPv6 mandates that fragmentation is only undertaken by the sending > node, and thus IPv6 requires working PMTU Discovery [RFC1981]. An > existing RFC gives Recommendations for Filtering ICMPv6 Messages in >=20 >=20 >=20 > Chown & Venaas Expires October 21, 2011 [Page = 6] > Internet-Draft World IPv6 Day Call to Arms April = 2011 >=20 >=20 > Firewalls [RFC4890]; if this guidance is not followed, connectivity > problems are likely to arise. Blindly filtering all ICMPv6 = messages > is not good practise. In setting up monitors for World IPv6 Day participants, I've been struck = by the number of sites that filter inbound ICMP for 'security' or other = reasons. That actually led me to consider writing a short I-D = highlighting the importance of not adopting the same approach when = dealing with ICMPv6, right before call-to-arms popped into my inbox ;) Anyway, I wonder if the advice here needs to be beefed up a little. = Probably won't have any impact on the real world, but might make me feel = better... Maybe just stating, 'Filtering ICMP is a common practice in some IPv4 = networks today. Adopting the same approach to ICMPv6 when deploying IPv6 = networks will cause connectivity issues for users of the network = filtering ICMPv6 and hosts trying to reach the filtered network. RFC4890 = is therefore an important document for IPv6 deployment engineers to read = and it is similarly important to verify that IPv6 firewall deployments = support appropriate configurations for ICMPv6 filtering.' >=20 > The minimum MTU for IPv6 is 1280 bytes. Where PMTUD is not working > or not implemented, the minimum MTU should be used. This could be further emphasised: When IPv6 connectivity issues arise, = one of the first things to check is the MTU. In many cases, reducing MTU = to the minimum will resolve the problem. > Tunnel broker > services such as SixXS and HE set their MTUs to default to 1280, > probably due to the varying conditions their customers may be in. > However, it is preferable for enterprise networks to configure > appropriate ICMPv6 filtering to allow PMTUD to operate and = establish > the most efficient MTUs for a link. >=20 > 2.5. Rogue Router Advertisements >=20 > Within a site, hosts may use IPv6 Stateless Address = Autoconfiguration > (SLAAC) [RFC4862]. However, it is possible for accidental (or > malicious) rogue RAs to cause connectivity issues, as described in > the Rogue Router Advertisement Problem Statement [RFC6104]. >=20 > A typical cause of rogue RAs is Windows ICS, which can present a > rogue 6to4 router on its wireless interface. This will cause hosts > to potentially autoconfigure two global IPv6 addresses and pick the > wrong default router, with unpredictable results. As a (bad) = example > the author experienced a scenario where he had a rogue 6to4 RA, but > because the rogue 6to4 was working he was able to access IPv6 > networks outside his own network, but could not access most = internal > hosts inside his own network because he was unwittingly using 6to4 > from outside into his own network, and thus being firewalled from > those internal hosts. >=20 > In many cases, default address selection [RFC3484] (and > [I-D.ietf-6man-rfc3484-revise]) would avoid such cases, because the > address selection rules should prefer, or can be configured to > prefer, native IPv6 over 6to4. However not all operating systems > implement RFC 3484 yet, in particular MacOS X (though support may = be > appearing in Lion). Where rogue RAs cause broken IPv6 behaviour, = the > timeout issues discussed above may apply. >=20 > Adding ACLs to your switches to block ICMPv6 Type 134 packets on > ports that do not have routers connected would also minimise the > impact of rogue RAs. A more elegant solution is RA Guard = [RFC6105], > and another is use of SEcure Neighbour Discovery (SEND) [RFC3971]. > However neither is widely implemented yet. Indeed, any reported > operational experience of SEND in an enterprise network would be = very > welcome. >=20 > Finally, there is a tool called RAmond, available freely from > http://ramond.sourceforge.net, that can be configured to detect and >=20 >=20 >=20 > Chown & Venaas Expires October 21, 2011 [Page = 7] > Internet-Draft World IPv6 Day Call to Arms April = 2011 >=20 >=20 > issue deprecating RAs against observed rogue RAs. This software is > based on rafixd. >=20 > 2.6. Tunnel performance >=20 > In scenarios where sites currently have manually configured tunnels > to gain IPv6 connectivity, it may be the case that such = encapsulation > is performed by a router's CPU, in which case unexpected high = volumes > of traffic may cause problems. Bear in mind that on World IPv6 = Day, > you may start using IPv6 by default for some high bandwidth > applications that you had not used before, e.g. YouTube from = Google. > It may be prudent to estimate your load for such applications in > advance, and test the capability of your tunnelling solution to > handle that load. >=20 > 2.7. AAAA record advertised but service not enabled >=20 > If enabling a service for World IPv6 Day, be aware of other = existing > services that may be running on the same system. If a server has > multiple functions, all services should be IPv6 enabled before a = AAAA > record is entered into the DNS for services that may use that name. >=20 > A related consideration is to make sure that firewalls don't just > drop IPv6 packets to ports that are not in use. It's better if the > firewall or host sends an unreachable indication or a TCP RST to > avoid a potential timeout. For example, if you add a AAAA record = for > your web server that also runs say FTP, where FTP is IPv4 only, > either the firewall should have port 21 open or the firewall should > be configured ta send a TCP RST. There are of course tradeoffs in > enabling ICMP unreachables. Can these tradeoffs be mentioned explicitly? >=20 >=20 > 3. Instrumentation >=20 > In this section we discuss potential instrumentation approaches = that > may be configured in advance of World IPv6 Day, and then retained > longer term after the event. These are particularly useful if your > site is turning on AAAA records for its production web presence = (for > example) and wants to get the best insight into how the systems > performed and the nature of the end user experience. >=20 > These measurements should complement informal, subjective reports > from users at participating sites. It is probably prudent to make = at > least your organisation's IT staff aware of the 'at risk' day, and > actions they should take should the experience problems. It may = also s/should the/should they Again, a reference to = http://getipv6.info/index.php/Customer_problems_that_could_occur would = be of value here I think as it provides a lot of detailed information = that support staff could use in advance of the day to develop their = support strategy. > be desirable to undertake some form of user survey soon afterwards; > whether you inform general users in advance is an issue for each > site. >=20 >=20 >=20 > Chown & Venaas Expires October 21, 2011 [Page = 8] > Internet-Draft World IPv6 Day Call to Arms April = 2011 >=20 >=20 > 3.1. IPv6 traffic levels >=20 > It should be possible to measure raw IPv6 traffic levels > independently on dual-stack switch/router platforms, given > implementations of appropriate MIBs. Sites should take steps to > ensure they have the tools in place to be able to view the relative > levels of IPv4 and IPv6 traffic over time. >=20 > Application level measurement is also desirable, because handling = of > choice (preference) of protocol used lies with the application if > both A and AAAA records are returned. Sites should be aware that = due > to IPv6 Privacy Extensions [RFC4941] application logs may show more > apparent different clients connecting, due to clients cycling the > source IPv6 address they use over time. >=20 I think you've combined three distinct measurements into one section = here, and it might be helpful to break them out: 1. IPv6 traffic volume, sources of IPv6 traffic by AS, types of IPv6 = traffic (e.g. native, 6to4, Teredo, tunnelled) 2. IPv6 application mix, comparison with IPv4 3. Number and type of IPv6 client connections > 3.2. Network flow records >=20 > Where available, sites should seek to deploy network flow records = for I think 'deploy' needs to be unpacked. You're actually recommending = sites generate and record these records, yes? So let's say that: Where = available, sites should seek to generate and record network flow = records... > traffic, to maximise opportunities to analyse traffic patterns = after > the event, or in the case of reports of specific problems. Netflow > v9 supports IPv6. Open source IPv6-capable Netflow collectors also > exist, e.g. nfsen, from http://nfsen.sourceforge.net. >=20 > 3.3. Client Web Access Success Rate >=20 > There have been some recent studies on the capabilities of web > clients to access content on dual-stack servers by IPv4 or IPv6 in > the presence of both A and AAAA records existing for a web domain. >=20 > One good example is that of [Anderson10], as reported at RIPE-61, > where the author set up some application (web server) oriented = tests > for his newspaper content in Norway. The methodology was to add an > invisible IFRAME to his site that would include IMG links randomly = to > 1x1 images that were served either via an IPv4-only target or a = dual- > stack target. Variation in the hit rates would imply IPv6 > brokenness. By analysing the http metadata information could be > gleaned on the cause of the brokenness. Results in Q4'2009 showed > 0.2-0.3% brokenness, including the Opera bug mentioned above. >=20 > Recent figures published by Google suggest at most a 0.1% level of > brokenness, indicating some improvement, but that level is still > potentially 1 in 1000 users with a problem. >=20 > 3.4. Tools to measure IPv6 brokenness This seems like a continuation of =A73.3, or maybe a subsection. =A73.3 = is an introduction to work on measuring web client brokenness, now we're = going to discuss creating your own measurements. >=20 > Sites may wish to make their own measurements of IPv6 brokenness > rather than relying on third party reports. There are some openly > available tools available that work along similar principles to the >=20 >=20 >=20 > Chown & Venaas Expires October 21, 2011 [Page = 9] > Internet-Draft World IPv6 Day Call to Arms April = 2011 >=20 >=20 > method proposed by Tore Anderson above. >=20 I think it's important to note here that you can't measure brokenness = once you have enabled dual-stack service for a site. So, for content = providers planning to enable IPv6 access on the day, the interesting = measurements are comparisons of brokenness before and after World IPv6 = Day to explore whether the event helped spur the actions needed to = reduce brokenness.=20 > The APNIC Labs test tool uses a combination of JavaScript and = Google > Analytics to measure various types of brokenness [APNIC]. Eric > Vyncke's tool [Vyncke] measures a slightly smaller set of types of > brokenness, but also looks very useful, with additional reports on > the browser type for each failure. The author is currently using = the > latter tool, and plans to enable the APNIC measurement system = shortly > when other Analytics updates are applied locally. >=20 > 3.5. IPv4 Performance Comparison >=20 > Where a dual-stack service is deployed, measuring the relative > performance of both protocols is desirable. This may primarily be = a > measurement of throughput or delay, but may also include > availability/uptime measurement. A site may choose to set up its = own > performance measuring framework, for example using open source > bandwidth and throughput test tools. >=20 Here you might add: 'Participants in World IPv6 Day will be monitored = from a broad range of locations and measurements will be available to = show availability of AAAA records, reachability to http service, latency = and availability over time.' > 3.6. User Tickets >=20 > It is possible a higher than usual user ticket rate for = connectivity > issues may be experienced. being able to categorise these cases for > subsequent analysis is desirable. >=20 > 3.7. Security monitoring >=20 > We mentioned RAmond above in the context of watching for rogue RAs. > There is another useful package called NDPmon, also available = freely > from http://ndpmon.sourceforge.net, that can be configured to watch > for certain types of IPv6 'abuse' on your local network. It may be > interesting to run the tool to confirm whether any 'bad' traffic is > observed within your network on World IPv6 Day. >=20 >=20 > 4. IPv6-only testing >=20 > The long-term IPv6 deployment plan is IPv6-only networking, rather > than dual-stack. It is not clear how quickly significant IPv6-only > networks will emerge, but testing of approaches to IPv6-only > operation is desirable as soon as possible. >=20 A reference to draft-arkko-ipv6-only-experience would be helpful here I = think. > Some experience of NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] has > been described in [I-D.tan-v6ops-nat64-experiences], though this > appears to have used only NAT-PT so far. An implementation of = NAT64 > is available at http://ecdysis.viagenie.ca. Operational experience > of IVI is also desirable. An implementation of IVI is available at > http://www.ivi2.org/IVI. >=20 >=20 >=20 > Chown & Venaas Expires October 21, 2011 [Page = 10] > Internet-Draft World IPv6 Day Call to Arms April = 2011 >=20 >=20 > 5. Conclusions >=20 > With the ISOC World IPv6 Day event due on June 8th 2011, this > document aims to help focus attention on both improving awareness = and > mitigations of common causes of IPv6 connectivity problems, and > encouraging sites and organisations to introduce appropriate > instrumentation into their networks so they can observe traffic > behaviour appropriately. >=20 > This is still an early version of the text, and is thus a little > drafty. All comments are very welcome towards a mature version in > advance of June. >=20 >=20 > 6. Security Considerations >=20 > There are no extra security consideration for this document. >=20 >=20 > 7. IANA Considerations >=20 > There are no extra IANA consideration for this document. >=20 >=20 > 8. Acknowledgments >=20 > To be added. >=20 >=20 > 9. Informative References >=20 > [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU = Discovery > for IP version 6", RFC 1981, August 1996. >=20 > [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains > via IPv4 Clouds", RFC 3056, February 2001. >=20 > [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", > RFC 3068, June 2001. >=20 > [RFC3484] Draves, R., "Default Address Selection for Internet > Protocol version 6 (IPv6)", RFC 3484, February 2003. >=20 > [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure > Neighbor Discovery (SEND)", RFC 3971, March 2005. >=20 > [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through > Network Address Translations (NATs)", RFC 4380, >=20 >=20 >=20 > Chown & Venaas Expires October 21, 2011 [Page = 11] > Internet-Draft World IPv6 Day Call to Arms April = 2011 >=20 >=20 > February 2006. >=20 > [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless > Address Autoconfiguration", RFC 4862, September 2007. >=20 > [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for = Filtering > ICMPv6 Messages in Firewalls", RFC 4890, May 2007. >=20 > [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy > Extensions for Stateless Address Autoconfiguration in > IPv6", RFC 4941, September 2007. >=20 > [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router = Advertisement > Problem Statement", RFC 6104, February 2011. >=20 > [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and = J. > Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, > February 2011. >=20 > [I-D.carpenter-v6ops-6to4-teredo-advisory] > Carpenter, B., "Advisory Guidelines for 6to4 = Deployment", > draft-carpenter-v6ops-6to4-teredo-advisory-03 (work in > progress), March 2011. >=20 > [I-D.ietf-v6ops-happy-eyeballs] > Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending > Towards Success with Dual-Stack Hosts", > draft-ietf-v6ops-happy-eyeballs-01 (work in progress), > March 2011. >=20 > [I-D.tan-v6ops-nat64-experiences] > Tan, J., Lin, J., and W. Li, "Experience from NAT64 > applications", draft-tan-v6ops-nat64-experiences-00 = (work > in progress), March 2011. >=20 > [I-D.troan-v6ops-6to4-to-historic] > Troan, O., "Request to move Connection of IPv6 Domains = via > IPv4 Clouds (6to4) to Historic status", > draft-troan-v6ops-6to4-to-historic-01 (work in = progress), > March 2011. >=20 > [I-D.ietf-v6ops-v6-aaaa-whitelisting-implications] > Livingood, J., "IPv6 AAAA DNS Whitelisting = Implications", > draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 > (work in progress), February 2011. >=20 > [I-D.chen-mif-happy-eyeballs-extension] > Chen, G. and C. Williams, "Happy Eyeballs Extension for >=20 >=20 >=20 > Chown & Venaas Expires October 21, 2011 [Page = 12] > Internet-Draft World IPv6 Day Call to Arms April = 2011 >=20 >=20 > Multiple Interfaces", > draft-chen-mif-happy-eyeballs-extension-01 (work in > progress), March 2011. >=20 > [I-D.ietf-6man-rfc3484-revise] > Matsumoto, A., Kato, J., and T. Fujisaki, "Update to RFC > 3484 Default Address Selection for IPv6", > draft-ietf-6man-rfc3484-revise-02 (work in progress), > March 2011. >=20 > [I-D.ietf-behave-v6v4-xlate-stateful] > Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful > NAT64: Network Address and Protocol Translation from = IPv6 > Clients to IPv4 Servers", > draft-ietf-behave-v6v4-xlate-stateful-12 (work in > progress), July 2010. >=20 > [APNIC] "IPv6 Capability Tracker", . >=20 > [Vyncke] Vyncke, E., "Estimation of IPv6 brokenness", > . >=20 > [ISOC] "World IPv6 Day", . >=20 > [Huston2011] > Huston, G., "Stacking it Up: Experimental Observations = on > the operation of Dual Stack Services", 2011, > . >=20 > [Savolainen2011] > Savolainen, T., "Experiences of host behaviour in broken > IPv6 networks", 2011, > = . >=20 > [Anderson10] > Anderson, T., "Measuring and Combating IPv6 Brokenness", > 2010, > . >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Chown & Venaas Expires October 21, 2011 [Page = 13] > Internet-Draft World IPv6 Day Call to Arms April = 2011 >=20 >=20 > Authors' Addresses >=20 > Tim Chown > University of Southampton > Highfield > Southampton, Hampshire SO17 1BJ > United Kingdom >=20 > Email: tjc@ecs.soton.ac.uk >=20 >=20 > Stig Venaas > Cisco Systems > Tasman Drive > San Jose, CA 95134 > USA >=20 > Email: stig@cisco.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Chown & Venaas Expires October 21, 2011 [Page = 14] >=20 From ek@google.com Thu May 5 07:45: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 BDAC3E08D4 for ; Thu, 5 May 2011 07:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.019 X-Spam-Level: X-Spam-Status: No, score=-106.019 tagged_above=-999 required=5 tests=[AWL=-2.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_RAND_1=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 REEO1P-IRSKS for ; Thu, 5 May 2011 07:45:55 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 23EB3E08D3 for ; Thu, 5 May 2011 07:45:53 -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 p45EjqDe014847 for ; Thu, 5 May 2011 07:45:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304606753; bh=kAaekD/NnfIBLtJ71dcekzVa2V4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=fpontIitCkDv6W8xvnhqpkjAt6aShSKVr4k0DmdHIkPAhXWFoPnlsWuts5CGz1+XA 0eIUegTuPLdRZEAzJYcNw== Received: from pvg3 (pvg3.prod.google.com [10.241.210.131]) by wpaz1.hot.corp.google.com with ESMTP id p45EiJDP026284 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 May 2011 07:45:51 -0700 Received: by pvg3 with SMTP id 3so1174254pvg.32 for ; Thu, 05 May 2011 07:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DIJ3nQQ4lpiLLqeoo+EU6eEkP5lzY+Hi5m1lYVUn3no=; b=qjBkLz2fcFVGWtXhI4i2FI4N+r6hZZCOlI86eTFnICabLtOBjDmExJfVY70jMtUKNx yXxPArjCl6EbGb07abPw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YcbT97MqygE+WIfuUYU9QFDVScCTkcuJAH4mO5Kkorqe+13YPeO5jfLqs3LULdHCLZ RpX42osZQbp0aFOcMvyA== MIME-Version: 1.0 Received: by 10.142.250.2 with SMTP id x2mr1258587wfh.381.1304606751025; Thu, 05 May 2011 07:45:51 -0700 (PDT) Received: by 10.142.245.14 with HTTP; Thu, 5 May 2011 07:45:50 -0700 (PDT) In-Reply-To: <4DC29A96.6020709@globis.net> References: <4DC29A96.6020709@globis.net> Date: Thu, 5 May 2011 16:45:50 +0200 Message-ID: From: Erik Kline To: Ray Hunter Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 May 2011 14:45:55 -0000 [Random responses without commentary on the draft at hand.] > That should probably be noted as an architectural concern of the WG. It is > hinted at within the existing text: "An additional concern is that the IP > address of a recursive resolver is not a precise indicator of the IPv6 > preparedness, or lack of IPv6-related impairments, of end user hosts which > query (use) a particular recursive resolver." "Precise", no. But very definitely quantifiable, to varying degrees of accuracy. > But that text does not address the concern at any architectural level > whether there should be _any_ link at all between an IPv6 transport provider > and DNS recursive resolver server address, never mind if it is a reliable > link. It is trivial to build a map of client addresses and the resolvers they use. The connection is observable, whatever that connection may be. > To it seems that broken IPv6 connectivity is the real problem, not broken > name resolution as far as I can see. Especially when it is possible to > resolve both IPv4 and IPv6 records over either IPv4 or IPv6 transport, I > really fail to see the correlation. Perhaps someone can correct my myopia > with hard data. Broken AAAA resolution can cause broken dualstack connectivity. DNS resolvers in home gateways have been variously observed to do things like dropping any query that isn't for an A record, transform the high 32bits of an AAAA response and into an A response (Jason Fesler can even test for this!), and even dropping all responses that are still less than 512 bytes but have more than 16 address records. And worse. It's a pathological world out there, as I'm sure you well know. > If someone has broken DNS recursive resolution for IPv6, it is going to > affect the majority of the IPv6 services they are using, and should stand > out like a sore thumb. They are therefore likely to be highly motivated to > point their local resolver libs at a better DNS server, and which action is > generally a fairly trivial act (altering one DHCP record at best and > rebooting machines). Ahem...what IPv6 services are they using right now? Seriously. > If there are generally large numbers of broken IPv6 DNS resolvers out there, > then there's a much bigger problem, which is certainly not going to be > solved by a point solution deployed by a few content providers. In fact aaaa > whitelisting is more likely to mask the problem than solve it IMHO. The whitelisting is indeed designed to avoid the problems and allow IPv6 to be more broadly served to those who are properly able to make use of it. But absolutely, breaking things does highlight that some things need to be fixed, and sometimes some people can even identify what those things are, and sometimes not. From gert@space.net Thu May 5 07:48: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 A8B22E08D1 for ; Thu, 5 May 2011 07:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 N0E6Q37WQEJs for ; Thu, 5 May 2011 07:48:01 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id E0E3BE08C1 for ; Thu, 5 May 2011 07:47:58 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id ACA65F820C for ; Thu, 5 May 2011 16:47:56 +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 501C8F81F7 for ; Thu, 5 May 2011 16:47:56 +0200 (CEST) Received: (qmail 38277 invoked by uid 1007); 5 May 2011 16:47:56 +0200 Date: Thu, 5 May 2011 16:47:55 +0200 From: Gert Doering To: Pekka Savola Message-ID: <20110505144755.GH30227@Space.Net> References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com> <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p> <20110504150635.GY30227@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="afAgDJwXVQqLzu+z" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, Dave Crocker , "Richard L. Barnes" Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 May 2011 14:48:01 -0000 --afAgDJwXVQqLzu+z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, May 04, 2011 at 08:38:05PM +0300, Pekka Savola wrote: > >> So, if one employs aaaa-whitelisting, then it logically seems to > >> follow that the authoritative servers must not have AAAA glue records. > > > > DNS is very good at handling the situation where certain servers out > > of a delegated sets cannot be reached, or cannot be reached via a certa= in > > protocol. >=20 > I have to disagree here. DNS is very slow at handling these issues --=20 > if the answer is not in the cache or it has timed out. The timeouts=20 > take multiple seconds or even a dozen seconds. =20 =2E.. for end user resolver libraries. Proper recursive resolver software handles this quite well, and with usually much shorter timeouts before trying alternative pointers. And it's not like IPv6 is the only way a DNS delegation chain can be broken - we quite frequently see domains that are delegated to a number of IPv4 servers of which one is not reachable. Our recursors seem to handle that quite nicely... (unbound and pdns_recursor). > IMO, DNS lookup induced timeouts are one of the most visible issues=20 > affecting end-user usage satisfaction. I don't need to have an "O" here, I have actual *experience* here :-) -=20 our DNS recursors and DNS authoritative servers have been dual-stacked for at least the last 5 years, and that hat has not caused a single problem. > As a result, I don't see major content providers adding AAAA glue to=20 > their authoritative servers any time soon even if they had the=20 > technical capability to do so. But I'd love to see them say the=20 > opposite. (For similar reasons, I don't see them enabling DNSSEC any=20 > time soon.) We're mostly a hosting provider these days, and our nameservers are dual-stacked, with glue and everything. We might not be in the global Top 10, though, so it depends on your definition of "major". Gert Doering -- NetMaster --=20 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 --afAgDJwXVQqLzu+z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTcK4m6kuBuNlUUl1AQLSDwP+ItnfdqKbUU4QmnY8dpCkE+RZb96uBu1B xgedFlEfY19XYDGyQpXm9rJ0X80mqtvBZunYDS7oWBdKxQgNDRJ27nN1OmeqJzJn oh3tGHGGUAzZc+1f51iNaZnQPjebGILAU8MSa356icSdr/zezf+W+K+Wwa/Pp27m w5naAWg75GU= =xlfh -----END PGP SIGNATURE----- --afAgDJwXVQqLzu+z-- From v6ops@globis.net Thu May 5 08:54: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 615D9E06A6 for ; Thu, 5 May 2011 08:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RAND_1=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 AaOdqokqUw3h for ; Thu, 5 May 2011 08:54: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 A1960E0728 for ; Thu, 5 May 2011 08:54:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id CBDE38700EA; Thu, 5 May 2011 17:54:31 +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 iyF6jvJVuoJg; Thu, 5 May 2011 17:54: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 AB10687007C; Thu, 5 May 2011 17:54:25 +0200 (CEST) Message-ID: <4DC2C827.4060104@globis.net> Date: Thu, 05 May 2011 17:54:15 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Erik Kline References: <4DC29A96.6020709@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040700000401060904050108" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 May 2011 15:54:35 -0000 This is a multi-part message in MIME format. --------------040700000401060904050108 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Thanks very much for replying. Comments in line. Erik Kline wrote: > [Random responses without commentary on the draft at hand.] > > >> That should probably be noted as an architectural concern of the WG. It is >> hinted at within the existing text: "An additional concern is that the IP >> address of a recursive resolver is not a precise indicator of the IPv6 >> preparedness, or lack of IPv6-related impairments, of end user hosts which >> query (use) a particular recursive resolver." >> > > "Precise", no. But very definitely quantifiable, to varying degrees > of accuracy. > > hmm potentially some confusion over precision and accuracy. AFAIK Precision is whether a measurement is repeatable within a certain confidence range, irrespective of how true it is. Accuracy is how close the overall measured result is to the actually true value. Care to share operational data? >> But that text does not address the concern at any architectural level >> whether there should be _any_ link at all between an IPv6 transport provider >> and DNS recursive resolver server address, never mind if it is a reliable >> link. >> > > It is trivial to build a map of client addresses and the resolvers > they use. The connection is observable, whatever that connection may > be. > > Really? Interesting. I'm sure you can track back to the set of (recursive) DNS servers that have contacted your authoritative DNS over a period of time, plus how they connected you, but can you track all the way back to the individual hosts / DNS client resolver libraries that are querying those recursive DNS servers? That's partially my concern: how do you know where I've pointed my local resolver lib on my end hosts, compared to my next door neighbor, who may have broken IPv6 connectivity and/or a broken IPv6 DNS resolution? Especially if the recursive DNS name server for example has cached the response, how do you know who else has asked the same question from their local resolver lib to that recursive DNS name server, and you never ever even saw the query? p34 of DNS and Bind With version 4.8 8 & 9 of BIND name servers even implement negative caching .... if the name server has cached the answer, positive or negative, it simply returns the answer to the resolver. And what about DNS forwarders? Equally, with widespread use of tunnels like 6in4 (or even dual transport providers) expected to be deployed in the transition to IPv6, how do you reliably correlate my IPv4 address with my IPv6 address? They may be 100% completely separate paths and providers, except for that very last hop from my IPv6 dual stack node to my site border router(s). There's plenty of discussion still on multihoming and how to transition. Many recommend contracting a separate link for IPv6. There's especially still a lot of ongoing discussion on how to handle DNS resolution in a multihomed/ transitioning World. So I'd be very wary about making assumptions of relationships between IPv6 connectivity and DNS address resolution. YMMV. >> To it seems that broken IPv6 connectivity is the real problem, not broken >> name resolution as far as I can see. Especially when it is possible to >> resolve both IPv4 and IPv6 records over either IPv4 or IPv6 transport, I >> really fail to see the correlation. Perhaps someone can correct my myopia >> with hard data. >> > > Broken AAAA resolution can cause broken dualstack connectivity. DNS > resolvers in home gateways have been variously observed to do things > like dropping any query that isn't for an A record, transform the high > 32bits of an AAAA response and into an A response (Jason Fesler can > even test for this!), and even dropping all responses that are still > less than 512 bytes but have more than 16 address records. And worse. > > It's a pathological world out there, as I'm sure you well know. > > Sure. And I think we're both trying to make it better. Completely disabling or crippling IPv6 DNS resolution is not going to make it any better. So it's just a question of how we make it better. >> If someone has broken DNS recursive resolution for IPv6, it is going to >> affect the majority of the IPv6 services they are using, and should stand >> out like a sore thumb. They are therefore likely to be highly motivated to >> point their local resolver libs at a better DNS server, and which action is >> generally a fairly trivial act (altering one DHCP record at best and >> rebooting machines). >> > > Ahem...what IPv6 services are they using right now? Seriously. > > My company's web server, SSH, admin system, and SMTP mail service already run native IPv6 dual stack, without aaaa whitelisting. This very mail was probably sent over IPv6 to the IETF's server (the inbound mail certainly was if I check my logs.) If people have a problem with my IPv6 services, because of their broken service, I normally see it as their problem. The transition to IPv6 will probably be painful. AAAA whitelisting will probably also be painful. But I guess I have the luxury of not getting paid per click. >> If there are generally large numbers of broken IPv6 DNS resolvers out there, >> then there's a much bigger problem, which is certainly not going to be >> solved by a point solution deployed by a few content providers. In fact aaaa >> whitelisting is more likely to mask the problem than solve it IMHO. >> > > The whitelisting is indeed designed to avoid the problems and allow > IPv6 to be more broadly served to those who are properly able to make > use of it. > > But absolutely, breaking things does highlight that some things need > to be fixed, and sometimes some people can even identify what those > things are, and sometimes not. > --------------040700000401060904050108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Thanks very much for replying.

Comments in line.

Erik Kline wrote: 
[Random responses without commentary on the draft at hand.]

  
That should probably be noted as an architectural concern of the WG. It is
hinted at within the existing text: "An additional concern is that the IP
address of a recursive resolver is not a precise indicator of the IPv6
preparedness, or lack of IPv6-related impairments, of end user hosts which
query (use) a particular recursive resolver."
    

"Precise", no.  But very definitely quantifiable, to varying degrees
of accuracy.
hmm potentially some confusion over precision and accuracy.

AFAIK Precision is whether a measurement is repeatable within a certain confidence range, irrespective of how true it is.
Accuracy is how close the overall measured result is to the actually true value.

Care to share operational data?


  

    
But that text does not address the concern at any architectural level
whether there should be _any_ link at all between an IPv6 transport provider
and DNS recursive resolver server address, never mind if it is a reliable
link.
    

  

  

It is trivial to build a map of client addresses and the resolvers
they use.  The connection is observable, whatever that connection may
be.

  



Really? Interesting.



I'm sure you can track back to the set of (recursive) DNS servers that
have contacted your authoritative DNS over a period of time, plus how
they connected you, but can you track all the way back to the
individual hosts / DNS client resolver libraries that are querying
those recursive DNS servers?



That's partially my concern: how do you know where I've pointed my
local resolver lib on my end hosts, compared to my next door neighbor,
who may have broken IPv6 connectivity and/or a broken IPv6 DNS
resolution?



Especially if the recursive DNS name server for example has cached the
response, how do you know who else has asked the same question from
their local resolver lib to that recursive DNS name server, and you
never ever even saw the query?



p34 of DNS and Bind With version 4.8 8 & 9 of BIND name servers
even implement negative caching .... if the name server has cached the
answer, positive or negative, it simply returns the answer to the
resolver.



And what about DNS forwarders?



Equally, with widespread use of tunnels like 6in4 (or even dual
transport providers) expected to be deployed in the transition to IPv6,
how do you reliably correlate my IPv4 address with my IPv6 address?
They may be 100% completely separate paths and providers, except for
that very last hop from my IPv6 dual stack node to my site border
router(s). There's plenty of discussion still on multihoming and how to
transition. Many recommend contracting a separate link for IPv6.
There's especially still a lot of ongoing discussion on how to handle
DNS resolution in a multihomed/ transitioning World.



So I'd be very wary about making assumptions of relationships between
IPv6 connectivity and DNS address resolution. YMMV.





  

  

    
To it seems that broken IPv6 connectivity is the real problem, not broken
name resolution as far as I can see. Especially when it is possible to
resolve both IPv4 and IPv6 records over either IPv4 or IPv6 transport, I
really fail to see the correlation. Perhaps someone can correct my myopia
with hard data.
    

  

  

Broken AAAA resolution can cause broken dualstack connectivity.  DNS
resolvers in home gateways have been variously observed to do things
like dropping any query that isn't for an A record, transform the high
32bits of an AAAA response and into an A response (Jason Fesler can
even test for this!), and even dropping all responses that are still
less than 512 bytes but have more than 16 address records.  And worse.

It's a pathological world out there, as I'm sure you well know.

  



Sure. And I think we're both trying to make it better. Completely
disabling or crippling IPv6 DNS resolution is not going to make it any
better. So it's just a question of how we make it better.



  

  

    
If someone has broken DNS recursive resolution for IPv6, it is going to
affect the majority of the IPv6 services they are using, and should stand
out like a sore thumb. They are therefore likely to be highly motivated to
point their local resolver libs at a better DNS server, and which action is
generally a fairly trivial act (altering one DHCP record at best and
rebooting machines).
    

  

  

Ahem...what IPv6 services are they using right now?  Seriously.

  



My company's web server, SSH, admin system, and SMTP mail service
already run native IPv6 dual stack, without aaaa whitelisting.



This very mail was probably sent over IPv6 to the IETF's server (the
inbound mail certainly was if I check my logs.)



If people have a problem with my IPv6 services, because of their broken
service, I normally see it as their problem.



The transition to IPv6 will probably be painful. AAAA whitelisting will
probably also be painful.



But I guess I have the luxury of not getting paid per click.





  

  

    
If there are generally large numbers of broken IPv6 DNS resolvers out there,
then there's a much bigger problem, which is certainly not going to be
solved by a point solution deployed by a few content providers. In fact aaaa
whitelisting is more likely to mask the problem than solve it IMHO.
    

  

  

The whitelisting is indeed designed to avoid the problems and allow
IPv6 to be more broadly served to those who are properly able to make
use of it.

But absolutely, breaking things does highlight that some things need
to be fixed, and sometimes some people can even identify what those
things are, and sometimes not.
  








--------------040700000401060904050108--

From ek@google.com  Thu May  5 09:13: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 1D7B9E077B for ; Thu,  5 May 2011 09:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.862
X-Spam-Level: 
X-Spam-Status: No, score=-106.862 tagged_above=-999 required=5 tests=[AWL=-0.885, 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 iiVtekv7mfQE for ; Thu,  5 May 2011 09:13:38 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFD1E0694 for ; Thu,  5 May 2011 09:13:37 -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 p45GDapV022406 for ; Thu, 5 May 2011 09:13:36 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304612016; bh=RkYV5qDklK6YE8dHcBcF8nU9N3k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=NWjOqus7V2t0oAa4z6eTyhO5hUK4L05h7FnNoofANdwmtGcReNHsNLo16gPJabGXG lswkNYEEmYFedAytXyRUQ==
Received: from pzk30 (pzk30.prod.google.com [10.243.19.158]) by wpaz29.hot.corp.google.com with ESMTP id p45GDJep005680 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 May 2011 09:13:34 -0700
Received: by pzk30 with SMTP id 30so1220153pzk.32 for ; Thu, 05 May 2011 09:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=409fLuD8S/Ip0sRNXdlxhwV/wd65qjkOxNMUVjn5xvw=; b=RAFtUzVM63ftcYH6jr6iA0H+H/nqnxYjYubyCp8AVBA5k6B4WuCs2s7oU6lWRsJOM/ niSlLqMXnago/ydM3YiA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gfP3qhsRuYuPj1TDACdFeikXb0woQLzo98OYlkYAbR2eKkvJgIn55EF66e8IEixcOH 3Q6DJvEGQqM5OM8c1Rng==
MIME-Version: 1.0
Received: by 10.142.250.2 with SMTP id x2mr1307542wfh.381.1304612014428; Thu, 05 May 2011 09:13:34 -0700 (PDT)
Received: by 10.142.245.14 with HTTP; Thu, 5 May 2011 09:13:34 -0700 (PDT)
In-Reply-To: 
References: <4DBFB4E7.5010806@globis.net> 
Date: Thu, 5 May 2011 18:13:34 +0200
Message-ID: 
From: Erik Kline 
To: "John Mann (ITS)" 
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 05 May 2011 16:13:41 -0000

I would like to add that it's the asymmetric routing that's the
problem with proto41 blocking detection ever working for 6to4.

Terminology/glossary for the example below:

    C:  the 6to4-using client

    DR:  the Decapsulating Relay (where proto41 packets from C to
192.88.99.1 actually go)

    S1:  an IPv6 server

    S2:  another IPv6 server

    Sn:  the Nth IPv6 server

    ER1:  the Encapsulation Relay for S1 (where native IPv6 packets
from S1 toward 2002::/16 actually go)

    ER2:  the Encapsulation Relay for S2 (where native IPv6 packets
from S2 toward 2002::/16 actually go)

    ERn:  the Encapsulation Relay for Sn (where native IPv6 packets
from Sn toward 2002::/16 actually go)


[Assumption 1]

The IETF issues an RFC to update 6to4 to include
6rd/ISATAP/whatever-style in-band reachability checks such that a
suitably-compliant 6to4 client can verify that proto41 is successfully
reaching its DR and know that this is working and detect rapidly when
it stops working.


[Assumption 2]

Client C is running the super-awesome newly-fixed 6to4 code update
with an implementation of Assumption 1.


[Assumption 3]

Client C is using and monitoring a fully functioning and super-awesome DR.


[Assumption 4]

There are no IPv6 peering disputes and IPv6 traffic from DR to S1..Sn
works perfectly.  [In reality, this should be the steady state of the
IPv6 Internet.]


[Assumption 5]

There are no IPv4 peering disputes and IPv4 traffic from ER1..ERn to C
works perfectly.  [In reality, this should be the steady state of the
IPv4 Internet.]


[Assumption 6]

Each S1..Sn have a route for 2002::/16 successfully reaching
corresponding ER1..ERn.



The fundamental architectural problem is that even with "proto41
detection", C can not verify that proto41 packets can be sent from ER1
to C.  And if they do happen to pass just fine, there's no way to
verify that they can flow from ER2 to C, ..., or ERn to C.

Furthermore, Assumption 6 is seriously in doubt.  In order for 6to4 to
work reliably for all S1..Sn (where N is the total number of IPv6
destinations C might ever desire to reach), Assumption 6 must not be
an assumption but a proven, working fact.  This is something that is
operationally unrealistic.  It lives solely in the "if only everyone
would just..." category of wishes and fairy tales.

"Symmetric", managed uses of proto41 don't suffer from these problems.
 There are no uncertain paths from Sn to ERn (it's just Sn back to C's
IPv6 ISP which fall under Assumption 4), and there is multitude of ERn
to C links, but rather the "ERn"s collapse into DR (philosophically,
if not quite literally in implementation, obviously).  Both the key
troubling parts in the return path from Sn to C are removed, and
proto41 detection is basically sufficient.



From lorenzo@google.com  Thu May  5 09:16: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 D5BA9E0779 for ; Thu,  5 May 2011 09:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 1kwch5nsd1vK for ; Thu,  5 May 2011 09:16: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 52DE3E08A6 for ; Thu,  5 May 2011 09:16:39 -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 p45GGcJA029517 for ; Thu, 5 May 2011 09:16:38 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304612198; bh=jrc6+4ak0zK3bYssi3a+q4wDvPc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=DYW6tCLmJhWs3nTsIHSodoIYS5RGvpPMQFlgcV1BXSeoEoW3tR37J8gBYJIo2VD/g cSfYhGzsQH1Gb9jHVyPww==
Received: from gxk1 (gxk1.prod.google.com [10.202.11.1]) by wpaz29.hot.corp.google.com with ESMTP id p45GGb0d009482 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 May 2011 09:16:37 -0700
Received: by gxk1 with SMTP id 1so1095676gxk.24 for ; Thu, 05 May 2011 09:16:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OAvJyNoZ7uVUKc0MHd+xY3piuiuBsc3IctGjI4rq+r8=; b=xClx3Ib+nzNZlFqyh24LlYPVUQ6dHJY0paxRSNwCWelV7kwdqOfjoKfDYFxhqEZtsy UA95uBJErfiADTgNJi1g==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=L/kpX+qWTga4YmQ6/W4UcYbAK/SbM57mPUKeGckdjYLbe1eulztIQYM1FHF5O8BTyW NNMXXwApydtNIV/eRxhw==
Received: by 10.151.24.10 with SMTP id b10mr2385405ybj.93.1304612197211; Thu, 05 May 2011 09:16:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Thu, 5 May 2011 09:16:17 -0700 (PDT)
In-Reply-To: <4DC2C827.4060104@globis.net>
References: <4DC29A96.6020709@globis.net>  <4DC2C827.4060104@globis.net>
From: Lorenzo Colitti 
Date: Thu, 5 May 2011 18:16:17 +0200
Message-ID: 
To: Ray Hunter 
Content-Type: multipart/alternative; boundary=000e0cd23ef6959f9d04a289b2fb
X-System-Of-Record: true
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 05 May 2011 16:16:42 -0000

--000e0cd23ef6959f9d04a289b2fb
Content-Type: text/plain; charset=ISO-8859-1

On Thu, May 5, 2011 at 5:54 PM, Ray Hunter  wrote:

> Ahem...what IPv6 services are they using right now?  Seriously.
>
>  My company's web server, SSH, admin system, and SMTP mail service already
> run native IPv6 dual stack, without aaaa whitelisting.
>

I think that what Erik meant is that if you look at your favourite list of
most popular websites, you will find very few that are IPv6-enabled.

--000e0cd23ef6959f9d04a289b2fb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, May 5, 2011 at 5:54 PM, Ray Hunter <v6ops@globis.net&g=
t; wrote:





 =20


Ahem...what IPv6 services are they using right now?  Seriou=
sly.  



My company's web server, SSH, admin system, and SMTP mail service
already run native IPv6 dual stack, without aaaa whitelisting.

I think that what Erik meant is that=A0if you=
 look at your favourite list of most popular websites, you will find very f=
ew that are IPv6-enabled.





--000e0cd23ef6959f9d04a289b2fb--

From pch-b6B5344D9@u-1.phicoh.com  Thu May  5 13:23: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 C20BFE0A03 for ; Thu,  5 May 2011 13:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.932
X-Spam-Level: 
X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=0.667,  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 1wub0EWtrJPF for ; Thu,  5 May 2011 13:23:40 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5F39EE08CF for ; Thu,  5 May 2011 13:23:38 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #50) id m1QI556-0001k0C; Thu, 5 May 2011 22:23 +0200
Message-Id: 
To: Erik Kline 
From: Philip Homburg 
Sender: pch-b6B5344D9@u-1.phicoh.com
References: <4DC29A96.6020709@globis.net>  
In-reply-to: Your message of "Thu, 5 May 2011 16:45:50 +0200 ."  
Date: Thu, 05 May 2011 22:23:14 +0200
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 05 May 2011 20:23:40 -0000

In your letter dated Thu, 5 May 2011 16:45:50 +0200 you wrote:
>> To it seems that broken IPv6 connectivity is the real problem, not broken
>> name resolution as far as I can see. Especially when it is possible to
>> resolve both IPv4 and IPv6 records over either IPv4 or IPv6 transport, I
>> really fail to see the correlation. Perhaps someone can correct my myopia
>> with hard data.
>
>Broken AAAA resolution can cause broken dualstack connectivity.  DNS
>resolvers in home gateways have been variously observed to do things
>like dropping any query that isn't for an A record, transform the high
>32bits of an AAAA response and into an A response (Jason Fesler can
>even test for this!), and even dropping all responses that are still
>less than 512 bytes but have more than 16 address records.  And worse.
>
>It's a pathological world out there, as I'm sure you well know.
>
>> If someone has broken DNS recursive resolution for IPv6, it is going to
>> affect the majority of the IPv6 services they are using, and should stand
>> out like a sore thumb. They are therefore likely to be highly motivated to
>> point their local resolver libs at a better DNS server, and which action is
>> generally a fairly trivial act (altering one DHCP record at best and
>> rebooting machines).
>
>Ahem...what IPv6 services are they using right now?  Seriously.

I'd like to point out that many gTLD and ccTLD zones do have IPv6 addresses in
their glue. And there don't seem many complaints about it.

Now, I think the real issue, which seems to be missing in the draft (at
least after a quick read of the draft), is what happens to people who have
good IPv6 connectivity and poor IPv4 connectivity.

I don't get IPv6 addresses for Google at work (not whitelisted) or at home
(the network is whitelisted but I use a resolver in another netblock). But
does it really matter? I have excellent IPv4 connectivity. And there are
plenty of smaller sites with IPv6 addresses to test IPv6.

So the people who are really going to be affected by (the lack of) whitelisting
are those with good IPv6 connectivity poor IPv4 connectivity. I'm not sure
that there many of those at the moment.

But when they come, it will be interesting to see what will happen. Many big
companies have a very poor track record communicating with small parties.
So it is quite possible to at some point a small ISP will find it 
impossible to get it's customers whitelisted. And that will be the moment
whitelisting really hurts the Internet.



From Fred.L.Templin@boeing.com  Thu May  5 14: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 8FAF9E06D6 for ; Thu,  5 May 2011 14:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.532
X-Spam-Level: 
X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067,  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 5SJTvYoeDwjq for ; Thu,  5 May 2011 14:09:47 -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 37001E067C for ; Thu,  5 May 2011 14:09:47 -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 p45L9aAc009885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 May 2011 14:09:37 -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 p45L9axC026003 for ; Thu, 5 May 2011 14:09:36 -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 p45L9aLx025997 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Thu, 5 May 2011 14:09:36 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Thu, 5 May 2011 14:09:36 -0700
From: "Templin, Fred L" 
To: "v6ops@ietf.org" 
Date: Thu, 5 May 2011 14:09:35 -0700
Thread-Topic: Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP
Thread-Index: AcwLZrl0rQWfcfefT4KpYWOkmURZIAAAQgbg
Message-ID: 
References: <4DBFB4E7.5010806@globis.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
Subject: [v6ops] Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 05 May 2011 21:09:49 -0000

Hello,

There has been quite a bit of discussion about the
uncertainty of unmanaged transition tools such as
6to4 and teredo. One way to turn off the unmanaged
tools is to turn on a managed tool such as ISATAP.

A new I-D on "Operational Guidance for IPv6 Deployment
in IPv4 Sites Using ISATAP" has been posted (see below).
Please review and send comments to the list.

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

--- cut here ---
From: internet-drafts@ietf.org=20
To: i-d-announce@ietf.org=20
Reply-to: internet-drafts@ietf.org=20
Subject: I-D Action: draft-templin-v6ops-isops-00.txt=20
X-RSN: 1/0/935/36563/39932=20
=20
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.=20
=20
Title : Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP=
=20
Author(s) : Fred L. Templin=20
Filename : draft-templin-v6ops-isops-00.txt=20
Pages : 18=20
Date : 2011-05-05=20
=20
Many end user sites in the Internet today still have predominantly=20
IPv4 internal infrastructures. These sites range in size from small=20
home/office networks to large corporate enterprise networks, but=20
share the commonality that IPv4 continues to provide satisfactory=20
internal routing and addressing services for most applications. As=20
more and more IPv6-only services are deployed in the Internet,=20
however, end user devices within such sites will increasingly require=20
at least basic IPv6 functionality for external access. It is also=20
expected that more and more IPv6-only devices will be deployed within=20
the site over time. This document therefore provides operational=20
guidance for deployment of IPv6 within predominantly IPv4 sites using=20
the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).=20
=20
=20
A URL for this Internet-Draft is:=20
http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-00.txt=20
=20
Internet-Drafts are also available by anonymous FTP at:=20
ftp://ftp.ietf.org/internet-drafts/=20
=20
This Internet-Draft can be retrieved at:=20
ftp://ftp.ietf.org/internet-drafts/draft-templin-v6ops-isops-00.txt=20
_______________________________________________=20
I-D-Announce mailing list=20
I-D-Announce@ietf.org=20
https://www.ietf.org/mailman/listinfo/i-d-announce=20
Internet-Draft directories: http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =

From marka@isc.org  Thu May  5 15:12: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 6C186E07F0 for ; Thu,  5 May 2011 15:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.841
X-Spam-Level: 
X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.158,  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 t0-WI8vYXkQe for ; Thu,  5 May 2011 15:12:44 -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 EE005E0593 for ; Thu,  5 May 2011 15:12:43 -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 C5873C941E; Thu,  5 May 2011 22:12:40 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 4D11D216C1E; Thu,  5 May 2011 22:12:40 +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 DCDB9E7E914; Fri,  6 May 2011 08:12:37 +1000 (EST)
To: Pekka Savola 
From: Mark Andrews 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>   <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p>   <20110504150635.GY30227@Space.Net> 
In-reply-to: Your message of "Wed, 04 May 2011 20:38:05 +0300." 
Date: Fri, 06 May 2011 08:12:37 +1000
Message-Id: <20110505221237.DCDB9E7E914@drugs.dv.isc.org>
Cc: "Richard L. Barnes" , v6ops@ietf.org, Dave Crocker 
Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 05 May 2011 22:12:46 -0000

In message , Pekka Savola writes:
> On Wed, 4 May 2011, Gert Doering wrote:
> > The IPv6 connectivity or not of the recursive resolver is no indication
> > on the brokenness of the IPv6 connectivity of the *end user* querying
> > this resolver.
> 
> While this is true in theory, I don't think it applies in practise in 
> this case.
> 
> Whitelisting is done by whitelisting resolvers, i.e., ISPs.
> 
> There is a connection between broken users and broken (IPv6) resolvers 
> in the case that ISP's IPv6 is unreliable.  Indeed, Google has 
> requirements for the v6 connectivity of the ISP as well.
> 
> In the typical case, however, you're right that the brokenness of IPv6 
> resolvers and IPv6 end-users are orthogonal.  But that does not change 
> the main point, i.e., that in the case the IPv6-capable resolver is 
> broken, lots of end-users will be affected.
> 
> I would be interested in seeing measurements on the brokenness of 
> resolvers when a) IPv4 is used for AAAA queries, and b) IPv6 is used 
> for AAAA queries.  Both are known to have issues in certain cases.
> 
> >> So, if one employs aaaa-whitelisting, then it logically seems to
> >> follow that the authoritative servers must not have AAAA glue records.
> >
> > DNS is very good at handling the situation where certain servers out
> > of a delegated sets cannot be reached, or cannot be reached via a certain
> > protocol.
> 
> I have to disagree here.  DNS is very slow at handling these issues -- 
> if the answer is not in the cache or it has timed out.  The timeouts 
> take multiple seconds or even a dozen seconds.  In the worst case, the 
> resolver keeps hammering the authoritative server that's down again 
> and again, and every lookup will time out. If the end-user has to wait 
> even a couple of seconds or a dozen seconds, I think from Google POV 
> that's effectively equivalent to broken end-user experience.

Which really is not true.  Please go do the exercise of running a
dual stack recursive nameserver and filtering out the IPv6 DNS
traffic from that server without sending back ICMPv6 messages.  If
you want a server to zone to test against use isc.org's.  It, org
and the root have IPv6 address and IPv6 glue/hints.  All the zones
are also signed so you have big answers some of which will be
fragmented if your recursive server sets DO=1 in the queries.

Yes the initial query takes about 3 seconds as the resolver discovers
that it can't reach the root, org or isc.org over IPv6.  Subsequent
queries take much less time.  Usually a single round trip.

Look at the packet traces.  Named uses a 800ms timer on timeouts and
we will be dropping it to ~200ms in future versions mainly to deal
with firewalls blocking EDNS response > 512 bytes.  Other vendors
use similar timeouts.

Named can also be configured to run IPv4 only on a dual stack box
(named -4).
Named can also be configured to run IPv6 only on a dual stack box
(named -6).
Named can be configured to only query IPv4 servers but respond on
both stacks (servers ::/0 { bogus yes; };).
Named can be configured to only query IPv6 servers but respond on
both stacks (servers 0.0.0.0/0 { bogus yes; };).
Named can be configured to treat all but certain address ranges as
unreachable (if you are using ULA but have no external IPv6 connectivity
servers ::/0 { bogus yes; }; servers fdxx:xxx:xxxx::/48 { bogus no; }; ).

Some or all of these features are available from other vendors.

As a vendor we looked at this a decade ago back when people were
playing with site-local addresses.

> IMO, DNS lookup induced timeouts are one of the most visible issues 
> affecting end-user usage satisfaction.

Much more frustating is IPv4 nameservers that drop AAAA queries or
return invalid negative answers for AAAA queries.  These affect
everybody and there are no workarounds that can be deployed locally.

> As a result, I don't see major content providers adding AAAA glue to 
> their authoritative servers any time soon even if they had the 
> technical capability to do so. But I'd love to see them say the 
> opposite. (For similar reasons, I don't see them enabling DNSSEC any 
> time soon.)
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> _______________________________________________
> 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 v6ops@globis.net  Thu May  5 15:29: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 DDBDDE06B7 for ; Thu,  5 May 2011 15:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.361
X-Spam-Level: 
X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.237,  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 F-7VGNCE6PIe for ; Thu,  5 May 2011 15:29:08 -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 D6ADEE0593 for ; Thu,  5 May 2011 15:29:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 47E608700F2 for ; Fri,  6 May 2011 00:29: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 B9BdM50q5JBc for ; Fri,  6 May 2011 00:29:01 +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 108B38700B5 for ; Fri,  6 May 2011 00:29:01 +0200 (CEST)
Message-ID: <4DC324A1.4030109@globis.net>
Date: Fri, 06 May 2011 00:28:49 +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="------------070908070106050305030403"
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 05 May 2011 22:29:09 -0000

This is a multi-part message in MIME format.
--------------070908070106050305030403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

>
>
>
>
>
> On Thu, May 5, 2011 at 5:54 PM, Ray Hunter  > wrote:
>
>>     Ahem...what IPv6 services are they using right now?  Seriously.
>     My company's web server, SSH, admin system, and SMTP mail service
>     already run native IPv6 dual stack, without aaaa whitelisting.
>
>
> I think that what Erik meant is that if you look at your favourite 
> list of most popular websites, you will find very few that are 
> IPv6-enabled.
Please note my replies are meant to be humorous & thought provoking, and 
not meant to be considered antagonistic.

I know exactly what he meant. Well my website is in my favorites. It 
also hosts a bugzilla server, a Twiki knowledge base, a bzr code 
repository (over SSH), and my webmail for when I'm travelling. I use it 
every day for work. A lot. It's important to me. I can't say the same 
about Altavista or whatever other newcomer search engine is popular with 
the kids these days, unless someone else placed it in my favorites list 
automatically. ;)

What I mean to say, although perhaps it was too subtle:

The whole concept of whitelisting is suspect as a general deployment 
methodology.

AAAA whitelisting may be good in general for the Internet if the few big 
sites that currently generate a lot of IPv4 traffic do it well and use 
it to aid in a transition to IPv6, but absolutely terrible for the 
Internet if the overall majority of sites deploy it.

If everyone employs DNS aaaa whitelists then nothing may ever 
transition, because he'll be testing my DNS and my aaaa whitelist 
authoritative server may reply with IPv4 only addresses to him (I 
haven't whitelisted him yet, so in his eyes it looks broken), and if I 
test his DNS he'll be replying with IPv4 only to me because my DNS quite 
obviously does not have any IPv6 content yet (even though it actually 
already has top level domain glue records in place), and no-one gets 
anywhere, because we have this continual stalemate of "why deploy IPv6 
because there's no traffic and IPv4 works just fine for me".

We all seriously need to start eating our own dog food, and I'm 
delighted to see such large players supporting World IPv6 day.

regards,
RayH

--------------070908070106050305030403
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit










  

    
      

        

        		
      

      

        

        		
      

      

        

        		
      

    
  

  

  

  
On Thu, May 5, 2011 at 5:54 PM, Ray Hunter <v6ops@globis.net>
wrote:

  

    

    

    

      
Ahem...what IPv6 services are they using right now?  Seriously.  

    

    

My company's web server, SSH, admin system, and SMTP mail service
already run native IPv6 dual stack, without aaaa whitelisting.

    

  

  


  

  
I
think that what Erik meant is that if you look at your favourite list
of most popular websites, you will find very few that are IPv6-enabled.

  

  



Please note my replies are meant to be humorous & thought
provoking, and not meant to be considered antagonistic.



I know exactly what he meant. Well my website is in my favorites. It
also hosts a bugzilla server, a Twiki knowledge base, a bzr code
repository (over SSH), and my webmail for when I'm travelling. I use it
every day for work. A lot. It's important to me. I can't say the same
about Altavista or whatever other newcomer search engine is popular
with the kids these days, unless someone else placed it in my favorites
list automatically. ;)



What I mean to say, although perhaps it was too subtle: 



The whole concept of whitelisting is suspect as a general deployment
methodology.



AAAA whitelisting may be good in general for the Internet if the few
big
sites that currently generate a lot of IPv4 traffic do it well and use
it to aid in a transition to IPv6, but absolutely terrible for the
Internet if the overall majority of sites deploy it.



If everyone employs DNS aaaa whitelists then nothing may ever
transition, because he'll be testing my DNS and my aaaa whitelist
authoritative server may reply with IPv4 only addresses to him (I
haven't whitelisted him yet, so in his eyes it looks broken), and if I
test his DNS he'll be replying with IPv4 only to me because my DNS
quite obviously does not have any IPv6 content yet (even though it
actually already has top level domain glue records in place), and
no-one gets anywhere, because we have this continual stalemate of "why
deploy IPv6 because there's no traffic and IPv4 works just fine for me".



We all seriously need to start eating our own dog food, and I'm
delighted to see such large players supporting World IPv6 day.



regards,

RayH




--------------070908070106050305030403--

From martin@millnert.se  Thu May  5 16:45: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 F27EEE0678 for ; Thu,  5 May 2011 16:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.419
X-Spam-Level: 
X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180,  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 bFtJrvuPYJtk for ; Thu,  5 May 2011 16:45:16 -0700 (PDT)
Received: from ncis.csbnet.se (ncis.csbnet.se [IPv6:2a02:9a0:4:104:5054:ff:feb8:99a4]) by ietfa.amsl.com (Postfix) with ESMTP id DD3A3E06DF for ; Thu,  5 May 2011 16:45:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id A5E437827; Fri,  6 May 2011 02:02:05 +0200 (CEST)
Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ereXG-5fZcT2; Fri,  6 May 2011 02:02:05 +0200 (CEST)
Received: from [192.168.124.253] (209-6-92-201.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.92.201]) by ncis.csbnet.se (Postfix) with ESMTPSA id 8DCDD774F; Fri,  6 May 2011 02:02:04 +0200 (CEST)
From: Martin Millnert 
To: Ray Hunter 
In-Reply-To: <4DC2C827.4060104@globis.net>
References: <4DC29A96.6020709@globis.net>  <4DC2C827.4060104@globis.net>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 05 May 2011 19:45:05 -0400
Message-ID: <1304639105.3125.90.camel@shakira.millnert.se>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 05 May 2011 23:45:17 -0000

Ray,

On Thu, 2011-05-05 at 17:54 +0200, Ray Hunter wrote:
> I'm sure you can track back to the set of (recursive) DNS servers that
> have contacted your authoritative DNS over a period of time, plus how
> they connected you, but can you track all the way back to the
> individual hosts / DNS client resolver libraries that are querying
> those recursive DNS servers?
> 
> That's partially my concern: how do you know where I've pointed my
> local resolver lib on my end hosts, compared to my next door neighbor,
> who may have broken IPv6 connectivity and/or a broken IPv6 DNS
> resolution?

Seeing how Erik did not yet reply to this (and assuming he does not
intend to), I'd just like to offer a plausible explanation from a
general computer engineering perspective:

Assuming:
 1) you have a way to track user sessions or users,
 2) you have a way to log DNS queries and additionally setup mappings
for special queries, like those some IPv6 test sites famously does
(unique records per test/user/session),
 3) you have a way to connect the session/user driving code in 1 to
generate certain specific records in 2, OR, you have some even more
intelligent log parsing algorithms and some prepared/algorithmic unique
record response scheme,

you should be able to with quite high confidentiality build a map of
this relationship.  You don't have to hit every user on every hit,
either, you can add some statistical mumbu jumbo :) in it to arrive at
results within a certain confidence interval.

The above is just what seems obvious to me.  Takes a non-trivial amount
of supporting system code, especially for a larger system, but even at
least one of these test-IPv6 sites managed to do it, presumably with a
lot less backing resources and less code.

It will probably not fingerprint what resolver library you use (though
that seems like a research field in itself), and may only give a more
generalized / aggregate view of the (subnet:resolver):ipv6-score
mappings.  But this information is surely telling more about the general
quality of a ISPs IPv6-readiness, than no such information at all.

Best,
Martin


From marka@isc.org  Thu May  5 17: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 093ACE06CF for ; Thu,  5 May 2011 17:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.153
X-Spam-Level: 
X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446,  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 M8JsIN8qDd1N for ; Thu,  5 May 2011 17:39:20 -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 3A446E0676 for ; Thu,  5 May 2011 17:39:19 -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 42EB4C9423; Fri,  6 May 2011 00:39:15 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 D0A85216C31; Fri,  6 May 2011 00:39:14 +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 395B1E84435; Fri,  6 May 2011 10:39:12 +1000 (EST)
To: "Williams, Marcus (Contractor)" 
From: Mark Andrews 
References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com>   <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> <20110503191344.GA6741@srv03.cluenet.de> <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.com> 
In-reply-to: Your message of "Thu, 05 May 2011 08:25:49 EST." 
Date: Fri, 06 May 2011 10:39:12 +1000
Message-Id: <20110506003912.395B1E84435@drugs.dv.isc.org>
Cc: Thomas Narten , "v6ops@ietf.org" 
Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 00:39:21 -0000

In message , "W
illiams, Marcus (Contractor)" writes:
> 
> > Also, the 6bone example is not a good analogy, IMO. The 6bone was
> > created as an temporary experiment of sorts to get around the problem
> > that RIRs were not allocating IPv6 addresses. Once that problem got
> > fixed, sites were expected to transition over to using proper IPv6
> > prefixes -- the need for continuing to operate the 6bone was
> > gone. There was no deprecation of "technology" or deprecating
> > "brokenness".
> 
> 
> There was in fact brokeness caused by 6bone.  Operators filtered 6bone 3FFE r
> outes while a v6 exchange continued to use it for peering.   Those v6 routers
>  at the exchange would send PMTU sourced in 3ffe . . .   This sort of focused
>  shakeout improves the integrity of v6 instead of allowing problems to fester
> .

Most of the 6to4 problems would go away if the 6to4 CPE routers
did dead router detection.  6rd already has a description of how
to do this in its specification.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From ggm+ietf@apnic.net  Thu May  5 17:45: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 DE39BE0700 for ; Thu,  5 May 2011 17:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.605
X-Spam-Level: 
X-Spam-Status: No, score=-101.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994, 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 hhYHm0U0X7QE for ; Thu,  5 May 2011 17:45:59 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 01727E06FB for ; Thu,  5 May 2011 17:45:57 -0700 (PDT)
Received: from dynamic186.apnic.net (dynamic186.apnic.net [203.119.42.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id BD63EB66C9 for ; Fri,  6 May 2011 10:45:55 +1000 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: George Michaelson 
In-Reply-To: <20110506003912.395B1E84435@drugs.dv.isc.org>
Date: Fri, 6 May 2011 10:45:55 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F0DD253-886D-47B8-9614-01A0F5F81785@apnic.net>
References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com>   <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> <20110503191344.GA6741@srv03.cluenet.de> <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.com>  <20110506003912.395B1E84435@drugs.dv.isc.org>
To: IPv6 Ops WG 
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 00:46:00 -0000

On 06/05/2011, at 10:39 AM, Mark Andrews wrote:

>=20
> Most of the 6to4 problems would go away if the 6to4 CPE routers
> did dead router detection.  6rd already has a description of how
> to do this in its specification.
>=20
> Mark
> -- =20

I want to repeat my take on something Alain Durand said to me in RIPE =
Tallin a few years back.

Any investment in the IPv4 stack inside CPE has consequences for the =
supply chain dynamics facing IPv6. Asking for codework on IPv4 causes =
massive delay to work on IPv6. It takes months to alter supply chain =
dynamics, and you really really want to know this, if you think =
something you are doing is a 'good idea' because the law of unintended =
consequences is going to come into effect.

[this was in the context of the 240/4 draft I was involved in]

So Mark: do you think suggesting CPE developers make changes in 6rd, =
6to4 and other tunnelling methods is good investment of their time, =
facing other choices in their IP stack? If you did this, what would you =
be prepared to see delayed in the native IPv6 stack?

Because for me, I think fixing the various issues around DHCPv6, the L2 =
bindings into the ADSL and Cable technology, making better choices =
around subnet masking, use of privacy mode addresses, etc all might take =
a higher priority than a 6to4 fix.

-G


From marka@isc.org  Thu May  5 17:59: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 797C5E0700 for ; Thu,  5 May 2011 17:59:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.885
X-Spam-Level: 
X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_RAND_1=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 XJpPQctIzBaG for ; Thu,  5 May 2011 17:59: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 91FA1E06CF for ; Thu,  5 May 2011 17:59:11 -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 99D7C5F9891; Fri,  6 May 2011 00:58:13 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 ED530216C1E; Fri,  6 May 2011 00:58:10 +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 C526CE848C9; Fri,  6 May 2011 10:58:09 +1000 (EST)
To: Erik Kline 
From: Mark Andrews 
References: <4DC29A96.6020709@globis.net> 
In-reply-to: Your message of "Thu, 05 May 2011 16:45:50 +0200." 
Date: Fri, 06 May 2011 10:58:09 +1000
Message-Id: <20110506005809.C526CE848C9@drugs.dv.isc.org>
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 00:59:12 -0000

In message , Erik Kline wri
tes:
> [Random responses without commentary on the draft at hand.]
> 
> > That should probably be noted as an architectural concern of the WG. It is
> > hinted at within the existing text: "An additional concern is that the IP
> > address of a recursive resolver is not a precise indicator of the IPv6
> > preparedness, or lack of IPv6-related impairments, of end user hosts which
> > query (use) a particular recursive resolver."
> 
> "Precise", no.  But very definitely quantifiable, to varying degrees
> of accuracy.
> 
> > But that text does not address the concern at any architectural level
> > whether there should be _any_ link at all between an IPv6 transport provide
> r
> > and DNS recursive resolver server address, never mind if it is a reliable
> > link.
> 
> It is trivial to build a map of client addresses and the resolvers
> they use.  The connection is observable, whatever that connection may
> be.
> 
> > To it seems that broken IPv6 connectivity is the real problem, not broken
> > name resolution as far as I can see. Especially when it is possible to
> > resolve both IPv4 and IPv6 records over either IPv4 or IPv6 transport, I
> > really fail to see the correlation. Perhaps someone can correct my myopia
> > with hard data.
> 
> Broken AAAA resolution can cause broken dualstack connectivity.  DNS
> resolvers in home gateways have been variously observed to do things
> like dropping any query that isn't for an A record, transform the high
> 32bits of an AAAA response and into an A response (Jason Fesler can
> even test for this!), and even dropping all responses that are still
> less than 512 bytes but have more than 16 address records.  And worse.
> 
> It's a pathological world out there, as I'm sure you well know.

Yep, but even combined the number of those boxes are not enough to
require filtering.  There are also plenty of drop in replacements
available that do work or there are firmware updates that fix these
problems.

> > If someone has broken DNS recursive resolution for IPv6, it is going to
> > affect the majority of the IPv6 services they are using, and should stand
> > out like a sore thumb. They are therefore likely to be highly motivated to
> > point their local resolver libs at a better DNS server, and which action is
> > generally a fairly trivial act (altering one DHCP record at best and
> > rebooting machines).
> 
> Ahem...what IPv6 services are they using right now?  Seriously.

Actually more and more these days.

> > If there are generally large numbers of broken IPv6 DNS resolvers out there
> ,
> > then there's a much bigger problem, which is certainly not going to be
> > solved by a point solution deployed by a few content providers. In fact aaa
> a
> > whitelisting is more likely to mask the problem than solve it IMHO.
> 
> The whitelisting is indeed designed to avoid the problems and allow
> IPv6 to be more broadly served to those who are properly able to make
> use of it.

And there are plenty that can use IPv6 but can't get AAAA records
due to whitelisting.

> But absolutely, breaking things does highlight that some things need
> to be fixed, and sometimes some people can even identify what those
> things are, and sometimes not.
> _______________________________________________
> 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 marka@isc.org  Thu May  5 18:24: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 A3FE0E0741 for ; Thu,  5 May 2011 18:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.676
X-Spam-Level: 
X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_REALLY=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 3F6YDd+BpA6U for ; Thu,  5 May 2011 18:24:16 -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 CB4F6E0688 for ; Thu,  5 May 2011 18:24:15 -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 D9A7EC9423; Fri,  6 May 2011 01:24:08 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 6E17B216C1E; Fri,  6 May 2011 01:24:08 +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 35984E84A43; Fri,  6 May 2011 11:24:07 +1000 (EST)
To: George Michaelson 
From: Mark Andrews 
References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com>   <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> <20110503191344.GA6741@srv03.cluenet.de> <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.com>  <20110506003912.395B1E84435@drugs.dv.isc.org> <9F0DD253-886D-47B8-9614-01A0F5F81785@apnic.net>
In-reply-to: Your message of "Fri, 06 May 2011 10:45:55 +1000." <9F0DD253-886D-47B8-9614-01A0F5F81785@apnic.net>
Date: Fri, 06 May 2011 11:24:07 +1000
Message-Id: <20110506012407.35984E84A43@drugs.dv.isc.org>
Cc: IPv6 Ops WG 
Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 01:24:16 -0000

In message <9F0DD253-886D-47B8-9614-01A0F5F81785@apnic.net>, George Michaelson 
writes:
> 
> On 06/05/2011, at 10:39 AM, Mark Andrews wrote:
> 
> > 
> > Most of the 6to4 problems would go away if the 6to4 CPE routers
> > did dead router detection.  6rd already has a description of how
> > to do this in its specification.
> > 
> > Mark
> > --  
> 
> I want to repeat my take on something Alain Durand said to me in RIPE Tallin 
> a few years back.
> 
> Any investment in the IPv4 stack inside CPE has consequences for the supply c
> hain dynamics facing IPv6. Asking for codework on IPv4 causes massive delay t
> o work on IPv6. It takes months to alter supply chain dynamics, and you reall
> y really want to know this, if you think something you are doing is a 'good i
> dea' because the law of unintended consequences is going to come into effect.
> 
> [this was in the context of the 240/4 draft I was involved in]
> 
> So Mark: do you think suggesting CPE developers make changes in 6rd, 6to4 and
> other tunnelling methods is good investment of their time, facing other choi
> ces in their IP stack? If you did this, what would you be prepared to see del
> ayed in the native IPv6 stack?

Yes.  6rd already requires dead router detection.  Adding it to
6to4 would put it on the same level.  The router would send back
ICMPv6 unreachables to internal clients which helps everyone.

It also only requires CPE code changes so there is no co-ordination
required.

It could have been implemented many times over in the amount of time
we have discussed 6to4-historic.

> Because for me, I think fixing the various issues around DHCPv6, the L2 bindi
> ngs into the ADSL and Cable technology, making better choices around subnet m
> asking, use of privacy mode addresses, etc all might take a higher priority t
> han a 6to4 fix.
> 
> -G
> 
> _______________________________________________
> 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 lorenzo@google.com  Thu May  5 18:27: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 92FBBE06A5 for ; Thu,  5 May 2011 18:27:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 cveEJQsM4Mtc for ; Thu,  5 May 2011 18:27:36 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id BE082E0688 for ; Thu,  5 May 2011 18:27:35 -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 p461RY9H025569 for ; Thu, 5 May 2011 18:27:34 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304645254; bh=Hc8rUBkwbHJZAwzFnIPYBbkOm2w=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=s4DpV1WUbseXpvG2KA1ZJm476oibMQ9CFgcdKNJs5R+RwvKUD6As/MMfkdNuDzJHi g7epLkq8SIcRzI+WGavug==
Received: from yie30 (yie30.prod.google.com [10.243.66.30]) by hpaq12.eem.corp.google.com with ESMTP id p461RWfr011122 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 May 2011 18:27:33 -0700
Received: by yie30 with SMTP id 30so1026829yie.9 for ; Thu, 05 May 2011 18:27:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=e+6REA+VzgcEyCDlSYN2Fb7u0LXbyB3SJaIuSehMZxw=; b=QQ+SuXmJMPPh/8tApZO5VzerE2f2Dbbc2D+GgKOS85a3WO8VYd6btg7G2nu2PD7EAl /jx3gSo37wYXpMoA2RDg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=SbjV1fXDTyO1k3K5YhscDqGNgFRxyhcjjSGRj/jpnHAi0E9Vvsg/BjVpUAz28y6kjU 2BLSWVfOnmkbFYrrWMBQ==
Received: by 10.151.24.10 with SMTP id b10mr2783178ybj.93.1304645252077; Thu, 05 May 2011 18:27:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Thu, 5 May 2011 18:27:11 -0700 (PDT)
In-Reply-To: <20110506012407.35984E84A43@drugs.dv.isc.org>
References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com>   <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> <20110503191344.GA6741@srv03.cluenet.de> <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.com>  <20110506003912.395B1E84435@drugs.dv.isc.org> <9F0DD253-886D-47B8-9614-01A0F5F81785@apnic.net> <20110506012407.35984E84A43@drugs.dv.isc.org>
From: Lorenzo Colitti 
Date: Fri, 6 May 2011 03:27:11 +0200
Message-ID: 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=000e0cd23ef6cedad504a291640d
X-System-Of-Record: true
Cc: IPv6 Ops WG , George Michaelson 
Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 01:27:36 -0000

--000e0cd23ef6cedad504a291640d
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 6, 2011 at 3:24 AM, Mark Andrews  wrote:

> Yes.  6rd already requires dead router detection.  Adding it to
> 6to4 would put it on the same level.  The router would send back
> ICMPv6 unreachables to internal clients which helps everyone.
>

No, it doesn't help Windows (it ignores them) and only marginally helps mac.


> It also only requires CPE code changes so there is no co-ordination
> required.
>

Upgrading the code on any significant fraction of CPEs that have been sold
and are now in users' homes is not realistic. Better to do it in the hosts,
which have better upgrade mechanisms.

--000e0cd23ef6cedad504a291640d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Fri, May 6, 2011 at 3:24 AM, Mark Andrews <marka=
@isc.org> wrote:



Yes. =A06rd already requires dead router detection. =A0Adding it to

6to4 would put it on the same level. =A0The router would send back

ICMPv6 unreachables to internal clients which helps everyone.

No, it doesn't help Windows (it ignores them) an=
d only marginally helps mac.
=A0



It also only requires CPE code changes so there is no co-ordination

required.
=A0
Upgrading the code on any sign=
ificant fraction of CPEs that have been sold and are now in users' home=
s is not realistic. Better to do it in the hosts, which have better upgrade=
 mechanisms.





--000e0cd23ef6cedad504a291640d--

From marka@isc.org  Thu May  5 18:52: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 29DEDE06A8 for ; Thu,  5 May 2011 18:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.065
X-Spam-Level: 
X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.534,  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 ybEjEoIpKNMx for ; Thu,  5 May 2011 18:52:58 -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 82703E0675 for ; Thu,  5 May 2011 18:52:58 -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 4143A5F9891; Fri,  6 May 2011 01:52:15 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 9D375216C1E; Fri,  6 May 2011 01:52:13 +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 51150E84C67; Fri,  6 May 2011 11:52:12 +1000 (EST)
To: Lorenzo Colitti 
From: Mark Andrews 
References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com>   <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> <20110503191344.GA6741@srv03.cluenet.de> <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.com>  <20110506003912.395B1E84435@drugs.dv.isc.org> <9F0DD253-886D-47B8-9614-01A0F5F81785@apnic.net> <20110506012407.35984E84A43@drugs.dv.isc.org> 
In-reply-to: Your message of "Fri, 06 May 2011 03:27:11 +0200." 
Date: Fri, 06 May 2011 11:52:12 +1000
Message-Id: <20110506015212.51150E84C67@drugs.dv.isc.org>
Cc: IPv6 Ops WG , George Michaelson 
Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 01:52:59 -0000

In message , Lorenzo Colitt
i writes:
> On Fri, May 6, 2011 at 3:24 AM, Mark Andrews  wrote:
> 
> > Yes.  6rd already requires dead router detection.  Adding it to
> > 6to4 would put it on the same level.  The router would send back
> > ICMPv6 unreachables to internal clients which helps everyone.
> >
> 
> No, it doesn't help Windows (it ignores them) and only marginally helps mac.

So Windows is broken.  Complain to Microsoft who do have a working
update program.  Apple also has a working update program.
 
> > It also only requires CPE code changes so there is no co-ordination
> > required.
> 
> Upgrading the code on any significant fraction of CPEs that have been sold
> and are now in users' homes is not realistic.

Only because people WILL NOT TRY to do it.  People used to say the
same thing about Windows.  We now have a community that are used
to having their equipement updated to fix problems, whether it is
their PC, phone, printer, Kindle ....  The update processes do work.
They are NOT too hard for the average user.  You just have to tell
them they need to do it.

> Better to do it in the hosts, which have better upgrade mechanisms.

And a lot of the problem 6to4 CPE routers are *hosts* with ICS enabled.
Put dead router detection on them.
 
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  Thu May  5 19:16: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 6A0F7E0663 for ; Thu,  5 May 2011 19:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level: 
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.203,  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 r1C8aLy2188G for ; Thu,  5 May 2011 19:16:08 -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 59FB5E0593 for ; Thu,  5 May 2011 19:16:07 -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 5C95AC941E; Fri,  6 May 2011 02:16:02 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 DDEE4216C1E; Fri,  6 May 2011 02:16:01 +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 7AD97E85025; Fri,  6 May 2011 12:16:00 +1000 (EST)
To: Erik Kline 
From: Mark Andrews 
References: <4DBFB4E7.5010806@globis.net>  
In-reply-to: Your message of "Thu, 05 May 2011 18:13:34 +0200." 
Date: Fri, 06 May 2011 12:16:00 +1000
Message-Id: <20110506021600.7AD97E85025@drugs.dv.isc.org>
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 02:16:09 -0000

In message , Erik Kline wri
tes:
> I would like to add that it's the asymmetric routing that's the
> problem with proto41 blocking detection ever working for 6to4.
> 
> Terminology/glossary for the example below:
> 
>     C:  the 6to4-using client
> 
>     DR:  the Decapsulating Relay (where proto41 packets from C to
> 192.88.99.1 actually go)
> 
>     S1:  an IPv6 server
> 
>     S2:  another IPv6 server
> 
>     Sn:  the Nth IPv6 server
> 
>     ER1:  the Encapsulation Relay for S1 (where native IPv6 packets
> from S1 toward 2002::/16 actually go)
> 
>     ER2:  the Encapsulation Relay for S2 (where native IPv6 packets
> from S2 toward 2002::/16 actually go)
> 
>     ERn:  the Encapsulation Relay for Sn (where native IPv6 packets
> from Sn toward 2002::/16 actually go)
> 
> 
> [Assumption 1]
> 
> The IETF issues an RFC to update 6to4 to include
> 6rd/ISATAP/whatever-style in-band reachability checks such that a
> suitably-compliant 6to4 client can verify that proto41 is successfully
> reaching its DR and know that this is working and detect rapidly when
> it stops working.
> 
> [Assumption 2]
> 
> Client C is running the super-awesome newly-fixed 6to4 code update
> with an implementation of Assumption 1.
> 
> 
> [Assumption 3]
> 
> Client C is using and monitoring a fully functioning and super-awesome DR.
> 
> 
> [Assumption 4]
> 
> There are no IPv6 peering disputes and IPv6 traffic from DR to S1..Sn
> works perfectly.  [In reality, this should be the steady state of the
> IPv6 Internet.]
> 
> 
> [Assumption 5]
> 
> There are no IPv4 peering disputes and IPv4 traffic from ER1..ERn to C
> works perfectly.  [In reality, this should be the steady state of the
> IPv4 Internet.]
> 
> 
> [Assumption 6]
> 
> Each S1..Sn have a route for 2002::/16 successfully reaching
> corresponding ER1..ERn.
> 
> 
> 
> The fundamental architectural problem is that even with "proto41
> detection", C can not verify that proto41 packets can be sent from ER1
> to C.  And if they do happen to pass just fine, there's no way to
> verify that they can flow from ER2 to C, ..., or ERn to C.
> 
> Furthermore, Assumption 6 is seriously in doubt.  In order for 6to4 to
> work reliably for all S1..Sn (where N is the total number of IPv6
> destinations C might ever desire to reach), Assumption 6 must not be
> an assumption but a proven, working fact.  This is something that is
> operationally unrealistic.  It lives solely in the "if only everyone
> would just..." category of wishes and fairy tales.
> 
> "Symmetric", managed uses of proto41 don't suffer from these problems.
>  There are no uncertain paths from Sn to ERn (it's just Sn back to C's
> IPv6 ISP which fall under Assumption 4), and there is multitude of ERn
> to C links, but rather the "ERn"s collapse into DR (philosophically,
> if not quite literally in implementation, obviously).  Both the key
> troubling parts in the return path from Sn to C are removed, and
> proto41 detection is basically sufficient.
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


The general case is:

1.  IPv6 client (with a 6to4 address)
2.  IPv6 encapsulating router
3.  IPv4 hops
4.  IPv6 decapsulating router
5.  IPv6 hops
6.  IPv6 server
7.  IPv6 hops
8.  IPv6 encapsulating router
9.  IPv4 hops
10. IPv6 decapsulating router
11. IPv6 client

1 and 2 can be the same box which makes 10 and 11 the same box.
6 and 8 can be the same box which removes 7.

Asymetric routing is not unique to 6to4 but almost always happens
with 6to4.  Making sure 2,3,4,9 and 10 work with dead router detection
seem like a win to me.  The rest of the problems are not unique
to 6to4.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From jhw@apple.com  Thu May  5 19:59: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 EF05AE0675 for ; Thu,  5 May 2011 19:59:33 -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.000, 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 E-OFW0tzcSys for ; Thu,  5 May 2011 19:59:33 -0700 (PDT)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6A21BE0670 for ; Thu,  5 May 2011 19:59:33 -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 <0LKR00MV66VDIG90@mail-out.apple.com> for v6ops@ietf.org; Thu, 05 May 2011 19:59:32 -0700 (PDT)
X-AuditID: 11807130-b7c15ae000005aca-6e-4dc364148762
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 relay11.apple.com (Apple SCV relay) with SMTP id 21.F4.23242.41463CD4; Thu, 05 May 2011 19:59:32 -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 <0LKR001686Z7JA10@cardamom.apple.com> for v6ops@ietf.org; Thu, 05 May 2011 19:59:32 -0700 (PDT)
From: james woodyatt 
In-reply-to: <20110506021600.7AD97E85025@drugs.dv.isc.org>
Date: Thu, 05 May 2011 19:59:31 -0700
Message-id: <722F21EF-B046-4429-9317-6B3ED1EF04D9@apple.com>
References: <4DBFB4E7.5010806@globis.net>   <20110506021600.7AD97E85025@drugs.dv.isc.org>
To: Mark Andrews 
X-Mailer: Apple Mail (2.1226)
X-Brightmail-Tracker: AAAAAA==
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 02:59:34 -0000

On May 5, 2011, at 19:16 , Mark Andrews wrote:
> 
> The general case is:
> 
> 1.  IPv6 client (with a 6to4 address)
> 2.  IPv6 encapsulating router
> 3.  IPv4 hops
> 4.  IPv6 decapsulating router
> 5.  IPv6 hops
> 6.  IPv6 server
> 7.  IPv6 hops
> 8.  IPv6 encapsulating router
> 9.  IPv4 hops
> 10. IPv6 decapsulating router
> 11. IPv6 client
> 
> 1 and 2 can be the same box which makes 10 and 11 the same box.
> 6 and 8 can be the same box which removes 7.

Erik's argument is basically that box 8 is "operationally unrealistic" by which he means it isn't operationally realistic for large content providers or content delivery networks.

How many people in favor of moving 6to4 to Historic are very much concerned with the case where box 6 is some residential subscriber's network appliance at a 6to4 address, box 4 and box 8 are the same box, i.e. a dual-stack residential CPE router, and therefore path 5 and path 7 the same path, a single, lightly managed home network link?  Not many, it seems to me, and I'll bet money that those who are concerned with it would very much prefer to see that particular profile of 6to4 usage halted immediately.

> Asymetric routing is not unique to 6to4 but almost always happens
> with 6to4.  Making sure 2,3,4,9 and 10 work with dead router detection
> seem like a win to me.  The rest of the problems are not unique
> to 6to4.

Alas, dead router detection won't happen quickly.  Personally, I'd prefer to just abandon the 6to4 CPE router feature altogether, if that was possible, but without a phase-out plan, I don't think I will be able to do that.  The usage case I describe above is too attractive for people with monopoly service providers that, even today, have no announced plans to deploy IPv6 any time soon.

It will take longer than you might think to get dead relay router detection, and the proper functionality for reacting to it, rolled out to the field.  Failure to reach the default relay router means that all of the other potential decapsulating relay routers for the 2002:a.b.c.d::/48 prefixes, for which the default relay router is unnecessary, are also unreachable to hosts behind the 6to4 CPE router when the default relay is dead.  RFC 4191 More-specific Routes (MSR) options would be the natural way to deal with that, except MSR option processing isn't widely deployed in host systems yet.  Yet another feature that needs to be rolled out to the field.

New features don't appear the day after an engineer codes them.  They have to be qualified and loaded into delivery vehicles that launch on their own weird schedules, in very narrow windows, that only come every now and then when the entire tribe of miscreant faeries all dance together in the moonlight under just the right oak tree.

Shorter james: you might be waiting a long time for all the pieces of a proper solution to come together.


--
james woodyatt 
member of technical staff, core os networking




From marka@isc.org  Thu May  5 20:49: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 8E043E078A for ; Thu,  5 May 2011 20:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level: 
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.492,  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 uYXszCUe1VSb for ; Thu,  5 May 2011 20:49:29 -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 3CDDAE072C for ; Thu,  5 May 2011 20:49: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 ED9A2C9423; Fri,  6 May 2011 03:49:24 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 7C5B5216C1E; Fri,  6 May 2011 03:49:24 +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 45386E86B0B; Fri,  6 May 2011 13:49:23 +1000 (EST)
To: james woodyatt 
From: Mark Andrews 
References: <4DBFB4E7.5010806@globis.net>   <20110506021600.7AD97E85025@drugs.dv.isc.org> <722F21EF-B046-4429-9317-6B3ED1EF04D9@apple.com>
In-reply-to: Your message of "Thu, 05 May 2011 19:59:31 MST." <722F21EF-B046-4429-9317-6B3ED1EF04D9@apple.com>
Date: Fri, 06 May 2011 13:49:23 +1000
Message-Id: <20110506034923.45386E86B0B@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 03:49:32 -0000

In message <722F21EF-B046-4429-9317-6B3ED1EF04D9@apple.com>, james woodyatt wri
tes:
> On May 5, 2011, at 19:16 , Mark Andrews wrote:
> > 
> > The general case is:
> > 
> > 1.  IPv6 client (with a 6to4 address)
> > 2.  IPv6 encapsulating router
> > 3.  IPv4 hops
> > 4.  IPv6 decapsulating router
> > 5.  IPv6 hops
> > 6.  IPv6 server
> > 7.  IPv6 hops
> > 8.  IPv6 encapsulating router
> > 9.  IPv4 hops
> > 10. IPv6 decapsulating router
> > 11. IPv6 client
> > 
> > 1 and 2 can be the same box which makes 10 and 11 the same box.
> > 6 and 8 can be the same box which removes 7.
> 
> Erik's argument is basically that box 8 is "operationally unrealistic" by whi
> ch he means it isn't operationally realistic for large content providers or c
> ontent delivery networks.

You mean its impossible for them to add something like this to the
boot scripts of 6 yet it is possible for them to configure a http
server, database and whatever else they are using.

# ifconfig ne0 inet6 2001:..... prefixlen 64
# ifconfig ne0 inet 133.4.5.6 netmask 0xffffff00
# ifconfig stf0 inet6 2002:8504:0506:: prefixlen 16 alias anycast link0
# route add -inet6 2002:: -prefixlen 16 ::1
# route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0

This is how much work it is to configure a FreeBSD box to do return
encapsulation for its own traffic.  Three extra configuration lines
at boot time.  The anycast prevents the OS using 2002:8504:0506::
as a source address for IPv6 connections initiated from the box and
the link0 blocks incoming encapsulated traffic.  This is a outbound
interface only.

Alternatively they configure the first hop router to do a similar thing.

You don't need to advertise 2002::/16 to anyone, you just encapsulate
the traffic you get through normal routing.

> How many people in favor of moving 6to4 to Historic are very much concerned w
> ith the case where box 6 is some residential subscriber's network appliance a
> t a 6to4 address, box 4 and box 8 are the same box, i.e. a dual-stack residen
> tial CPE router, and therefore path 5 and path 7 the same path, a single, lig
> htly managed home network link?  Not many, it seems to me, and I'll bet money
> that those who are concerned with it would very much prefer to see that part
> icular profile of 6to4 usage halted immediately.
> 
> > Asymetric routing is not unique to 6to4 but almost always happens
> > with 6to4.  Making sure 2,3,4,9 and 10 work with dead router detection
> > seem like a win to me.  The rest of the problems are not unique
> > to 6to4.
> 
> Alas, dead router detection won't happen quickly.  Personally, I'd prefer to 
> just abandon the 6to4 CPE router feature altogether, if that was possible, bu
> t without a phase-out plan, I don't think I will be able to do that.  The usa
> ge case I describe above is too attractive for people with monopoly service p
> roviders that, even today, have no announced plans to deploy IPv6 any time so
> on.
> 
> It will take longer than you might think to get dead relay router detection, 
> and the proper functionality for reacting to it, rolled out to the field.  Fa
> ilure to reach the default relay router means that all of the other potential
> decapsulating relay routers for the 2002:a.b.c.d::/48 prefixes, for which th
> e default relay router is unnecessary, are also unreachable to hosts behind t
> he 6to4 CPE router when the default relay is dead.  RFC 4191 More-specific Ro
> utes (MSR) options would be the natural way to deal with that, except MSR opt
> ion processing isn't widely deployed in host systems yet.  Yet another featur
> e that needs to be rolled out to the field.
> 
> New features don't appear the day after an engineer codes them.  They have to
> be qualified and loaded into delivery vehicles that launch on their own weir
> d schedules, in very narrow windows, that only come every now and then when t
> he entire tribe of miscreant faeries all dance together in the moonlight unde
> r just the right oak tree.
> 
> Shorter james: you might be waiting a long time for all the pieces of a prope
> r solution to come together.
> 
> 
> --
> james woodyatt 
> member of technical staff, core os networking
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From lorenzo@google.com  Thu May  5 23:25: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 281BDE0659 for ; Thu,  5 May 2011 23:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 Frr5eTQgNWns for ; Thu,  5 May 2011 23:25:39 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF2BE0679 for ; Thu,  5 May 2011 23:25:39 -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 p466Pb11005920 for ; Thu, 5 May 2011 23:25:37 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304663137; bh=JOyrz/CUcuvgFVEaBvz0QL2xLA4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=fDZjDRc73YItT28FsQHNUbCxKnmtgTg7rUIASZA3NMUdVd1I08UQDAQbCnqwxvOem Hw3W2XEF4mbm8OzX/3FxA==
Received: from ywk9 (ywk9.prod.google.com [10.192.11.9]) by hpaq1.eem.corp.google.com with ESMTP id p466PZUG006091 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 5 May 2011 23:25:36 -0700
Received: by ywk9 with SMTP id 9so1488945ywk.35 for ; Thu, 05 May 2011 23:25:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=N0UPYS7MoQmEsKWDxAIEb1/HnG0JbA68nBqooXdVrjs=; b=RdgeZRxv7sK6j6fzqyc87szAUMxCRP7LRuRgd2gGNEobhS70ed32quurxeq//NvZ2r l9aeniGyBYDKJ08R4O/w==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=RYsLbGw3JfjBJiJThIYmscGX4PacQHX9D2VgQufjen1xMwuac7fUgYirj2unDRLg+g 6i0AZoMr2C3cPa6FsODQ==
Received: by 10.150.91.10 with SMTP id o10mr1816304ybb.264.1304663135089; Thu, 05 May 2011 23:25:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Thu, 5 May 2011 23:25:15 -0700 (PDT)
In-Reply-To: <20110506015212.51150E84C67@drugs.dv.isc.org>
References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com>   <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> <20110503191344.GA6741@srv03.cluenet.de> <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.com>  <20110506003912.395B1E84435@drugs.dv.isc.org> <9F0DD253-886D-47B8-9614-01A0F5F81785@apnic.net> <20110506012407.35984E84A43@drugs.dv.isc.org>  <20110506015212.51150E84C67@drugs.dv.isc.org>
From: Lorenzo Colitti 
Date: Fri, 6 May 2011 08:25:15 +0200
Message-ID: 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=000e0cd47d06b7f43904a2958ebb
X-System-Of-Record: true
Cc: IPv6 Ops WG , George Michaelson 
Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 06:25:40 -0000

--000e0cd47d06b7f43904a2958ebb
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 6, 2011 at 3:52 AM, Mark Andrews  wrote:

> > No, it doesn't help Windows (it ignores them) and only marginally helps
> mac.
>
> So Windows is broken.  Complain to Microsoft who do have a working
> update program.  Apple also has a working update program.
>

Nope, ICMP unreachables are soft errors.


> Only because people WILL NOT TRY to do it.  People used to say the
> same thing about Windows.  We now have a community that are used
> to having their equipement updated to fix problems, whether it is
> their PC, phone, printer, Kindle ....  The update processes do work.
> They are NOT too hard for the average user.  You just have to tell
> them they need to do it.
>

Sure. So a vendor who licensed some code five years ago from a third-party
manufacturer that maybe no longer exists needs to see a business case to
reopen the code base for a product that's not shipping any more, spend
engineering cycles to fix it, and release it. And users need to hear about
it, download it, and upgrade it successfully. Good luck with that.

> Better to do it in the hosts, which have better upgrade mechanisms.
>
> And a lot of the problem 6to4 CPE routers are *hosts* with ICS enabled.
> Put dead router detection on them.


Yes, it needs to be in the host. But dead router detection? Why? That's like
saying "I'm going to enable this service that is unreliable and
high-latency, but it's OK, because if it happens not to work (in the only
direction) I can measure I'm going to disable again". Why enable it in the
first place then?

--000e0cd47d06b7f43904a2958ebb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Fri, May 6, 2011 at 3:52 AM, Mark Andrews <marka@isc.org> wrote:



> No, it doesn't help Windows (it ignores them) an=
d only marginally helps mac.




So Windows is broken. =A0Complain to Microsoft who do have a working<=
br>
update program. =A0Apple also has a working update program.

Nope, ICMP unreachables are soft errors.
=A0=





Only because people WILL NOT TRY to do it. =A0People used=
 to say the

same thing about Windows. =A0We now have a community that are used

to having their equipement updated to fix problems, whether it is

their PC, phone, printer, Kindle .... =A0The update processes do work.

They are NOT too hard for the average user. =A0You just have to tell

them they need to do it.

Sure. So a ven=
dor who licensed some code five years ago from a third-party manufacturer t=
hat maybe no longer exists needs to see a business case to reopen the code =
base for a product that's not shipping any more, spend engineering cycl=
es to fix it, and release it. And users need to hear about it, download it,=
 and upgrade it successfully. Good luck with that.






> Better to do it in the hosts, which have better upgr=
ade mechanisms.




And a lot of the problem 6to4 CPE routers are *hosts* with ICS enable=
d.

Put dead router detection on them.

Yes, it =
needs to be in the host. But dead router detection? Why? That's like sa=
ying "I'm going to enable this service that is unreliable and high=
-latency, but it's OK, because if it happens not to work (in the only d=
irection) I can measure I'm going to disable again". Why enable it=
 in the first place then?





--000e0cd47d06b7f43904a2958ebb--

From ek@google.com  Fri May  6 00:04: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 AE40AE069F for ; Fri,  6 May 2011 00:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.798
X-Spam-Level: 
X-Spam-Status: No, score=-106.798 tagged_above=-999 required=5 tests=[AWL=-0.821, 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 j2S6IJz0ODbt for ; Fri,  6 May 2011 00:04:37 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 93315E0663 for ; Fri,  6 May 2011 00:04:37 -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 p4674ZKm020052 for ; Fri, 6 May 2011 00:04:36 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304665476; bh=30N2UIYBC64NVfl/NjoLX2/gG9k=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=S+kM1zLtbrhz6tvdnHusFiBXk4ymj0NgIef4X4GaTIgan2hZQxSU01cknfhDpC9dD tryP6U4BN8bG8nE9241Ew==
Received: from pxi9 (pxi9.prod.google.com [10.243.27.9]) by kpbe12.cbf.corp.google.com with ESMTP id p4674YvU005317 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 6 May 2011 00:04:34 -0700
Received: by pxi9 with SMTP id 9so2154282pxi.14 for ; Fri, 06 May 2011 00:04:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T5zvhVAWiqdQ5qP/HmNQJuE0Rjs7QWIH/hafFrxlBAQ=; b=CFeZ03kpfZsqpcnXBSqQPMxO8WqPca5thgboovMKe5Y7tQ25uXhBAT1lZstNkAa4cU L17M2WsnqxwweOQIdCSw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VPkJDFqXeVlFLaabaNWMO3smZTUib/RRKsTQtHRFGYp1oUg21STKKwyM+wndsr++1Y FTjiwE3Hp83vRM5fSMpA==
MIME-Version: 1.0
Received: by 10.143.26.29 with SMTP id d29mr1749797wfj.438.1304665473783; Fri, 06 May 2011 00:04:33 -0700 (PDT)
Received: by 10.142.245.14 with HTTP; Fri, 6 May 2011 00:04:33 -0700 (PDT)
In-Reply-To: <20110506034923.45386E86B0B@drugs.dv.isc.org>
References: <4DBFB4E7.5010806@globis.net>   <20110506021600.7AD97E85025@drugs.dv.isc.org> <722F21EF-B046-4429-9317-6B3ED1EF04D9@apple.com> <20110506034923.45386E86B0B@drugs.dv.isc.org>
Date: Fri, 6 May 2011 09:04:33 +0200
Message-ID: 
From: Erik Kline 
To: Mark Andrews 
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] 6to4-historic summary point: 2. "protocol 41"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 07:04:38 -0000

You're vastly oversimplifying it.  Google does not run on a handful of
FreeBSD boxes, with a little bit of PHP and a MySQL backend.  This
kind of absurd reduction of reality is neither convincing nor
relevant.

From ek@google.com  Fri May  6 00:10: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 A88C8E0679 for ; Fri,  6 May 2011 00:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.744
X-Spam-Level: 
X-Spam-Status: No, score=-106.744 tagged_above=-999 required=5 tests=[AWL=-0.767, 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 WCP3L-yw2p6g for ; Fri,  6 May 2011 00:10:44 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA44E065A for ; Fri,  6 May 2011 00:10:44 -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 p467AhQa016565 for ; Fri, 6 May 2011 00:10:43 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304665843; bh=tdFmGXfisltuYaWzGu1ibLgcv0c=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=kS6d4XI+AcOAHQ06xXhHpGYx9be5c8a31lXJ11omxjt1qdr7bfFuBNt/UbRNYXvqN JsKOJiE19EYx2HZC86K6Q==
Received: from pwi6 (pwi6.prod.google.com [10.241.219.6]) by wpaz21.hot.corp.google.com with ESMTP id p467AfGm013811 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 6 May 2011 00:10:41 -0700
Received: by pwi6 with SMTP id 6so1641838pwi.4 for ; Fri, 06 May 2011 00:10:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=am7TSFWrQSJpB8W74dFu7R0CmByduqHor7kW8Md0VrA=; b=YVXj8FYHj/NnKO5X9Ux4JrVoqx4M1D11lVrtdBrNoG/L76uPSBk8r196e+pHHCLZvA cJ/r0DfrAhW4uc1S/3OA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PwOa/cN8Di2qCCRzMMWkXCbgd1i2t3A3joTho/K4ZVRTcKcDEtuudkCb8rBxyThhgY mhh393YwqoBfxKJB2xag==
MIME-Version: 1.0
Received: by 10.142.56.19 with SMTP id e19mr1839583wfa.153.1304665840880; Fri, 06 May 2011 00:10:40 -0700 (PDT)
Received: by 10.142.245.14 with HTTP; Fri, 6 May 2011 00:10:40 -0700 (PDT)
In-Reply-To: <20110506005809.C526CE848C9@drugs.dv.isc.org>
References: <4DC29A96.6020709@globis.net>  <20110506005809.C526CE848C9@drugs.dv.isc.org>
Date: Fri, 6 May 2011 09:10:40 +0200
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] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 07:10:45 -0000

>> The whitelisting is indeed designed to avoid the problems and allow
>> IPv6 to be more broadly served to those who are properly able to make
>> use of it.
>
> And there are plenty that can use IPv6 but can't get AAAA records
> due to whitelisting.

I look forward to seeing your data that backs up this assertion.

From ichiroumakino@gmail.com  Fri May  6 01:08: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 58795E068C for ; Fri,  6 May 2011 01:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.313
X-Spam-Level: 
X-Spam-Status: No, score=-3.313 tagged_above=-999 required=5 tests=[AWL=0.286,  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 sev5hiqoOYio for ; Fri,  6 May 2011 01:08: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 31EF4E067C for ; Fri,  6 May 2011 01:08:57 -0700 (PDT)
Received: by wwa36 with SMTP id 36so2240716wwa.13 for ; Fri, 06 May 2011 01:08:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=ckgzg9Um+sx1hdEKQlm4EW66WNbtTVhHTTJ1b/6OkMk=; b=SF5Q0SX/oWkuOEqTk2qOy8bPQaaa4+UnmLirmxMxnpQm7/8G6nED+tPHd92FdoCfsr u+l9MB3eS5ph9Dtrc+QAkNFXG8MJd/16UQpkMJx4Nre80p8pc4qN3V6QaT/jWELGnlfL dgMXjZJMECA5ayvG+RqsK2TRx+ifqGH9fu0ZU=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=BuwJVO/MRQNTPQqxUF29/ob4hOBa+rTVBYyYNzhHC5NaTZECfvIRWMVffReKkXUNX5 oSfSeMkzRuH6IxBOzDUD8Sc1L34l+Cv6Gw79I8j9tOk1edF3gm2V75SfXp9rtULt7J8Y FqjvtGm7Gs9OQbSSgMsPaux+RDoZ3iyvRB+jU=
Received: by 10.216.50.135 with SMTP id z7mr3298698web.112.1304669336223; Fri, 06 May 2011 01:08:56 -0700 (PDT)
Received: from dhcp-osl-vl300-64-103-53-245.cisco.com (dhcp-osl-vl300-64-103-53-245.cisco.com [64.103.53.245]) by mx.google.com with ESMTPS id g58sm1435405wen.44.2011.05.06.01.08.53 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2011 01:08:53 -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: <20110506012407.35984E84A43@drugs.dv.isc.org>
Date: Fri, 6 May 2011 10:08:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <380D0724-9B2F-4AF9-AA39-AE6A038DF3E3@employees.org>
References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com>   <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> <20110503191344.GA6741@srv03.cluenet.de> <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.com>  <20110506003912.395B1E84435@drugs.dv.isc.org> <9F0DD253-886D-47B8-9614-01A0F5F81785@apnic.net> <20110506012407.35984E84A43@drugs.dv.isc.org>
To: Mark Andrews 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Ops WG , George Michaelson 
Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 08:08:58 -0000

Mark,

[...]

> Yes.  6rd already requires dead router detection.  Adding it to
> 6to4 would put it on the same level.  The router would send back
> ICMPv6 unreachables to internal clients which helps everyone.

incorrect.

> It also only requires CPE code changes so there is no co-ordination
> required.
>=20
> It could have been implemented many times over in the amount of time
> we have discussed 6to4-historic.

but it wouldn't have solved 'the problem'.

from the draft, I leave it as an exercise for the reader to figure out =
which ones would be resolved by adding forward relay liveness detection =
on the 6to4 router / host.

   List of some of the known issues with 6to4:

   o  Use of relays. 6to4 depends on an unknown third- party to operate
      the relays between the 6to4 cloud and the native IPv6 Internet.
   o  The placement of the relay can lead to increased latency, and in
      the case the relay is overloaded packet loss.
   o  There is generally no customer relationship or even a way for the
      end-user to know who the relay operator is, so no support is
      possible.
   o  In case of the reverse path 6to4 relay and the anycast forward
      6to4 relay, these have to be open for any address.  Only limited
      by the scope of the routing advertisement. 6to4 relays can be used
      to anonymize traffic and inject attacks into IPv6 that are very
      difficult to trace.
   o  6to4 may black hole traffic in the case where protocol (41) is
      blocked in intermediate firewalls.  Even if a firewall sent an
      ICMP message unreachable back, an IPv4 ICMP message rarely
      contains enough of the original IPv6 packet so that it can be
      relayed back to the IPv6 sender.  That makes this problem hard to
      detect and react upon by the sender of the packet.
   o  As 6to4 tunnels across the Internet, the IPv4 addresses used must
      be globally reachable.  RFC3056 states that a private address
      [RFC1918] MUST NOT be used. 6to4 will not work in networks that
      employ other addresses with limited topological span.

cheers,
Ole


From v6ops@globis.net  Fri May  6 01:39: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 9A8CBE06F0 for ; Fri,  6 May 2011 01:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.387
X-Spam-Level: 
X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.211,  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 WvyzSD8fZnHz for ; Fri,  6 May 2011 01:39:27 -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 BD8F4E0663 for ; Fri,  6 May 2011 01:39:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1D2A58700EB for ; Fri,  6 May 2011 10:39:25 +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 dAx-yQgyvq13 for ; Fri,  6 May 2011 10:39:19 +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 E0986870086 for ; Fri,  6 May 2011 10:39:19 +0200 (CEST)
Message-ID: <4DC3B3AC.5020308@globis.net>
Date: Fri, 06 May 2011 10:39:08 +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="------------030807060204070407060601"
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 08:39:28 -0000

This is a multi-part message in MIME format.
--------------030807060204070407060601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for the reply.

Yes I had thought of structured replies and tracking people via logs 
(which is questionable in some jurisdictions without their consent) and 
statistical multiplexing. Maybe my understanding of "trivial" is 
different from other people's.

And I agree that you can certainly get a "general" view of IPv6 readiness.

But it's all about making  clever assumptions leading to conclusions 
without ever asking directly the communication partner what they've 
actually done in their migration.

So I'm still to be convinced that Party X can get enough granularity 
through Party X's one sided and uncoordinated action of trying to guess 
what Party Y is doing without ever actually asking Party Y, so that 
Party X can generate enough confidence in their actions that Party X is 
not actually causing Party Y harm.

I'm not yet convinced that there's enough large scale operational 
experience out there of how people are going to migrate that we can draw 
these conclusions about DNS being orthogonal to transport connectivity 
or not, which is why building solutions on architectural links that 
don't actually exist may be so dangerous.

Even if my authoritative DNS only replies 50% of the time at a latency 
of 3s, because the result is then cached locally, that may have very 
little adverse effect on my users' perceived transport quality to my 
site, depending on the application.

Philip Homburg has already posted that he uses a resolver in another net 
block, so he does not receive IPv6 records. I do too. Maybe this will 
become the "new normal" that the providers of IPv6 transport and DNS 
resolution are not strongly operationally coupled (because there is no 
architectural requirement to do so) Who really knows yet?

Which is why my original posting suggested that the WG might wish to 
express a concern about anyone making assumptions about any undocumented 
architectural links between DNS and transport, and also suggest that 
operators of aaaa whitelists (party X) should disclose their aaaa 
methodology and data, and that they should not share whitelist data with 
other aaaa operators in an uncontrolled manner, so that at least Party Y 
could see what was happening and why, and also have a chance of 
correcting it.

I know a lot of people get paid by traffic volume. Traffic volumes are 
not always a good indicator of traffic importance. In most companies, 
the monthly payroll batch run is still the most important job, even 
though it is also probably "trivial" and consumes very few bytes on the 
network. I'm sure the CFO would rather that the payroll ran properly, 
than that his staff could watch videos. Often times in computing 
"importance" is actually proportional to the inverse to the volume.

So I am also concerned that we also do not make the assumption that 
"IPv6 readiness" equates to people's ability to access the biggest video 
site on the Internet. Which may actually happen if other site operators 
copy that site's aaaa whitelist policy blindly. Yes, that is an 
important source of income for a lot of operators, but there are also a 
lot of other applications and "important" content out there.

Another viable alternative to deal with broken IPv6 connectivity would 
be simply to ask users or fellow ISP's to express a preference per net 
block whether they wanted their content delivered via IPv6 or IPv4 (with 
the default being filled in automatically), and then implement this in 
the existing geographical DNS response systems. IMHO the Internet 
community is generally a pretty friendly place.

Again no provocation or flames, just pointing out the dangers of making 
assumptions in complex systems, and sometimes trying to be too clever.

regards,
RayH

>
>
> Ray,
> On Thu, 2011-05-05 at 17:54 +0200, Ray Hunter wrote:
>    
>> >  I'm sure you can track back to the set of (recursive) DNS servers that
>> >  have contacted your authoritative DNS over a period of time, plus how
>> >  they connected you, but can you track all the way back to the
>> >  individual hosts / DNS client resolver libraries that are querying
>> >  those recursive DNS servers?
>> >  
>> >  That's partially my concern: how do you know where I've pointed my
>> >  local resolver lib on my end hosts, compared to my next door neighbor,
>> >  who may have broken IPv6 connectivity and/or a broken IPv6 DNS
>> >  resolution?
>>      
>
> Seeing how Erik did not yet reply to this (and assuming he does not
> intend to), I'd just like to offer a plausible explanation from a
> general computer engineering perspective:
>
> Assuming:
>   1) you have a way to track user sessions or users,
>   2) you have a way to log DNS queries and additionally setup mappings
> for special queries, like those some IPv6 test sites famously does
> (unique records per test/user/session),
>   3) you have a way to connect the session/user driving code in 1 to
> generate certain specific records in 2, OR, you have some even more
> intelligent log parsing algorithms and some prepared/algorithmic unique
> record response scheme,
>
> you should be able to with quite high confidentiality build a map of
> this relationship.  You don't have to hit every user on every hit,
> either, you can add some statistical mumbu jumbo:)  in it to arrive at
> results within a certain confidence interval.
>
> The above is just what seems obvious to me.  Takes a non-trivial amount
> of supporting system code, especially for a larger system, but even at
> least one of these test-IPv6 sites managed to do it, presumably with a
> lot less backing resources and less code.
>
> It will probably not fingerprint what resolver library you use (though
> that seems like a research field in itself), and may only give a more
> generalized / aggregate view of the (subnet:resolver):ipv6-score
> mappings.  But this information is surely telling more about the general
> quality of a ISPs IPv6-readiness, than no such information at all.
>
> Best,
> Martin
>
>
>    

--------------030807060204070407060601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit








Thanks for the reply.



Yes I had thought of structured replies and tracking people via logs
(which is questionable in some jurisdictions without their consent) and
statistical multiplexing. Maybe my understanding of "trivial" is
different from other people's.



And I agree that you can certainly get a "general" view of IPv6
readiness.



But it's all about making  clever assumptions leading to conclusions
without ever asking directly the communication partner what they've
actually done in their migration.



So I'm still to be convinced that Party X can get enough granularity
through Party X's one sided and uncoordinated action of trying to guess
what Party Y is doing without ever actually asking Party Y, so that
Party X can generate enough confidence in their actions that Party X is
not actually causing Party Y harm.



I'm not yet convinced that there's enough large scale operational
experience out there of how people are going to migrate that we can
draw these conclusions about DNS being orthogonal to transport
connectivity or not, which is why building solutions on architectural
links that don't actually exist may be so dangerous.



Even if my authoritative DNS only replies 50% of the time at a latency
of 3s, because
the result is then cached locally, that may have very little adverse
effect on my
users' perceived transport quality to my site, depending on the
application.



Philip Homburg has already posted that he uses a resolver in another
net block, so he does not receive IPv6 records. I do too. Maybe this
will become the "new normal" that the providers of IPv6 transport and
DNS resolution are not strongly operationally coupled (because there is
no architectural requirement to do so) Who really knows yet?



Which is why my original posting suggested that the WG might wish to
express a concern about anyone making assumptions about any
undocumented architectural links between DNS and transport, and also
suggest that operators of aaaa whitelists (party X) should disclose
their aaaa methodology and data, and that they should not share
whitelist data with other aaaa operators in an uncontrolled manner, so
that at least Party Y could see what was happening and why, and also
have a chance of correcting it.



I know a lot of people get paid by traffic volume. Traffic volumes are
not always a good indicator of traffic importance. In most companies,
the monthly payroll batch run is still the most important job, even
though it is also probably "trivial" and consumes very few bytes on the
network. I'm sure the CFO would rather that the payroll ran properly,
than that his staff could watch videos. Often times in computing
"importance" is actually proportional to the inverse to the volume.



So I am also concerned that we also do not make the assumption that
"IPv6 readiness" equates to people's ability to access the biggest
video site on the Internet. Which may actually happen if other site
operators copy that site's aaaa whitelist policy blindly. Yes, that is
an important source of income for a lot of operators, but there are
also a lot of other applications and "important" content out there.



Another viable alternative to deal with broken IPv6 connectivity would
be simply to ask users or fellow ISP's to express a preference per net
block whether they wanted their content delivered via IPv6 or IPv4
(with the default being filled in automatically), and then implement
this in the existing geographical DNS response systems. IMHO the
Internet community is generally a pretty friendly place.



Again no provocation or flames, just pointing out the dangers of making
assumptions in complex systems, and sometimes trying to be too clever.



regards,

RayH





  

    
      

        

        		
      

      

        

        		
      

    
  

Ray,

  

  
On Thu, 2011-05-05 at 17:54 +0200, Ray Hunter wrote:
  

  

    
> I'm sure you can track back to the set of (recursive) DNS servers that
> have contacted your authoritative DNS over a period of time, plus how
> they connected you, but can you track all the way back to the
> individual hosts / DNS client resolver libraries that are querying
> those recursive DNS servers?
> 
> That's partially my concern: how do you know where I've pointed my
> local resolver lib on my end hosts, compared to my next door neighbor,
> who may have broken IPv6 connectivity and/or a broken IPv6 DNS
> resolution?
    

  

  

Seeing how Erik did not yet reply to this (and assuming he does not
intend to), I'd just like to offer a plausible explanation from a
general computer engineering perspective:

Assuming:
 1) you have a way to track user sessions or users,
 2) you have a way to log DNS queries and additionally setup mappings
for special queries, like those some IPv6 test sites famously does
(unique records per test/user/session),
 3) you have a way to connect the session/user driving code in 1 to
generate certain specific records in 2, OR, you have some even more
intelligent log parsing algorithms and some prepared/algorithmic unique
record response scheme,

you should be able to with quite high confidentiality build a map of
this relationship.  You don't have to hit every user on every hit,
either, you can add some statistical mumbu jumbo :) in it to arrive at
results within a certain confidence interval.

The above is just what seems obvious to me.  Takes a non-trivial amount
of supporting system code, especially for a larger system, but even at
least one of these test-IPv6 sites managed to do it, presumably with a
lot less backing resources and less code.

It will probably not fingerprint what resolver library you use (though
that seems like a research field in itself), and may only give a more
generalized / aggregate view of the (subnet:resolver):ipv6-score
mappings.  But this information is surely telling more about the general
quality of a ISPs IPv6-readiness, than no such information at all.

Best,
Martin


  

  






--------------030807060204070407060601--

From fred@cisco.com  Fri May  6 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 8566AE072F for ; Fri,  6 May 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 3IModJTTeUXa for ; Fri,  6 May 2011 06:55:01 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 33162E067A for ; Fri,  6 May 2011 06:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=129; q=dns/txt; s=iport; t=1304690101; x=1305899701; h=date:from:message-id:to:subject:cc; bh=Clt2AanHQtTwcU9vkt2iDRuMv3pT+jINyZDhMPD/5Ek=; b=FpLrp6SvTBMUS/Cu2s7XwfxWIE6QB1ebnIfB7LBYWHRXmOO0dxxMDGNR 2aQFrfOCTZwIbu5WweZQuT0cABwjodUWd8jJ7rYRHqDjUFHX+oBjVE5Nd ATk/aTGYNbBXnfnwvf/iAs2PuGOdldXrG+NJyQO+l4U9pe9x2V6FInqiB U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigIACX9w02rRDoJ/2dsb2JhbACYWgEBjWZ3pz+eDoYJBIY9mA8
X-IronPort-AV: E=Sophos;i="4.64,326,1301875200"; d="scan'208";a="351807201"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 06 May 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 p46Dt0k6002967; Fri, 6 May 2011 13:55:00 GMT
Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p46Dt0G18939; Fri, 6 May 2011 06:55:00 -0700 (PDT)
Date: Fri, 6 May 2011 06:55:00 -0700 (PDT)
From: 
Message-Id: <201105061355.p46Dt0G18939@ftpeng-update.cisco.com>
To: v6ops@ietf.org
Cc: draft-templin-v6ops-isops@tools.ietf.org
Subject: [v6ops] new draft: draft-templin-v6ops-isops-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, 06 May 2011 13:55:02 -0000

A new draft has been posted, at http://tools.ietf.org/draft-templin-v6ops-isops-00.txt. Please take a look at it and comment.

From shemant@cisco.com  Fri May  6 07:01: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 6140EE0737 for ; Fri,  6 May 2011 07:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.059
X-Spam-Level: 
X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 Qw+c+0IpXSc3 for ; Fri,  6 May 2011 07:01:29 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id D6A08E0724 for ; Fri,  6 May 2011 07:01:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=815; q=dns/txt; s=iport; t=1304690488; x=1305900088; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=TnoPE4cJ0C/odUbLtIv3Q1NohYi4HJzb4nW6ThRN8/U=; b=TWR094X8tlrAX6Ku06ZVHuDuNTA/CJV9/qfFyPVQD+lBSBPLkvQ9hqIR oNqhswFpJtemKXKCSs0cS5jgbALehtmIrarkCOJKKIjnjRwjJpj8KVXUW hw0POofmJU6VHbhFQZ6MnYBa5jz7mKxVo/+ztoE3DKGuhWLk/ADtIKnC6 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkoBAHr+w02tJV2Z/2dsb2JhbACYHI4md6dLng6GCQSGPY1IikU
X-IronPort-AV: E=Sophos;i="4.64,326,1301875200"; d="scan'208";a="693169620"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 06 May 2011 14:01:28 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p46E1SnG028221;  Fri, 6 May 2011 14:01:28 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);  Fri, 6 May 2011 09:01:27 -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: Fri, 6 May 2011 09:01:26 -0500
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C301973CB8@XMB-RCD-109.cisco.com>
In-Reply-To: <201105061355.p46Dt0G18939@ftpeng-update.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] new draft: draft-templin-v6ops-isops-00.txt
Thread-Index: AcwL9VGluAH7pv5qSlOz96+USfR8bgAAH5oQ
References: <201105061355.p46Dt0G18939@ftpeng-update.cisco.com>
From: "Hemant Singh (shemant)" 
To: "Fred Baker (fred)" , 
X-OriginalArrivalTime: 06 May 2011 14:01:27.0530 (UTC) FILETIME=[17C134A0:01CC0BF6]
Cc: draft-templin-v6ops-isops@tools.ietf.org
Subject: Re: [v6ops] new draft: draft-templin-v6ops-isops-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, 06 May 2011 14:01:29 -0000

URL sent in the email does not work.  Here is one URL to the document
that works.

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

Thanks Fred B. for the FYI and Fred T. for the document.  I will go thru
the document when I get a chance.

Hemant

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Fred Baker (fred)
Sent: Friday, May 06, 2011 9:55 AM
To: v6ops@ietf.org
Cc: draft-templin-v6ops-isops@tools.ietf.org
Subject: [v6ops] new draft: draft-templin-v6ops-isops-00.txt


A new draft has been posted, at
http://tools.ietf.org/draft-templin-v6ops-isops-00.txt. Please take a
look at it and comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

From jason_livingood@cable.comcast.com  Fri May  6 07:44: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 687A8E073C for ; Fri,  6 May 2011 07:44:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.403
X-Spam-Level: 
X-Spam-Status: No, score=-102.403 tagged_above=-999 required=5 tests=[AWL=-1.269, 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 jg12KLc3sa2k for ; Fri,  6 May 2011 07:44:15 -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 A8FBDE06DD for ; Fri,  6 May 2011 07:44:15 -0700 (PDT)
Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.37226590; Fri, 06 May 2011 08:47:36 -0600
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Fri, 6 May 2011 10:44:03 -0400
From: "Livingood, Jason" 
To: Philip Homburg , "v6ops@ietf.org WG" 
Thread-Topic: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
Thread-Index: AQHMC/wKgnsqrGgIkUOmwOT8dNw9zQ==
Date: Fri, 6 May 2011 14:44:02 +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.10.0.110310
x-originating-ip: [147.191.227.190]
Content-Type: multipart/alternative; boundary="_000_C9E980E5254E4jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 14:44:16 -0000

--_000_C9E980E5254E4jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Philip =96 Thanks for the suggestion and I'll see if I can add something ab=
out this in the =9604. One scenario I could imagine to cause good IPv6 / ba=
d IPv4 is the ISP exhausts IPv4 addresses and starts doing something like N=
AT444, which degrades IPv4 performance, while giving out a /64 of IPv6 addr=
esses (with good IPv6 connectivity).

Thanks
Jason

Now, I think the real issue, which seems to be missing in the draft (at
least after a quick read of the draft), is what happens to people who have
good IPv6 connectivity and poor IPv4 connectivity.

I don't get IPv6 addresses for Google at work (not whitelisted) or at home
(the network is whitelisted but I use a resolver in another netblock). But
does it really matter? I have excellent IPv4 connectivity. And there are
plenty of smaller sites with IPv6 addresses to test IPv6.

So the people who are really going to be affected by (the lack of) whitelis=
ting
are those with good IPv6 connectivity poor IPv4 connectivity. I'm not sure
that there many of those at the moment.

But when they come, it will be interesting to see what will happen. Many bi=
g
companies have a very poor track record communicating with small parties.
So it is quite possible to at some point a small ISP will find it
impossible to get it's customers whitelisted. And that will be the moment
whitelisting really hurts the Internet.


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


--_000_C9E980E5254E4jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <3786618DC688F94496268E898901A0D2@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable







Philip =96 Thanks for the suggestion and I'll see if I can add somethi=
ng about this in the =9604. One scenario I could imagine to cause good IPv6=
 / bad IPv4 is the ISP exhausts IPv4 addresses and starts doing something l=
ike NAT444, which degrades IPv4 performance,
 while giving out a /64 of IPv6 addresses (with good IPv6 connectivity).






Thanks


Jason









Now, I think the real issue, which seems to be missing in the draft (a=
t


least after a quick read of the draft), is what happens to people who =
have


good IPv6 connectivity and poor IPv4 connectivity.







I don't get IPv6 addresses for Google at work (not whitelisted) or at =
home


(the network is whitelisted but I use a resolver in another netblock).=
 But


does it really matter? I have excellent IPv4 connectivity. And there a=
re


plenty of smaller sites with IPv6 addresses to test IPv6.







So the people who are really going to be affected by (the lack of) whi=
telisting


are those with good IPv6 connectivity poor IPv4 connectivity. I'm not =
sure


that there many of those at the moment.







But when they come, it will be interesting to see what will happen. Ma=
ny big


companies have a very poor track record communicating with small parti=
es.


So it is quite possible to at some point a small ISP will find it 

impossible to get it's customers whitelisted. And that will be the mom=
ent


whitelisting really hurts the Internet.












_______________________________________________


v6ops mailing list













--_000_C9E980E5254E4jasonlivingoodcablecomcastcom_--

From cb.list6@gmail.com  Fri May  6 08:32: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 82B9DE06F4 for ; Fri,  6 May 2011 08:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.343
X-Spam-Level: 
X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 4W9ZqW79xCAD for ; Fri,  6 May 2011 08:32:34 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7166BE067A for ; Fri,  6 May 2011 08:32:34 -0700 (PDT)
Received: by eye13 with SMTP id 13so1188753eye.31 for ; Fri, 06 May 2011 08:32:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5opSzEvPZh7QGUvvJE0G8Ovu6aLQA4TXtrLj0bh4OQk=; b=sfvbP/enocrN6mF5QmS/ma18UAOwyRXMacEbmlShdqqeBhQW64CpIhGpXMwmnCJqTF IuIGeGCmS5Yw8HVt5N8EqRNkd1kgMSRRe+M1N0dNO8zDl21ppPUEu02OSU6NQOusvdBM QgfOxj1T0fF6bru8CqtAAJzxq8gbXDe/xcPfI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lpAExlHVfn06VzS2cMeVZJUIgs+3i4Gzc6VwHyzgphcoH+IJ0/ItbYaQPyh7D4TcKH I1fe+gHmlNanKGegP3fX4yfK5+3V5EiizepgEIdxVWc0/T8pOxYqbJ6BzJzE2VNFv1Hi w0f58mcqpStQKaTVN+DC+P+IoZ0sA8yQywhSg=
MIME-Version: 1.0
Received: by 10.14.122.201 with SMTP id t49mr1832020eeh.25.1304695953419; Fri, 06 May 2011 08:32:33 -0700 (PDT)
Received: by 10.14.37.143 with HTTP; Fri, 6 May 2011 08:32:29 -0700 (PDT)
Received: by 10.14.37.143 with HTTP; Fri, 6 May 2011 08:32:29 -0700 (PDT)
In-Reply-To: 
References: <9C8D5918-3BCD-499F-AEDE-C0EA3F0C55F4@cisco.com> <2464DCCB-94B8-47E4-B93A-EABA1064217E@apple.com>   <201105021746.p42Hk1dc022646@cichlid.raleigh.ibm.com> <20110503191344.GA6741@srv03.cluenet.de> <201105041231.p44CVHF2010939@cichlid.raleigh.ibm.com>  <20110506003912.395B1E84435@drugs.dv.isc.org> <9F0DD253-886D-47B8-9614-01A0F5F81785@apnic.net> <20110506012407.35984E84A43@drugs.dv.isc.org>  <20110506015212.51150E84C67@drugs.dv.isc.org> 
Date: Fri, 6 May 2011 08:32:29 -0700
Message-ID: 
From: Cameron Byrne 
To: Lorenzo Colitti 
Content-Type: multipart/alternative; boundary=e0cb4e43d0b7d7edc204a29d3264
Cc: IPv6 Ops WG , George Michaelson 
Subject: Re: [v6ops] 6to4-historic summary point: 4. "Phase out plan"
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 15:32:35 -0000

--e0cb4e43d0b7d7edc204a29d3264
Content-Type: text/plain; charset=ISO-8859-1

On May 5, 2011 11:25 PM, "Lorenzo Colitti"  wrote:
>
> On Fri, May 6, 2011 at 3:52 AM, Mark Andrews  wrote:
>>
>> > No, it doesn't help Windows (it ignores them) and only marginally helps
mac.
>>
>> So Windows is broken.  Complain to Microsoft who do have a working
>> update program.  Apple also has a working update program.
>
>
> Nope, ICMP unreachables are soft errors.
>
>>
>> Only because people WILL NOT TRY to do it.  People used to say the
>> same thing about Windows.  We now have a community that are used
>> to having their equipement updated to fix problems, whether it is
>> their PC, phone, printer, Kindle ....  The update processes do work.
>> They are NOT too hard for the average user.  You just have to tell
>> them they need to do it.
>
>
> Sure. So a vendor who licensed some code five years ago from a third-party
manufacturer that maybe no longer exists needs to see a business case to
reopen the code base for a product that's not shipping any more, spend
engineering cycles to fix it, and release it. And users need to hear about
it, download it, and upgrade it successfully. Good luck with that.
>
>> > Better to do it in the hosts, which have better upgrade mechanisms.
>>
>> And a lot of the problem 6to4 CPE routers are *hosts* with ICS enabled.
>> Put dead router detection on them.
>
>
> Yes, it needs to be in the host. But dead router detection? Why? That's
like saying "I'm going to enable this service that is unreliable and
high-latency, but it's OK, because if it happens not to work (in the only
direction) I can measure I'm going to disable again". Why enable it in the
first place then?
>

Agreed.  It's yet another layer of duct tape. I really wish we can move on
and leave 6to4 behind.

At the end of the day 6to4 cannot succeed without the service providers
running relays .... and there is no business case for that since there is no
v6only content.

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

--e0cb4e43d0b7d7edc204a29d3264
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On May 5, 2011 11:25 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:

>

> On Fri, May 6, 2011 at 3:52 AM, Mark Andrews <marka@isc.org> wrote:

>>

>> > No, it doesn't help Windows (it ignores them) and only ma=
rginally helps mac.

>>

>> So Windows is broken. =A0Complain to Microsoft who do have a worki=
ng

>> update program. =A0Apple also has a working update program.

>

>

> Nope, ICMP unreachables are soft errors.

> =A0

>>

>> Only because people WILL NOT TRY to do it. =A0People used to say t=
he

>> same thing about Windows. =A0We now have a community that are used=


>> to having their equipement updated to fix problems, whether it is<=
br>
>> their PC, phone, printer, Kindle .... =A0The update processes do w=
ork.

>> They are NOT too hard for the average user. =A0You just have to te=
ll

>> them they need to do it.

>

>

> Sure. So a vendor who licensed some code five years ago from a third-p=
arty manufacturer that maybe no longer exists needs to see a business case =
to reopen the code base for a product that's not shipping any more, spe=
nd engineering cycles to fix it, and release it. And users need to hear abo=
ut it, download it, and upgrade it successfully. Good luck with that.


>

>> > Better to do it in the hosts, which have better upgrade mecha=
nisms.

>>

>> And a lot of the problem 6to4 CPE routers are *hosts* with ICS ena=
bled.

>> Put dead router detection on them.

>

>

> Yes, it needs to be in the host. But dead router detection? Why? That&=
#39;s like saying "I'm going to enable this service that is unreli=
able and high-latency, but it's OK, because if it happens not to work (=
in the only direction) I can measure I'm going to disable again". =
Why enable it in the first place then?


>


Agreed.=A0 It's yet another layer of duct tape. I really wish we can=
 move on and leave 6to4 behind.


At the end of the day 6to4 cannot succeed without the service providers =
running relays .... and there is no business case for that since there is n=
o v6only content.=A0 


Cb

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

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

>




--e0cb4e43d0b7d7edc204a29d3264--

From jason_livingood@cable.comcast.com  Fri May  6 08:40: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 A2D02E06D0 for ; Fri,  6 May 2011 08:40:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.189
X-Spam-Level: 
X-Spam-Status: No, score=-102.189 tagged_above=-999 required=5 tests=[AWL=-1.055, 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 0K6M5grj0pBT for ; Fri,  6 May 2011 08:40:16 -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 BC6E1E0694 for ; Fri,  6 May 2011 08:40:16 -0700 (PDT)
Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.37239320; Fri, 06 May 2011 09:42:34 -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; Fri, 6 May 2011 11:38:39 -0400
From: "Livingood, Jason" 
To: Erik Kline , "STARK, BARBARA H (ATTSI)" 
Thread-Topic: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
Thread-Index: AQHMCZzqgewuui2dTEKFUhZWXW2in5R7bjWA///0gICABJFlgA==
Date: Fri, 6 May 2011 15:38:38 +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.10.0.110310
x-originating-ip: [147.191.227.190]
Content-Type: multipart/alternative; boundary="_000_C9E98DB125522jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "Richard L. Barnes" , "v6ops@ietf.org" , Dave Crocker 
Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 15:40:17 -0000

--_000_C9E98DB125522jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Here is the text I plan to add to Section 2 to address the discussion below=
. Please advise if folks think this is inelegantly-worded and should be mod=
ified in any way.

"DNS whitelisting also works independently of whether an authoritative serv=
er, recursive resolver, or end user host uses IPv4 transport, IPv6, or both=
. So, for example, whitelisting may prevent sending AAAA responses even in =
those cases where the recursive resolver has queried the authoritative serv=
er over IPv6 transport, or where the end user host's original query to the =
recursive resolver was over IPv6 transport. One important reason for this i=
s that even though the recursive resolver may have no IPv6-related impairme=
nts, this is not a reliable predictor of whether the same is true of the en=
d user host. This also means that a DNS whitelist can contain both IPv4 and=
 IPv6 addresses."

Thanks
Jason

On 5/3/11 1:53 PM, "Livingood, Jason" > wrote:

On 5/3/11 10:34 AM, "Erik Kline" > wrot=
e:

DNSv6 is theoretically in scope as well.  (i.e. we would include IPv6
prefixes in our resolver ACLs if [and when] we serve authoritative DNS
over v6)

Erik is correct =96 the concept is that a resolver's IP addresses, whether =
they are IPv4 or IPv6 addresses, could be on a whitelist in the authoritati=
ve DNS. I will add some text to the =9604 version to make this more clear.

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

--_000_C9E98DB125522jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable











Here is the text I plan to add to Section 2 to address the discussion =
below. Please advise if folks think this is inelegantly-worded and should b=
e modified in any way.











"DNS whitelisting also works independently of whether an autho=
ritative server, recursive resolver, or end user host uses IPv4 transport, =
IPv6, or both. So, for example, whitelisting may prevent sending AAAA respo=
nses even in those cases where the recursive
 resolver has queried the authoritative server over IPv6 transport, or wher=
e the end user host's original query to the recursive resolver was over IPv=
6 transport. One important reason for this is that even though the recursiv=
e resolver may have no IPv6-related
 impairments, this is not a reliable predictor of whether the same is true =
of the end user host. This also means that a DNS whitelist can contain both=
 IPv4 and IPv6 addresses."







Thanks


Jason










On 5/3/11 1:53 PM, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>=
; wrote:

















On 5/3/11 10:34 AM, "Erik Kline" <ek@google.com> wrote:











DNSv6 is theoretically in scope as well.  (i.e. we would inc=
lude IPv6


prefixes in our resolver ACLs if [and when] we serve authoritative DNS=



over v6)









Erik is correct =96 the concept is that a resolver's IP addresses, whe=
ther they are IPv4 or IPv6 addresses, could be on a whitelist in the author=
itative DNS. I will add some text to the =9604 version to make this more cl=
ear.







Thanks


Jason





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






--_000_C9E98DB125522jasonlivingoodcablecomcastcom_--

From Internet-Drafts@ietf.org  Fri May  6 09:00: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 17DC3E067A; Fri,  6 May 2011 09:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.574
X-Spam-Level: 
X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 kU0b-Q0F7K1n; Fri,  6 May 2011 09:00:01 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CB3E0704; Fri,  6 May 2011 09:00:01 -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.53
Message-ID: <20110506160001.16952.9583.idtracker@ietfa.amsl.com>
Date: Fri, 06 May 2011 09:00:01 -0700
Cc: v6ops@ietf.org
Subject: [v6ops] I-D ACTION:draft-ietf-v6ops-3gpp-eps-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: Fri, 06 May 2011 16:00:02 -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         : IPv6 in 3GPP Evolved Packet System
    Author(s)     : J. Korhonen, et al
    Filename      : draft-ietf-v6ops-3gpp-eps-01.txt
    Pages         : 32
    Date          : 2011-05-02
    
   Internet connectivity and use of data services in 3GPP based mobile
   networks has increased rapidly as a result of smart phones, broadband
   service via HSPA and HSPA+ networks, competitive service offerings by
   operators and a large number of applications.  Operators who have
   deployed networks based on 3GPP architectures are facing IPv4 address
   shortages.  With the impending exhaustion of available IPv4 addresses
   from the registries there is an increased emphasis for operators 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-01.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-3gpp-eps-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2011-05-06084951.I-D@ietf.org>


--NextPart--

From jason_livingood@cable.comcast.com  Fri May  6 10: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 97ABFE073A for ; Fri,  6 May 2011 10:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.423
X-Spam-Level: 
X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=-0.689, 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 vTyJRcCotPJT for ; Fri,  6 May 2011 10:03:03 -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 731E7E071E for ; Fri,  6 May 2011 10:03:02 -0700 (PDT)
Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.37258192; Fri, 06 May 2011 11:05:13 -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; Fri, 6 May 2011 13:01:26 -0400
From: "Livingood, Jason" 
To: Dave CROCKER 
Thread-Topic: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
Thread-Index: AQHMCZzqgewuui2dTEKFUhZWXW2in5R7bjWA///0gICABJFlgIAAShmA///NA4A=
Date: Fri, 6 May 2011 17:01:26 +0000
Message-ID: 
In-Reply-To: <4DC41BE5.8050403@bbiw.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [147.191.227.190]
Content-Type: multipart/alternative; boundary="_000_C9E9A0F62555Ajasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , "Richard L. Barnes" 
Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 17:03:07 -0000

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

/"DNS whitelisting also works independently of whether an authoritative ser=
ver,
recursive resolver, or end user host uses IPv4 transport, IPv6, or both. So=
, for
example, whitelisting may prevent sending AAAA responses even in those case=
s
where the recursive resolver has queried the authoritative server over IPv6
transport, or where the end user host's original query to the recursive res=
olver
was over IPv6 transport. One important reason for this is that even though =
the
recursive resolver may have no IPv6-related impairments, this is not a reli=
able
predictor of whether the same is true of the end user host. This also means=
 that
a DNS whitelist can contain both IPv4 and IPv6 addresses."/


I do not understand this text.

    "independently of whether an... end user host user..."

I don't think I say "end user host user" though. ??

appears to be saying that this mechanism 'works' even when its constraint o=
n DNS
response content is useless, by virtue of preventing the response to be
delivered.  That, at least, appears to be the implication of some of the
combinatorials the text seems to cover.

I'm trying to say that the transport used (v4 or v6) of the stub, recursive=
 resolver, and authoritative server are orthogonal to the application of a =
whitelist or whether a host or network is or is not on the whitelist.

JL



d/
--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


--_000_C9E9A0F62555Ajasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <23DC5F21A49DEF48B8229A69C398BD6E@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable











/"DNS whitelisting also works independently of whether an authori=
tative server,


recursive resolver, or end user host uses IPv4 transport, IPv6, or bot=
h. So, for


example, whitelisting may prevent sending AAAA responses even in those=
 cases


where the recursive resolver has queried the authoritative server over=
 IPv6


transport, or where the end user host's original query to the recursiv=
e resolver


was over IPv6 transport. One important reason for this is that even th=
ough the


recursive resolver may have no IPv6-related impairments, this is not a=
 reliable


predictor of whether the same is true of the end user host. This also =
means that


a DNS whitelist can contain both IPv4 and IPv6 addresses."/














I do not understand this text.







    "independently of whether an... end user =
host user..."









I don't think I say "end user host user" though. ??









appears to be saying that this mechanism 'works' even when its constra=
int on DNS


response content is useless, by virtue of preventing the response to b=
e 


delivered.  That, at least, appears to be the implication of=
 some of the 


combinatorials the text seems to cover.









I'm trying to say that the transport used (v4 or v6) of the stub, recu=
rsive resolver, and authoritative server are orthogonal to the application =
of a whitelist or whether a host or network is or is not on the whitelist.<=
/div>






JL



















d/


-- 







   Dave Crocker


   Brandenburg InternetWorking


   bbiw.net











--_000_C9E9A0F62555Ajasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Fri May  6 10:33: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 483A4E0769 for ; Fri,  6 May 2011 10:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.447
X-Spam-Level: 
X-Spam-Status: No, score=-105.447 tagged_above=-999 required=5 tests=[AWL=2.415, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 7TOOU3wcoWrr for ; Fri,  6 May 2011 10:33:51 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF28E075E for ; Fri,  6 May 2011 10:33:50 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.122201054; Fri, 06 May 2011 13:33:49 -0400
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; Fri, 6 May 2011 13:33:49 -0400
From: "Livingood, Jason" 
To: Philip Homburg , "v6ops@ietf.org WG" 
Thread-Topic: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
Thread-Index: AQHMC/wKgnsqrGgIkUOmwOT8dNw9zZSAD4qA
Date: Fri, 6 May 2011 17:33:48 +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.10.0.110310
x-originating-ip: [147.191.227.190]
Content-Type: multipart/alternative; boundary="_000_C9E98FE72552Ejasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 17:33:52 -0000

--_000_C9E98FE72552Ejasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Here's the draft text I am adding to address this in a new section (7.7). L=
et me know if you wish to see changes to this text (I've taken my best shot=
 at it):

"7.7 Implications with Poor IPv4 and Good IPv6 Transport

It is possible that there could be situations where the differing quality o=
f the IPv4 and IPv6 connectivity of an end user could cause complications i=
n accessing content which is in a whitelisted domain, when the end user's r=
ecursive DNS resolver is not on that whitelist. While today most end users'=
 IPv4 connectivity is typically superior to IPv6 connectivity (if such conn=
ectivity exists at all), there could be implications when the reverse is tr=
ue and and end user has markedly superior IPv6 connectivity as compared to =
IPv4. This is admittedly theoretical but could become a factor as the trans=
ition to IPv6 continues and IPv4 address availability within networks becom=
es strained.

For example, in one possible scenario, a user is issued IPv6 addresses by t=
heir ISP and has a home network and devices or operating systems which full=
y support IPv6. As a result this theoretical user has very good IPv6 connec=
tivity. However, this end user's ISP may have exhausted their available poo=
l of unique IPv4 address, and so that ISP uses NAT in order to reuse IPv4 a=
ddresses. So for IPv4 content, the end user must send their IPv4 traffic th=
rough some additional network element (e.g. NAT, proxy, tunnel server). Use=
 of this additional network element may cause the end user to experience su=
b-optimal IPv4 connectivity when certain protocols or applications are used=
. This user then has good IPv6 connectivity but impaired IPv4 connectivity.=
 Furthermore, this end user's recursive DNS resolver is not whitelisted by =
the authoritative server for a domain that the user is trying to access, me=
aning the end user only gets A record responses for their impaired IPv4 tra=
nsport rather than also AAAA record responses for their stable and well-per=
forming IPv6 transport. Thus, the user's poor IPv4 connectivity situation i=
s potentially exacerbated by not having access to a given domain's IPv6 con=
tent since they must use the address family with relatively poor performanc=
e."

Thank you
Jason


On 5/6/11 10:44 AM, "Livingood, Jason" > wrote:

Philip =96 Thanks for the suggestion and I'll see if I can add something ab=
out this in the =9604. One scenario I could imagine to cause good IPv6 / ba=
d IPv4 is the ISP exhausts IPv4 addresses and starts doing something like N=
AT444, which degrades IPv4 performance, while giving out a /64 of IPv6 addr=
esses (with good IPv6 connectivity).

Thanks
Jason

Now, I think the real issue, which seems to be missing in the draft (at
least after a quick read of the draft), is what happens to people who have
good IPv6 connectivity and poor IPv4 connectivity.

I don't get IPv6 addresses for Google at work (not whitelisted) or at home
(the network is whitelisted but I use a resolver in another netblock). But
does it really matter? I have excellent IPv4 connectivity. And there are
plenty of smaller sites with IPv6 addresses to test IPv6.

So the people who are really going to be affected by (the lack of) whitelis=
ting
are those with good IPv6 connectivity poor IPv4 connectivity. I'm not sure
that there many of those at the moment.

But when they come, it will be interesting to see what will happen. Many bi=
g
companies have a very poor track record communicating with small parties.
So it is quite possible to at some point a small ISP will find it
impossible to get it's customers whitelisted. And that will be the moment
whitelisting really hurts the Internet.


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


--_000_C9E98FE72552Ejasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <09B517C5F711A5428CA13EAB86581834@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable











Here's the draft text I am adding to address this in a new section (7.=
7). Let me know if you wish to see changes to this text (I've taken my best=
 shot at it):







"7.7 Implications with Poor IPv4 and Good IPv6 Transport






It is possible that there could be situations where the differing q=
uality of the IPv4 and IPv6 connectivity of an end user could cause complic=
ations in accessing content which is in a whitelisted domain, when the end =
user's recursive DNS resolver is
 not on that whitelist. While today most end users' IPv4 connectivity is ty=
pically superior to IPv6 connectivity (if such connectivity exists at all),=
 there could be implications when the reverse is true and and end user has =
markedly superior IPv6 connectivity
 as compared to IPv4. This is admittedly theoretical but could become a fac=
tor as the transition to IPv6 continues and IPv4 address availability withi=
n networks becomes strained.







For example, in one possible scenario, a user is issued IPv6 addres=
ses by their ISP and has a home network and devices or operating systems wh=
ich fully support IPv6. As a result this theoretical user has very good IPv=
6 connectivity. However, this end
 user's ISP may have exhausted their available pool of unique IPv4 address,=
 and so that ISP uses NAT in order to reuse IPv4 addresses. So for IPv4 con=
tent, the end user must send their IPv4 traffic through some additional net=
work element (e.g. NAT, proxy, tunnel
 server). Use of this additional network element may cause the end user to =
experience sub-optimal IPv4 connectivity when certain protocols or applicat=
ions are used. This user then has good IPv6 connectivity but impaired IPv4 =
connectivity. Furthermore, this
 end user's recursive DNS resolver is not whitelisted by the authoritative =
server for a domain that the user is trying to access, meaning the end user=
 only gets A record responses for their impaired IPv4 transport rather than=
 also AAAA record responses for
 their stable and well-performing IPv6 transport. Thus, the user's poor IPv=
4 connectivity situation is potentially exacerbated by not having access to=
 a given domain's IPv6 content since they must use the address family with =
relatively poor performance."







Thank you


Jason



























On 5/6/11 10:44 AM, "Livingood, Jason" <jason_livingood@cable.comcast.com&g=
t; wrote:















Philip =96 Thanks for the suggestion and I'll see if I can add somethi=
ng about this in the =9604. One scenario I could imagine to cause good IPv6=
 / bad IPv4 is the ISP exhausts IPv4 addresses and starts doing something l=
ike NAT444, which degrades IPv4 performance,
 while giving out a /64 of IPv6 addresses (with good IPv6 connectivity).






Thanks


Jason









Now, I think the real issue, which seems to be missing in the draft (a=
t


least after a quick read of the draft), is what happens to people who =
have


good IPv6 connectivity and poor IPv4 connectivity.







I don't get IPv6 addresses for Google at work (not whitelisted) or at =
home


(the network is whitelisted but I use a resolver in another netblock).=
 But


does it really matter? I have excellent IPv4 connectivity. And there a=
re


plenty of smaller sites with IPv6 addresses to test IPv6.







So the people who are really going to be affected by (the lack of) whi=
telisting


are those with good IPv6 connectivity poor IPv4 connectivity. I'm not =
sure


that there many of those at the moment.







But when they come, it will be interesting to see what will happen. Ma=
ny big


companies have a very poor track record communicating with small parti=
es.


So it is quite possible to at some point a small ISP will find it 

impossible to get it's customers whitelisted. And that will be the mom=
ent


whitelisting really hurts the Internet.












_______________________________________________


v6ops mailing list




















--_000_C9E98FE72552Ejasonlivingoodcablecomcastcom_--

From dcrocker@bbiw.net  Fri May  6 09:05: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 33DC2E0715 for ; Fri,  6 May 2011 09:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.499
X-Spam-Level: 
X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=1.100,  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 HjYx6TNS+Vhl for ; Fri,  6 May 2011 09:05:39 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 34B9CE07A4 for ; Fri,  6 May 2011 09:04:53 -0700 (PDT)
Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p46G41qF018938 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 6 May 2011 09:04:06 -0700
Message-ID: <4DC41BE5.8050403@bbiw.net>
Date: Fri, 06 May 2011 09:03:49 -0700
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Livingood, Jason" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 06 May 2011 09:04:09 -0700 (PDT)
X-Mailman-Approved-At: Fri, 06 May 2011 11:36:04 -0700
Cc: "v6ops@ietf.org" , "Richard L. Barnes" 
Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 16:05:40 -0000

On 5/6/2011 8:38 AM, Livingood, Jason wrote:
> Here is the text I plan to add to Section 2 to address the discussion below.
> Please advise if folks think this is inelegantly-worded and should be modified
> in any way.
>
> /"DNS whitelisting also works independently of whether an authoritative server,
> recursive resolver, or end user host uses IPv4 transport, IPv6, or both. So, for
> example, whitelisting may prevent sending AAAA responses even in those cases
> where the recursive resolver has queried the authoritative server over IPv6
> transport, or where the end user host's original query to the recursive resolver
> was over IPv6 transport. One important reason for this is that even though the
> recursive resolver may have no IPv6-related impairments, this is not a reliable
> predictor of whether the same is true of the end user host. This also means that
> a DNS whitelist can contain both IPv4 and IPv6 addresses."/


I do not understand this text.

    "independently of whether an... end user host user..."

appears to be saying that this mechanism 'works' even when its constraint on DNS 
response content is useless, by virtue of preventing the response to be 
delivered.  That, at least, appears to be the implication of some of the 
combinatorials the text seems to cover.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From v6ops@globis.net  Fri May  6 11:57: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 AB4C6E07EE for ; Fri,  6 May 2011 11:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level: 
X-Spam-Status: No, score=-2.109 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 EjUNj0gPUmck for ; Fri,  6 May 2011 11:57:09 -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 5D6FFE078A for ; Fri,  6 May 2011 11:57:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E9EA78700ED for ; Fri,  6 May 2011 20:57: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 elFqTCmk9EEi for ; Fri,  6 May 2011 20:57:01 +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 ACF7B870083 for ; Fri,  6 May 2011 20:57:01 +0200 (CEST)
Message-ID: <4DC44472.6080208@globis.net>
Date: Fri, 06 May 2011 20:56:50 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: "v6ops@ietf.org WG" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [v6ops]  new draft: draft-templin-v6ops-isops-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, 06 May 2011 18:57:09 -0000

Excellent document. Really clear. Thanks very much.

I still have a few outstanding operational issues with ISATAP in a 
commercial/ industrial environment that I'd greatly appreciate the 
authors expending some brain cycles on:

1) to confirm that these issues are real
2) whether there are any operational workarounds the v6ops group can provide
3) to come up with ideas for mitigation

I beg your indulgence.

After a fair bit of careful consideration, I have currently come to the 
conclusion that deploying ISATAP would probably be an epic fail if I 
deployed it in my customers' networks, and it has to be 100% disabled 
during the transition to native IPv6 (ironically enough as it is meant 
to be a transition mechanism). I suspect that deploying ISATAP in my 
customer's environments would be "career shortening." This isn't a 
flame. Just a statement of the way I see things at the moment. Maybe I'm 
wrong. But it would certainly be a risk. We're talking major 
multinationals. Maybe these aren't typical customer environments or 
target environments where ISATAP is intended to be deployed. Funnily 
enough, IPv4 has also proven quite popular in these environments too though.

The issues all revolve around SLA's, and the preference of ISATAP over 
native IPv4, rather than any "broken connectivity" like 6to4. The word 
"latency" looms large.



Firstly, I have a minor issue with the use of firewalls in commercial 
environments (They are unavoidable. Sorry. Blame the accountants)

In your draft you state that:

ISATAP client to client communications should therefore also only be 
used when the path between the clients is first tested in an initial 
reachability exchange.

I understand that this is functionality uses NUD after name resolution 
(Section 8.4 of RFC5214)

That means that IPv6 may fail after initially trying to establish a session.

Can you give me any guidance to how quickly NUD will fail when detecting 
unreachable hosts behind firewalls over ISATAP (presumably with a host 
unreachable) and then fallback to IPv4 ?

The issue is that even though the fallback is safe, it will probably not 
result in happy eyeballs (addressed elsewhere I guess) because the 
damage has already be done due to the initial connection delay.



Secondly, I see no links to any documents warning of the dangers of 
automatic tunnels.[e.g. rfc6169]

I think a link would be useful.

Again, it's the auditors. They don't seem to like it if someone can 
automatically tunnel into the finance data centre and blind side their 
firewall audit logging. Firewall support for native IPv6 and IPv6 over 
IPv4 is poor at the moment. Sorry, that was a whine. Let's move on.



Thirdly, I see no way to have common QoS mechanisms properly handle 
ISATAP encapsulated traffic.

Apparently QoS isn't that important a topic on the Public Internet yet 
(although I suspect it will become so as more people download video over 
wireless to their mobile devices)

Many corporations have spent significant amounts of money implementing 
WAN acceleration, packet shaping etc. (more fool them you might say, as 
many of the devices are not IPv6 aware).

Many corporations have also implemented IETF derived mechanisms like 
DSCP based WRED (based on RFC 2597).

Is there any guidance to vendors that they should support detection of 
IPv4 DSCP markings within an IPv6 ISATAP tunnel?
or whether/how these IPv4 DSCP bits should be made visible outside of 
the ISATAP encapsulation so that they can be acted upon by intermediate 
devices?

Otherwise all of the companies' QoS policies get blown out of the water 
as soon as ISATAP kicks in (and by default it does kick in on many 
popular operating systems, as confirmed in a customer's environment.)

QoS and differential services is a cornerstone of many SLA's.



Fourthly, many of my customers have strict SLA's for latency. The 
presumption of ISATAP would still seem to be that tunneled connectivity 
is fine, and that any additional latency to the nearest gateway router 
is not operationally significant.

Given that in a large multinational corporation there may be 
inter-continental hops involved to reach an ISATAP router, compared to a 
typical engineering requirement of <50mS round trip delay within a 
country for accelerated X windows applications, is there any mechanism 
to detect and/or limit the additional latency to the ISATAP router, over 
and above the basic test for connectivity?

This is complicated by the fact that so many of these executive types 
seem to insist on flying around the World and taking their laptops with 
them, rather than video conferencing over IP from their own desk. They 
also like to work from home, or on their customers' premises. I keep on 
telling them about speed of light limitations and to move the sites 
closer together, but they won't listen.

I'm guessing the answer will be "no" on the existence of a built-in 
ISATAP latency reduction/optimization mechanism. Such a mechanism could 
theoretically detect the round trip latency to a number of candidate 
ISATAP routers in the prl and then select the "closest" as part of the 
initial ISATAP router selection mechanism. Perhaps something to consider 
recommending to vendors as a future enhancement? Possibly with a 
configurable upper limit on the acceptable latency before declaring the 
router unusable?

Since the list of candidate ISATAP routers in the prl is fetched via DNS 
in many implementations, I guess my clients could implement some 
mitigation by setting the DNS server via DHCP based on location, and 
then serving different answers for isatap.foobar.com. However a lot of 
corporations have centralised their DNS servers via IPAM tooling, so 
there's only one per region nowadays, so that may or may not fly 
depending on the tooling. We're back to geographically aware DNS services.

But even then, they'd probably have to deploy an ISATAP router per site 
(several hundred sites) which may not all be rolled out at the same 
time. By the time you've done that, rolling out native IPv6 on multiple 
MPLS networks doesn't look so bad after all.



I'm not expecting ISATAP to be perfect, so please don't take this as 
whining, but I would like to avoid it breaking anything by default.

Now the main two showstoppers in common implementations:

a. by default, ISATAP is enabled

Is there any plan to request vendors disable ISATAP by default?

b. also by default, IPv6 over ISATAP over IPv4 appears to be preferred 
over native IPv4.

If I want to use ISATAP at all, at the moment I expect it'll always be 
preferred over native IPv4 if I prefer native IPv6 over native IPv4 
(default).

Can I prefer native IPv6 above native IPv4 above IPv6 over ISATAP over IPv4?

Because ISATAP is based on a well-known node prefix (last 64 bits of an 
IPv6 address, and not well-known IPv6 prefixes (left anchored front 
portion of an IPv6 address), and it provides IPv6 connectivity using 
standard IPv6 prefixes, even after implementing RFC3484 bis,  I know of 
no mechanism where a network administrator of a network with 
well-managed native IPv4 connectivity can prefer native IPv6 above 
native IPv4, but also prefer native IPv4 above ISATAP during a migration.

Is there any other operational way to achieve this?

Because if there isn't, the only options left over are to prefer 
corporate native IPv4 above all IPv6 (ouch, and not default today), or 
to disable ISATAP completely on all nodes (ouch, a potentially herculean 
task, because ISATAP is enabled by default today).

None of which is very satisfactory.

Thanks for reading this far.

regards,
RayH

From pch-b6B5344D9@u-1.phicoh.com  Fri May  6 13:39: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 C0A45E07DE for ; Fri,  6 May 2011 13:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.028
X-Spam-Level: 
X-Spam-Status: No, score=-8.028 tagged_above=-999 required=5 tests=[AWL=0.571,  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 JBraY6oz8iQR for ; Fri,  6 May 2011 13:39:33 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8B37BE07D1 for ; Fri,  6 May 2011 13:39:31 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #50) id m1QIRo8-00021sC; Fri, 6 May 2011 22:39 +0200
Message-Id: 
To: Ray Hunter 
From: Philip Homburg 
Sender: pch-b6B5344D9@u-1.phicoh.com
In-reply-to: Your message of "Fri, 06 May 2011 10:39:08 +0200 ." <4DC3B3AC.5020308@globis.net> 
Date: Fri, 06 May 2011 22:39:19 +0200
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 20:39:33 -0000

In your letter dated Fri, 06 May 2011 10:39:08 +0200 you wrote:
>Philip Homburg has already posted that he uses a resolver in another net 
>block, so he does not receive IPv6 records. I do too. Maybe this will 
>become the "new normal" that the providers of IPv6 transport and DNS 
>resolution are not strongly operationally coupled (because there is no 
>architectural requirement to do so) Who really knows yet?
>
>Which is why my original posting suggested that the WG might wish to 
>express a concern about anyone making assumptions about any undocumented 
>architectural links between DNS and transport, 

Very curious in this case is that Google also provides a public DNS resolver.
So, where their IPv6 whitelisting depends on a connection between the 
resolver and the user's IPv6 capabilities, at the same time, they promote a
de-coupling between users netblocks and the DNS resolvers they use.

Coming back to my use of a DNS resolver in a different netblock. The main
reason is the limited number of IPv4 addresses provided with consumer DSL
connection (i.e., just one). For IPv6 that is not an issue. But apparently,
the line of reasoning that led Google to implementing DNS whitelisting also
led to a lack of IPv6 glue for their domains.

So, for the hypothetical user with good IPv6 connectivity and poor IPv4
connectivity, even if he can get his resolver whitelisted, he still has to
go over IPv4 to get those AAAA records.

Just a thought. I wonder if people will start running public DNS resolvers
that are hand populated with the IPv6 addresses of popular sites that employ
DNS whitelisting. Sounds like a useful service.



From Fred.L.Templin@boeing.com  Fri May  6 13:52: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 C243CE0816 for ; Fri,  6 May 2011 13:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.237
X-Spam-Level: 
X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=-0.238, 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 ixqUFhxfqaLp for ; Fri,  6 May 2011 13:52:19 -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 5A092E0815 for ; Fri,  6 May 2011 13:52:19 -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 p46Kq33O029247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 May 2011 15:52:04 -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 p46Kq35S005283; Fri, 6 May 2011 13:52:03 -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 p46Kq3EL005279 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 6 May 2011 13:52:03 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Fri, 6 May 2011 13:52:03 -0700
From: "Templin, Fred L" 
To: Ray Hunter , "v6ops@ietf.org WG" 
Date: Fri, 6 May 2011 13:52:01 -0700
Thread-Topic: [v6ops]  new draft: draft-templin-v6ops-isops-00.txt
Thread-Index: AcwMH4Oy/p8WK185TjyMZcwzk/WQTAAAzo1g
Message-ID: 
References: <4DC44472.6080208@globis.net>
In-Reply-To: <4DC44472.6080208@globis.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] new draft: draft-templin-v6ops-isops-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, 06 May 2011 20:52:20 -0000

Hi Ray,=20

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20
> On Behalf Of Ray Hunter
> Sent: Friday, May 06, 2011 11:57 AM
> To: v6ops@ietf.org WG
> Subject: [v6ops] new draft: draft-templin-v6ops-isops-00.txt
>=20
> Excellent document. Really clear. Thanks very much.

Thanks for taking the time to review and comment.

> I still have a few outstanding operational issues with ISATAP in a=20
> commercial/ industrial environment that I'd greatly appreciate the=20
> authors expending some brain cycles on:
>=20
> 1) to confirm that these issues are real
> 2) whether there are any operational workarounds the v6ops=20
> group can provide
> 3) to come up with ideas for mitigation
>=20
> I beg your indulgence.
>=20
> After a fair bit of careful consideration, I have currently=20
> come to the=20
> conclusion that deploying ISATAP would probably be an epic fail if I=20
> deployed it in my customers' networks, and it has to be 100% disabled=20
> during the transition to native IPv6 (ironically enough as it=20
> is meant=20
> to be a transition mechanism). I suspect that deploying ISATAP in my=20
> customer's environments would be "career shortening." This isn't a=20
> flame. Just a statement of the way I see things at the=20
> moment. Maybe I'm=20
> wrong. But it would certainly be a risk. We're talking major=20
> multinationals. Maybe these aren't typical customer environments or=20
> target environments where ISATAP is intended to be deployed. Funnily=20
> enough, IPv4 has also proven quite popular in these=20
> environments too though.

Wow - these seem like fairly strong sentiments. But,
I appreciate that you have a serious obligation to
your customers!

> The issues all revolve around SLA's, and the preference of=20
> ISATAP over=20
> native IPv4, rather than any "broken connectivity" like 6to4.=20
> The word=20
> "latency" looms large.

OK, but the preference only applies when there are
AAAA records for the intended correspondent in the
site name service. When there are only A records,
then native IPv4 will be used. So, a simple solution
is for the site administrator to simply not add any
AAAA records to the site-internal name service for
SLAAC-derived ISATAP addresses.

> Firstly, I have a minor issue with the use of firewalls in commercial=20
> environments (They are unavoidable. Sorry. Blame the accountants)
>=20
> In your draft you state that:
>=20
> ISATAP client to client communications should therefore also only be=20
> used when the path between the clients is first tested in an initial=20
> reachability exchange.
>=20
> I understand that this is functionality uses NUD after name=20
> resolution=20
> (Section 8.4 of RFC5214)

I think you mean NUD after *address* resolution? The
RFC says: "ISATAP hosts SHOULD perform an initial
reachability confirmation by sending Neighbor
Solicitation messages and receiving a Neighbor
Advertisement message.". But, that does not prevent
the hosts from performing an initial reachability
confirmation via some other means, e.g., RS/RA,
ICMP echo/reply, etc.

> That means that IPv6 may fail after initially trying to=20
> establish a session.

The only time this would happen is when a pair
of ISATAP clients attempt to communicate directly
without sending their initial packets through an
advertising ISATAP router. The draft is advocating
that all initial communications go through an
advertising ISATAP router, which may return
redirection messages. When an ISATAP client
receives the redirection messages, however, it
does not need to heed them immediately. It could
instead continue to send its packets via the
advertising ISATAP router while testing the path
to the peer ISATAP client in parallel. Maybe the
draft could say this explicitly.

> Can you give me any guidance to how quickly NUD will fail=20
> when detecting=20
> unreachable hosts behind firewalls over ISATAP (presumably=20
> with a host=20
> unreachable) and then fallback to IPv4 ?

According to the draft recommendations, direct
peer-to-peer comms would only be enabled after
the path between the peers has been tested. Again,
this can be done in parallel with continuing to
send packets via an advertising ISATAP router,
hence ordinary data packets would not be subject
to loss.

The host unreachable is a nice optimization,
but if it is not generated nor dropped due to
filtering then it can't be counted on. You may
have better knowledge on this point than I do;
in well-managed sites, is it reasonable to
expect that ICMPs will be delivered by the
network without loss due to filtering?=20

> The issue is that even though the fallback is safe, it will=20
> probably not=20
> result in happy eyeballs (addressed elsewhere I guess) because the=20
> damage has already be done due to the initial connection delay.

Again, this comes down to whether AAAA records
should be entered into the site-internal name
service in the first place. For SLAAC-derived
ISATAP addresses, the draft says no.

> Secondly, I see no links to any documents warning of the dangers of=20
> automatic tunnels.[e.g. rfc6169]
>=20
> I think a link would be useful.

OK.

> Again, it's the auditors. They don't seem to like it if someone can=20
> automatically tunnel into the finance data centre and blind=20
> side their=20
> firewall audit logging. Firewall support for native IPv6 and=20
> IPv6 over=20
> IPv4 is poor at the moment. Sorry, that was a whine. Let's move on.

OK.
=20
> Thirdly, I see no way to have common QoS mechanisms properly handle=20
> ISATAP encapsulated traffic.
>=20
> Apparently QoS isn't that important a topic on the Public=20
> Internet yet=20
> (although I suspect it will become so as more people download=20
> video over=20
> wireless to their mobile devices)
>=20
> Many corporations have spent significant amounts of money=20
> implementing=20
> WAN acceleration, packet shaping etc. (more fool them you=20
> might say, as=20
> many of the devices are not IPv6 aware).
>=20
> Many corporations have also implemented IETF derived mechanisms like=20
> DSCP based WRED (based on RFC 2597).
>=20
> Is there any guidance to vendors that they should support=20
> detection of=20
> IPv4 DSCP markings within an IPv6 ISATAP tunnel?
> or whether/how these IPv4 DSCP bits should be made visible outside of=20
> the ISATAP encapsulation so that they can be acted upon by=20
> intermediate=20
> devices?

Well, this is an interesting point. RFC5214 is
silent on the subject, and RFC4213 says: "Type
of Service: 0 unless otherwise specified.". But,
when I look at the Linux source code I see it
doing both DSCP and ECN mapping between inner
and outer headers - I guess that would be in
keeping with RFCs 2983 and 3168?
=20
> Otherwise all of the companies' QoS policies get blown out of=20
> the water=20
> as soon as ISATAP kicks in (and by default it does kick in on many=20
> popular operating systems, as confirmed in a customer's environment.)
>=20
> QoS and differential services is a cornerstone of many SLA's.
>=20
>=20
>=20
> Fourthly, many of my customers have strict SLA's for latency. The=20
> presumption of ISATAP would still seem to be that tunneled=20
> connectivity=20
> is fine, and that any additional latency to the nearest=20
> gateway router=20
> is not operationally significant.
>=20
> Given that in a large multinational corporation there may be=20
> inter-continental hops involved to reach an ISATAP router,=20
> compared to a=20
> typical engineering requirement of <50mS round trip delay within a=20
> country for accelerated X windows applications, is there any=20
> mechanism=20
> to detect and/or limit the additional latency to the ISATAP=20
> router, over=20
> and above the basic test for connectivity?

Well, yes. The site could put an IPv4 anycast
address as the lone address in the PRL. Then,
ISATAP clients will find the advertising ISATAP
router that is topologically closest. All the
site needs to do then is deploy sufficiently
distributed advertising ISATAP routers.

> This is complicated by the fact that so many of these executive types=20
> seem to insist on flying around the World and taking their=20
> laptops with=20
> them, rather than video conferencing over IP from their own=20
> desk. They=20
> also like to work from home, or on their customers' premises.=20
> I keep on=20
> telling them about speed of light limitations and to move the sites=20
> closer together, but they won't listen.

Agreed that moving the sites closer together
would be a useful but miraculous feat. For
example, asking everyone in the southwest region
to relocate to the northeast would be a recipe
for failure (not that I have anything against
the northeast).

> I'm guessing the answer will be "no" on the existence of a built-in=20
> ISATAP latency reduction/optimization mechanism. Such a=20
> mechanism could=20
> theoretically detect the round trip latency to a number of candidate=20
> ISATAP routers in the prl and then select the "closest" as=20
> part of the=20
> initial ISATAP router selection mechanism. Perhaps something=20
> to consider=20
> recommending to vendors as a future enhancement? Possibly with a=20
> configurable upper limit on the acceptable latency before=20
> declaring the=20
> router unusable?

The two options are to either manage the name
service entries so that there are "regional"
PRL names (e.g., northeast.example.com,
southwest.example.com, etc.) and put regionally
localized unicast IPv4 addresses in each PRL
name. Or, simply put an IPv4 anycast address
in the PRL and let IPv4 routing steer ISATAP
clients to the closest advertising ISATAP
router.

> Since the list of candidate ISATAP routers in the prl is=20
> fetched via DNS=20
> in many implementations, I guess my clients could implement some=20
> mitigation by setting the DNS server via DHCP based on location, and=20
> then serving different answers for isatap.foobar.com. However=20
> a lot of=20
> corporations have centralised their DNS servers via IPAM tooling, so=20
> there's only one per region nowadays, so that may or may not fly=20
> depending on the tooling. We're back to geographically aware=20
> DNS services.

Or geographically-relative FQDNs as noted
above. Or simply place an IPv4 anycast
address in the PRL.

> But even then, they'd probably have to deploy an ISATAP=20
> router per site=20
> (several hundred sites) which may not all be rolled out at the same=20
> time. By the time you've done that, rolling out native IPv6=20
> on multiple=20
> MPLS networks doesn't look so bad after all.

I think this would very much depend on how the
site is organized. Surely, each partition within
the site needs to have a border router that can
reach the Internet. If that border router were
to become an advertising ISATAP router, then
the partition has a way of using ISATAP.

> I'm not expecting ISATAP to be perfect, so please don't take this as=20
> whining, but I would like to avoid it breaking anything by default.
>=20
> Now the main two showstoppers in common implementations:
>=20
> a. by default, ISATAP is enabled

Yes.

> Is there any plan to request vendors disable ISATAP by default?

No.

> b. also by default, IPv6 over ISATAP over IPv4 appears to be=20
> preferred=20
> over native IPv4.

That's not a problem as long as the ISATAP clients
only need to access IPv6 services that are outside
of the site and/or as long as site administrators
only place AAAA records within the site name service
for IPv6-only correspondents.
=20

> If I want to use ISATAP at all, at the moment I expect it'll=20
> always be=20
> preferred over native IPv4 if I prefer native IPv6 over native IPv4=20
> (default).
>=20
> Can I prefer native IPv6 above native IPv4 above IPv6 over=20
> ISATAP over IPv4?

There is not really a way to distinguish IPv6
prefixes used for ISATAP from any other native
IPv6 prefixes unless there were some sort of
distributed configuration files maintained.
However, the draft advocates that no ISATAP
addresses derived from SLAAC be entered into
AAAA records within the site name service.

> Because ISATAP is based on a well-known node prefix (last 64=20
> bits of an=20
> IPv6 address, and not well-known IPv6 prefixes (left anchored front=20
> portion of an IPv6 address), and it provides IPv6 connectivity using=20
> standard IPv6 prefixes, even after implementing RFC3484 bis, =20
> I know of=20
> no mechanism where a network administrator of a network with=20
> well-managed native IPv4 connectivity can prefer native IPv6 above=20
> native IPv4, but also prefer native IPv4 above ISATAP during=20
> a migration.
>=20
> Is there any other operational way to achieve this?

Simply don't put SLAAC-derived ISATAP addresses
in AAAA records in the site name service, as
discussed in the draft.

> Because if there isn't, the only options left over are to prefer=20
> corporate native IPv4 above all IPv6 (ouch, and not default=20
> today), or=20
> to disable ISATAP completely on all nodes (ouch, a=20
> potentially herculean=20
> task, because ISATAP is enabled by default today).
>=20
> None of which is very satisfactory.
>=20
> Thanks for reading this far.

I hope this response has helped?

Thanks - Fred
fred.l.templin@boeing.com
=20
> regards,
> RayH
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> =

From pch-b6B5344D9@u-1.phicoh.com  Fri May  6 13:54: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 1E630E07F6 for ; Fri,  6 May 2011 13:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.099
X-Spam-Level: 
X-Spam-Status: No, score=-8.099 tagged_above=-999 required=5 tests=[AWL=0.500,  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 aGLSpl9y3luh for ; Fri,  6 May 2011 13:54:44 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 15D3DE0778 for ; Fri,  6 May 2011 13:54:43 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #50) id m1QIRt7-00021qC; Fri, 6 May 2011 22:44 +0200
Message-Id: 
To: "Livingood, Jason" 
From: Philip Homburg 
Sender: pch-b6B5344D9@u-1.phicoh.com
In-reply-to: Your message of "Fri, 6 May 2011 17:33:48 +0000 ."  
Date: Fri, 06 May 2011 22:44:36 +0200
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 06 May 2011 20:54:45 -0000

In your letter dated Fri, 6 May 2011 17:33:48 +0000 you wrote:
>"7.7 Implications with Poor IPv4 and Good IPv6 Transport
>
>It is possible that there could be situations where the differing quality o=
>f the IPv4 and IPv6 connectivity of an end user could cause complications i=
>n accessing content which is in a whitelisted domain, when the end user's r=
>ecursive DNS resolver is not on that whitelist. 

My main comment, and that applies to the entire document, is that the
text is very verbose. Reducing the amount of text by a factor of two seems
to be quite possible, and is likely to result in a much more readable
document.



From Internet-Drafts@ietf.org  Fri May  6 15:45: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 973D8E0736; Fri,  6 May 2011 15:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.574
X-Spam-Level: 
X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 X8pf6ckf6iGi; Fri,  6 May 2011 15:45:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40EEE069B; Fri,  6 May 2011 15:45:02 -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.53
Message-ID: <20110506224502.28621.37433.idtracker@ietfa.amsl.com>
Date: Fri, 06 May 2011 15:45:02 -0700
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action:draft-ietf-v6ops-tunnel-loops-07.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, 06 May 2011 22:45:03 -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           : Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations
	Author(s)       : G. Nakibly, F. Templin
	Filename        : draft-ietf-v6ops-tunnel-loops-07.txt
	Pages           : 20
	Date            : 2011-05-06

This document is concerned with security vulnerabilities in IPv6-in-
IPv4 automatic tunnels.  These vulnerabilities allow an attacker to
take advantage of inconsistencies between the IPv4 routing state and
the IPv6 routing state.  The attack forms a routing loop which can be
abused as a vehicle for traffic amplification to facilitate DoS
attacks.  The first aim of this document is to inform on this attack
and its root causes.  The second aim is to present some possible
mitigation measures.  It should be noted that at the time of this
writing there are no known reports of malicious attacks exploiting
these vulnerabilities.  Nonetheless, these vulnerabilities can be
activated by accidental misconfiguarion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-tunnel-loops-07.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-tunnel-loops-07.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2011-05-06153903.I-D@ietf.org>


--NextPart--

From bingxuere@gmail.com  Fri May  6 19:32: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 CAA3AE06A0 for ; Fri,  6 May 2011 19:32:04 -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 yCaI8C+TRboH for ; Fri,  6 May 2011 19:32:04 -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 F03E3E069D for ; Fri,  6 May 2011 19:32:03 -0700 (PDT)
Received: by vxg33 with SMTP id 33so4844872vxg.31 for ; Fri, 06 May 2011 19:32:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=TyfLo0LC0kTb1CV27yNHe13zezbo5QySMKUBopEdmcI=; b=lckOBscctNPyfQAgYkopCojtZ/jd+WpX+zWPCWZk9kudF9EhBWrGVSbtDlbhi09KKk Zbg2wuR1zQfVWBex8C5Y0EeoXR5yAjdwpQkGSMZ2OsCCIIywtKORvHMlVF7gPOnQpE6h TrsAdIAr2Jj5Ei8ovpZzNQHa1dXO5P93rx9EU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cJtJsGMDSpZF2AnlC28Z/2zUhpaMdwLl22Sh12Dg4Nav5sA66rcfJQtXQkI23HWhLw qKF3+uhxL59zWNfm6YG5XOOx5zK/huqil5/0UAH8v50NsxFrPyGaTzQ8uUl7Cp+6CFLc QpJxwH/nvpDdy4XhtjCTVlSq/uDhLuKyPlE98=
MIME-Version: 1.0
Received: by 10.52.98.40 with SMTP id ef8mr2649579vdb.54.1304735523197; Fri, 06 May 2011 19:32:03 -0700 (PDT)
Received: by 10.52.170.41 with HTTP; Fri, 6 May 2011 19:32:03 -0700 (PDT)
Date: Sat, 7 May 2011 10:32:03 +0800
Message-ID: 
From: Qiong 
To: v6ops@ietf.org
Content-Type: multipart/alternative; boundary=20cf307f37fc62d0d004a2a66945
Subject: [v6ops] new draft: draft-sunq-v6ops-contents-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: Sat, 07 May 2011 02:32:04 -0000

--20cf307f37fc62d0d004a2a66945
Content-Type: text/plain; charset=UTF-8

Dear All,

We have uploaded a new ID of NAT64 deployment model aiming to rapidly
increase the amount of IPv6 contents. In the current stage, lacking of IPv6
contents is one of the biggest problems for IPv6 industry chain and it is
difficult for the great many small-to-medium size content providers to
upgrade to IPv6 directly in a timely manner. As a result, we think this kind
of deployment model would be helpful to quickly enrich IPv6 contents. We
have deployed a prototype in Hunan province, China,  with three websites
connected and there are IPv6 users all around the world (including 6to4
users) accessing these contents via IPv6.

Please find it out from following url:
http://www.ietf.org/id/draft-sunq-v6ops-contents-transition-00.txt

We'd like to have your kind review, and comments.

Best wishes

Qiong SUN

--20cf307f37fc62d0d004a2a66945
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Dear All,

We have uploaded a new ID of NAT64 deployment model aiming=
 to   rapidly increase the amount of IPv6 contents. In the current stage, l=
acking of IPv6 contents is one of the biggest problems for IPv6 industry ch=
ain and it is difficult for the great many small-to-medium size content pro=
viders to upgrade to IPv6 directly in a timely manner. As a result, we thin=
k this kind of deployment model would be helpful to quickly enrich IPv6 con=
tents. We have deployed a prototype in Hunan province, China,=C2=A0 with th=
ree websites connected and there are IPv6 users all around the world (inclu=
ding 6to4 users) accessing these contents via IPv6.



Please find it out from following url:
http://www.ietf.org/id/draft-=
sunq-v6ops-contents-transition-00.txt


We'd like to have your kind review, and comments.

Best wishes
Qiong SUN




--20cf307f37fc62d0d004a2a66945--

From v6ops@globis.net  Sat May  7 02:17: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 DAE72E0698 for ; Sat,  7 May 2011 02:17:09 -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.400,  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 8CM-CZ32b+Dd for ; Sat,  7 May 2011 02:16:54 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id B4118E0692 for ; Sat,  7 May 2011 02:16:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AB9A98700D5; Sat,  7 May 2011 11:16:49 +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 kDE6ikMtqlbZ; Sat,  7 May 2011 11:16: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 536568700B2; Sat,  7 May 2011 11:16:42 +0200 (CEST)
Message-ID: <4DC50DEE.7040402@globis.net>
Date: Sat, 07 May 2011 11:16:30 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: "Templin, Fred L" 
References: <4DC44472.6080208@globis.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060107000403020800000202"
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] new draft: draft-templin-v6ops-isops-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, 07 May 2011 09:17:10 -0000

This is a multi-part message in MIME format.
--------------060107000403020800000202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for the reply. I appreciate it. Sounds like I've got a problem 
for every solution though. :(

Templin, Fred L wrote:
> Hi Ray,
>
>    
>> -----Original Message-----
>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]
>> On Behalf Of Ray Hunter
>> Sent: Friday, May 06, 2011 11:57 AM
>> To: v6ops@ietf.org WG
>> Subject: [v6ops] new draft: draft-templin-v6ops-isops-00.txt
>>
>> Excellent document. Really clear. Thanks very much.
>>      
>
> Thanks for taking the time to review and comment.
>
>    
>> I still have a few outstanding operational issues with ISATAP in a
>> commercial/ industrial environment that I'd greatly appreciate the
>> authors expending some brain cycles on:
>>
>> 1) to confirm that these issues are real
>> 2) whether there are any operational workarounds the v6ops
>> group can provide
>> 3) to come up with ideas for mitigation
>>
>> I beg your indulgence.
>>
>> After a fair bit of careful consideration, I have currently
>> come to the
>> conclusion that deploying ISATAP would probably be an epic fail if I
>> deployed it in my customers' networks, and it has to be 100% disabled
>> during the transition to native IPv6 (ironically enough as it
>> is meant
>> to be a transition mechanism). I suspect that deploying ISATAP in my
>> customer's environments would be "career shortening." This isn't a
>> flame. Just a statement of the way I see things at the
>> moment. Maybe I'm
>> wrong. But it would certainly be a risk. We're talking major
>> multinationals. Maybe these aren't typical customer environments or
>> target environments where ISATAP is intended to be deployed. Funnily
>> enough, IPv4 has also proven quite popular in these
>> environments too though.
>>      
>
> Wow - these seem like fairly strong sentiments. But,
> I appreciate that you have a serious obligation to
> your customers!
>
>    
They employ me because I keep on delivering. I'm only as good as my last 
project. I've successfully executed dis-entanglements and complex 
migrations of tens of thousands of users without any unplanned downtime. 
That requires control, advance planning, and most of all, predictability.

We're talking 10000+ users on 100+ sites in 20+ countries with 4 major 
outsource providers. And that's a mid-sized customer. Big ones are 100K 
users on 500+ sites in 50+ countries. All combinations are possible. 
There'll be both AAAA records and A records simultaneously. There'll be 
IPv4 only servers and dual stack servers simultaneously. There'll be 
every flavour of Windows you have ever heard of, and possibly even some 
you haven't. There'll be machines that are so ancient that they need to 
have the entire OS recompiled just to renumber the IPv4 address (so they 
won't be renumbering). I came across one PDP11 machine in a factory 
running DECnet phase III (yes III, not IV) There'll be some laptops that 
have migrated and some that haven't. There'll be broken 
implementations.  There'll be admins with limited IPv6 knowledge and 
experience. There'll be at least 2 major LAN switch vendors (one of 
which is now bankrupt). There'll be some site LANs that have migrated to 
dual stack and some that haven't. There'll be some firewalls that work 
well, and others that don't.

And above everything, there's the expectation in senior management that 
this will be a smooth migration (hey even the most recent IETF v6ops 
drafts are still claiming this.)

Nothing will be migrating in a big bang. So I think you get the idea 
that these are not homogeneous environments.
>> The issues all revolve around SLA's, and the preference of
>> ISATAP over
>> native IPv4, rather than any "broken connectivity" like 6to4.
>> The word
>> "latency" looms large.
>>      
>
> OK, but the preference only applies when there are
> AAAA records for the intended correspondent in the
> site name service. When there are only A records,
> then native IPv4 will be used.

Got that one. If there are only A records then they'll be used, because 
AAAA won't even be known to the address selection algorithm. Sounds 
obvious, and logical, However, an awful lot of systems are already 
registering IPv6 addresses automatically, even in an IPv4 only environment.

Also got the fact that global addresses are preferred over local 
addresses (due to scope = rule 2 from RC3484).

So IPv4 (global) is preferred over ISATAP using a link local derived 
address (local scope). Got that too.
> So, a simple solution
> is for the site administrator to simply not add any
> AAAA records to the site-internal name service for
> SLAAC-derived ISATAP addresses.
>
>    

This could be the key gap in my knowledge / incorrect assumption.
Thanks for identifying this.

This is homework for me to see what exactly gets registered automatically.

When looking at Microsoft's book Understanding IPv6 v2 page 219-221.

Here it shows 2 ISATAP addresses:
2001:db8:21a5:a499::5fe:157.60.17.211 (global ISATAP address, non 
deprecated state)
and
fe80::5fe:157.60.17.211 (link-local address, non deprecated state)

So I'm not afraid of the fe80:: address. It's got lower scope (local) 
than a public PI IPv4 (global)
This is unlikely to cause any harm. It appears safe if a node complies 
with RFC3484 or anything similar.

p221 then goes on to show how 2001:db8:21a5:a499::5fe:157.60.17.211 
*would* be preferred over 157.60.17.211

That's the case that really scares me. The native IPv4 connectivity is 
undoubtedly fully functional and in control.
But that automatic tunnel is very probably out of control, slow, 
possibly broken, but it's still preferred by default.

Sorry, but that does not sound at all logical to me.

The key questions for me are then
when would that 2001:db8:21a5:a499::5fe:157.60.17.211 address be 
generated by a server?
when and how would that SLAAC derived ISATAP address appear in a naming 
service (DNS WINS host files etc.)?

That's the two things I know I don't know right now.

Windows auto registers a lot of AAAA records for servers in the IPAM / 
DNS system automagically as part of Active Directory (a non IETF 
protocol) by default using DNS dynamic update. Active Directory requires 
DNS. There's a direct mapping between the AD tree and the DNS tree. You 
cannot decouple AD and DNS, or disable this function.

Windows servers register these AAAA records even over an IPv4 only 
transport.

Microsoft recommend that you do not disable IPv6 as part of server 2008, 
because IPv6 is used internally for clustering (non IETF protocol).

Windows 7 also quite happily resolves these AAAA records over an IPv4 
only transport, and all of those nodes will try to contact an ISATAP 
router as soon as "isatap" is resolvable (via DNS, WINS or whatever).

So I'm guessing / hoping that the Windows implementations are well 
behaved and do not auto register the SLAAC derived ISATAP addresses as 
per the RFC: but then again they have incorrectly turned on RA when 
"connection sharing" has been enabled, creating rogue RA advertisements 
on wireless networks. That's a good example of how to create an 
unplanned downtime for many users caused by a seemingly innocent action 
by one single admin.

OMG here it is .... page 282 of Microsoft's Understanding IPv6 2nd 
edition. Last sentence.

"By default, an ISATAP host running Windows Server 2008 or Windows Vista 
will attempt to register global and unique local addresses in DNS using 
DNS dynamic update"

That's the problem right there if it's true. Servers auto registering 
SLAAC-derived ISATAP addresses in DNS, whereas the RFC recommends not to 
do this unless.... That's what I need to check.

Your assumption that it took human intervention to register a SLAAC 
derived ISATAP address in DNS would seem to be incorrect (if that text 
is correct and I've read it correctly), and at first glance the Windows 
implementation of ISATAP would NOT appear to be compliant with the 
recommendation of not registering SLAAC-derived ISATAP addresses into 
DNS. [to be checked of course]

>> Firstly, I have a minor issue with the use of firewalls in commercial
>> environments (They are unavoidable. Sorry. Blame the accountants)
>>
>> In your draft you state that:
>>
>> ISATAP client to client communications should therefore also only be
>> used when the path between the clients is first tested in an initial
>> reachability exchange.
>>
>> I understand that this is functionality uses NUD after name
>> resolution
>> (Section 8.4 of RFC5214)
>>      
>
> I think you mean NUD after *address* resolution? The
> RFC says: "ISATAP hosts SHOULD perform an initial
> reachability confirmation by sending Neighbor
> Solicitation messages and receiving a Neighbor
> Advertisement message.". But, that does not prevent
> the hosts from performing an initial reachability
> confirmation via some other means, e.g., RS/RA,
> ICMP echo/reply, etc.
>
>    
sorry yes. my bad. Ah OK, but do they really do this today? My 
understanding was that implementations only detected reachability 
information of the ISATAP router. Is it recommended practice to always 
ICMP ping before starting a session?

What would that time out be (or is it implementation dependent)?
>> That means that IPv6 may fail after initially trying to
>> establish a session.
>>      
>
> The only time this would happen is when a pair
> of ISATAP clients attempt to communicate directly
> without sending their initial packets through an
> advertising ISATAP router. The draft is advocating
> that all initial communications go through an
> advertising ISATAP router, which may return
> redirection messages. When an ISATAP client
> receives the redirection messages, however, it
> does not need to heed them immediately. It could
> instead continue to send its packets via the
> advertising ISATAP router while testing the path
> to the peer ISATAP client in parallel. Maybe the
> draft could say this explicitly.
>
>    
I'm not sure I agree with your statement. These automatic tunnel 
mechanisms assume transparent and contiguous IPv4 and IPv6 clouds, with 
a single consistent crossing point between the two clouds.

Three letters and two words: "SOX compliance" & "outsourcing."

There are dozens, if not hundreds, of firewalls in most corporate 
environments. There is sometimes even a firewall per host for sensitive 
machines (like a database server).

All of these firewalls have different access rules and are managed by 
different groups. Sometimes they have thousands of rules each.

I don't think it is going to be safe to assume that all IPv6 nodes are 
available transparently to all ISATAP routers with the same access 
rules. That certainly isn't true for IPv4, so I see no reason why this 
would be true for IPv6. That means client to client connectivity can be 
highly irregular, but very predictable (you only get through if you've 
been authorized, but two machines next door to each other may have very 
different access)

Especially when different management groups / sites/ suppliers may be 
migrating at different times.

The ISATAP router may be on site A, the laptop of the traveling user on 
the customer's design-in project located on Site B, the DNS server on 
site C, and the server machines that the user is trying to access on 
site D, E, F & G (engineering simulation server, outsourced project 
management service server, cloud computing code repository, and home 
file server).

These sites could be hundreds of kilometers/miles apart and are very 
likely to be under different management regimes.

Both the IPv4 and (more than likely) the IPv6 clouds are anything but 
transparent and contiguous.

During transition it is definitely going to be a complete nightmare to 
synchronise all firewall rules for IPv4, native IPv6, and IPv6 over 
ISATAP/6to4/Teredo over IPv4 (especially given the awful support for 
IPv6 in firewalls, but I'm whining again)

That firewall rules synchronization problem could be a reason to kill 
ISATAP on its own. Just so that the firewall rules are native IPv4 and 
native IPv6 only. That takes away at least half of the additional effort 
of rule synchronization.

I don't know of any firewall implementation that allows you to properly 
filter and maintain control of IPv6 over ISATAP over IPv4. They have 
enough problems switching native IPv6 fast enough without performing 
deep packet inspection on tunnels. Which means you could lose control of 
connectivity over network security zone boundaries, which is a certain 
no-no.
[this is almost certainly a showstopper for deploying ISATAP in any sort 
of useful manner, but at least it means it's less harmful]
>> Can you give me any guidance to how quickly NUD will fail
>> when detecting
>> unreachable hosts behind firewalls over ISATAP (presumably
>> with a host
>> unreachable) and then fallback to IPv4 ?
>>      
>
> According to the draft recommendations, direct
> peer-to-peer comms would only be enabled after
> the path between the peers has been tested. Again,
> this can be done in parallel with continuing to
> send packets via an advertising ISATAP router,
> hence ordinary data packets would not be subject
> to loss.
>
> The host unreachable is a nice optimization,
> but if it is not generated nor dropped due to
> filtering then it can't be counted on. You may
> have better knowledge on this point than I do;
> in well-managed sites, is it reasonable to
> expect that ICMPs will be delivered by the
> network without loss due to filtering?
>
>    
They'll  almost certainly be filtered by stateful firewalls. Those 
accountants have a lot to answer for.
>> The issue is that even though the fallback is safe, it will
>> probably not
>> result in happy eyeballs (addressed elsewhere I guess) because the
>> damage has already be done due to the initial connection delay.
>>      
>
> Again, this comes down to whether AAAA records
> should be entered into the site-internal name
> service in the first place. For SLAAC-derived
> ISATAP addresses, the draft says no.
>
>    
OK. That's very clear to me. Thanks. This is a key focus area. 
Unfortunately DNS content is generally not under the same control as the 
network transport provider in any multinational I know of. So to talk 
about a single "site admin" is pretty meaningless. There's a LAN admin, 
a workstation admin, a server admin, an engineering server admin, a DNS 
admin, a WAN admin .... and most are located off site and outsourced.


>> Secondly, I see no links to any documents warning of the dangers of
>> automatic tunnels.[e.g. rfc6169]
>>
>> I think a link would be useful.
>>      
>
> OK.
>
>    
>> Again, it's the auditors. They don't seem to like it if someone can
>> automatically tunnel into the finance data centre and blind
>> side their
>> firewall audit logging. Firewall support for native IPv6 and
>> IPv6 over
>> IPv4 is poor at the moment. Sorry, that was a whine. Let's move on.
>>      
>
> OK.
>
>    
>> Thirdly, I see no way to have common QoS mechanisms properly handle
>> ISATAP encapsulated traffic.
>>
>> Apparently QoS isn't that important a topic on the Public
>> Internet yet
>> (although I suspect it will become so as more people download
>> video over
>> wireless to their mobile devices)
>>
>> Many corporations have spent significant amounts of money
>> implementing
>> WAN acceleration, packet shaping etc. (more fool them you
>> might say, as
>> many of the devices are not IPv6 aware).
>>
>> Many corporations have also implemented IETF derived mechanisms like
>> DSCP based WRED (based on RFC 2597).
>>
>> Is there any guidance to vendors that they should support
>> detection of
>> IPv4 DSCP markings within an IPv6 ISATAP tunnel?
>> or whether/how these IPv4 DSCP bits should be made visible outside of
>> the ISATAP encapsulation so that they can be acted upon by
>> intermediate
>> devices?
>>      
>
> Well, this is an interesting point. RFC5214 is
> silent on the subject, and RFC4213 says: "Type
> of Service: 0 unless otherwise specified.". But,
> when I look at the Linux source code I see it
> doing both DSCP and ECN mapping between inner
> and outer headers - I guess that would be in
> keeping with RFCs 2983 and 3168?
>    
As I say, the engineering guys start to get twitchy at anything >35mS 
(and that's between sites 800Km / 500 miles apart in different countries).

There are at least 2 different MPLS clouds so I'd have to check which 
each carrier offers which facilities.
Some companies have 4 or 5 separate MPLS clouds.

I know one of them certainly does NOT support NBAR (network based 
application recognition) matching.

Fortunately the match commands within the backbone "match DSCP" act on 
both IPv4 and IPv6 traffic, so that those do not need updating.

RFC 2983 seems to be IPv4 only. But I guess the Linux boys interpreted 
IP liberally as IPv4 or IPv6. Creative thinking.

Mapping sounded promising at first reading, but not for too long I'm 
afraid now I think about it more deeply.

The current DSCP classifiers act at the edge of the wide area network 
and are pretty basic. They generally act on a match of IPv4 source + 
IPv4 destination address + source port + destination port number + 
protocol (you know the usual 5 tuple suspects), or they allow a whole 
VLAN to set the EF bit for voice traffic for hard VoIP phones.

These classifier ACL's can be easily updated to include similar matches 
for native IPv6 protocols. No worries there.

They will almost certainly never be able to look inside a tunnel like 
ISATAP. It's way too heavy an operation for a CPE router.

I think this is beginning to sound tough, as the customers are unlikely 
to want to accept the DSCP markings from the end node. They've always 
done the DSCP marking in the WAN ingress routers / CPE. The classifiers 
generally over-write any existing DSCP bits set in the end node to 
prevent theft of service. It's going to mean a policy change to accept 
DSCP settings from end nodes.

Not only that, but the end node does not usually have a clue what the 
correct/appropriate QoS policy settings are in the first place. So you 
usually end up with defaults like EF for voice transport, but not much 
more than that.

Also each wide area network supplier generally has their own local 
configuration standard of what each DSCP marking means.....

One may use AF41 marking for video, and another AF41 for class 1 
traffic, which then translate into carrier-specific traffic engineering 
rules in their MPLS backbones, which are common for all customers, so 
these cannot be fiddled with.

So unless we can roll out a company specific classifying scheme to every 
single ISATAP node (= every workstation) that says ISATAP should mark 
traffic from Node X to Node Y as DSCP AF31, but with a default AF21 
(when connected in China) but to use AF41 and AF21 (when the laptop is 
outside of China).....

I not sure this sounds like it will fly in any sort of a manageable way.

So I guess anyone in my customers who wants QoS just has to avoid 
ISATAP. End of story.

I can certainly communicate that in advance. At least it might prevent 
people experimenting and being disappointed with IPv6.

>> Otherwise all of the companies' QoS policies get blown out of
>> the water
>> as soon as ISATAP kicks in (and by default it does kick in on many
>> popular operating systems, as confirmed in a customer's environment.)
>>
>> QoS and differential services is a cornerstone of many SLA's.
>>
>>
>>
>> Fourthly, many of my customers have strict SLA's for latency. The
>> presumption of ISATAP would still seem to be that tunneled
>> connectivity
>> is fine, and that any additional latency to the nearest
>> gateway router
>> is not operationally significant.
>>
>> Given that in a large multinational corporation there may be
>> inter-continental hops involved to reach an ISATAP router,
>> compared to a
>> typical engineering requirement of<50mS round trip delay within a
>> country for accelerated X windows applications, is there any
>> mechanism
>> to detect and/or limit the additional latency to the ISATAP
>> router, over
>> and above the basic test for connectivity?
>>      
>
> Well, yes. The site could put an IPv4 anycast
> address as the lone address in the PRL. Then,
> ISATAP clients will find the advertising ISATAP
> router that is topologically closest. All the
> site needs to do then is deploy sufficiently
> distributed advertising ISATAP routers.
>
>    
Sites do not manage their own LANs. That's ancient history. The 
outsourcer could put in an anycast address and an ISATAP router. But at 
a fee. And if it isn't in their standard service, that's going to be a 
big fee. Multiply that by 500 sites.

Sounds once again like a single step to native IPv6 is going to be the 
correct migration route.
>> This is complicated by the fact that so many of these executive types
>> seem to insist on flying around the World and taking their
>> laptops with
>> them, rather than video conferencing over IP from their own
>> desk. They
>> also like to work from home, or on their customers' premises.
>> I keep on
>> telling them about speed of light limitations and to move the sites
>> closer together, but they won't listen.
>>      
>
> Agreed that moving the sites closer together
> would be a useful but miraculous feat. For
> example, asking everyone in the southwest region
> to relocate to the northeast would be a recipe
> for failure (not that I have anything against
> the northeast).
>
>    
Oh intra-continental would be easy, we're talking moving continents. 
Engineers collaborating in India and Europe, factory in China.
>> I'm guessing the answer will be "no" on the existence of a built-in
>> ISATAP latency reduction/optimization mechanism. Such a
>> mechanism could
>> theoretically detect the round trip latency to a number of candidate
>> ISATAP routers in the prl and then select the "closest" as
>> part of the
>> initial ISATAP router selection mechanism. Perhaps something
>> to consider
>> recommending to vendors as a future enhancement? Possibly with a
>> configurable upper limit on the acceptable latency before
>> declaring the
>> router unusable?
>>      
>
> The two options are to either manage the name
> service entries so that there are "regional"
> PRL names (e.g., northeast.example.com,
> southwest.example.com, etc.) and put regionally
> localized unicast IPv4 addresses in each PRL
> name. Or, simply put an IPv4 anycast address
> in the PRL and let IPv4 routing steer ISATAP
> clients to the closest advertising ISATAP
> router.
>
>    
OK understood. Might just be workable, but that might be too expensive. 
We'll have to investigate that thanks.

>> Since the list of candidate ISATAP routers in the prl is
>> fetched via DNS
>> in many implementations, I guess my clients could implement some
>> mitigation by setting the DNS server via DHCP based on location, and
>> then serving different answers for isatap.foobar.com. However
>> a lot of
>> corporations have centralised their DNS servers via IPAM tooling, so
>> there's only one per region nowadays, so that may or may not fly
>> depending on the tooling. We're back to geographically aware
>> DNS services.
>>      
>
> Or geographically-relative FQDNs as noted
> above. Or simply place an IPv4 anycast
> address in the PRL.
>
>    
Right, but then we almost certainly lose the ability to debug 
meaningfully (see 6to4 discussion on anycast). The helpdesk is not 
located on site any more and has to debug remotely.
>> But even then, they'd probably have to deploy an ISATAP
>> router per site
>> (several hundred sites) which may not all be rolled out at the same
>> time. By the time you've done that, rolling out native IPv6
>> on multiple
>> MPLS networks doesn't look so bad after all.
>>      
>
> I think this would very much depend on how the
> site is organized. Surely, each partition within
> the site needs to have a border router that can
> reach the Internet. If that border router were
> to become an advertising ISATAP router, then
> the partition has a way of using ISATAP.
>
>    
There are multiple outsourcers and LAN providers in any multinational.

Sites are generally much more complicated than you'd imagine you could 
possibly make them. I sometimes think people do this on purpose just to 
make my life interesting. Some are flat LANs. Some are campus networks 
shared among multiple companies. Campus networks are managed by the 
campus IT provider and not by the company: then there's a demarc hand 
over point into the corporate WAN. Campus / research sites mostly 
already have native IPv6 anyway.

Some physical sites house researchers, sales staff, engineering staff, 
high-security engineering staff (with their own firewalls), 
manufacturing, and third party engineers from a previous merger or 
de-merger, all on the same site. Some of them have multiple firewalls 
within the sites. Some of these sites have a firewall at the site egress 
(between the site router and the WAN router). Some don't.  Some of the 
data centres run their own internal MPLS networks, shared amongst 
multiple customers. Many sites don't have any local servers any more 
(file servers centralised per region)

So yes there is generally a main site site egress router at the WAN 
entry point, but there is often a debate about security and feature support.

So it's going to be very much on a case by case basis, and you can't 
talk about a "typical site."

The WAN CPE router is generally where it all comes together. Again if 
the WAN outsourcer decides to offer ISATAP as part of their standard 
service then maybe we'll get lucky. But that WAN router is also outside 
any site firewall so end users may be vey reluctant to use it. 
Considering the WAN suppliers relutance to turn on native IPv6, I 
suspect it will be an uphill/ expensive battle to get them to support an 
ISATAP router on that device too.

>> I'm not expecting ISATAP to be perfect, so please don't take this as
>> whining, but I would like to avoid it breaking anything by default.
>>
>> Now the main two showstoppers in common implementations:
>>
>> a. by default, ISATAP is enabled
>>      
>
> Yes.
>
>    
>> Is there any plan to request vendors disable ISATAP by default?
>>      
>
> No.
>
>    
ah. That's where I have a problem. Default behavior for automatic 
tunneling should just be "off". Plain and simple IMVHO.

The default end node behavior should not be dependent on assumptions 
like if X and Y then do W, but if Z then do V, but only if A and B, 
unless .... but that's the way it is today. And RFC 3484 isn't even 
widely implemented apparently, so who knows how many implementations 
really behave and whether they've been tested in a particular 
combination of environments?

The default behavior should remain understandable to mere mortals, and 
it should always remain predictable throughout the migration. I submit 
that "Automatic tunneling = off" is both simple and predictable as a 
default.

If people want to consciously enable ISATAP, then fine make that easy. 
But make it so that they have to consciously touch each and every node 
in some way (AD policy setting, local config file, click here to enable 
whatever), and not so that the behavior of 10000+ nodes can be changed 
dramatically en masse and in an opaque way just because of a simple 
mistake or experiment in DNS by one administrator on the other side of 
the globe.

One shouldn't second guess the machine admin unless one is certain that 
it will not cause them problems, because the protocol designers and 
implementers have no way of checking whether the assumptions that were 
made when designing or implementing the protocol match the real 
assumptions and requirements in the actual deployment.

With all due respect, (and taking into account your email address), I'm 
sure that aircraft aren't designed with complex default behavior that 
may kick in unexpectedly dependent on external factors. Satellites are 
built the same way: if all else goes wrong, they go into "safe mode". 
IMVHO We should also design and specify protocols with simple, 
predictable, and safe-mode default behavior.
>> b. also by default, IPv6 over ISATAP over IPv4 appears to be
>> preferred
>> over native IPv4.
>>      
>
> That's not a problem as long as the ISATAP clients
> only need to access IPv6 services that are outside
> of the site and/or as long as site administrators
> only place AAAA records within the site name service
> for IPv6-only correspondents.
>
>
>    
See above for the quote from Microsoft and auto registration [again to 
be confirmed].
>> If I want to use ISATAP at all, at the moment I expect it'll
>> always be
>> preferred over native IPv4 if I prefer native IPv6 over native IPv4
>> (default).
>>
>> Can I prefer native IPv6 above native IPv4 above IPv6 over
>> ISATAP over IPv4?
>>      
>
> There is not really a way to distinguish IPv6
> prefixes used for ISATAP from any other native
> IPv6 prefixes unless there were some sort of
> distributed configuration files maintained.
> However, the draft advocates that no ISATAP
> addresses derived from SLAAC be entered into
> AAAA records within the site name service.
>
>    
Exactly what I thought. The nodes currently pretty much universally use 
PI IPv4 addresses even internally (which of course confuses the 
assumption made for Teredo that everyone uses RFC1918 addresses on their 
LANs) These assumptions made in the design of the transition mechanisms 
are killing in all sorts of practical scenarios.

No matter what else you do, it's good practice to prefer native 
protocols over automatic tunneling as a default, unless this has been 
overruled by a conscious action by the machine administrator. RFC3484 
bis has finally come to that conclusion for 6to4 and Teredo.

The node administrator should be able to specify (and override) the 
default preference selection behavior for ISATAP SLAAC (global) and 
link-local (local) derived addresses compared to IPv4, but he can't as 
there's not tool or switch to do this.

I'd really like to change the prioritization of these global SLAAC 
derived ISATAP addresses (which are also automatic tunnels) to be less 
preferred than native IPv4 (for a warm safety feeling and to protect 
from rogue DNS admins) but I can't.

So that leaves the option of disabling ISATAP completely in all nodes.
>> Because ISATAP is based on a well-known node prefix (last 64
>> bits of an
>> IPv6 address, and not well-known IPv6 prefixes (left anchored front
>> portion of an IPv6 address), and it provides IPv6 connectivity using
>> standard IPv6 prefixes, even after implementing RFC3484 bis,
>> I know of
>> no mechanism where a network administrator of a network with
>> well-managed native IPv4 connectivity can prefer native IPv6 above
>> native IPv4, but also prefer native IPv4 above ISATAP during
>> a migration.
>>
>> Is there any other operational way to achieve this?
>>      
>
> Simply don't put SLAAC-derived ISATAP addresses
> in AAAA records in the site name service, as
> discussed in the draft.
>
>    
Yeah, and as I said you have potentially rogue DNS admins (you always 
have these, but one record could derail an awful lot) and potentially 
rogue implementations (again you have little protection here from bad 
programmers) but at least you could put in place multiple lines of defense.

I'm finding it's very difficult to override default policies and 
settings for the IPv6 transition mechanisms if I don't like them, or 
they don't fit my customers' operational requirements. And defaults 
should be just that: a default. Certainly not mandated or difficult to 
override behavior. Again, we should apply the principle of "the local 
node admin knows best."
>> Because if there isn't, the only options left over are to prefer
>> corporate native IPv4 above all IPv6 (ouch, and not default
>> today), or
>> to disable ISATAP completely on all nodes (ouch, a
>> potentially herculean
>> task, because ISATAP is enabled by default today).
>>
>> None of which is very satisfactory.
>>
>> Thanks for reading this far.
>>      
>
> I hope this response has helped?
>
> Thanks - Fred
> fred.l.templin@boeing.com
>
>    
>> regards,
>> RayH
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>      

It certainly helped clarify an awful lot, and I appreciate you taking 
the time to look at my questions, but I still don't have workable 
solutions for:
1) managing security of ISATAP automatic tunnels between network 
security zones (and every multinational has these, but it's outside the 
scope of your document),
2) setting correct QoS at a new point in the network (at an end node 
tunnel) (and many multinationals use DSCP),
3) really being able to mange latency introduced by tunneling (apart 
from via DNS content, which is not under the direct control of the 
network transport guys)
4) protecting against the odd rogue/incompetent DNS admin. (and I have 
seen them)
5) being able to set and manage default behavior and protocol preference 
settings with the granularity I need, which is a real concern. Relying 
on DNS content is not an acceptable solution for this IMHO.
6) there's still that question about Windows specific behavior and 
whether it registers SLAAC derived IPv6 addresses automatically in DNS 
by default (which would be a broken implementation)

On the flip side I perceive little or no benefit in having ISATAP 
enabled in the environments I work in. It just doesn't really feel 
scalable or manageable in a long and dynamic transition. There's just 
too many cross-functional / cross departmental / cross supplier 
dependencies. This is a personal opinion. Others working in more 
homogeneous, more geographically limited, less security paranoid, 
environments may come to a very different conclusion, and think it's a 
blessing.

The strategy to go forward would appear to be a one step to native IPv6 
on the end nodes.

That means employing transition mechanisms like GRE, 6in4, 6PE, and 
perhaps 6RD.

But in any case, solutions where native IPv6 goes in one end, and native 
IPv6 comes out the other end at a predictable location, managed by the 
network transport people, without anything in the middle or periphery 
being able to mess around with it.

So in conclusion, I still think the only sensible option at this time is 
to disable ISATAP completely in all end nodes. That's horrible I know, 
and a lot of work, and IMHO should be the default. This isn't just a 
knee jerk reaction. It's just the best least worst option IMHO.

regards,


--------------060107000403020800000202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Thanks for the reply. I appreciate it. Sounds like I've got a problem
for every solution though. :(



Templin, Fred L wrote:


  
Hi Ray, 

  

  

    
-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] 
On Behalf Of Ray Hunter
Sent: Friday, May 06, 2011 11:57 AM
To: v6ops@ietf.org WG
Subject: [v6ops] new draft: draft-templin-v6ops-isops-00.txt

Excellent document. Really clear. Thanks very much.
    

  

  

Thanks for taking the time to review and comment.

  

  

    
I still have a few outstanding operational issues with ISATAP in a 
commercial/ industrial environment that I'd greatly appreciate the 
authors expending some brain cycles on:

1) to confirm that these issues are real
2) whether there are any operational workarounds the v6ops 
group can provide
3) to come up with ideas for mitigation

I beg your indulgence.

After a fair bit of careful consideration, I have currently 
come to the 
conclusion that deploying ISATAP would probably be an epic fail if I 
deployed it in my customers' networks, and it has to be 100% disabled 
during the transition to native IPv6 (ironically enough as it 
is meant 
to be a transition mechanism). I suspect that deploying ISATAP in my 
customer's environments would be "career shortening." This isn't a 
flame. Just a statement of the way I see things at the 
moment. Maybe I'm 
wrong. But it would certainly be a risk. We're talking major 
multinationals. Maybe these aren't typical customer environments or 
target environments where ISATAP is intended to be deployed. Funnily 
enough, IPv4 has also proven quite popular in these 
environments too though.
    

  

  

Wow - these seem like fairly strong sentiments. But,
I appreciate that you have a serious obligation to
your customers!

  



They employ me because I keep on delivering. I'm only as good as my
last project. I've successfully executed dis-entanglements and complex
migrations of tens of thousands of users without any unplanned
downtime. That requires control, advance planning, and most of all,
predictability.



We're talking 10000+ users on 100+ sites in 20+ countries with 4 major
outsource
providers. And that's a mid-sized customer. Big ones are 100K users on
500+ sites in 50+ countries. All combinations are possible. There'll be
both AAAA records and A records simultaneously. There'll be IPv4 only
servers and dual stack servers simultaneously. There'll be every
flavour of Windows you have ever heard of, and possibly even some you
haven't. There'll be machines that are so ancient that they need to
have the entire OS recompiled just to renumber the IPv4 address (so
they won't
be renumbering). I came across one PDP11 machine in a factory running
DECnet
phase III (yes III, not IV) There'll be some laptops that have migrated
and some that haven't. There'll be broken implementations.  There'll be
admins with limited IPv6 knowledge and experience. There'll be at least
2 major LAN switch vendors
(one of which is now bankrupt). There'll be some site LANs that have
migrated to dual stack and some that haven't. There'll be some
firewalls that work well, and others that don't.



And above everything, there's the expectation in senior management that
this will be a smooth migration (hey even the most recent IETF v6ops
drafts are still claiming this.)



Nothing will be migrating in a big bang. So I think you get the idea
that these are not homogeneous environments.



  

  

    
The issues all revolve around SLA's, and the preference of 
ISATAP over 
native IPv4, rather than any "broken connectivity" like 6to4. 
The word 
"latency" looms large.
    

  

  

OK, but the preference only applies when there are
AAAA records for the intended correspondent in the
site name service. When there are only A records,
then native IPv4 will be used. 





Got that one. If there are only A records then they'll be used, because
AAAA won't even be known to the address selection algorithm. Sounds
obvious, and logical, However, an awful lot of systems are already
registering IPv6 addresses automatically, even in an IPv4 only
environment.



Also got the fact that global addresses are preferred over local
addresses (due to scope = rule 2 from RC3484).



So IPv4 (global) is preferred over ISATAP using a link local derived
address (local scope). Got that too.



  
So, a simple solution
is for the site administrator to simply not add any
AAAA records to the site-internal name service for
SLAAC-derived ISATAP addresses.

  





This could be the key gap in my knowledge / incorrect assumption.

Thanks for identifying this.



This is homework for me to see what exactly gets registered
automatically.



When looking at Microsoft's book Understanding IPv6 v2 page 219-221.



Here it shows 2 ISATAP addresses:

2001:db8:21a5:a499::5fe:157.60.17.211 (global ISATAP address, non
deprecated state)

and

fe80::5fe:157.60.17.211 (link-local address, non deprecated state)



So I'm not afraid of the fe80:: address. It's got lower scope (local)
than a public PI IPv4 (global)

This is unlikely to cause any harm. It appears safe if a node complies
with RFC3484 or anything similar.



p221 then goes on to show how 2001:db8:21a5:a499::5fe:157.60.17.211
*would* be preferred over 157.60.17.211



That's the case that really scares me. The native IPv4 connectivity is
undoubtedly fully functional and in control.

But that automatic tunnel is very probably out of control, slow,
possibly broken, but it's still preferred by default.



Sorry, but that does not sound at all logical to me.



The key questions for me are then

when would that 2001:db8:21a5:a499::5fe:157.60.17.211 address be
generated by a server?

when and how would that SLAAC derived ISATAP address appear in a naming
service (DNS WINS host files etc.)?



That's the two things I know I don't know right now.



Windows auto registers a lot of AAAA records for servers in the IPAM /
DNS system automagically as part of Active Directory (a non IETF
protocol) by default using DNS dynamic update. Active Directory
requires DNS. There's a direct mapping between the AD tree and the DNS
tree. You cannot decouple AD and DNS, or disable this function.



Windows servers register these AAAA records even over an IPv4 only
transport. 



Microsoft recommend that you do not disable IPv6 as part of server
2008, because IPv6 is used internally for clustering (non IETF
protocol).



Windows 7 also quite happily resolves these AAAA records
over an IPv4 only transport, and all of those nodes will try to contact
an ISATAP router as soon as "isatap" is resolvable (via DNS, WINS or
whatever).



So I'm guessing / hoping that the Windows implementations are well
behaved and do not auto register the SLAAC derived ISATAP addresses as
per the RFC: but then again they have incorrectly turned on RA when
"connection sharing" has been enabled, creating rogue RA advertisements
on wireless networks. That's a good example of how to create an
unplanned downtime for many users caused by a seemingly innocent action
by one single admin.



OMG here it is .... page 282 of Microsoft's Understanding IPv6 2nd
edition. Last sentence.



"By default, an ISATAP host running Windows Server 2008 or Windows
Vista will attempt to register global and unique local addresses in DNS
using DNS dynamic update"



That's the problem right there if it's true. Servers auto registering
SLAAC-derived ISATAP addresses in DNS, whereas the RFC recommends not
to do this unless.... That's what I need to check.



Your assumption that it took human intervention to register a SLAAC
derived ISATAP address in DNS would seem to be incorrect (if that text
is correct and I've read it correctly), and at first glance the Windows
implementation of ISATAP would NOT appear to be compliant with the
recommendation of not registering SLAAC-derived ISATAP addresses into
DNS. [to be checked of course]





  

  

    
Firstly, I have a minor issue with the use of firewalls in commercial 
environments (They are unavoidable. Sorry. Blame the accountants)

In your draft you state that:

ISATAP client to client communications should therefore also only be 
used when the path between the clients is first tested in an initial 
reachability exchange.

I understand that this is functionality uses NUD after name 
resolution 
(Section 8.4 of RFC5214)
    

  

  

I think you mean NUD after *address* resolution? The
RFC says: "ISATAP hosts SHOULD perform an initial
reachability confirmation by sending Neighbor
Solicitation messages and receiving a Neighbor
Advertisement message.". But, that does not prevent
the hosts from performing an initial reachability
confirmation via some other means, e.g., RS/RA,
ICMP echo/reply, etc.

  



sorry yes. my bad. Ah OK, but do they really do this today? My
understanding was that implementations only detected reachability
information of the ISATAP router. Is it recommended practice to always
ICMP ping before starting a session?



What would that time out be (or is it implementation dependent)?



  

  

    
That means that IPv6 may fail after initially trying to 
establish a session.
    

  

  

The only time this would happen is when a pair
of ISATAP clients attempt to communicate directly
without sending their initial packets through an
advertising ISATAP router. The draft is advocating
that all initial communications go through an
advertising ISATAP router, which may return
redirection messages. When an ISATAP client
receives the redirection messages, however, it
does not need to heed them immediately. It could
instead continue to send its packets via the
advertising ISATAP router while testing the path
to the peer ISATAP client in parallel. Maybe the
draft could say this explicitly.

  



I'm not sure I agree with your statement. These automatic tunnel
mechanisms assume transparent and contiguous IPv4 and IPv6 clouds, with
a single consistent crossing point between the two clouds.



Three letters and two words: "SOX compliance" & "outsourcing."



There are dozens, if not hundreds, of firewalls in most corporate
environments. There is sometimes even a firewall per host for sensitive
machines (like a database server).



All of these firewalls have different access rules and are managed by
different groups. Sometimes they have thousands of rules each.



I don't think it is going to be safe to assume that all IPv6 nodes are
available transparently to all ISATAP routers with the same access
rules. That certainly isn't true for IPv4, so I see no reason why this
would be true for IPv6. That means client to client connectivity can be
highly irregular, but very predictable (you only get through if you've
been authorized, but two machines next door to each other may have very
different access)



Especially when different management groups / sites/ suppliers may be
migrating at different times.



The ISATAP router may be on site A, the laptop of the traveling user on
the customer's design-in project located on Site B, the DNS server on
site C, and the server machines that the user is trying to access on
site D, E, F & G (engineering simulation server, outsourced project
management service server, cloud computing code repository, and home
file server).



These sites could be hundreds of kilometers/miles apart and are very
likely to be under different management regimes.



Both the IPv4 and (more than likely) the IPv6 clouds are anything but
transparent and contiguous. 



During transition it is definitely going to be a complete nightmare to
synchronise all firewall rules for IPv4, native IPv6, and IPv6 over
ISATAP/6to4/Teredo over IPv4 (especially given the awful support for
IPv6 in firewalls, but I'm whining again)



That firewall rules synchronization problem could be a reason to kill
ISATAP on its own. Just so that the firewall rules are native IPv4 and
native IPv6 only. That takes away at least half of the additional
effort of rule synchronization.



I don't know of any firewall implementation that allows you to properly
filter and maintain control of IPv6 over ISATAP over IPv4. They have
enough problems switching native IPv6 fast enough without performing
deep packet inspection on tunnels. Which means you could lose control
of connectivity over network security zone boundaries, which is a
certain no-no.

[this is almost certainly a showstopper for deploying ISATAP in any
sort of useful manner, but at least it means it's less harmful]



  

  

    
Can you give me any guidance to how quickly NUD will fail 
when detecting 
unreachable hosts behind firewalls over ISATAP (presumably 
with a host 
unreachable) and then fallback to IPv4 ?
    

  

  

According to the draft recommendations, direct
peer-to-peer comms would only be enabled after
the path between the peers has been tested. Again,
this can be done in parallel with continuing to
send packets via an advertising ISATAP router,
hence ordinary data packets would not be subject
to loss.

The host unreachable is a nice optimization,
but if it is not generated nor dropped due to
filtering then it can't be counted on. You may
have better knowledge on this point than I do;
in well-managed sites, is it reasonable to
expect that ICMPs will be delivered by the
network without loss due to filtering? 

  



They'll  almost certainly be filtered by stateful firewalls. Those
accountants have a lot to answer for.



  

  

    
The issue is that even though the fallback is safe, it will 
probably not 
result in happy eyeballs (addressed elsewhere I guess) because the 
damage has already be done due to the initial connection delay.
    

  

  

Again, this comes down to whether AAAA records
should be entered into the site-internal name
service in the first place. For SLAAC-derived
ISATAP addresses, the draft says no.

  



OK. That's very clear to me. Thanks. This is a key focus area.
Unfortunately DNS content is generally not under the same control as
the network transport provider in any multinational I know of. So to
talk about a single "site admin" is pretty meaningless. There's a LAN
admin, a workstation admin, a server admin, an engineering server
admin, a DNS admin, a WAN admin .... and most are located off site and
outsourced.







  

  

    
Secondly, I see no links to any documents warning of the dangers of 
automatic tunnels.[e.g. rfc6169]

I think a link would be useful.
    

  

  

OK.

  

  

    
Again, it's the auditors. They don't seem to like it if someone can 
automatically tunnel into the finance data centre and blind 
side their 
firewall audit logging. Firewall support for native IPv6 and 
IPv6 over 
IPv4 is poor at the moment. Sorry, that was a whine. Let's move on.
    

  

  

OK.
 
  

  

    
Thirdly, I see no way to have common QoS mechanisms properly handle 
ISATAP encapsulated traffic.

Apparently QoS isn't that important a topic on the Public 
Internet yet 
(although I suspect it will become so as more people download 
video over 
wireless to their mobile devices)

Many corporations have spent significant amounts of money 
implementing 
WAN acceleration, packet shaping etc. (more fool them you 
might say, as 
many of the devices are not IPv6 aware).

Many corporations have also implemented IETF derived mechanisms like 
DSCP based WRED (based on RFC 2597).

Is there any guidance to vendors that they should support 
detection of 
IPv4 DSCP markings within an IPv6 ISATAP tunnel?
or whether/how these IPv4 DSCP bits should be made visible outside of 
the ISATAP encapsulation so that they can be acted upon by 
intermediate 
devices?
    

  

  

Well, this is an interesting point. RFC5214 is
silent on the subject, and RFC4213 says: "Type
of Service: 0 unless otherwise specified.". But,
when I look at the Linux source code I see it
doing both DSCP and ECN mapping between inner
and outer headers - I guess that would be in
keeping with RFCs 2983 and 3168?
  



As I say, the engineering guys start to get twitchy at anything
>35mS (and that's between sites 800Km / 500 miles apart in different
countries).



There are at least 2 different MPLS clouds so I'd have to check which
each carrier offers which facilities.

Some companies have 4 or 5 separate MPLS clouds.



I know one of them certainly does NOT support NBAR (network based
application recognition) matching.



Fortunately the match commands within the backbone "match DSCP" act on
both IPv4 and IPv6 traffic, so that those do not need updating.



RFC 2983 seems to be IPv4 only. But I guess the Linux boys interpreted
IP liberally as IPv4 or IPv6. Creative thinking.



Mapping sounded promising at first reading, but not for too long I'm
afraid now I think about it more deeply. 



The current DSCP classifiers act at the edge of the wide area network
and are pretty basic. They generally act on a match of IPv4 source +
IPv4 destination address + source port + destination port number +
protocol (you know the usual 5 tuple suspects), or they allow a whole
VLAN to set the EF bit for voice traffic for hard VoIP phones.



These classifier ACL's can be easily updated to include similar matches
for native IPv6 protocols. No worries there.



They will almost certainly never be able to look inside a tunnel like
ISATAP. It's way too heavy an operation for a CPE router.



I think this is beginning to sound tough, as the customers are unlikely
to want to accept the DSCP markings from the end node. They've
always done the DSCP marking in the WAN ingress routers / CPE. The
classifiers generally over-write any existing DSCP bits set in the end
node to prevent theft of service. It's going to mean a policy change to
accept DSCP settings from end nodes.



Not only that, but the end node does not usually have a clue what the
correct/appropriate QoS policy settings are in the first place. So you
usually end up with defaults like EF for voice transport, but not much
more than that.



Also each wide area network supplier generally has their own local
configuration standard of what each DSCP marking means.....



One may use AF41 marking for video, and another AF41 for class 1
traffic, which then translate into carrier-specific traffic engineering
rules in their MPLS backbones, which are common for all customers, so
these cannot be fiddled with.



So unless we can roll out a company specific classifying scheme to
every single ISATAP node (= every workstation) that says ISATAP should
mark traffic from Node X to Node Y as DSCP AF31, but with a default
AF21 (when connected in China) but to use AF41 and AF21 (when the
laptop is outside of China).....



I not sure this sounds like it will fly in any sort of a manageable way.



So I guess anyone in my customers who wants QoS just has to avoid
ISATAP. End of story.



I can certainly communicate that in advance. At least it might prevent
people experimenting and being disappointed with IPv6.





  

    
Otherwise all of the companies' QoS policies get blown out of 
the water 
as soon as ISATAP kicks in (and by default it does kick in on many 
popular operating systems, as confirmed in a customer's environment.)

QoS and differential services is a cornerstone of many SLA's.



Fourthly, many of my customers have strict SLA's for latency. The 
presumption of ISATAP would still seem to be that tunneled 
connectivity 
is fine, and that any additional latency to the nearest 
gateway router 
is not operationally significant.

Given that in a large multinational corporation there may be 
inter-continental hops involved to reach an ISATAP router, 
compared to a 
typical engineering requirement of <50mS round trip delay within a 
country for accelerated X windows applications, is there any 
mechanism 
to detect and/or limit the additional latency to the ISATAP 
router, over 
and above the basic test for connectivity?
    

  

  

Well, yes. The site could put an IPv4 anycast
address as the lone address in the PRL. Then,
ISATAP clients will find the advertising ISATAP
router that is topologically closest. All the
site needs to do then is deploy sufficiently
distributed advertising ISATAP routers.

  



Sites do not manage their own LANs. That's ancient history. The
outsourcer could put in an anycast address and an ISATAP router. But at
a fee. And if it isn't in their standard service, that's going to be a
big fee. Multiply that by 500 sites. 



Sounds once again like a single step to native IPv6 is going to be the
correct migration route.



  

  

    
This is complicated by the fact that so many of these executive types 
seem to insist on flying around the World and taking their 
laptops with 
them, rather than video conferencing over IP from their own 
desk. They 
also like to work from home, or on their customers' premises. 
I keep on 
telling them about speed of light limitations and to move the sites 
closer together, but they won't listen.
    

  

  

Agreed that moving the sites closer together
would be a useful but miraculous feat. For
example, asking everyone in the southwest region
to relocate to the northeast would be a recipe
for failure (not that I have anything against
the northeast).

  



Oh intra-continental would be easy, we're talking moving continents.
Engineers collaborating in India and Europe, factory in China.



  

  

    
I'm guessing the answer will be "no" on the existence of a built-in 
ISATAP latency reduction/optimization mechanism. Such a 
mechanism could 
theoretically detect the round trip latency to a number of candidate 
ISATAP routers in the prl and then select the "closest" as 
part of the 
initial ISATAP router selection mechanism. Perhaps something 
to consider 
recommending to vendors as a future enhancement? Possibly with a 
configurable upper limit on the acceptable latency before 
declaring the 
router unusable?
    

  

  

The two options are to either manage the name
service entries so that there are "regional"
PRL names (e.g., northeast.example.com,
southwest.example.com, etc.) and put regionally
localized unicast IPv4 addresses in each PRL
name. Or, simply put an IPv4 anycast address
in the PRL and let IPv4 routing steer ISATAP
clients to the closest advertising ISATAP
router.

  



OK understood. Might just be workable, but that might be too expensive.
We'll have to investigate that thanks.





  

  

    
Since the list of candidate ISATAP routers in the prl is 
fetched via DNS 
in many implementations, I guess my clients could implement some 
mitigation by setting the DNS server via DHCP based on location, and 
then serving different answers for isatap.foobar.com. However 
a lot of 
corporations have centralised their DNS servers via IPAM tooling, so 
there's only one per region nowadays, so that may or may not fly 
depending on the tooling. We're back to geographically aware 
DNS services.
    

  

  

Or geographically-relative FQDNs as noted
above. Or simply place an IPv4 anycast
address in the PRL.

  



Right, but then we almost certainly lose the ability to debug
meaningfully (see 6to4 discussion on anycast). The helpdesk is not
located on site any more and has to debug remotely.



  

  

    
But even then, they'd probably have to deploy an ISATAP 
router per site 
(several hundred sites) which may not all be rolled out at the same 
time. By the time you've done that, rolling out native IPv6 
on multiple 
MPLS networks doesn't look so bad after all.
    

  

  

I think this would very much depend on how the
site is organized. Surely, each partition within
the site needs to have a border router that can
reach the Internet. If that border router were
to become an advertising ISATAP router, then
the partition has a way of using ISATAP.

  



There are multiple outsourcers and LAN providers in any multinational.



Sites are generally much more complicated than you'd imagine you could
possibly make them. I sometimes think people do this on purpose just to
make my life interesting. Some are flat LANs. Some are campus networks
shared among multiple companies. Campus networks are managed by the
campus IT provider and not by the company: then there's a demarc hand
over point into the corporate WAN. Campus / research sites mostly
already have native IPv6 anyway.



Some physical sites house researchers, sales staff, engineering staff,
high-security engineering staff (with their own firewalls),
manufacturing, and third party engineers from a previous merger or
de-merger, all on the same site. Some of them have multiple firewalls
within the sites. Some of these sites have a firewall at the site
egress (between the site router and the WAN router). Some don't.  Some
of the data centres run their own internal MPLS networks, shared
amongst multiple customers. Many sites don't have any local servers any
more (file servers centralised per region)



So yes there is generally a main site site egress router at the WAN
entry point, but there is often a debate about security and feature
support.



So it's going to be very much on a case by case basis, and you can't
talk about a "typical site."



The WAN CPE router is generally where it all comes together. Again if
the WAN outsourcer decides to offer ISATAP as part of their standard
service then maybe we'll get lucky. But that WAN router is also outside
any site firewall so end users may be vey reluctant to use it.
Considering the WAN suppliers relutance to turn on native IPv6, I
suspect it will be an uphill/ expensive battle to get them to support
an ISATAP router on that device too.





  

  

    
I'm not expecting ISATAP to be perfect, so please don't take this as 
whining, but I would like to avoid it breaking anything by default.

Now the main two showstoppers in common implementations:

a. by default, ISATAP is enabled
    

  

  

Yes.

  

  

    
Is there any plan to request vendors disable ISATAP by default?
    

  

  

No.

  



ah. That's where I have a problem. Default behavior for automatic
tunneling should just be "off". Plain and simple IMVHO.



The default end node behavior should not be dependent on assumptions
like if X and Y then do W, but if Z then do V, but only if A and B,
unless .... but that's the way it is today. And RFC 3484 isn't even
widely implemented apparently, so who knows how many implementations
really behave and whether they've been tested in a particular
combination of environments?



The default behavior should remain understandable to mere mortals, and
it should always remain predictable throughout the migration. I submit
that "Automatic tunneling = off" is both simple and predictable as a
default.



If people want to consciously enable ISATAP, then fine make that easy.
But make it so that they have to consciously touch each and every node
in some way (AD policy setting, local config file, click here to enable
whatever), and not so that the behavior of 10000+ nodes can be changed
dramatically en masse and in an opaque way just because of a simple
mistake or experiment in DNS by one administrator on the other side of
the globe.



One shouldn't second guess the machine admin unless one is certain that
it will not cause them problems, because the protocol designers and
implementers have no way of checking whether the assumptions that were
made when designing or implementing the protocol match the real
assumptions and requirements in the actual deployment.



With all due respect, (and taking into account your email address), I'm
sure that aircraft aren't designed with complex default behavior that
may kick in unexpectedly dependent on external factors. Satellites are
built the same way: if all else goes wrong, they go into "safe mode".
IMVHO We should also design and specify protocols with simple,
predictable, and safe-mode default behavior.



  

  

    
b. also by default, IPv6 over ISATAP over IPv4 appears to be 
preferred 
over native IPv4.
    

  

  

That's not a problem as long as the ISATAP clients
only need to access IPv6 services that are outside
of the site and/or as long as site administrators
only place AAAA records within the site name service
for IPv6-only correspondents.
 

  



See above for the quote from Microsoft and auto registration [again to
be confirmed].



  

  

    
If I want to use ISATAP at all, at the moment I expect it'll 
always be 
preferred over native IPv4 if I prefer native IPv6 over native IPv4 
(default).

Can I prefer native IPv6 above native IPv4 above IPv6 over 
ISATAP over IPv4?
    

  

  

There is not really a way to distinguish IPv6
prefixes used for ISATAP from any other native
IPv6 prefixes unless there were some sort of
distributed configuration files maintained.
However, the draft advocates that no ISATAP
addresses derived from SLAAC be entered into
AAAA records within the site name service.

  



Exactly what I thought. The nodes currently pretty much universally use
PI IPv4 addresses even internally (which of course confuses the
assumption made for Teredo that everyone uses RFC1918 addresses on
their LANs) These assumptions made in the design of the transition
mechanisms are killing in all sorts of practical scenarios.



No matter what else you do, it's good practice to prefer native
protocols over automatic tunneling as a default, unless this has been
overruled by a conscious action by the machine administrator. RFC3484
bis has finally come to that conclusion for 6to4 and Teredo.



The node administrator should be able to specify (and override) the
default preference selection behavior for ISATAP SLAAC (global) and
link-local (local) derived addresses compared to IPv4, but he can't as
there's not tool or switch to do this.



I'd really like to change the prioritization of these global SLAAC
derived ISATAP addresses (which are also automatic tunnels) to be less
preferred than native IPv4 (for a warm safety feeling and to protect
from rogue DNS admins) but I can't.



So that leaves the option of disabling ISATAP completely in all nodes.



  

  

    
Because ISATAP is based on a well-known node prefix (last 64 
bits of an 
IPv6 address, and not well-known IPv6 prefixes (left anchored front 
portion of an IPv6 address), and it provides IPv6 connectivity using 
standard IPv6 prefixes, even after implementing RFC3484 bis,  
I know of 
no mechanism where a network administrator of a network with 
well-managed native IPv4 connectivity can prefer native IPv6 above 
native IPv4, but also prefer native IPv4 above ISATAP during 
a migration.

Is there any other operational way to achieve this?
    

  

  

Simply don't put SLAAC-derived ISATAP addresses
in AAAA records in the site name service, as
discussed in the draft.

  



Yeah, and as I said you have potentially rogue DNS admins (you always
have these, but one record could derail an awful lot) and potentially
rogue implementations (again you have little protection here from bad
programmers) but at least you could put in place multiple lines of
defense.



I'm finding it's very difficult to override default policies and
settings for the IPv6 transition mechanisms if I don't like them, or
they don't fit my customers' operational requirements. And defaults
should be just that: a default. Certainly not mandated or difficult to
override behavior. Again, we should apply the principle of "the local
node admin knows best."



  

  

    
Because if there isn't, the only options left over are to prefer 
corporate native IPv4 above all IPv6 (ouch, and not default 
today), or 
to disable ISATAP completely on all nodes (ouch, a 
potentially herculean 
task, because ISATAP is enabled by default today).

None of which is very satisfactory.

Thanks for reading this far.
    

  

  

I hope this response has helped?

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

  

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

  





It certainly helped clarify an awful lot, and I appreciate you taking
the time to look at my questions, but I still don't have workable
solutions for:

1) managing security of ISATAP automatic tunnels between network
security zones (and every multinational has these, but it's outside the
scope of your document),

2) setting correct QoS at a new point in the network (at an end node
tunnel) (and many multinationals use DSCP),

3) really being able to mange latency introduced by tunneling (apart
from via DNS content, which is not under the direct control of the
network transport guys)

4) protecting against the odd rogue/incompetent DNS admin. (and I have
seen them)

5) being able to set and manage default behavior and protocol
preference settings with the granularity I need, which is a real
concern. Relying on DNS content is not an acceptable solution for this
IMHO.

6) there's still that question about Windows specific behavior and
whether it registers SLAAC derived IPv6 addresses automatically in DNS
by default (which would be a broken implementation)



On the flip side I perceive little or no benefit in having ISATAP
enabled in the environments I work in. It just doesn't really feel
scalable or manageable in a long and dynamic transition. There's just
too many cross-functional / cross departmental / cross supplier
dependencies. This is a personal opinion. Others working in more
homogeneous, more
geographically limited, less security paranoid, environments may come
to
a very different conclusion, and think it's a blessing.



The strategy to go forward would appear to be a one step to native IPv6
on the end nodes.



That means employing transition mechanisms like GRE, 6in4, 6PE, and
perhaps 6RD. 



But in any case, solutions where native IPv6 goes in one end, and
native IPv6 comes out the other end at a predictable location, managed
by the network transport people, without anything in the middle or
periphery being able to mess around with it.



So in conclusion, I still think the only sensible option at this time
is to disable ISATAP completely in all end nodes. That's horrible I
know, and a lot of work, and IMHO should be the default. This isn't
just a knee jerk reaction. It's just the best least worst option IMHO.



regards,






--------------060107000403020800000202--

From rogerj@gmail.com  Sat May  7 03:01: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 39283E0659 for ; Sat,  7 May 2011 03:01:59 -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=[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 lY65DF45Sfu7 for ; Sat,  7 May 2011 03:01:58 -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 3A398E0651 for ; Sat,  7 May 2011 03:01:57 -0700 (PDT)
Received: by wwa36 with SMTP id 36so2940934wwa.13 for ; Sat, 07 May 2011 03:01:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iCsgR5R4OXD4q52ZupQSpGbmW66u7g2npH04AE+OtLM=; b=t6r6vaoKuF4MqabF6UP7A7mnLQKLq5tc5UqEwetw5SdTllMWNNoEXABAWt2/1yMQEc MTQFoiFTBnvLD1a62GlnZjs0/3KXu2vSnTz+v6+tvEK4g6K7eowU9k0dnGG86RaLPT6p Fog35AciQrhZcRKpl3FJHWhNuNYkhrAEFuujA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sgLlQxS4J0h3R3gPxEJNOMvO2dtcRB3p7cVihyVywNUftJyKUMO8n2U3CSd5SVJQNr DDslPx4nyHeqEEOkeM5vpWUEZbeLO7BOESTU/rBY0l03CeuMtZb54J+2Q/6rzuMK8aND e5aJhqH4mBlofGKi87bdz+Zpkdx8EfgIGjOpo=
MIME-Version: 1.0
Received: by 10.227.198.10 with SMTP id em10mr3546919wbb.108.1304762515288; Sat, 07 May 2011 03:01:55 -0700 (PDT)
Received: by 10.227.146.208 with HTTP; Sat, 7 May 2011 03:01:55 -0700 (PDT)
In-Reply-To: 
References: <4DC29A96.6020709@globis.net>  <20110506005809.C526CE848C9@drugs.dv.isc.org> 
Date: Sat, 7 May 2011 12:01:55 +0200
Message-ID: 
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: Erik Kline , "v6ops@ietf.org WG" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 07 May 2011 10:01:59 -0000

On Fri, May 6, 2011 at 9:10 AM, Erik Kline  wrote:
>>> The whitelisting is indeed designed to avoid the problems and allow
>>> IPv6 to be more broadly served to those who are properly able to make
>>> use of it.
>>
>> And there are plenty that can use IPv6 but can't get AAAA records
>> due to whitelisting.
>
> I look forward to seeing your data that backs up this assertion.

I can guess there are quite some with decent IPv6 connectivity but their
ISP is not whitelisted.  The reason is probably (my guess) that the ISP
haven't yet got around to, or used resources on being whitelisted...

My home network happen to be one of these cases, my ISP has a fairly
good IPv6 network but no whitelisting for their resolvers.
Im so lucky to have my own NS servers and they happen to be in a
netblock (ipv4/ipv6) that happen to be whitelisted... only problem I've had
was some MTU issue that only affected loading of youtube video, after
adjusting MTU on the LAN side everything worked great:)


(that I might have to do tweaks, MTU or others, on my side is one downside
of IPv6 at the current stage all over really)

--=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 May  7 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 87221E06CE for ; Sat,  7 May 2011 06:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.547
X-Spam-Level: 
X-Spam-Status: No, score=-109.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=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 Kh5YJ7J8AcdN for ; Sat,  7 May 2011 06:55:01 -0700 (PDT)
Received: from sj-iport-3.cisco.com (unknown [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id CFE54E0651 for ; Sat,  7 May 2011 06:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=138; q=dns/txt; s=iport; t=1304776501; x=1305986101; h=date:from:message-id:to:subject:cc; bh=VQI1ksWEjcsg/lb3dUQh4l2hmhz2EIZ4McwS3pZ/U3w=; b=mdo1AmMJ/u3qY/Uyhk/Z1Q8q29q0Aik7vAcMZ84f5tVCSkqkf2QbX2+i HbY2OYnCtN5jsoQa4YkYenyhAZy1/pOSAS5ZhEPJMcXZ2pUck/ShoNdF7 P68lO/lXuMy40YV2YdAY6dU5lxXQ7WTNH8mTOzy/LiDGOmNfTjX7caNnJ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak0HAB5OxU2rRDoJ/2dsb2JhbACYMQEBjXJ3p02dOoYMBIZAmCI
X-IronPort-AV: E=Sophos;i="4.64,331,1301875200"; d="scan'208";a="310574673"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 07 May 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 p47Dt1lU014938; Sat, 7 May 2011 13:55:01 GMT
Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p47Dt1517380; Sat, 7 May 2011 06:55:01 -0700 (PDT)
Date: Sat, 7 May 2011 06:55:01 -0700 (PDT)
From: 
Message-Id: <201105071355.p47Dt1517380@ftpeng-update.cisco.com>
To: v6ops@ietf.org
Cc: draft-sunq-v6ops-contents-transition@tools.ietf.org
Subject: [v6ops] new draft: draft-sunq-v6ops-contents-transition-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, 07 May 2011 13:55:02 -0000

A new draft has been posted, at http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition. Please take a look at it and comment.

From ek@google.com  Sat May  7 11:08: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 CF0F7E0715 for ; Sat,  7 May 2011 11:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.652
X-Spam-Level: 
X-Spam-Status: No, score=-105.652 tagged_above=-999 required=5 tests=[AWL=-0.275, 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 6wpjSZ7xy22i for ; Sat,  7 May 2011 11:08: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 BD456E0713 for ; Sat,  7 May 2011 11:08:36 -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 p47I8Ykk012019 for ; Sat, 7 May 2011 11:08:34 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304791715; bh=KsPPJNTN6ppmjm31jOj7IszLuYg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=jyQH28XeDhfwtybh4ct6v/9G/mJn37/pSnBHd/TUpJ1+I5Eo+dMuszZqhBrHp9qCU glA1WvT3HEvmvhj53PTaw==
Received: from pxi10 (pxi10.prod.google.com [10.243.27.10]) by hpaq11.eem.corp.google.com with ESMTP id p47I8WO1022184 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 7 May 2011 11:08:33 -0700
Received: by pxi10 with SMTP id 10so2997183pxi.22 for ; Sat, 07 May 2011 11:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fVhvCmoNpkmyOkM32vd6pNHl7edvNtW9C344tD1JpLs=; b=sdgx9pC8agE8NQ9iWzwsvpD74YEoG4XmwAubH32y5ly9/Cp5Z+Ucx4yTM9Mec6S0NT dRg6ZHJzEmB9bo/kCGBA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=utwOpZex2N9UNwCpeTgqml7+4dk/cjEcD6yV4nJDiHAr6nOsK+CycNChQJ6R4hpn4P vDiF5JEIlYF2X9aGnvgQ==
MIME-Version: 1.0
Received: by 10.142.250.2 with SMTP id x2mr2608355wfh.381.1304791711595; Sat, 07 May 2011 11:08:31 -0700 (PDT)
Received: by 10.142.245.14 with HTTP; Sat, 7 May 2011 11:08:31 -0700 (PDT)
In-Reply-To: <201105071355.p47Dt1517380@ftpeng-update.cisco.com>
References: <201105071355.p47Dt1517380@ftpeng-update.cisco.com>
Date: Sat, 7 May 2011 20:08:31 +0200
Message-ID: 
From: Erik Kline 
To: fred@cisco.com
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
Cc: v6ops@ietf.org, draft-sunq-v6ops-contents-transition@tools.ietf.org
Subject: Re: [v6ops] new draft: draft-sunq-v6ops-contents-transition-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, 07 May 2011 18:08:37 -0000

Can there be some discussion of MTU-mismatch and implications?

On 7 May 2011 15:55,   wrote:
>
> A new draft has been posted, at http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition. Please take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

From v6ops@globis.net  Sat May  7 13:08: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 BFF86E0737 for ; Sat,  7 May 2011 13:08:20 -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 lEGnFWzkcNn8 for ; Sat,  7 May 2011 13:08:19 -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 28894E0735 for ; Sat,  7 May 2011 13:08:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 35EF68700D9; Sat,  7 May 2011 22:08:17 +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 33-eCtyPvfei; Sat,  7 May 2011 22:08:11 +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 27DA1870061; Sat,  7 May 2011 22:08:11 +0200 (CEST)
Message-ID: <4DC5A69D.1040700@globis.net>
Date: Sat, 07 May 2011 22:07:57 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: "Templin, Fred L" 
References: <4DC44472.6080208@globis.net>  <4DC50DEE.7040402@globis.net>
In-Reply-To: <4DC50DEE.7040402@globis.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] new draft: draft-templin-v6ops-isops-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, 07 May 2011 20:08:20 -0000

Ray Hunter wrote:
> It certainly helped clarify an awful lot, and I appreciate you taking 
> the time to look at my questions, but I still don't have workable 
> solutions for:
> 1) managing security of ISATAP automatic tunnels between network 
> security zones (and every multinational has these, but it's outside 
> the scope of your document),
> 2) setting correct QoS at a new point in the network (at an end node 
> tunnel) (and many multinationals use DSCP),
> 3) really being able to mange latency introduced by tunneling (apart 
> from via DNS content, which is not under the direct control of the 
> network transport guys)
> 4) protecting against the odd rogue/incompetent DNS admin. (and I have 
> seen them)
> 5) being able to set and manage default behavior and protocol 
> preference settings with the granularity I need, which is a real 
> concern. Relying on DNS content is not an acceptable solution for this 
> IMHO.
> 6) there's still that question about Windows specific behavior and 
> whether it registers SLAAC derived IPv6 addresses automatically in DNS 
> by default (which would be a broken implementation)

I have worked out what I think is a workable and scalable answer to one 
of the problems anyway. It probably won't help me to be honest, but I 
think it may be useful for others to know who have less challenges. 
Maybe you could include this in a section on "Avoiding Excessive Latency 
to ISATAP routers"


so for

Problem 3) really being able to mange latency introduced by tunneling 
(apart from via DNS content, which may not be under the direct control 
of the transport network manager)


The "normal" suggested way of controlling which ISATAP client connects 
to which ISATAP router in a large organization network would be via 
controlling DNS content distribution, so users on site X would connect 
to isatap.sitex.example.com, whilst users on site Y would connect to 
isatap.sitey.example.com.

This creates a dependency between correct management of the content of 
DNS and the routing of traffic through the transport network.

Another alternative would be to deploy anycast addresses, so that the 
ISATAP client would connect to the nearest "local" ISATAP router. Use of 
anycast can also bring operational and debugging issues, which may not 
be desirable.

Yet another alternative is to use geographically aware DNS services to 
provide different answers for the list of routers to place in the plr 
list, dependent on the location of the ISATAP client. Geographically 
aware DNS can be complex to implement.

A related problem is the deployment of rogue ISATAP routers in the 
network, which may suffer from long-latency especially in international 
networks.

The optimal management of DNS content is thus not always practical in 
all cases. Although the management of the DNS server itself might be 
under tight central control of the group responsible for managing the 
transport network, the management of the DNS content may be distributed 
to separate entities and managed via IPAM tooling, including 
configuration of individual name and address records by less experienced 
or knowledgeable LAN and host managers. Some AAAA and A records may also 
be entered into DNS automatically (e.g. Windows Active Directory DNS 
dynamic updates). The DNS tree may not be subdivided by site. Use of 
geographically aware DNS services, or anycast addresses may not be 
desirable. Or there may be a large proportion of traveling users who 
move between sites.

All of the above may lead to inefficiencies, additional latency, and 
trombone-ing (where traffic travels from one site to an ISATAP router 
located on remote site via an ISATAP tunnel, before returning as native 
IPv6 to a third site) Trombone-ing would likely be particularly harmful 
in large international organizations, where there is generally 
significant base network latency due to speed of light limitations.

All of which leaves the transport network manager with the potential 
problem of how to control ISATAP client to router latency independently 
of DNS / plr content.


from http://tools.ietf.org/html/draft-templin-v6ops-isops-00#page-14

In order to avoid communication failures that may result from filtering, 
ISATAP clients (i.e., hosts and non-advertising routers) should only 
enable the service after an initial reachability exchange with an 
advertising ISATAP router (e.g., in an initial RS/RA exchange).

The ISATAP service should always check for connectivity before selecting 
one of the ISATAP routers from the plr list and enabling the service, 
and this is a one off action at start up, providing another potential 
and workable control mechanism.

Therefore a possible solution for the case where the transport network 
is separately managed from the DNS content, would be to intentionally 
disrupt the communication process during ISATAP service start up to 
disable ISATAP clients connecting to ISATAP routers with too high 
latency, or to off site ISATAP routers which have not been authorized 
for use by central management (partial rogue ISATAP router prevention).

There are two convenient locations where these additional traffic 
filters could be placed in typical corporate networks.

i) As an addition to the site egress filter / WAN ingress filter

Many corporations already deploy a WAN ingress filter to prevent IPv4 
spoofing, or to provide some base-level security via packet filtering.

The filter typically only allows traffic to enter the WAN that has 
source addresses from the ranges delegated to the site, and thus blocks 
all spoofed addresses, and other odd packets.

The existing WAN ingress filter could be extended to only allow protocol 
41 traffic to a cluster of "locally" located sites, some of which may be 
hosting ISATAP routers, some of which may be hosting ISATAP clients, 
whilst filtering all other protocol 41 traffic.

i.e. allow protocol 41 traffic from the local site address ranges to the 
address ranges associated with the cluster of sites hosting ISATAP 
routers and ISATAP clients that are connected to the network within an 
acceptable network latency distance of each other, whilst denying all 
other protocol 41 traffic.

This filter definition assumes that the 6to4 transition mechanism has 
not been deployed, because 6to4 also runs over protocol 41 tunnels. It 
also assumes that the filters are centrally coordinated so that clients 
on other sites will still be able to contact each other directly within 
the cluster via protocol 41 traffic for intra-subnet ISATAP traffic, as 
well as other native IPv6 hosts via the ISATAP router.

ii) as an egress filter on the LAN router hosting the ISATAP router, or 
as an ingress filter on the inbound LAN interface of the ISATAP router 
itself.

The filter here would only allow protocol 41 traffic to the ISATAP 
router from client IPv4 ranges delegated to sites that are connected 
within an acceptable network latency away from the ISATAP router. Native 
IPv6 traffic would be allowed from the ISATAP router to all IPv6 ranges. 
All other protocol 41 traffic would be blocked.

The appropriate choice of whether to deploy one or other or both filters 
would probably be made based on convenience and cost considerations 
(cost of changing WAN ingress filters, versus a dedicated filter in 
front of each ISATAP router). It should be noted that the WAN ingress 
filter is perhaps better placed to protect users from any rogue (and 
high latency) ISATAP routers in the network located on sites that are 
outside of the cluster.

So then, no matter how many ISATAP routers are seeded into the plr list, 
and no matter what their geographic location relative to the ISATAP 
clients, only ISATAP routers within acceptable latency, and located on 
sites which have been authorized for use, will be reachable during the 
initial reachability exchange, thus helping to reduce unintentional long 
hop latency or trombone-ing in the network.

[thanks to Fred Templin for the draft and explanation, ans John Mann 
(ITS) for the mail that helped turn the light on]

regards,
RayH

From v6ops@globis.net  Sat May  7 13:26: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 99F4AE06E2 for ; Sat,  7 May 2011 13:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.015
X-Spam-Level: 
X-Spam-Status: No, score=-3.015 tagged_above=-999 required=5 tests=[AWL=0.584,  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 QrUdkiELmYvF for ; Sat,  7 May 2011 13:26:19 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id C8B77E0698 for ; Sat,  7 May 2011 13:26:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 93F168700D9; Sat,  7 May 2011 22:26:15 +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 ASX1LYPDerhC; Sat,  7 May 2011 22:26:10 +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 46118870061; Sat,  7 May 2011 22:26:10 +0200 (CEST)
Message-ID: <4DC5AAD5.8060700@globis.net>
Date: Sat, 07 May 2011 22:25:57 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: "Templin, Fred L" 
References: <4DC44472.6080208@globis.net>  <4DC50DEE.7040402@globis.net> <4DC5A69D.1040700@globis.net>
In-Reply-To: <4DC5A69D.1040700@globis.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] new draft: draft-templin-v6ops-isops-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, 07 May 2011 20:26:20 -0000

Ray Hunter wrote:
> Ray Hunter wrote:
>> It certainly helped clarify an awful lot, and I appreciate you taking 
>> the time to look at my questions, but I still don't have workable 
>> solutions for:
>> 1) managing security of ISATAP automatic tunnels between network 
>> security zones (and every multinational has these, but it's outside 
>> the scope of your document),
>> 2) setting correct QoS at a new point in the network (at an end node 
>> tunnel) (and many multinationals use DSCP),
>> 3) really being able to mange latency introduced by tunneling (apart 
>> from via DNS content, which is not under the direct control of the 
>> network transport guys)
>> 4) protecting against the odd rogue/incompetent DNS admin. (and I 
>> have seen them)
>> 5) being able to set and manage default behavior and protocol 
>> preference settings with the granularity I need, which is a real 
>> concern. Relying on DNS content is not an acceptable solution for 
>> this IMHO.
>> 6) there's still that question about Windows specific behavior and 
>> whether it registers SLAAC derived IPv6 addresses automatically in 
>> DNS by default (which would be a broken implementation) 
>
> I have worked out what I think is a workable and scalable answer to 
> one of the problems anyway. It probably won't help me to be honest, 
> but I think it may be useful for others to know who have less 
> challenges. Maybe you could include this in a section on "Avoiding 
> Excessive Latency to ISATAP routers"
>
>
> so for
>
> Problem 3) really being able to mange latency introduced by tunneling 
> (apart from via DNS content, which may not be under the direct control 
> of the transport network manager)
>
>
By the way. A far simpler solution, and shorter text. However it does 
require new code.

Avoidance of Excessive latency:

In order to avoid introducing excessive latency, ISATAP clients (i.e., 
hosts and non-advertising routers) should only enable the service after 
an initial check of network latency to the advertising ISATAP router 
(e.g. via an initial RS/RA exchange or ICMPv6 ping).

ISATAP client to client communications may also test the path between 
the clients in an initial exchange to check for acceptable latency.






From bingxuere@gmail.com  Sat May  7 23:25: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 9724EE06E0 for ; Sat,  7 May 2011 23:25:06 -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 X9fCuXUwPhFl for ; Sat,  7 May 2011 23:25:05 -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 B8977E0662 for ; Sat,  7 May 2011 23:25:05 -0700 (PDT)
Received: by vxg33 with SMTP id 33so5756326vxg.31 for ; Sat, 07 May 2011 23:25:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=0bq4gmaQOI9nwWzUgci9BQHU+ZX7jFxIAVdv5xTn2Gs=; b=h7Cr22UDZchgtaRv8yTl9F7xU3aaxR/meCi+ywgYDwpuUuvELwMzaQhp8f1oCDJN2E y2430L8Cc2PVF976+KGm2Z61xRTGOokHlEyaKwd9rMcB/tAfVwbbkRF4M6nPcKgDG1KN cALNP4g6j1YTzXU/kod0HB0iWKfXk1kNe/9fU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=U1idJCab4WrQOGiYHqDJaOKeCrBR2t6AE3UsxkWvNgbCiu40XKWdVmg+IEtRlNLw7+ MjRaIYV1g3gbpLECYFjzvNEXDqXa9hnEj/qBCnXGYY3qVUEXv4mubR20p8Uki8Ojw8zC KqD0iGYdgfE+odK/m7BWE9etlzhgbTaTMQGbo=
MIME-Version: 1.0
Received: by 10.52.180.169 with SMTP id dp9mr853300vdc.134.1304835905140; Sat, 07 May 2011 23:25:05 -0700 (PDT)
Received: by 10.52.170.41 with HTTP; Sat, 7 May 2011 23:25:05 -0700 (PDT)
Date: Sun, 8 May 2011 14:25:05 +0800
Message-ID: 
From: Qiong 
To: ek@google.com, v6ops@ietf.org
Content-Type: multipart/alternative; boundary=bcaec5101c739db8e904a2bdc840
Subject: Re: [v6ops] new draft: draft-sunq-v6ops-contents-transition-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, 08 May 2011 06:25:06 -0000

--bcaec5101c739db8e904a2bdc840
Content-Type: text/plain; charset=UTF-8

Dear Erik,

In this deployment, packet fragmentation and reassembly might take place due
to the IPv4/IPv6 packet-length mismatch and MTU-mismatch. So, a fragmented
IPv4/IPv6 packet should be firstly reassembled to an integrated packet, and
then the NAT64 box will do IPv4/IPv6 packet translation, MTU discovery, and
packet fragmentation if necessary.

Is it  enough for your question?

Best wishes

Qiong SUN

From: Erik Kline 
To: fred@cisco.com
Date: Sat, 7 May 2011 20:08:31 +0200
Subject: Re: [v6ops] new draft: draft-sunq-v6ops-contents-transition-00.txt
Can there be some discussion of MTU-mismatch and implications?

On 7 May 2011 15:55,   wrote:
>
> A new draft has been posted, at
http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition. Please take
a look at it and comment.
> ______________________________
_________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--bcaec5101c739db8e904a2bdc840
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Dear Erik,

In this deployment, packet fragmentation and reassembly m=
ight take place due to the IPv4/IPv6 packet-length mismatch and MTU-mismatc=
h. So, a fragmented IPv4/IPv6 packet should be firstly reassembled to an in=
tegrated packet, and then the NAT64 box will do IPv4/IPv6 packet translatio=
n, MTU discovery, and packet fragmentation if necessary. 


Is it=C2=A0 enough for your question?

Best wishes

Qiong S=
UN =C2=A0 =C2=A0 

From:=C2=A0Erik Kline <ek@google.com>
To:=C2=A0fred@cisco.com
Date:=C2=A0Sat, 7 May 2011 20:08:31 +0200

Subject:=C2=A0Re: [v6ops] new draft: draft-sunq-v6ops-contents-transition-0=
0.txt
Can there be some discussion of MTU-mismatch and implications?



On 7 May 2011 15:55, =C2=A0<fred@cisco=
.com> wrote:

>

> A new draft has been posted, at http://tools.ietf.o=
rg/html/draft-sunq-v6ops-contents-transition. Please take a look at it =
and comment.


> ______________________________
_________________

> v6ops mailing list

> v6ops@ietf.org

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

>


--bcaec5101c739db8e904a2bdc840--

From randy@psg.com  Sun May  8 02: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 DC222E0681 for ; Sun,  8 May 2011 02:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.408
X-Spam-Level: 
X-Spam-Status: No, score=-5.408 tagged_above=-999 required=5 tests=[AWL=1.191,  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 6mr1oR+oK4Xy for ; Sun,  8 May 2011 02:21:02 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 63D3AE065A for ; Sun,  8 May 2011 02:21:02 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.home.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QIzse-0004wy-IC; Sun, 08 May 2011 09:02:24 +0000
Date: Sun, 08 May 2011 11:03:56 +0200
Message-ID: 
From: Randy Bush 
To: Qiong 
In-Reply-To: 
References: 
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
Subject: Re: [v6ops] new draft: draft-sunq-v6ops-contents-transition-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, 08 May 2011 09:21:03 -0000

> In this deployment, packet fragmentation and reassembly might take
> place due to the IPv4/IPv6 packet-length mismatch and MTU-mismatch.
> So, a fragmented IPv4/IPv6 packet should be firstly reassembled to an
> integrated packet, and then the NAT64 box will do IPv4/IPv6 packet
> translation, MTU discovery, and packet fragmentation if necessary.

i think erik meant in the document, please

randy

From fred@cisco.com  Sun May  8 06:51: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 DA632E0783 for ; Sun,  8 May 2011 06:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.486
X-Spam-Level: 
X-Spam-Status: No, score=-109.486 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=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 NXAh+FVhgwMU for ; Sun,  8 May 2011 06:51:48 -0700 (PDT)
Received: from sj-iport-2.cisco.com (unknown [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id EFA03E0771 for ; Sun,  8 May 2011 06:51:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2067; q=dns/txt; s=iport; t=1304862707; x=1306072307; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=VerHBFhiMs8UZEtlm/khplGc4rqaGMe1FU3oOJ2DFXc=; b=YmwOyiG8iSO2JSjn7+CcS0uuX2n3+hnwSbfvfWvnC5/IKNZVTjJ+39ws ArDbmTCtUtj4jRahdC5MvYxbTnt+Bzt5UustPyyFuV3FEGp5FRECoHm/B IwWbt86ghKeIxI8VdJ3MfrNSn8lb5JCiBCzb2Pe8k2JvMlN0oSok7duuW Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEACOfxk2rRDoH/2dsb2JhbACmGHeIcZ8OnQSGDASGQIklhCiKVQ
X-IronPort-AV: E=Sophos;i="4.64,334,1301875200"; d="scan'208";a="352690089"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 08 May 2011 13:51:47 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p48DpfoL014487; Sun, 8 May 2011 13:51:47 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Sun, 08 May 2011 06:51:47 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Sun, 08 May 2011 06:51:47 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: 
Date: Sun, 8 May 2011 06:51:31 -0700
Message-Id: <9A13B378-9FC9-42D0-BB46-BCFD1FCFC8FB@cisco.com>
References: 
To: Qiong 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-sunq-v6ops-contents-transition-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, 08 May 2011 13:51:49 -0000

On May 7, 2011, at 11:25 PM, Qiong wrote:

> In this deployment, packet fragmentation and reassembly might take =
place due to the IPv4/IPv6 packet-length mismatch and MTU-mismatch. So, =
a fragmented IPv4/IPv6 packet should be firstly reassembled to an =
integrated packet, and then the NAT64 box will do IPv4/IPv6 packet =
translation, MTU discovery, and packet fragmentation if necessary.=20


Per RFC 6145           =20

1.4.  Path MTU Discovery and Fragmentation

   Due to the different sizes of the IPv4 and IPv6 header, which are 20+
   octets and 40 octets respectively, handling the maximum packet size
   is critical for the operation of the IPv4/IPv6 translator.  There are
   three mechanisms to handle this issue: path MTU discovery (PMTUD),
   fragmentation, and transport-layer negotiation such as the TCP
   Maximum Segment Size (MSS) option [RFC0879].  Note that the
   translator MUST behave as a router, i.e., the translator MUST send a
   Packet Too Big error message or fragment the packet when the packet
   size exceeds the MTU of the next-hop interface.

   Don't Fragment, ICMP Packet Too Big, and packet fragmentation are
   discussed in Sections 4 and 5 of this document.  The reassembling of
   fragmented packets in the stateful translator is discussed in
   [RFC6146], since it requires state maintenance in the translator.

Path MTU is mandatory in IPv6, so in the IPv6->IPv4 direction that =
should be sufficient for any fragmentation issues. In the IPv4->IPv6 =
direction, Path MTU addresses any case in which IPv4 DF is set. If DF is =
zero (the end system is expecting the network to fragment), I would =
expect you would look to section 4 for guidance. The section is too long =
to quote, but in essence the datagram is fragmented as an IPv4 datagram =
and then the fragments are translated into IPv6 datagrams containing the =
fragment header.

The reason to not reassemble and then re-fragment is that datagrams can =
be load-shared - they might not all go through the same translator.=

From fred@cisco.com  Sun May  8 11:00: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 27607E06F0 for ; Sun,  8 May 2011 11:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.789
X-Spam-Level: 
X-Spam-Status: No, score=-109.789 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 dy1LScpGkXiR for ; Sun,  8 May 2011 11:00:37 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC86E068B for ; Sun,  8 May 2011 11:00:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=605; q=dns/txt; s=iport; t=1304877637; x=1306087237; h=subject:mime-version:from:date:cc:message-id:to: content-transfer-encoding; bh=+5Zg8AmD55EW/ldgdmpzDPBbuYM7h6IpikcOfQaO61Q=; b=Ikb/SekRNuGflMzaARhlybW5/ChtQK44cZUMeUm1uSd19/gFTQ/1PAeQ bTG9AosHtQY1O23vEHWl+BZvN5eTW1PwdaGOUpPDiVQI7BCF8sL8ymUra 4vCpiD+xOyqDOD0d/y0bHsbNQ4DzILl9BlBcRDdjJlfE/SwQJgrA7XoRT s=;
X-IronPort-AV: E=Sophos;i="4.64,335,1301875200";  d="scan'208,217";a="352740962"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 08 May 2011 18:00:36 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p48I0VpK031687; Sun, 8 May 2011 18:00:36 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Sun, 08 May 2011 11:00:36 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Sun, 08 May 2011 11:00:36 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
Date: Sun,  8 May 2011 11:00:10 -0700
Message-Id: <8DC67846-4E1F-4D86-8B89-CA6105B26C10@cisco.com>
To: v6ops@ietf.org
X-Mailer: Apple Mail (2.1084)
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: v6ops-chairs@tools.ietf.org, Ron Bonica 
Subject: [v6ops] Reminder: draft-chown-v6ops-call-to-arms WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 08 May 2011 18:00:38 -0000


The working group last call for this draft announced last week continues for another week. Please feel free to comment on it.

 


From brian.e.carpenter@gmail.com  Sun May  8 15:53: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 17C42E0698 for ; Sun,  8 May 2011 15:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.486
X-Spam-Level: 
X-Spam-Status: No, score=-103.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 2uOw5nRV7OZ0 for ; Sun,  8 May 2011 15:53:03 -0700 (PDT)
Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 25B57E0689 for ; Sun,  8 May 2011 15:53:02 -0700 (PDT)
Received: by pxi2 with SMTP id 2so2899315pxi.38 for ; Sun, 08 May 2011 15:53:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vnl1sm+FXUcNd6ZGluYHw8KgxQdC3mt9EmU6wexjFok=; b=Tm/Qp167HBb1qmoxABjaMcfYa2vaBK9wR2udpYEbDH4RiPQnu0IFcoIlKaXzSUQggM JNvBwU729CR2JYj9pckXHDbvIEqUBOyvj32orE36D3osSLItgSuGjjEYzRKp2SkGWubH uP9Rhu/osPI/iVvK+Uqd9GkkZPKGN7ixP9Jk0=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=ZmYKiFdAMQfWknG9UrKdkcux+zPLM4P8wEFAuF6ctERJ93I0+NzH/E6isLPZQHEgHG 3TP+8xCoY1x0hzbYXtI8ravYwHY2SsgQae8sSEqLf2AS1Nw9bQu+JuB6lUfKehj8+AmX fRFBWVGoRjlDcqk7mnKVWJXjdrT9A1gQwZ95k=
Received: by 10.68.30.97 with SMTP id r1mr2643698pbh.12.1304895182653; Sun, 08 May 2011 15:53:02 -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 l9sm2657030pbc.14.2011.05.08.15.53.00 (version=SSLv3 cipher=OTHER); Sun, 08 May 2011 15:53:01 -0700 (PDT)
Message-ID: <4DC71ECA.5070505@gmail.com>
Date: Mon, 09 May 2011 10:52:58 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ray Hunter 
References: <4DC127BE.2060301@globis.net>
In-Reply-To: <4DC127BE.2060301@globis.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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: Sun, 08 May 2011 22:53:04 -0000

Ray,

Thanks for the review. Unfortunately the WGLC is technically over, so the
current version is now in AD review - no doubt there will be a new version
in due course. My comments below:

On 2011-05-04 22:17, Ray Hunter wrote:
> Here are my comments.
> 
> On the whole an excellent document. There's obviously been a lot of hard
> work put in on preparing this one so far.
> 
> I think perhaps it might be even better if there was some factual list
> included in the introduction on the assumptions that were made when 6to4
> (via anycast) was specified and implemented. It doesn't have to
> apportion blame or flame anyone. Just straight facts.

I can't really speak for the author of RFC 3068 about the assumptions
(except where they are documentd in the RFC). Also, we had exactly the
opposite comment from Pekka Savola - he thinks there is too much text
about RFC 3056 and 3068. So IMHO we shouldn't add anything.
Nevertheless I basically agree with the points you make.

> Here's my take; I'm sure you can improve.
> 
> "The 6to4 transition mechanism can create an automatic tunnel to carry
> IPv6 traffic over a protocol 41 tunnel terminated at an IPv4 anycast
> address, and this assumes that:
> IPv4 and IPv6 clouds within an enterprise or the public Internet are
> contiguous and transparent
> there is a single universal boundary between the IPv4 and IPv6 clouds,
> and the precise crossing point between the two clouds is not important
> the forward and reverse paths do not need to be symmetrical
> protocol 41 is transported and supported in an equal manner to native
> IPv4 and native IPv6 encapsulations
> the additional latency introduced by tunneling via a gateway is not
> operationally significant
> waiting for a failed IPv6 session to time out is not operationally
> significant
> any IPv6 connectivity (no matter what quality) is better than no IPv6
> connectivity (as of RFC3484 and not taking into account the proposed
> RFC3484 bis)
> no need for explicit support of IPv4 NAT traversal
> ease of use is paramount
> 
> It's easy to say with hindsight, but these assumptions do not always
> hold true in a number of real-world use cases, which may lead to
> operational difficulties. Users of 6to4 would be well-advised to check
> that these assumptions hold true in their particular use-case."
> 
> [this last sentence pending approval of moving 6to4 to historic?]
> 
> I also would like to comment on the following:
> 
> "Some operators, particularly enterprise networks, silently block
> Protocol 41 on security grounds. Doing this on its own is bad practice,
> since it contributes to the problem and harms any users who are
> knowingly or unknowingly attempting to run 6to4. "
> 
> Sure that might be considered bad practice, but maybe you should also
> include text saying that "allowing uncontrolled automatic tunneling
> across a firewall is also bad practice."

Personal opinion: I disagree. It all depends on the site or network
concerned and on its service model.

> 
> Equally I see no text in the "vendor issues" covering
> 
> "complete lack of support for protocol 41 in some devices",

Well, ideal routers and switches don't support *any* protocol
numbers, and that's as it should be - only devices acting as
tunnel end points should support the tunnel protocol.
> 
> or
> 
> "lack of feature equivalence in the majority of security devices,
> meaning that an organisation may not be able to effectively implement a
> similar security policy for native IPv6 and IPv6 over protocol 41 as it
> can for IPv4."

There's no doubt that digging into encapsulated packets is extra
work for a firewall, but that applies to all tunnels, not just to 6to4
and not even just to protocol 41. But going into that just seems
out of scope to me; advising firewall vendors what to do is a bit
of a third rail in the IETF anyway.

> 
> It's not about apportioning blame, but sometimes there's little choice.
> There are many people I know who would love to be able to control these
> boundaries effectively whilst transitioning to IPv6, but they just don't
> have the tools to do so, so the only course of action open to them is to
> disable much larger sets of functionality than they really want to. This
> isn't always just a knee jerk reaction. These people have auditors on
> their backs, and users shouting in their ears.
> 
> Similarly the other extreme is also true, the only way to enable
> protocol 41 on my home gateway (for 6in4) is to open up literally
> everything and forward all incoming traffic to a bastion host, and then
> control the traffic there.

Most home gateways are NATs anyway, so 6to4 doesn't work at all and
the issue doesn't arise. If you're fortunate enough to have a supply
of real IPv4 addresses inside the home, yes, you need a home router
than can do things right. In that case, the home is really behaving
like a mini-enterprise, isn't it?

> As you rightly say later on "Enterprise operators who have complete
> administrative control of all end-systems may choose to disable 6to4 in
> those systems as an integral part of their plan to deploy IPv6."
> 
> I'm afraid that's the only logical choice most large enterprises have at
> the moment: disable all IPv6 transition mechanisms.
> 
> But keeping these comments to the scope of your proposal, I'd appreciate
> inclusion of some text in the vendor issues section on the subject of
> support in security devices.

Security devices should contain no 6to4-specific code,
and their protocol 41 behaviour is covered elsewhere.
> 
> 
> Section 4.5 Page 14 "We assume that content providers and their ISPs
> have IPv6 connectivity, and that content servers are dual stacked."
> 
> That's a big assumption. Most corporate content is accelerated by Akamai
> today AFAIK, either directly or indirectly. Have you tried to buy an
> IPv6 capable content acceleration service today? Hopefully that'll
> change very very soon, but again vendor support (today, as I write).

Well, Akamai have it up and running, ready for World IPv6 Day.
However, there is a gap in the draft: it should state that the
content provider recommendations also apply to CDN servers and
to HTTP caches. I need to add that.

> 
> What if this assumption does not hold true?
> 
> What if SLB IPv6-to-IPv4 takes off instead, as it is less painful?
> Does that have any impact?

Can you explain the scenario you have in mind?

> I think I know the answer, but I think a lot of people will ask the
> question.
> 
> There's a lot of very strong language in this section:
> 
> "To avoid this, there must be a locally positioned 6to4 relay."
> "There must be a 2002::/16 route from the content server to the relay."
> "Protocol 41 must not be filtered in the ISP's IPv4 network or firewalls."
> 
> page 15 "This is in fact trivial," Maybe technically speaking for
> someone with root access and your brain power, but not operationally
> speaking. Certainly it isn't trivial on a hosted web service.

The word 'trivial' is badly chosen; 'straightforward' would be better.
The Geoff Huston reference talks about how to do it.

On a hosted service it's the hosting provider who should be doing this.
That should probably be clarified in the text.

> 
> I know this is only an informational RFC, but putting myself in the
> position of a first time reader of this section, I'm not really getting
> what I'm supposed to do, and what happens if I don't.
> 
> Can section 4.5 be made more advisory with achievable actions, and then
> listing the possible negative consequences of not complying? e.g.
> unpredictable latency, users experiencing noticeable delay as sessions
> fall back to IPv4. losing all your customers and going bankrupt?

Well, that really applies to the whole draft - "If you don't do these
things, you will lose customer sessions, annoy users, and receive more
help desk calls." We generally don't dwell on business issues in
IETF documents, however. Don't you think the problem analysis
in section 3 covers this?

> 
> 
> 
> p16 "A blanket recommendation to block Protocol 41 is not compatible
> with mitigating the 6to4 problems described in this document."
> 
> Suggest adding
> ", as it will cause operational problems for other protocols that also
> make use of protocol 41 tunneling and which do not suffer from the same
> problems as 6to4."

It will also cause problems to successful users of 6to4, which is the
focus here.

Regards
    Brian

From marka@isc.org  Sun May  8 16:46: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 385E8E07AF for ; Sun,  8 May 2011 16:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.133
X-Spam-Level: 
X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.466,  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 aEUmdRdiKFiN for ; Sun,  8 May 2011 16:46:26 -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 1ADF8E071F for ; Sun,  8 May 2011 16:46: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.pao1.isc.org (Postfix) with ESMTPS id 61D66C944E; Sun,  8 May 2011 23:46:16 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 26FE1216C31; Sun,  8 May 2011 23:46:16 +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 57690E93D0A; Mon,  9 May 2011 09:46:32 +1000 (EST)
To: Brian E Carpenter 
From: Mark Andrews 
References: <4DC127BE.2060301@globis.net> <4DC71ECA.5070505@gmail.com>
In-reply-to: Your message of "Mon, 09 May 2011 10:52:58 +1200." <4DC71ECA.5070505@gmail.com>
Date: Mon, 09 May 2011 09:46:32 +1000
Message-Id: <20110508234632.57690E93D0A@drugs.dv.isc.org>
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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: Sun, 08 May 2011 23:46:27 -0000

One thing I havn't seen suggested yet is a DHCP option to distribute
local 6to4 outbound relay information.  This would allow ISP's to
to provide managed relays which arn't open to the world.  It would
also allow them to distribute load by adjusting which DHCP clients
get which relay.  There isn't a chance of the anycast route leaking.
Clients using using such 6to4 relays have a clear point of contact.

		<4>

The option could also be used to signal that 6to4 should not be used with
this IPv4 address by setting the value to 0.0.0.0.

		<4><0.0.0.0>		Disable 6to4.

Yes. I know this is very late in the 6to4 lifetime and there may be
limited implementation.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From ek@google.com  Sun May  8 17:43: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 5D4ADE073B for ; Sun,  8 May 2011 17:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.696
X-Spam-Level: 
X-Spam-Status: No, score=-106.696 tagged_above=-999 required=5 tests=[AWL=-0.719, 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 qSdti01A8gXu for ; Sun,  8 May 2011 17:43:03 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 64BCDE0738 for ; Sun,  8 May 2011 17:42:58 -0700 (PDT)
Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p490W3oF010520 for ; Sun, 8 May 2011 17:32:03 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304901123; bh=Oy1jKRUt6UkG3Zw3f85b/JhM4KI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=d7aFyuuA0RQIlStTxMGJ4DQw6E8NQssoFgIXhr776Vi2HvvxRsDPn8JcupAB+h52f ZIf+PbPgrT1jF2f7huECQ==
Received: from pvf33 (pvf33.prod.google.com [10.241.210.97]) by kpbe15.cbf.corp.google.com with ESMTP id p490W1ht008240 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 8 May 2011 17:32:01 -0700
Received: by pvf33 with SMTP id 33so2579045pvf.38 for ; Sun, 08 May 2011 17:32:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vYsGGHCTT1JSlUcA/7LyJdAJLc+ITR4hyjplj/ExjPY=; b=Mu4OQylxX/6iLUUfpCDjCil2DXirjMA5yZJKp4egDZNGtucYk79YcoOpOudwDZoj4w eSG4PkB+spd7BbX8jABw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EyrP9DZhQswAszwhLnUrwbDPO3xjH1HcUAsNrDF2oNwWOn0VU78h8ejh0u+X/0P3YS FMfo2CRusu5TUy5sbLWw==
MIME-Version: 1.0
Received: by 10.68.57.42 with SMTP id f10mr8759302pbq.2.1304901121131; Sun, 08 May 2011 17:32:01 -0700 (PDT)
Received: by 10.142.245.14 with HTTP; Sun, 8 May 2011 17:32:01 -0700 (PDT)
In-Reply-To: <20110508234632.57690E93D0A@drugs.dv.isc.org>
References: <4DC127BE.2060301@globis.net> <4DC71ECA.5070505@gmail.com> <20110508234632.57690E93D0A@drugs.dv.isc.org>
Date: Mon, 9 May 2011 02:32:01 +0200
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] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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, 09 May 2011 00:43:04 -0000

> Yes. I know this is very late in the 6to4 lifetime and there may be
> limited implementation.

Yeah, I think if you want to go down this road you're going to end up
at 6rd (the 6to4 client nodes will need a software refresh to get
knowledge of this DHCP option anyway).

It might be worth recommending that existing 6to4 implementors support
transitioning their code to 6rd in coming updates (I can't recall if
such a statement is in the draft already or not).

From marka@isc.org  Sun May  8 18:52: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 E0048E069A for ; Sun,  8 May 2011 18:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.157
X-Spam-Level: 
X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.443,  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 2GjaeU+Lr0zZ for ; Sun,  8 May 2011 18:52:23 -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 B8DE0E0651 for ; Sun,  8 May 2011 18:52:22 -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 6AFE05F991D; Mon,  9 May 2011 01:52:04 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 0A60D216C1E; Mon,  9 May 2011 01:52:02 +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 AA7D8E951C4; Mon,  9 May 2011 11:52:19 +1000 (EST)
To: Erik Kline 
From: Mark Andrews 
References: <4DC127BE.2060301@globis.net> <4DC71ECA.5070505@gmail.com> <20110508234632.57690E93D0A@drugs.dv.isc.org> 
In-reply-to: Your message of "Mon, 09 May 2011 02:32:01 +0200." 
Date: Mon, 09 May 2011 11:52:19 +1000
Message-Id: <20110509015219.AA7D8E951C4@drugs.dv.isc.org>
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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, 09 May 2011 01:52:30 -0000

In message , Erik Kline wri
tes:
> > Yes. I know this is very late in the 6to4 lifetime and there may be
> > limited implementation.
> 
> Yeah, I think if you want to go down this road you're going to end up
> at 6rd (the 6to4 client nodes will need a software refresh to get
> knowledge of this DHCP option anyway).

Except 6rd requires kernel changes.  For many OS's this is just a
userland change which doesn't require new code to be compiled,
just minor tweeks to existing shell scripts and configuration files.

e.g.
/etc/dhclient.conf:
option 6to4-router code  = ip-address ;
request subnet-mask, broadcast-address, time-offset, routers,
	domain-name, domain-name-servers, ntp-servers, 6to4-router;

/etc/dhclient-exit-hooks:
new_6to4_router=${new_6to4_router:-192.88.99.1}
if [ "$new_6to4_router" != 0.0.0.0 ]
then
	ether=`ifconfig $interface ether | sed -n s/ether//p | sed 's/:/ /g'`
	local=`printf 2e%s:%sff:%s%s:%s%s $ether`
	octets=`echo $new_ip_address | sed 's/\./ /g'`
	stfaddress=2002:`printf %02x%02x:%02x%02x $octets`::$local
	ifconfig stf0 inet6 $stfaddress prefixlen 16 alias
	ifconfig stf0 inet6 | grep -v $stfaddress |
		sed -n 's/inet6/ifconfig stf0 delete /p' | sh
	octets=`echo $new_6to4_router | sed 's/\./ /g'`
	route add inet6 default 2002:`printf %02x%02x:%02x%02x $octets`::
	# configure internal interfaces.
else
	route delete -inet6 default
	ifconfig stf0 down
	# deconfigure internal interfaces.
fi

instead of adding the ipv6 default route you could start a daemon that
does reachability checks.

> It might be worth recommending that existing 6to4 implementors support
> transitioning their code to 6rd in coming updates (I can't recall if
> such a statement is in the draft already or not).

Indeed.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From marka@isc.org  Sun May  8 19:13: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 0063EE076E for ; Sun,  8 May 2011 19:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.178
X-Spam-Level: 
X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=4.421,  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 TKIFWQc1cGpo for ; Sun,  8 May 2011 19:13:38 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 29A67E066E for ; Sun,  8 May 2011 19:13:37 -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 C25025F98B1; Mon,  9 May 2011 02:13:22 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 C0433216C1E; Mon,  9 May 2011 02:13: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 7646FE9539D; Mon,  9 May 2011 12:13:38 +1000 (EST)
To: Brian E Carpenter 
From: Mark Andrews 
References: <4DC127BE.2060301@globis.net> <4DC71ECA.5070505@gmail.com> <20110508234632.57690E93D0A@drugs.dv.isc.org>  <4DC74AC3.9050808@gmail.com>
In-reply-to: Your message of "Mon, 09 May 2011 14:00:35 +1200." <4DC74AC3.9050808@gmail.com>
Date: Mon, 09 May 2011 12:13:38 +1000
Message-Id: <20110509021338.7646FE9539D@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" , Ray Hunter 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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, 09 May 2011 02:13:53 -0000

In message <4DC74AC3.9050808@gmail.com>, Brian E Carpenter writes:
> 
> On 2011-05-09 12:32, Erik Kline wrote:
> >> Yes. I know this is very late in the 6to4 lifetime and there may be
> >> limited implementation.
> 
> Yes, I rather wish we'd done that instead of RFC 3068.
> 
> Anyway, there will be no new protocol ideas in the -advisory draft.

Fine.  I'm just putting it out there. 
 
> > Yeah, I think if you want to go down this road you're going to end up
> > at 6rd (the 6to4 client nodes will need a software refresh to get
> > knowledge of this DHCP option anyway).
> 
> 6rd is only for ISPs who can upgrade the CPEs, but yes.
> 
> > It might be worth recommending that existing 6to4 implementors support
> > transitioning their code to 6rd in coming updates (I can't recall if
> > such a statement is in the draft already or not).
> 
> Not in -advisory; anyway it seems more like a point for -historic.
> 
>    Brian
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From brian.e.carpenter@gmail.com  Sun May  8 19:28: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 E4E5CE07AA for ; Sun,  8 May 2011 19:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.5
X-Spam-Level: 
X-Spam-Status: No, score=-103.5 tagged_above=-999 required=5 tests=[AWL=0.099,  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 9rmzEUS1XFuB for ; Sun,  8 May 2011 19:28:40 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 178FAE0684 for ; Sun,  8 May 2011 19:28:40 -0700 (PDT)
Received: by pwi5 with SMTP id 5so2930372pwi.31 for ; Sun, 08 May 2011 19:28:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2lb6Wgv/ySF68gmZvVpuEu5kEpSRqKLw2RamdJfOQd4=; b=hXY7/ajrqE5x+cqwpLB3qzZPVzJZ4fEQ0WTxUDjIxlzOU2E7bPoHwrtVCSUE+hI3TX Lfs6QJBeso7ZNbNBG4FG2on03Rftv5bx/F5RRfs3NEDaCTmSUlDmARzKLOVjREz/Nvj+ 1suWj4nCvEQe5Z5Or30LTl5RO341LpZg/U5GQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=odlEujEFIA0k/N5GSJb89aLHr4qbYthvuZ5rheKVQ2gwVrcT65tK5QiqR4cqAp0EFs msps7WhoHAKomTWvj7zRZXnHyIBOlVTRPoJawYc3cnQ3OlwgJTYImyC0rjSU4kXtqlvA kWntYlSUGF2Dw7+XiFnx6MJmIT35covzZlR84=
Received: by 10.68.36.10 with SMTP id m10mr9403498pbj.224.1304906440402; Sun, 08 May 2011 19:00:40 -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 k10sm3771313pbl.76.2011.05.08.19.00.37 (version=SSLv3 cipher=OTHER); Sun, 08 May 2011 19:00:39 -0700 (PDT)
Message-ID: <4DC74AC3.9050808@gmail.com>
Date: Mon, 09 May 2011 14:00:35 +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: <4DC127BE.2060301@globis.net>	<4DC71ECA.5070505@gmail.com>	<20110508234632.57690E93D0A@drugs.dv.isc.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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, 09 May 2011 02:28:41 -0000

On 2011-05-09 12:32, Erik Kline wrote:
>> Yes. I know this is very late in the 6to4 lifetime and there may be
>> limited implementation.

Yes, I rather wish we'd done that instead of RFC 3068.

Anyway, there will be no new protocol ideas in the -advisory draft.

> Yeah, I think if you want to go down this road you're going to end up
> at 6rd (the 6to4 client nodes will need a software refresh to get
> knowledge of this DHCP option anyway).

6rd is only for ISPs who can upgrade the CPEs, but yes.

> It might be worth recommending that existing 6to4 implementors support
> transitioning their code to 6rd in coming updates (I can't recall if
> such a statement is in the draft already or not).

Not in -advisory; anyway it seems more like a point for -historic.

   Brian



From marka@isc.org  Sun May  8 20:54: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 E8C03E0651 for ; Sun,  8 May 2011 20:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.307
X-Spam-Level: 
X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 tNRKko410Jjc for ; Sun,  8 May 2011 20:54: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 65A59E0777 for ; Sun,  8 May 2011 20:54:11 -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 3C9785F983B; Mon,  9 May 2011 03:53:58 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 22CE8216C1E; Mon,  9 May 2011 03:53:56 +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 2490FE957D0; Mon,  9 May 2011 13:53:44 +1000 (EST)
From: Mark Andrews 
In-reply-to: Your message of "Mon, 09 May 2011 11:52:19 +1000."
Date: Mon, 09 May 2011 13:53:40 +1000
Message-Id: <20110509035345.2490FE957D0@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" , Ray Hunter 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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, 09 May 2011 03:54:12 -0000

Better still would be to specify a default in dhclient.conf if the
administrator wants to use the anycast address as a fallback and
adjust dhclient-exit-hooks appropriately.

Mark

/etc/dhclient.conf:
option 6to4-router code  = ip-address ;
request subnet-mask, broadcast-address, time-offset, routers,
	domain-name, domain-name-servers, ntp-servers, 6to4-router;
default 6to4-router 192.88.99.1;
 
/etc/dhclient-exit-hooks:
if [ -n "$new_6to4_router" && "$new_6to4_router" != 0.0.0.0 ]
then
 	ether=`ifconfig $interface ether | sed -n s/ether//p | sed 's/:/ /g'`
 	local=`printf 2e%s:%sff:%s%s:%s%s $ether`
 	octets=`echo $new_ip_address | sed 's/\./ /g'`
 	stfaddress=2002:`printf %02x%02x:%02x%02x $octets`::$local
 	ifconfig stf0 inet6 $stfaddress prefixlen 16 alias
 	ifconfig stf0 inet6 | grep -v $stfaddress |
 		sed -n 's/inet6/ifconfig stf0 delete /p' | sh
 	octets=`echo $new_6to4_router | sed 's/\./ /g'`
	route add inet6 default 2002:`printf %02x%02x:%02x%02x $octets`::
	# configure internal interfaces.
elif [ -n "$new_6to4_router" && "$new_6to4_router" = 0.0.0.0 ]
then
 	route delete -inet6 default
 	ifconfig stf0 down
 	# deconfigure internal interfaces.
fi
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From v6ops@globis.net  Mon May  9 00:32: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 20167E0731 for ; Mon,  9 May 2011 00:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.76
X-Spam-Level: 
X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.238,  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 yBAlVdi1Ossf for ; Mon,  9 May 2011 00:32:41 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 33BFAE06AE for ; Mon,  9 May 2011 00:32:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7AAA0870082; Mon,  9 May 2011 09:32:36 +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 zlydcK2gAOl8; Mon,  9 May 2011 09:32:29 +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 7D046870062; Mon,  9 May 2011 09:32:29 +0200 (CEST)
Message-ID: <4DC79880.1010700@globis.net>
Date: Mon, 09 May 2011 09:32:16 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Brian E Carpenter 
References: <4DC127BE.2060301@globis.net> <4DC71ECA.5070505@gmail.com>
In-Reply-To: <4DC71ECA.5070505@gmail.com>
Content-Type: multipart/alternative; boundary="------------010903000100010807080705"
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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, 09 May 2011 07:32:43 -0000

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

If I'm too late, I'm too late. Fair enough. Apologies. Just attempting 
to suggest what I considered "improvements" on something that is 
already  fit for purpose. I shall try to be more timely in my comments 
in future (I sometimes get confused about the status in the IETF web 
tooling. Unless you follow every single email on the list it's sometimes 
not immediately obvious when comments are welcome, and certainly by 
which cut off date) Mea culpa.



As for whether blocking protocol 41 is "bad practice" or not: I defer to 
others e.g.

international standard ISO/IEC 27001:2005(E). I have not come across a 
single organization in my line of work that have interpreted that 
allowing automatic tunneling over protocol 41 over a network security 
zone boundary would be desirable in their security policy.

Microsoft, for example says protocol 41 to the Internet can and should 
be filtered. http://technet.microsoft.com/en-us/library/bb726956.aspx

Cisco say it is wrong to allow implicitly configured tunnels that are 
not under administrator control through the firewall 
www.cisco.com/.../02Eric_Vyncke_*Security*_*Best*_*Practices*.pdf

And last, but not least, http://www.rfc-archive.org/getrfc.php?rfc=5214

quote: There is a possible spoofing attack in which spurious 
ip-protocol-41packets are injected into an ISATAP link from outside.  
Since an ISATAP link spans an entire IPv4 site, restricting access to 
the link can be achieved by restricting access to the site; i.e., by 
having site border routers implement IPv4 ingress filtering and 
ip-protocol-41 filtering.

So if blocking protocol 41 is "bad practice" then the v6ops WG had 
better come up with a better way of authenticating and securing ISATAP 
tunnels.


I do worry that firewalls seem somehow to be considered to be "out of 
scope" or "off limits" for the IETF WG, whereas the reality is that they 
are absolutely everywhere today (fact of life), they're not going to go 
away, and they really could be the number one stumbling block for the 
vast majority of users transitioning to IPv6.

They're the elephant in the room, and I'm not afraid to point it out.

best regards,

RayH


Brian E Carpenter wrote:
> Ray,
>
> Thanks for the review. Unfortunately the WGLC is technically over, so the
> current version is now in AD review - no doubt there will be a new version
> in due course. My comments below:
>
> On 2011-05-04 22:17, Ray Hunter wrote:
>    
>> Here are my comments.
>>
>> On the whole an excellent document. There's obviously been a lot of hard
>> work put in on preparing this one so far.
>>
>> I think perhaps it might be even better if there was some factual list
>> included in the introduction on the assumptions that were made when 6to4
>> (via anycast) was specified and implemented. It doesn't have to
>> apportion blame or flame anyone. Just straight facts.
>>      
>
> I can't really speak for the author of RFC 3068 about the assumptions
> (except where they are documentd in the RFC). Also, we had exactly the
> opposite comment from Pekka Savola - he thinks there is too much text
> about RFC 3056 and 3068. So IMHO we shouldn't add anything.
> Nevertheless I basically agree with the points you make.
>
>    
>> Here's my take; I'm sure you can improve.
>>
>> "The 6to4 transition mechanism can create an automatic tunnel to carry
>> IPv6 traffic over a protocol 41 tunnel terminated at an IPv4 anycast
>> address, and this assumes that:
>> IPv4 and IPv6 clouds within an enterprise or the public Internet are
>> contiguous and transparent
>> there is a single universal boundary between the IPv4 and IPv6 clouds,
>> and the precise crossing point between the two clouds is not important
>> the forward and reverse paths do not need to be symmetrical
>> protocol 41 is transported and supported in an equal manner to native
>> IPv4 and native IPv6 encapsulations
>> the additional latency introduced by tunneling via a gateway is not
>> operationally significant
>> waiting for a failed IPv6 session to time out is not operationally
>> significant
>> any IPv6 connectivity (no matter what quality) is better than no IPv6
>> connectivity (as of RFC3484 and not taking into account the proposed
>> RFC3484 bis)
>> no need for explicit support of IPv4 NAT traversal
>> ease of use is paramount
>>
>> It's easy to say with hindsight, but these assumptions do not always
>> hold true in a number of real-world use cases, which may lead to
>> operational difficulties. Users of 6to4 would be well-advised to check
>> that these assumptions hold true in their particular use-case."
>>
>> [this last sentence pending approval of moving 6to4 to historic?]
>>
>> I also would like to comment on the following:
>>
>> "Some operators, particularly enterprise networks, silently block
>> Protocol 41 on security grounds. Doing this on its own is bad practice,
>> since it contributes to the problem and harms any users who are
>> knowingly or unknowingly attempting to run 6to4. "
>>
>> Sure that might be considered bad practice, but maybe you should also
>> include text saying that "allowing uncontrolled automatic tunneling
>> across a firewall is also bad practice."
>>      
>
> Personal opinion: I disagree. It all depends on the site or network
> concerned and on its service model.
>
>    
>> Equally I see no text in the "vendor issues" covering
>>
>> "complete lack of support for protocol 41 in some devices",
>>      
>
> Well, ideal routers and switches don't support *any* protocol
> numbers, and that's as it should be - only devices acting as
> tunnel end points should support the tunnel protocol.
>    
>> or
>>
>> "lack of feature equivalence in the majority of security devices,
>> meaning that an organisation may not be able to effectively implement a
>> similar security policy for native IPv6 and IPv6 over protocol 41 as it
>> can for IPv4."
>>      
>
> There's no doubt that digging into encapsulated packets is extra
> work for a firewall, but that applies to all tunnels, not just to 6to4
> and not even just to protocol 41. But going into that just seems
> out of scope to me; advising firewall vendors what to do is a bit
> of a third rail in the IETF anyway.
>
>    
>> It's not about apportioning blame, but sometimes there's little choice.
>> There are many people I know who would love to be able to control these
>> boundaries effectively whilst transitioning to IPv6, but they just don't
>> have the tools to do so, so the only course of action open to them is to
>> disable much larger sets of functionality than they really want to. This
>> isn't always just a knee jerk reaction. These people have auditors on
>> their backs, and users shouting in their ears.
>>
>> Similarly the other extreme is also true, the only way to enable
>> protocol 41 on my home gateway (for 6in4) is to open up literally
>> everything and forward all incoming traffic to a bastion host, and then
>> control the traffic there.
>>      
>
> Most home gateways are NATs anyway, so 6to4 doesn't work at all and
> the issue doesn't arise. If you're fortunate enough to have a supply
> of real IPv4 addresses inside the home, yes, you need a home router
> than can do things right. In that case, the home is really behaving
> like a mini-enterprise, isn't it?
>
>    
>> As you rightly say later on "Enterprise operators who have complete
>> administrative control of all end-systems may choose to disable 6to4 in
>> those systems as an integral part of their plan to deploy IPv6."
>>
>> I'm afraid that's the only logical choice most large enterprises have at
>> the moment: disable all IPv6 transition mechanisms.
>>
>> But keeping these comments to the scope of your proposal, I'd appreciate
>> inclusion of some text in the vendor issues section on the subject of
>> support in security devices.
>>      
>
> Security devices should contain no 6to4-specific code,
> and their protocol 41 behaviour is covered elsewhere.
>    
>> Section 4.5 Page 14 "We assume that content providers and their ISPs
>> have IPv6 connectivity, and that content servers are dual stacked."
>>
>> That's a big assumption. Most corporate content is accelerated by Akamai
>> today AFAIK, either directly or indirectly. Have you tried to buy an
>> IPv6 capable content acceleration service today? Hopefully that'll
>> change very very soon, but again vendor support (today, as I write).
>>      
>
> Well, Akamai have it up and running, ready for World IPv6 Day.
> However, there is a gap in the draft: it should state that the
> content provider recommendations also apply to CDN servers and
> to HTTP caches. I need to add that.
>
>    
>> What if this assumption does not hold true?
>>
>> What if SLB IPv6-to-IPv4 takes off instead, as it is less painful?
>> Does that have any impact?
>>      
>
> Can you explain the scenario you have in mind?
>
>    
>> I think I know the answer, but I think a lot of people will ask the
>> question.
>>
>> There's a lot of very strong language in this section:
>>
>> "To avoid this, there must be a locally positioned 6to4 relay."
>> "There must be a 2002::/16 route from the content server to the relay."
>> "Protocol 41 must not be filtered in the ISP's IPv4 network or firewalls."
>>
>> page 15 "This is in fact trivial," Maybe technically speaking for
>> someone with root access and your brain power, but not operationally
>> speaking. Certainly it isn't trivial on a hosted web service.
>>      
>
> The word 'trivial' is badly chosen; 'straightforward' would be better.
> The Geoff Huston reference talks about how to do it.
>
> On a hosted service it's the hosting provider who should be doing this.
> That should probably be clarified in the text.
>
>    
>> I know this is only an informational RFC, but putting myself in the
>> position of a first time reader of this section, I'm not really getting
>> what I'm supposed to do, and what happens if I don't.
>>
>> Can section 4.5 be made more advisory with achievable actions, and then
>> listing the possible negative consequences of not complying? e.g.
>> unpredictable latency, users experiencing noticeable delay as sessions
>> fall back to IPv4. losing all your customers and going bankrupt?
>>      
>
> Well, that really applies to the whole draft - "If you don't do these
> things, you will lose customer sessions, annoy users, and receive more
> help desk calls." We generally don't dwell on business issues in
> IETF documents, however. Don't you think the problem analysis
> in section 3 covers this?
>
>    
>>
>> p16 "A blanket recommendation to block Protocol 41 is not compatible
>> with mitigating the 6to4 problems described in this document."
>>
>> Suggest adding
>> ", as it will cause operational problems for other protocols that also
>> make use of protocol 41 tunneling and which do not suffer from the same
>> problems as 6to4."
>>      
>
> It will also cause problems to successful users of 6to4, which is the
> focus here.
>
> Regards
>      Brian
>    


--------------010903000100010807080705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




  


If I'm too late, I'm too late. Fair enough. Apologies. Just attempting
to suggest what I considered "improvements" on something that is
already  fit for purpose. I shall try to be more timely in my comments
in future (I sometimes get confused about the status in the IETF web
tooling. Unless you follow every single email on the list it's
sometimes not immediately obvious when comments are welcome, and
certainly by which cut off date) Mea culpa.







As for whether blocking protocol 41 is "bad practice" or not: I defer
to others e.g.



international standard ISO/IEC 27001:2005(E). I have not come across a
single organization in my line of work that have interpreted that
allowing automatic tunneling over protocol 41 over a network security
zone boundary would be desirable in their security policy.



Microsoft, for example says protocol 41 to the Internet can and should
be filtered. http://technet.microsoft.com/en-us/library/bb726956.aspx



Cisco say it is wrong to allow implicitly configured tunnels that are
not under administrator control through the firewall

www.cisco.com/.../02Eric_Vyncke_Security_Best_Practices.pdf



And last, but not least, http://www.rfc-archive.org/getrfc.php?rfc=5214



quote: There is a possible spoofing attack in which spurious
ip-protocol-41packets are injected into an ISATAP link from outside. 
Since an ISATAP link spans an entire IPv4 site, restricting access to
the link can be achieved by restricting access to the site; i.e., by
having site border routers implement IPv4 ingress filtering and
ip-protocol-41 filtering.



So if blocking protocol 41 is "bad practice" then the v6ops WG had
better come up with a better way of authenticating and securing ISATAP
tunnels.





I do worry that firewalls seem somehow to be considered to be "out of
scope" or "off limits" for the IETF WG, whereas the reality is that
they are absolutely everywhere today (fact of life), they're not going
to go away, and they really could be the number one stumbling block for
the vast majority of users transitioning to IPv6.



They're the elephant in the room, and I'm not afraid to point it out.



best regards,



RayH





Brian E Carpenter wrote:


  
Ray,

Thanks for the review. Unfortunately the WGLC is technically over, so the
current version is now in AD review - no doubt there will be a new version
in due course. My comments below:

On 2011-05-04 22:17, Ray Hunter wrote:
  

  

    
Here are my comments.

On the whole an excellent document. There's obviously been a lot of hard
work put in on preparing this one so far.

I think perhaps it might be even better if there was some factual list
included in the introduction on the assumptions that were made when 6to4
(via anycast) was specified and implemented. It doesn't have to
apportion blame or flame anyone. Just straight facts.
    

  

  

I can't really speak for the author of RFC 3068 about the assumptions
(except where they are documentd in the RFC). Also, we had exactly the
opposite comment from Pekka Savola - he thinks there is too much text
about RFC 3056 and 3068. So IMHO we shouldn't add anything.
Nevertheless I basically agree with the points you make.

  

  

    
Here's my take; I'm sure you can improve.

"The 6to4 transition mechanism can create an automatic tunnel to carry
IPv6 traffic over a protocol 41 tunnel terminated at an IPv4 anycast
address, and this assumes that:
IPv4 and IPv6 clouds within an enterprise or the public Internet are
contiguous and transparent
there is a single universal boundary between the IPv4 and IPv6 clouds,
and the precise crossing point between the two clouds is not important
the forward and reverse paths do not need to be symmetrical
protocol 41 is transported and supported in an equal manner to native
IPv4 and native IPv6 encapsulations
the additional latency introduced by tunneling via a gateway is not
operationally significant
waiting for a failed IPv6 session to time out is not operationally
significant
any IPv6 connectivity (no matter what quality) is better than no IPv6
connectivity (as of RFC3484 and not taking into account the proposed
RFC3484 bis)
no need for explicit support of IPv4 NAT traversal
ease of use is paramount

It's easy to say with hindsight, but these assumptions do not always
hold true in a number of real-world use cases, which may lead to
operational difficulties. Users of 6to4 would be well-advised to check
that these assumptions hold true in their particular use-case."

[this last sentence pending approval of moving 6to4 to historic?]

I also would like to comment on the following:

"Some operators, particularly enterprise networks, silently block
Protocol 41 on security grounds. Doing this on its own is bad practice,
since it contributes to the problem and harms any users who are
knowingly or unknowingly attempting to run 6to4. "

Sure that might be considered bad practice, but maybe you should also
include text saying that "allowing uncontrolled automatic tunneling
across a firewall is also bad practice."
    

  

  

Personal opinion: I disagree. It all depends on the site or network
concerned and on its service model.

  

  

    
Equally I see no text in the "vendor issues" covering

"complete lack of support for protocol 41 in some devices",
    

  

  

Well, ideal routers and switches don't support *any* protocol
numbers, and that's as it should be - only devices acting as
tunnel end points should support the tunnel protocol.
  

  

    
or

"lack of feature equivalence in the majority of security devices,
meaning that an organisation may not be able to effectively implement a
similar security policy for native IPv6 and IPv6 over protocol 41 as it
can for IPv4."
    

  

  

There's no doubt that digging into encapsulated packets is extra
work for a firewall, but that applies to all tunnels, not just to 6to4
and not even just to protocol 41. But going into that just seems
out of scope to me; advising firewall vendors what to do is a bit
of a third rail in the IETF anyway.

  

  

    
It's not about apportioning blame, but sometimes there's little choice.
There are many people I know who would love to be able to control these
boundaries effectively whilst transitioning to IPv6, but they just don't
have the tools to do so, so the only course of action open to them is to
disable much larger sets of functionality than they really want to. This
isn't always just a knee jerk reaction. These people have auditors on
their backs, and users shouting in their ears.

Similarly the other extreme is also true, the only way to enable
protocol 41 on my home gateway (for 6in4) is to open up literally
everything and forward all incoming traffic to a bastion host, and then
control the traffic there.
    

  

  

Most home gateways are NATs anyway, so 6to4 doesn't work at all and
the issue doesn't arise. If you're fortunate enough to have a supply
of real IPv4 addresses inside the home, yes, you need a home router
than can do things right. In that case, the home is really behaving
like a mini-enterprise, isn't it?

  

  

    
As you rightly say later on "Enterprise operators who have complete
administrative control of all end-systems may choose to disable 6to4 in
those systems as an integral part of their plan to deploy IPv6."

I'm afraid that's the only logical choice most large enterprises have at
the moment: disable all IPv6 transition mechanisms.

But keeping these comments to the scope of your proposal, I'd appreciate
inclusion of some text in the vendor issues section on the subject of
support in security devices.
    

  

  

Security devices should contain no 6to4-specific code,
and their protocol 41 behaviour is covered elsewhere.
  

  

    
Section 4.5 Page 14 "We assume that content providers and their ISPs
have IPv6 connectivity, and that content servers are dual stacked."

That's a big assumption. Most corporate content is accelerated by Akamai
today AFAIK, either directly or indirectly. Have you tried to buy an
IPv6 capable content acceleration service today? Hopefully that'll
change very very soon, but again vendor support (today, as I write).
    

  

  

Well, Akamai have it up and running, ready for World IPv6 Day.
However, there is a gap in the draft: it should state that the
content provider recommendations also apply to CDN servers and
to HTTP caches. I need to add that.

  

  

    
What if this assumption does not hold true?

What if SLB IPv6-to-IPv4 takes off instead, as it is less painful?
Does that have any impact?
    

  

  

Can you explain the scenario you have in mind?

  

  

    
I think I know the answer, but I think a lot of people will ask the
question.

There's a lot of very strong language in this section:

"To avoid this, there must be a locally positioned 6to4 relay."
"There must be a 2002::/16 route from the content server to the relay."
"Protocol 41 must not be filtered in the ISP's IPv4 network or firewalls."

page 15 "This is in fact trivial," Maybe technically speaking for
someone with root access and your brain power, but not operationally
speaking. Certainly it isn't trivial on a hosted web service.
    

  

  

The word 'trivial' is badly chosen; 'straightforward' would be better.
The Geoff Huston reference talks about how to do it.

On a hosted service it's the hosting provider who should be doing this.
That should probably be clarified in the text.

  

  

    
I know this is only an informational RFC, but putting myself in the
position of a first time reader of this section, I'm not really getting
what I'm supposed to do, and what happens if I don't.

Can section 4.5 be made more advisory with achievable actions, and then
listing the possible negative consequences of not complying? e.g.
unpredictable latency, users experiencing noticeable delay as sessions
fall back to IPv4. losing all your customers and going bankrupt?
    

  

  

Well, that really applies to the whole draft - "If you don't do these
things, you will lose customer sessions, annoy users, and receive more
help desk calls." We generally don't dwell on business issues in
IETF documents, however. Don't you think the problem analysis
in section 3 covers this?

  

  

    

p16 "A blanket recommendation to block Protocol 41 is not compatible
with mitigating the 6to4 problems described in this document."

Suggest adding
", as it will cause operational problems for other protocols that also
make use of protocol 41 tunneling and which do not suffer from the same
problems as 6to4."
    

  

  

It will also cause problems to successful users of 6to4, which is the
focus here.

Regards
    Brian
  








--------------010903000100010807080705--

From marka@isc.org  Mon May  9 00:58: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 397D2E065D for ; Mon,  9 May 2011 00:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.653
X-Spam-Level: 
X-Spam-Status: No, score=-5.653 tagged_above=-999 required=5 tests=[AWL=4.346,  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 oaoO19Hn23-a for ; Mon,  9 May 2011 00:57:57 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id 775B6E07A1 for ; Mon,  9 May 2011 00:57:57 -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 56FFDC94CD; Mon,  9 May 2011 07:57:45 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 C6090216C31; Mon,  9 May 2011 07:57:44 +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 94B3EE97BED; Mon,  9 May 2011 17:58:02 +1000 (EST)
To: Ray Hunter 
From: Mark Andrews 
References: <4DC127BE.2060301@globis.net> <4DC71ECA.5070505@gmail.com> <4DC79880.1010700@globis.net>
In-reply-to: Your message of "Mon, 09 May 2011 09:32:16 +0200." <4DC79880.1010700@globis.net>
Date: Mon, 09 May 2011 17:58:02 +1000
Message-Id: <20110509075802.94B3EE97BED@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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, 09 May 2011 07:58:14 -0000

In message <4DC79880.1010700@globis.net>, Ray Hunter writes:
> 
> If I'm too late, I'm too late. Fair enough. Apologies. Just attempting 
> to suggest what I considered "improvements" on something that is 
> already  fit for purpose. I shall try to be more timely in my comments 
> in future (I sometimes get confused about the status in the IETF web 
> tooling. Unless you follow every single email on the list it's sometimes 
> not immediately obvious when comments are welcome, and certainly by 
> which cut off date) Mea culpa.
> 
> As for whether blocking protocol 41 is "bad practice" or not: I defer to 
> others e.g.
> 
> international standard ISO/IEC 27001:2005(E). I have not come across a 
> single organization in my line of work that have interpreted that 
> allowing automatic tunneling over protocol 41 over a network security 
> zone boundary would be desirable in their security policy.
> 
> Microsoft, for example says protocol 41 to the Internet can and should 
> be filtered. http://technet.microsoft.com/en-us/library/bb726956.aspx
>
> Cisco say it is wrong to allow implicitly configured tunnels that are 
> not under administrator control through the firewall 
> www.cisco.com/.../02Eric_Vyncke_*Security*_*Best*_*Practices*.pdf
> 
> And last, but not least, http://www.rfc-archive.org/getrfc.php?rfc=5214
> 
> quote: There is a possible spoofing attack in which spurious 
> ip-protocol-41packets are injected into an ISATAP link from outside.  
> Since an ISATAP link spans an entire IPv4 site, restricting access to 
> the link can be achieved by restricting access to the site; i.e., by 
> having site border routers implement IPv4 ingress filtering and 
> ip-protocol-41 filtering.
> 
> So if blocking protocol 41 is "bad practice" then the v6ops WG had 
> better come up with a better way of authenticating and securing ISATAP 
> tunnels.

Blocking protocol 41 *by ISPs* is bad practice.  Blocking protocol
41 without sending back destination unreachable by enterprises is
bad practice.

> I do worry that firewalls seem somehow to be considered to be "out of 
> scope" or "off limits" for the IETF WG, whereas the reality is that they 
> are absolutely everywhere today (fact of life), they're not going to go 
> away, and they really could be the number one stumbling block for the 
> vast majority of users transitioning to IPv6.
> 
> They're the elephant in the room, and I'm not afraid to point it out.

draft-ietf-v6ops-6to4-advisory-01.txt acknowledged that firewalls
exist and that block is reasonable under certain conditions.

> best regards,
> 
> RayH


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From marka@isc.org  Mon May  9 01:08: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 8FEFEE07C1 for ; Mon,  9 May 2011 01:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.126
X-Spam-Level: 
X-Spam-Status: No, score=-8.126 tagged_above=-999 required=5 tests=[AWL=2.473,  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 GRZnufnPrILE for ; Mon,  9 May 2011 01:08:39 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id 57E4EE06F4 for ; Mon,  9 May 2011 01:08:39 -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 D3AB5C94DA for ; Mon,  9 May 2011 08:08:32 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 0EDDB216C1E for ; Mon,  9 May 2011 08:08:32 +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 D2CB7E97C8E for ; Mon,  9 May 2011 18:08:48 +1000 (EST)
To: v6ops@ietf.org
From: Mark Andrews 
Date: Mon, 09 May 2011 18:08:48 +1000
Message-Id: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>
Subject: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 09 May 2011 08:08:40 -0000

	I just posted draft-andrews-v6ops-6to4-router-option-00.txt.
	Feedback welcome.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka@isc.org

From v6ops@globis.net  Mon May  9 01:40: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 4AC52E07D4 for ; Mon,  9 May 2011 01:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.077
X-Spam-Level: 
X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[AWL=0.521,  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 DLMMqS4ccPqc for ; Mon,  9 May 2011 01:40:09 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id A9D9EE066A for ; Mon,  9 May 2011 01:40:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id CA4E98700DE; Mon,  9 May 2011 10:40: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 LNDW925C8jgy; Mon,  9 May 2011 10:40: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 EFE268700DD; Mon,  9 May 2011 10:39:59 +0200 (CEST)
Message-ID: <4DC7A852.6030801@globis.net>
Date: Mon, 09 May 2011 10:39:46 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Mark Andrews 
References: <20110509035345.2490FE957D0@drugs.dv.isc.org>
In-Reply-To: <20110509035345.2490FE957D0@drugs.dv.isc.org>
Content-Type: multipart/alternative; boundary="------------090500050302010506000404"
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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, 09 May 2011 08:40:10 -0000

This is a multi-part message in MIME format.
--------------090500050302010506000404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

-1 as it is proposed but +0.2 with a tweak.

In the ideal world this would have been baked into the original 
deployment design from the very beginning, especially allowing the DHCP 
"OFF" option plus making the default behavior OFF. Then it might have 
been a really great idea.

Erm. But now? No thanks. 6to4 is enabled by default in Windows 7 and has 
already been deployed on many desktops. The timing is just wrong. So an 
option of having to place a "0.0.0.0" to turn off 6to4 via an option in 
DHCP that is acted upon by a few nodes that have implemented a new 
standard, whilst all other nodes ignore it, is just the wrong way around 
IMHO.

This change as proposed would potentially put 6to4 even further out of 
the control of the administrators of the transport network for the few 
nodes that are going to support it. One wiseguy host admin flips one 
switch in DHCP and the whole transport network goes haywire switching to 
IPv6 over tunnels rather than native IPv4.

At least the route to the well-known anycast address can be filtered and 
controlled by the guys controlling the transport network (as already 
clearly advised in the draft).

I can tell you that I'm spending a ratio of approx 40:1 of my time 
worrying about how to stop inappropriate or unexpected deployment of 
transition mechanisms messing up a perfectly good native IPv4 service 
than I am worrying about how to deploy native IPv6.

These automatic tunnels should just be "off" by default.  There are an 
awful lot of major enterprises considering a "Bring you own device" 
policy and then running virtual desktops on top of those (or using cloud 
computing). That means a lot of end nodes on the corporate networks may 
be configured with default settings and may not even be controllable via 
Active Directory as per today. That also means network transport admins 
may have very limited tooling to be mandate / configure the 
configuration of the end nodes. All of which suggest that the default 
should be a "fail safe" so that the administrators of the transport 
network can remain in control.



However, if you also mandate OFF as the default when adding this DHCP 
option, and so only a positive non NULL reply would enable 6to4 e.g..

/etc/dhclient.conf:
option 6to4-router code  = ip-address ;
request subnet-mask, broadcast-address, time-offset, routers,
	domain-name, domain-name-servers, ntp-servers, 6to4-router;

/etc/dhclient-exit-hooks:

if [ "$new_6to4_router" != 0.0.0.0&&  "$new_6to4_router" != NULL]
then
	...
else
	...
fi


Then it well might be a marginal improvement, but of course would break 
existing all deployments unless they also tweaked their DHCP repsonse to 
include the option. So it's a bit of a no win situation (hence the +.2 
in my vote.)

But please don't make these transition mechanisms any worse / more 
complicated to control than they already are now that they're out there.

All IMVHO [and bear in mind that I am just the messenger relaying what 
these IT strategy guys are considering]

>
> Blocking protocol 41*by ISPs*  is bad practice.  Blocking protocol
> 41 without sending back destination unreachable by enterprises is
> bad practice.
>
>    
Got it. Is is possible to make this small tweak and add the "destination 
unreachable" portion? I completely missed the significance of "silently" 
even though I read that phrase many times.

best regards,
RayH






Mark Andrews wrote:
> Better still would be to specify a default in dhclient.conf if the
> administrator wants to use the anycast address as a fallback and
> adjust dhclient-exit-hooks appropriately.
>
> Mark
>
> /etc/dhclient.conf:
> option 6to4-router code  = ip-address ;
> request subnet-mask, broadcast-address, time-offset, routers,
> 	domain-name, domain-name-servers, ntp-servers, 6to4-router;
> default 6to4-router 192.88.99.1;
>
> /etc/dhclient-exit-hooks:
> if [ -n "$new_6to4_router"&&  "$new_6to4_router" != 0.0.0.0 ]
> then
>   	ether=`ifconfig $interface ether | sed -n s/ether//p | sed 's/:/ /g'`
>   	local=`printf 2e%s:%sff:%s%s:%s%s $ether`
>   	octets=`echo $new_ip_address | sed 's/\./ /g'`
>   	stfaddress=2002:`printf %02x%02x:%02x%02x $octets`::$local
>   	ifconfig stf0 inet6 $stfaddress prefixlen 16 alias
>   	ifconfig stf0 inet6 | grep -v $stfaddress |
>   		sed -n 's/inet6/ifconfig stf0 delete /p' | sh
>   	octets=`echo $new_6to4_router | sed 's/\./ /g'`
> 	route add inet6 default 2002:`printf %02x%02x:%02x%02x $octets`::
> 	# configure internal interfaces.
> elif [ -n "$new_6to4_router"&&  "$new_6to4_router" = 0.0.0.0 ]
> then
>   	route delete -inet6 default
>   	ifconfig stf0 down
>   	# deconfigure internal interfaces.
> fi
>    


--------------090500050302010506000404
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


-1 as it is proposed but +0.2 with a tweak.



In the ideal world this would have been baked into the original
deployment design from the very beginning, especially allowing the DHCP
"OFF" option plus making the default behavior OFF. Then it might have
been a really great idea.



Erm. But now? No thanks. 6to4 is enabled by default in Windows 7 and
has already been deployed on many desktops. The timing is just wrong.
So an option of having to place a "0.0.0.0" to turn off 6to4 via an
option in DHCP that is acted upon by a few nodes that have implemented
a new standard, whilst all other nodes ignore it, is just the wrong way
around IMHO. 



This change as proposed would potentially put 6to4 even further out of
the control of the administrators of the transport network for the few
nodes that are going to support it. One wiseguy host admin flips one
switch in DHCP and the whole transport network goes haywire switching
to IPv6 over tunnels rather than native IPv4.



At least the route to the well-known anycast address can be filtered
and controlled by the guys controlling the transport network (as
already clearly advised in the draft).



I can tell you that I'm spending a ratio of approx 40:1 of my time
worrying about how to stop inappropriate or unexpected deployment of
transition mechanisms messing up a perfectly good native IPv4 service
than I am worrying about how to deploy native IPv6.



These automatic tunnels should just be "off" by default.  There are an
awful lot of major enterprises considering a "Bring you own device"
policy and then running virtual desktops on top of those (or using
cloud computing). That means a lot of end nodes on the corporate
networks may be configured with default settings and may not even be
controllable via Active Directory as per today. That also means network
transport admins may have very limited tooling to be mandate /
configure the configuration of the end nodes. All of which suggest that
the default should be a "fail safe" so that the administrators of the
transport network can remain in control.







However, if you also mandate OFF as the default when adding this DHCP
option, and so only a positive non NULL reply would enable 6to4 e.g..




/etc/dhclient.conf:
option 6to4-router code <tbd> = ip-address ;
request subnet-mask, broadcast-address, time-offset, routers,
	domain-name, domain-name-servers, ntp-servers, 6to4-router;

/etc/dhclient-exit-hooks:

if [ "$new_6to4_router" != 0.0.0.0 && "$new_6to4_router" != NULL]
then
	...
else
	...
fi



Then it well might be a marginal improvement, but of course would break
existing all deployments unless they also tweaked their DHCP repsonse
to include the option. So it's a bit of a no win situation (hence the
+.2 in my vote.)



But please don't make these transition mechanisms any worse / more
complicated to control than they already are now that they're out there.



All IMVHO [and bear in mind that I am just the messenger relaying what
these IT strategy guys are considering]





  

Blocking protocol 41 *by ISPs* is bad practice.  Blocking protocol
41 without sending back destination unreachable by enterprises is
bad practice.

  



Got it. Is is possible to make this small tweak and add the
"destination unreachable" portion? I completely missed the significance
of "silently" even though I read that phrase many times. 



best regards,

RayH













Mark Andrews wrote:


  
Better still would be to specify a default in dhclient.conf if the
administrator wants to use the anycast address as a fallback and
adjust dhclient-exit-hooks appropriately.

Mark

/etc/dhclient.conf:
option 6to4-router code <tbd> = ip-address ;
request subnet-mask, broadcast-address, time-offset, routers,
	domain-name, domain-name-servers, ntp-servers, 6to4-router;
default 6to4-router 192.88.99.1;
 
/etc/dhclient-exit-hooks:
if [ -n "$new_6to4_router" && "$new_6to4_router" != 0.0.0.0 ]
then
 	ether=`ifconfig $interface ether | sed -n s/ether//p | sed 's/:/ /g'`
 	local=`printf 2e%s:%sff:%s%s:%s%s $ether`
 	octets=`echo $new_ip_address | sed 's/\./ /g'`
 	stfaddress=2002:`printf %02x%02x:%02x%02x $octets`::$local
 	ifconfig stf0 inet6 $stfaddress prefixlen 16 alias
 	ifconfig stf0 inet6 | grep -v $stfaddress |
 		sed -n 's/inet6/ifconfig stf0 delete /p' | sh
 	octets=`echo $new_6to4_router | sed 's/\./ /g'`
	route add inet6 default 2002:`printf %02x%02x:%02x%02x $octets`::
	# configure internal interfaces.
elif [ -n "$new_6to4_router" && "$new_6to4_router" = 0.0.0.0 ]
then
 	route delete -inet6 default
 	ifconfig stf0 down
 	# deconfigure internal interfaces.
fi
  








--------------090500050302010506000404--

From jacniq@gmail.com  Mon May  9 01:54: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 74047E067E for ; Mon,  9 May 2011 01:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.973
X-Spam-Level: 
X-Spam-Status: No, score=-2.973 tagged_above=-999 required=5 tests=[AWL=0.025,  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 fTZyVN6vWC6n for ; Mon,  9 May 2011 01:54:42 -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 8BA2FE06B4 for ; Mon,  9 May 2011 01:54:41 -0700 (PDT)
Received: by vxg33 with SMTP id 33so6759074vxg.31 for ; Mon, 09 May 2011 01:54:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GC4V5hxKNVsXW5C13YxHAcAk5wiQH1zZ0QJ91/Rwb+g=; b=aCsQxBWudC4B76s57xV0GFgOV2WURIm43NS9EyG1/kcQzCgj6oY8VbRNYF6NbLkIdG +IM2j1sZey3RrJoqkB6N9EEavz9OznY9KoRrHhfZ/Ch/IHZTVORs10I3RXVRI2ics36Q 8DGCi3QceKyKVOD6vHnLaJtPnJUHmDpSZvWUY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QaImBis4LmffW+T6pSPnSMSpGBdOUx1nNS55d4H8H+8E6zidZRiAzkvcd5s8EfOlyT 5WDbiG/choPtvlJ7fASyBU8LIaeqtc6dACVvGszCdqcqaEvy3C23fl2HVNv9Dyh59En7 ARhdTzq9BKfINZk/F4YVh9MuDkbDILZAMhWVM=
MIME-Version: 1.0
Received: by 10.52.93.107 with SMTP id ct11mr2609517vdb.243.1304931280695; Mon, 09 May 2011 01:54:40 -0700 (PDT)
Received: by 10.52.186.227 with HTTP; Mon, 9 May 2011 01:54:40 -0700 (PDT)
In-Reply-To: 
References:  
Date: Mon, 9 May 2011 16:54:40 +0800
Message-ID: 
From: Jacni Qin 
To: Randy Bush , ek@google.com
Content-Type: multipart/alternative; boundary=bcaec501638971303704a2d3fdbf
Cc: v6ops@ietf.org, Qiong 
Subject: Re: [v6ops] new draft: draft-sunq-v6ops-contents-transition-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, 09 May 2011 08:54:43 -0000

--bcaec501638971303704a2d3fdbf
Content-Type: text/plain; charset=ISO-8859-1

Hi Randy and Erik,

This is a first version to start the work. We'll take it into account in the
next revision.
Thanks a lot for your comments!


Cheers,
Jacni

On Sun, May 8, 2011 at 5:03 PM, Randy Bush  wrote:

> > In this deployment, packet fragmentation and reassembly might take
> > place due to the IPv4/IPv6 packet-length mismatch and MTU-mismatch.
> > So, a fragmented IPv4/IPv6 packet should be firstly reassembled to an
> > integrated packet, and then the NAT64 box will do IPv4/IPv6 packet
> > translation, MTU discovery, and packet fragmentation if necessary.
>
> i think erik meant in the document, please
>
> randy
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--bcaec501638971303704a2d3fdbf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Randy and Erik,

This is a first=
 version to start the work. We'll take it into account in the next revi=
sion.
Thanks a lot for your comments!


Cheers,
Jacni



On Sun, May 8, 2011 at 5:03 PM, Randy Bush <randy@psg.com> wrote:


> In this deployment, packet fragmentation and reassem=
bly might take

> place due to the IPv4/IPv6 packet-length mismatch and MTU-mismatch.
> So, a fragmented IPv4/IPv6 packet should be firstly reassembled to an<=
br>
> integrated packet, and then the NAT64 box will do IPv4/IPv6 packet

> translation, MTU discovery, and packet fragmentation if necessary.




i think erik meant in the document, please



randy

_______________________________________________





--bcaec501638971303704a2d3fdbf--

From jacniq@gmail.com  Mon May  9 01:57: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 A2945E06CF for ; Mon,  9 May 2011 01:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.978
X-Spam-Level: 
X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=0.020,  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 7EBpgcdPhV46 for ; Mon,  9 May 2011 01:57:46 -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 9006EE06C4 for ; Mon,  9 May 2011 01:57:46 -0700 (PDT)
Received: by vxg33 with SMTP id 33so6762107vxg.31 for ; Mon, 09 May 2011 01:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/u28UNh0FRyvtKOB+ypIGEJKARnh0goKs38Ym5LG7PE=; b=J8vT1bDQi1zESM6FY2cuU5aWSnUyRvAvGygekjtfNwWOe7gGENGi9t7jByklZmle28 r5FCSpPTXCgoOW+q0oVnis2vjEDKc3BnhV3sKA+Olv8WzZV0SuZvkQcnep9TmpbGYmt9 zDDnhHI+Ao+fAwyk66tpM02MPyfvULz6e8g9Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SAhczS69RokuKZ3O2mKdrW9ptAzTz/FkhQPxcuWffq2PArPVZnnIG6MOHRvmr6XQeh DXR8UB3+FVSF1h7Zlm0wGb0Sx9qO9mQntLbVx70ZDvDQDQRxHnkqpdXpchThxe2RNYFE uWOjys18xUApnEin2rXK7UvRfy4t4kKIvZ8P4=
MIME-Version: 1.0
Received: by 10.52.96.33 with SMTP id dp1mr3087925vdb.43.1304931465612; Mon, 09 May 2011 01:57:45 -0700 (PDT)
Received: by 10.52.186.227 with HTTP; Mon, 9 May 2011 01:57:45 -0700 (PDT)
In-Reply-To: <9A13B378-9FC9-42D0-BB46-BCFD1FCFC8FB@cisco.com>
References:  <9A13B378-9FC9-42D0-BB46-BCFD1FCFC8FB@cisco.com>
Date: Mon, 9 May 2011 16:57:45 +0800
Message-ID: 
From: Jacni Qin 
To: Fred Baker 
Content-Type: multipart/alternative; boundary=20cf307c9d2676cf1c04a2d40867
Cc: v6ops@ietf.org, Qiong 
Subject: Re: [v6ops] new draft: draft-sunq-v6ops-contents-transition-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, 09 May 2011 08:57:47 -0000

--20cf307c9d2676cf1c04a2d40867
Content-Type: text/plain; charset=ISO-8859-1

Hi Fred,

Thanks for the reply.

On Sun, May 8, 2011 at 9:51 PM, Fred Baker  wrote:

>
> On May 7, 2011, at 11:25 PM, Qiong wrote:
>
> > In this deployment, packet fragmentation and reassembly might take place
> due to the IPv4/IPv6 packet-length mismatch and MTU-mismatch. So, a
> fragmented IPv4/IPv6 packet should be firstly reassembled to an integrated
> packet, and then the NAT64 box will do IPv4/IPv6 packet translation, MTU
> discovery, and packet fragmentation if necessary.
>
>
> Per RFC 6145
>
> 1.4.  Path MTU Discovery and Fragmentation
>
>   Due to the different sizes of the IPv4 and IPv6 header, which are 20+
>   octets and 40 octets respectively, handling the maximum packet size
>   is critical for the operation of the IPv4/IPv6 translator.  There are
>   three mechanisms to handle this issue: path MTU discovery (PMTUD),
>   fragmentation, and transport-layer negotiation such as the TCP
>   Maximum Segment Size (MSS) option [RFC0879].  Note that the
>   translator MUST behave as a router, i.e., the translator MUST send a
>   Packet Too Big error message or fragment the packet when the packet
>   size exceeds the MTU of the next-hop interface.
>
>   Don't Fragment, ICMP Packet Too Big, and packet fragmentation are
>   discussed in Sections 4 and 5 of this document.  The reassembling of
>   fragmented packets in the stateful translator is discussed in
>   [RFC6146], since it requires state maintenance in the translator.
>
> Path MTU is mandatory in IPv6, so in the IPv6->IPv4 direction that should
> be sufficient for any fragmentation issues. In the IPv4->IPv6 direction,
> Path MTU addresses any case in which IPv4 DF is set. If DF is zero (the end
> system is expecting the network to fragment), I would expect you would look
> to section 4 for guidance. The section is too long to quote, but in essence
> the datagram is fragmented as an IPv4 datagram and then the fragments are
> translated into IPv6 datagrams containing the fragment header.
>

Jacni>:Thanks, maybe we can add a reference and some text.


>
> The reason to not reassemble and then re-fragment is that datagrams can be
> load-shared - they might not all go through the same translator.
>

Jacni>: Yes, load sharing is a good case.
And there is another special one mentioned in RFC6146, the "Incoming IPv4
UDP packets with a zero checksum" which must be reassembled.


Cheers,
Jacni

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

--20cf307c9d2676cf1c04a2d40867
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Fred,

Thanks for the reply.
=

On Sun, May 8, 2011 at 9:51 PM, Fred =
Baker <fred@cisco.co=
m> wrote:




On May 7, 2011, at 11:25 PM, Qiong wrote:



> In this deployment, packet fragmentation and reassembly might take pla=
ce due to the IPv4/IPv6 packet-length mismatch and MTU-mismatch. So, a frag=
mented IPv4/IPv6 packet should be firstly reassembled to an integrated pack=
et, and then the NAT64 box will do IPv4/IPv6 packet translation, MTU discov=
ery, and packet fragmentation if necessary.







Per RFC 6145



1.4. =A0Path MTU Discovery and Fragmentation



 =A0 Due to the different sizes of the IPv4 and IPv6 header, which are 20+<=
br>
 =A0 octets and 40 octets respectively, handling the maximum packet size
 =A0 is critical for the operation of the IPv4/IPv6 translator. =A0There ar=
e

 =A0 three mechanisms to handle this issue: path MTU discovery (PMTUD),

 =A0 fragmentation, and transport-layer negotiation such as the TCP

 =A0 Maximum Segment Size (MSS) option [RFC0879]. =A0Note that the

 =A0 translator MUST behave as a router, i.e., the translator MUST send a
 =A0 Packet Too Big error message or fragment the packet when the packet
 =A0 size exceeds the MTU of the next-hop interface.



 =A0 Don't Fragment, ICMP Packet Too Big, and packet fragmentation are<=
br>
 =A0 discussed in Sections 4 and 5 of this document. =A0The reassembling of=


 =A0 fragmented packets in the stateful translator is discussed in

 =A0 [RFC6146], since it requires state maintenance in the translator.



Path MTU is mandatory in IPv6, so in the IPv6->IPv4 direction that shoul=
d be sufficient for any fragmentation issues. In the IPv4->IPv6 directio=
n, Path MTU addresses any case in which IPv4 DF is set. If DF is zero (the =
end system is expecting the network to fragment), I would expect you would =
look to section 4 for guidance. The section is too long to quote, but in es=
sence the datagram is fragmented as an IPv4 datagram and then the fragments=
 are translated into IPv6 datagrams containing the fragment header.



Jacni>:Thanks, m=
aybe we can add a reference and some text.
=A0




The reason to not reassemble and then re-fragment is that datagrams can be =
load-shared - they might not all go through the same translator.

Jacni>: Yes, load shari=
ng is a good case.

And there is another special one mentioned in RFC6146, the "Incoming I=
Pv4 UDP packets with a zero checksum" which must be reassembled.

Cheers,
Jacni



_______________________________________________





--20cf307c9d2676cf1c04a2d40867--

From tjc@ecs.soton.ac.uk  Mon May  9 02:59: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 27380E06C0 for ; Mon,  9 May 2011 02:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149,  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 pPFJgkuCN0yA for ; Mon,  9 May 2011 02:59:19 -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 A24F5E0685 for ; Mon,  9 May 2011 02:59:17 -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 p499fLjj009615;  Mon, 9 May 2011 10:41:21 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p499fLjj009615
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1304934082; bh=jBYSLFG2ptAwVI6vP8X7aOjPC8s=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=crJ/NNoHrBBfZz7lMWCZcd5sjSxod0F8uuEiufdGVvc5aKQ8qoT+JaGoa2Zp46uO+ skOSOdhZEU34AH3ksjwjop0ZV1ii6ysGZ8E6MXJLxzoonul9rLVF1dYdbSteW1Yln7 gjy30I2XMQAq3Zh8jmuN6aSfY125MpQvFAw9/TLQ=
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 n48AfL0035646948wj ret-id none; Mon, 09 May 2011 10:41:22 +0100
Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p499fBZn026604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 May 2011 10:41:11 +0100
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-2-209356628
From: Tim Chown 
In-Reply-To: <8DC67846-4E1F-4D86-8B89-CA6105B26C10@cisco.com>
Date: Mon, 9 May 2011 10:41:10 +0100
Message-ID: 
References: <8DC67846-4E1F-4D86-8B89-CA6105B26C10@cisco.com> 
To: "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.1082)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n48AfL003564694800; tid=n48AfL0035646948wj; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: p499fLjj009615
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Cc: V6ops Chairs , Ron Bonica 
Subject: Re: [v6ops] Reminder: draft-chown-v6ops-call-to-arms WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 09:59:20 -0000

--Apple-Mail-2-209356628
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On 8 May 2011, at 19:00, Fred Baker wrote:

> The working group last call for this draft announced last week =
continues for another week. Please feel free to comment on it.
>=20

Hi,

Just for info the I-D announce that popped out on 6th May was from an =
update posted to the IETF submission tool on 19th April.  It is not the =
result of edits made on comments received in the last 3 weeks.

http://www.ietf.org/id/draft-chown-v6ops-call-to-arms-02.txt

Tim


--Apple-Mail-2-209356628
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


The =
working group last call for this draft announced last week continues for =
another week. Please feel free to comment on it.


Hi,

Just for info the I-D announce that popped out on =
6th May was from an update posted to the IETF submission tool on 19th =
April.  It is not the result of edits made on comments received in =
the last 3 weeks.

Tim

=

--Apple-Mail-2-209356628--

From marka@isc.org  Mon May  9 05: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 A634FE065A for ; Mon,  9 May 2011 05:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_44=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 UfIS8qs1ZV+C for ; Mon,  9 May 2011 05:05:55 -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 15EDDE07CC for ; Mon,  9 May 2011 05:05:54 -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 CA626C94BD; Mon,  9 May 2011 12:05:34 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 8E889216C1E; Mon,  9 May 2011 12:05: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 C07B3E9815A; Mon,  9 May 2011 22:05:51 +1000 (EST)
To: Ray Hunter 
From: Mark Andrews 
References: <20110509035345.2490FE957D0@drugs.dv.isc.org> <4DC7A852.6030801@globis.net>
In-reply-to: Your message of "Mon, 09 May 2011 10:39:46 +0200." <4DC7A852.6030801@globis.net>
Date: Mon, 09 May 2011 22:05:51 +1000
Message-Id: <20110509120551.C07B3E9815A@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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, 09 May 2011 12:05:56 -0000

In message <4DC7A852.6030801@globis.net>, Ray Hunter writes:
> This is a multi-part message in MIME format.
> --------------090500050302010506000404
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> -1 as it is proposed but +0.2 with a tweak.
> 
> In the ideal world this would have been baked into the original 
> deployment design from the very beginning, especially allowing the DHCP 
> "OFF" option plus making the default behavior OFF. Then it might have 
> been a really great idea.
> 
> Erm. But now? No thanks. 6to4 is enabled by default in Windows 7 and has 
> already been deployed on many desktops. The timing is just wrong. So an 
> option of having to place a "0.0.0.0" to turn off 6to4 via an option in 
> DHCP that is acted upon by a few nodes that have implemented a new 
> standard, whilst all other nodes ignore it, is just the wrong way around 
> IMHO.
> 
> This change as proposed would potentially put 6to4 even further out of 
> the control of the administrators of the transport network for the few 
> nodes that are going to support it. One wiseguy host admin flips one 
> switch in DHCP and the whole transport network goes haywire switching to 
> IPv6 over tunnels rather than native IPv4.

Only if the clients are requesting the option.

> At least the route to the well-known anycast address can be filtered and 
> controlled by the guys controlling the transport network (as already 
> clearly advised in the draft).

Which really doesn't help all that much.
 
> I can tell you that I'm spending a ratio of approx 40:1 of my time 
> worrying about how to stop inappropriate or unexpected deployment of 
> transition mechanisms messing up a perfectly good native IPv4 service 
> than I am worrying about how to deploy native IPv6.
> 
> These automatic tunnels should just be "off" by default.  There are an 
> awful lot of major enterprises considering a "Bring you own device" 
> policy and then running virtual desktops on top of those (or using cloud 
> computing). That means a lot of end nodes on the corporate networks may 
> be configured with default settings and may not even be controllable via 
> Active Directory as per today. That also means network transport admins 
> may have very limited tooling to be mandate / configure the 
> configuration of the end nodes. All of which suggest that the default 
> should be a "fail safe" so that the administrators of the transport 
> network can remain in control.

So the enterprise just sets "6to4-router 0.0.0.0;" and any client
that supports this disables itself when connected to the enterprise
network and re-enables itself when connected at home.

> However, if you also mandate OFF as the default when adding this DHCP 
> option, and so only a positive non NULL reply would enable 6to4 e.g..

> /etc/dhclient.conf:
> option 6to4-router code  = ip-address ;
> request subnet-mask, broadcast-address, time-offset, routers,
> 	domain-name, domain-name-servers, ntp-servers, 6to4-router;
> 
> /etc/dhclient-exit-hooks:
> 
> if [ "$new_6to4_router" != 0.0.0.0&&  "$new_6to4_router" != NULL]
> then
> 	...
> else
> 	...
> fi
> 
> 
> Then it well might be a marginal improvement, but of course would break 
> existing all deployments unless they also tweaked their DHCP repsonse to 
> include the option. So it's a bit of a no win situation (hence the +.2 
> in my vote.)

> But please don't make these transition mechanisms any worse / more 
> complicated to control than they already are now that they're out there.
> 
> All IMVHO [and bear in mind that I am just the messenger relaying what 
> these IT strategy guys are considering]
> 
> >
> > Blocking protocol 41*by ISPs*  is bad practice.  Blocking protocol
> > 41 without sending back destination unreachable by enterprises is
> > bad practice.
> >
> >    
> Got it. Is is possible to make this small tweak and add the "destination 
> unreachable" portion? I completely missed the significance of "silently" 
> even though I read that phrase many times.
> 
> best regards,
> RayH
> 
> 
> 
> 
> 
> 
> Mark Andrews wrote:
> > Better still would be to specify a default in dhclient.conf if the
> > administrator wants to use the anycast address as a fallback and
> > adjust dhclient-exit-hooks appropriately.
> >
> > Mark
> >
> > /etc/dhclient.conf:
> > option 6to4-router code  = ip-address ;
> > request subnet-mask, broadcast-address, time-offset, routers,
> > 	domain-name, domain-name-servers, ntp-servers, 6to4-router;
> > default 6to4-router 192.88.99.1;
> >
> > /etc/dhclient-exit-hooks:
> > if [ -n "$new_6to4_router"&&  "$new_6to4_router" != 0.0.0.0 ]
> > then
> >   	ether=`ifconfig $interface ether | sed -n s/ether//p | sed 's/:/ /g'`
> >   	local=`printf 2e%s:%sff:%s%s:%s%s $ether`
> >   	octets=`echo $new_ip_address | sed 's/\./ /g'`
> >   	stfaddress=2002:`printf %02x%02x:%02x%02x $octets`::$local
> >   	ifconfig stf0 inet6 $stfaddress prefixlen 16 alias
> >   	ifconfig stf0 inet6 | grep -v $stfaddress |
> >   		sed -n 's/inet6/ifconfig stf0 delete /p' | sh
> >   	octets=`echo $new_6to4_router | sed 's/\./ /g'`
> > 	route add inet6 default 2002:`printf %02x%02x:%02x%02x $octets`::
> > 	# configure internal interfaces.
> > elif [ -n "$new_6to4_router"&&  "$new_6to4_router" = 0.0.0.0 ]
> > then
> >   	route delete -inet6 default
> >   	ifconfig stf0 down
> >   	# deconfigure internal interfaces.
> > fi
> >    
> 
> 
> --------------090500050302010506000404
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> 
> 
> 
> 
>     http-equiv="Content-Type">
> 
> 
> -1 as it is proposed but +0.2 with a tweak.

> 

> In the ideal world this would have been baked into the original
> deployment design from the very beginning, especially allowing the DHCP
> "OFF" option plus making the default behavior OFF. Then it might have
> been a really great idea.

> 

> Erm. But now? No thanks. 6to4 is enabled by default in Windows 7 and
> has already been deployed on many desktops. The timing is just wrong.
> So an option of having to place a "0.0.0.0" to turn off 6to4 via an
> option in DHCP that is acted upon by a few nodes that have implemented
> a new standard, whilst all other nodes ignore it, is just the wrong way
> around IMHO. 

> 

> This change as proposed would potentially put 6to4 even further out of
> the control of the administrators of the transport network for the few
> nodes that are going to support it. One wiseguy host admin flips one
> switch in DHCP and the whole transport network goes haywire switching
> to IPv6 over tunnels rather than native IPv4.

> 

> At least the route to the well-known anycast address can be filtered
> and controlled by the guys controlling the transport network (as
> already clearly advised in the draft).

> 

> I can tell you that I'm spending a ratio of approx 40:1 of my time
> worrying about how to stop inappropriate or unexpected deployment of
> transition mechanisms messing up a perfectly good native IPv4 service
> than I am worrying about how to deploy native IPv6.

> 

> These automatic tunnels should just be "off" by default.  There are an
> awful lot of major enterprises considering a "Bring you own device"
> policy and then running virtual desktops on top of those (or using
> cloud computing). That means a lot of end nodes on the corporate
> networks may be configured with default settings and may not even be
> controllable via Active Directory as per today. That also means network
> transport admins may have very limited tooling to be mandate /
> configure the configuration of the end nodes. All of which suggest that
> the default should be a "fail safe" so that the administrators of the
> transport network can remain in control.

> 

> 

> 

> However, if you also mandate OFF as the default when adding this DHCP
> option, and so only a positive non NULL reply would enable 6to4 e.g..

> 

> 
/etc/dhclient.conf:
> option 6to4-router code <tbd> = ip-address ;
> request subnet-mask, broadcast-address, time-offset, routers,
> 	domain-name, domain-name-servers, ntp-servers, 6to4-router;
> 
> /etc/dhclient-exit-hooks:
> 
> if [ "$new_6to4_router" != 0.0.0.0 && "$new_6to4_router" != NULL]
> then
> 	...
> else
> 	...
> fi
> 
> 

> Then it well might be a marginal improvement, but of course would break
> existing all deployments unless they also tweaked their DHCP repsonse
> to include the option. So it's a bit of a no win situation (hence the
> +.2 in my vote.)

> 

> But please don't make these transition mechanisms any worse / more
> complicated to control than they already are now that they're out there.

> 

> All IMVHO [and bear in mind that I am just the messenger relaying what
> these IT strategy guys are considering]

> 

> 

>   

> Blocking protocol 41 * n>by ISPs  class="moz-txt-tag">* is bad practice.  Blocking protocol
> 41 without sending back destination unreachable by enterprises is
> bad practice.
> 
>   

> 

> Got it. Is is possible to make this small tweak and add the
> "destination unreachable" portion? I completely missed the significance
> of "silently" even though I read that phrase many times. 

> 

> best regards,

> RayH

> 

> 

> 

> 

> 

> 

> Mark Andrews wrote:
> 
  type="cite">
>   
Better still would be to specify a default in dhclient.conf if
>  the
> administrator wants to use the anycast address as a fallback and
> adjust dhclient-exit-hooks appropriately.
> 
> Mark
> 
> /etc/dhclient.conf:
> option 6to4-router code <tbd> = ip-address ;
> request subnet-mask, broadcast-address, time-offset, routers,
> 	domain-name, domain-name-servers, ntp-servers, 6to4-router;
> default 6to4-router 192.88.99.1;
>  
> /etc/dhclient-exit-hooks:
> if [ -n "$new_6to4_router" && "$new_6to4_router" != 0.0.0.0 ]
> then
>  	ether=`ifconfig $interface ether | sed -n s/ether//p | sed 's/:/ /g'`
>  	local=`printf 2e%s:%sff:%s%s:%s%s $ether`
>  	octets=`echo $new_ip_address | sed 's/\./ /g'`
>  	stfaddress=2002:`printf %02x%02x:%02x%02x $octets`::$local
>  	ifconfig stf0 inet6 $stfaddress prefixlen 16 alias
>  	ifconfig stf0 inet6 | grep -v $stfaddress |
>  		sed -n 's/inet6/ifconfig stf0 delete /p' | sh
>  	octets=`echo $new_6to4_router | sed 's/\./ /g'`
> 	route add inet6 default 2002:`printf %02x%02x:%02x%02x $octets`::
> 	# configure internal interfaces.
> elif [ -n "$new_6to4_router" && "$new_6to4_router" = 0.0.0.0 ]
> then
>  	route delete -inet6 default
>  	ifconfig stf0 down
>  	# deconfigure internal interfaces.
> fi
>   

> 

> 

> 
> 
> 
> --------------090500050302010506000404--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From v6ops@globis.net  Mon May  9 06:25: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 6A672E06CC for ; Mon,  9 May 2011 06:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.966
X-Spam-Level: 
X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=0.317,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 c7Wgl-aAkUfe for ; Mon,  9 May 2011 06:25:26 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7C594E0663 for ; Mon,  9 May 2011 06:25:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D97A98700F1; Mon,  9 May 2011 15:25:20 +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 lD3LJlY7WVG6; Mon,  9 May 2011 15:25:14 +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 80894870062; Mon,  9 May 2011 15:25:14 +0200 (CEST)
Message-ID: <4DC7EB2D.2070504@globis.net>
Date: Mon, 09 May 2011 15:25:01 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Mark Andrews 
References: <20110509035345.2490FE957D0@drugs.dv.isc.org> <4DC7A852.6030801@globis.net> <20110509120551.C07B3E9815A@drugs.dv.isc.org>
In-Reply-To: <20110509120551.C07B3E9815A@drugs.dv.isc.org>
Content-Type: multipart/alternative; boundary="------------010806040304010402080402"
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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, 09 May 2011 13:25:27 -0000

This is a multi-part message in MIME format.
--------------010806040304010402080402
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

It sounds like I'm the only paranoid on this list.

Mark Andrews wrote:
> In message<4DC7A852.6030801@globis.net>, Ray Hunter writes:
>    
>> This is a multi-part message in MIME format.
>> --------------090500050302010506000404
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> Content-Transfer-Encoding: 7bit
>>
>> -1 as it is proposed but +0.2 with a tweak.
>>
>> In the ideal world this would have been baked into the original
>> deployment design from the very beginning, especially allowing the DHCP
>> "OFF" option plus making the default behavior OFF. Then it might have
>> been a really great idea.
>>
>> Erm. But now? No thanks. 6to4 is enabled by default in Windows 7 and has
>> already been deployed on many desktops. The timing is just wrong. So an
>> option of having to place a "0.0.0.0" to turn off 6to4 via an option in
>> DHCP that is acted upon by a few nodes that have implemented a new
>> standard, whilst all other nodes ignore it, is just the wrong way around
>> IMHO.
>>
>> This change as proposed would potentially put 6to4 even further out of
>> the control of the administrators of the transport network for the few
>> nodes that are going to support it. One wiseguy host admin flips one
>> switch in DHCP and the whole transport network goes haywire switching to
>> IPv6 over tunnels rather than native IPv4.
>>      
>
> Only if the clients are requesting the option.
>
>    
And knowing the record of IPv6 implementations so far, the default is 
"on" and "yes, go for it!" (which I very much regret)
>> At least the route to the well-known anycast address can be filtered and
>> controlled by the guys controlling the transport network (as already
>> clearly advised in the draft).
>>      
>
> Which really doesn't help all that much.
>
>    
Yes it does. It prevents automatic tunnels from messing up QoS and 
latency of native IPv4 connectivity used in production networks.

If the tunnel can't be built to the anycast address it ain't going to 
cause uncontrolled trombone-ing in the network.

You guys seem to work on the fact that everything is homogeneous, 
networks are small, and 100% of admins know what they are doing.

I prefer a few more fail-safes. DNS and DHCP servers are generally 
managed by the network group in enterprises. DHCP and DNS content is 
generally not managed by the same guys who manage the transport network. 
In fact an awful lot of content is auto-generated nowadays (via AD)

>> I can tell you that I'm spending a ratio of approx 40:1 of my time
>> worrying about how to stop inappropriate or unexpected deployment of
>> transition mechanisms messing up a perfectly good native IPv4 service
>> than I am worrying about how to deploy native IPv6.
>>
>> These automatic tunnels should just be "off" by default.  There are an
>> awful lot of major enterprises considering a "Bring you own device"
>> policy and then running virtual desktops on top of those (or using cloud
>> computing). That means a lot of end nodes on the corporate networks may
>> be configured with default settings and may not even be controllable via
>> Active Directory as per today. That also means network transport admins
>> may have very limited tooling to be mandate / configure the
>> configuration of the end nodes. All of which suggest that the default
>> should be a "fail safe" so that the administrators of the transport
>> network can remain in control.
>>      
>
> So the enterprise just sets "6to4-router 0.0.0.0;" and any client
> that supports this disables itself when connected to the enterprise
> network and re-enables itself when connected at home.
>
>    
Remember in RFC3484 (out in the wild today on hundreds of thousands if 
not millions of desktop machines) 6to4 is preferred over IPv4 (that 
changes in RFC3484 bis, but how many nodes implement that today in 
production? precisely zero AFAIK.) And then you have yet another 
dependency / combination of things that could go wrong .... node 
implements 6to4 router config detection via DHCP before implementing 
RFC3484 bis.

This is yet another thing for an enterprise manager to "turn off" in 
order to maintain control. And this one I find hard to guarantee. How do 
I grant rights to an inexperienced DHCP admin to be able to add custom 
DHCP entry for turning on some useful feature like setting up a local 
print server or back up server, and yet prevent them from adding some 
content that is potentially disruptive for the normal business 
operations of a corporation?

Besides which, the flip side is also true. Since when has DHCP been 
universally deployed and controlled?

I presume this has to be a DHCP (v4) option, because at the point the 
record is requested there (may/will) be no IPv6 connectivity available 
to a DHVPv6 server. Otherwise what's the benefit of 6to4? Chicken and egg.

Once again firewalls and CPE routers creep in. The DHCP server behind a 
firewall is often run on the CPE, and not centrally. So the end hosts 
would probably not even see the central ISP setting. Or will that all 
change in IPv6 and home users have to start trusting an ISP's DHCP and 
DHCPv6?

All of this auto-configuration stuff is nice and works well in small and 
homogeneous environments. But my experience in practice tells me 
otherwise. Especially during a major transition. Remember Appletalk II 
ZIP storms? I do.

As I wrote to Fred Templin, we wouldn't design an aircraft with features 
that deployed major functionality or configuration changes automatically 
based on some remote and opaque dependency on external content. I 
wouldn't want the wheels to go down automatically if the aircraft 
thought it was at 100ft up, because the altimeter may be broken and the 
aircraft may be at 30000 feet and flying at 600 mph. Why are we assuming 
that this is a good idea to implement these features in network 
protocols, where the deployment is at least 2 steps removed from IETF 
control (implementers / developers and then network managers)?

We shouldn't be in the business of second guessing the guys who are 
managing the transition of the transport network.

best regards,
RayH
>> However, if you also mandate OFF as the default when adding this DHCP
>> option, and so only a positive non NULL reply would enable 6to4 e.g..
>>      
>
>    
>> /etc/dhclient.conf:
>> option 6to4-router code   = ip-address ;
>> request subnet-mask, broadcast-address, time-offset, routers,
>> 	domain-name, domain-name-servers, ntp-servers, 6to4-router;
>>
>> /etc/dhclient-exit-hooks:
>>
>> if [ "$new_6to4_router" != 0.0.0.0&&   "$new_6to4_router" != NULL]
>> then
>> 	...
>> else
>> 	...
>> fi
>>
>>
>> Then it well might be a marginal improvement, but of course would break
>> existing all deployments unless they also tweaked their DHCP repsonse to
>> include the option. So it's a bit of a no win situation (hence the +.2
>> in my vote.)
>>      
>
>    
>> But please don't make these transition mechanisms any worse / more
>> complicated to control than they already are now that they're out there.
>>
>> All IMVHO [and bear in mind that I am just the messenger relaying what
>> these IT strategy guys are considering]
>>
>>      
>>> Blocking protocol 41*by ISPs*  is bad practice.  Blocking protocol
>>> 41 without sending back destination unreachable by enterprises is
>>> bad practice.
>>>
>>>
>>>        
>> Got it. Is is possible to make this small tweak and add the "destination
>> unreachable" portion? I completely missed the significance of "silently"
>> even though I read that phrase many times.
>>
>> best regards,
>> RayH
>>
>>
>>
>>
>>
>>
>> Mark Andrews wrote:
>>      
>>> Better still would be to specify a default in dhclient.conf if the
>>> administrator wants to use the anycast address as a fallback and
>>> adjust dhclient-exit-hooks appropriately.
>>>
>>> Mark
>>>
>>> /etc/dhclient.conf:
>>> option 6to4-router code   = ip-address ;
>>> request subnet-mask, broadcast-address, time-offset, routers,
>>> 	domain-name, domain-name-servers, ntp-servers, 6to4-router;
>>> default 6to4-router 192.88.99.1;
>>>
>>> /etc/dhclient-exit-hooks:
>>> if [ -n "$new_6to4_router"&&   "$new_6to4_router" != 0.0.0.0 ]
>>> then
>>>    	ether=`ifconfig $interface ether | sed -n s/ether//p | sed 's/:/ /g'`
>>>    	local=`printf 2e%s:%sff:%s%s:%s%s $ether`
>>>    	octets=`echo $new_ip_address | sed 's/\./ /g'`
>>>    	stfaddress=2002:`printf %02x%02x:%02x%02x $octets`::$local
>>>    	ifconfig stf0 inet6 $stfaddress prefixlen 16 alias
>>>    	ifconfig stf0 inet6 | grep -v $stfaddress |
>>>    		sed -n 's/inet6/ifconfig stf0 delete /p' | sh
>>>    	octets=`echo $new_6to4_router | sed 's/\./ /g'`
>>> 	route add inet6 default 2002:`printf %02x%02x:%02x%02x $octets`::
>>> 	# configure internal interfaces.
>>> elif [ -n "$new_6to4_router"&&   "$new_6to4_router" = 0.0.0.0 ]
>>> then
>>>    	route delete -inet6 default
>>>    	ifconfig stf0 down
>>>    	# deconfigure internal interfaces.
>>> fi
>>>
>>>        
>>      


--------------010806040304010402080402
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


It sounds like I'm the only paranoid on this list.



Mark Andrews wrote:


  
In message <4DC7A852.6030801@globis.net>, Ray Hunter writes:
  

  

    
This is a multi-part message in MIME format.
--------------090500050302010506000404
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

-1 as it is proposed but +0.2 with a tweak.

In the ideal world this would have been baked into the original 
deployment design from the very beginning, especially allowing the DHCP 
"OFF" option plus making the default behavior OFF. Then it might have 
been a really great idea.

Erm. But now? No thanks. 6to4 is enabled by default in Windows 7 and has 
already been deployed on many desktops. The timing is just wrong. So an 
option of having to place a "0.0.0.0" to turn off 6to4 via an option in 
DHCP that is acted upon by a few nodes that have implemented a new 
standard, whilst all other nodes ignore it, is just the wrong way around 
IMHO.

This change as proposed would potentially put 6to4 even further out of 
the control of the administrators of the transport network for the few 
nodes that are going to support it. One wiseguy host admin flips one 
switch in DHCP and the whole transport network goes haywire switching to 
IPv6 over tunnels rather than native IPv4.
    

  

  

Only if the clients are requesting the option.

  



And knowing the record of IPv6 implementations so far, the default is
"on" and "yes, go for it!" (which I very much regret)



  

  

    
At least the route to the well-known anycast address can be filtered and 
controlled by the guys controlling the transport network (as already 
clearly advised in the draft).
    

  

  

Which really doesn't help all that much.
 
  



Yes it does. It prevents automatic tunnels from messing up QoS and
latency of native IPv4 connectivity used in production networks.



If the tunnel can't be built to the anycast address it ain't going to
cause uncontrolled trombone-ing in the network.



You guys seem to work on the fact that everything is homogeneous,
networks are small, and 100% of admins know what they are doing.



I prefer a few more fail-safes. DNS and DHCP servers are generally
managed by the network group in enterprises. DHCP and DNS content is
generally not managed by the same guys who manage the transport
network. In fact an awful lot of content is auto-generated nowadays
(via AD)





  

    
I can tell you that I'm spending a ratio of approx 40:1 of my time 
worrying about how to stop inappropriate or unexpected deployment of 
transition mechanisms messing up a perfectly good native IPv4 service 
than I am worrying about how to deploy native IPv6.

These automatic tunnels should just be "off" by default.  There are an 
awful lot of major enterprises considering a "Bring you own device" 
policy and then running virtual desktops on top of those (or using cloud 
computing). That means a lot of end nodes on the corporate networks may 
be configured with default settings and may not even be controllable via 
Active Directory as per today. That also means network transport admins 
may have very limited tooling to be mandate / configure the 
configuration of the end nodes. All of which suggest that the default 
should be a "fail safe" so that the administrators of the transport 
network can remain in control.
    

  

  

So the enterprise just sets "6to4-router 0.0.0.0;" and any client
that supports this disables itself when connected to the enterprise
network and re-enables itself when connected at home.

  



Remember in RFC3484 (out in the wild today on hundreds of thousands if
not millions of desktop machines) 6to4 is preferred over IPv4
(that changes in RFC3484 bis, but how many nodes implement that today
in production? precisely zero AFAIK.) And then you have yet another
dependency / combination of things that could go wrong .... node
implements 6to4 router config detection via DHCP before implementing
RFC3484 bis.



This is yet another thing for an enterprise manager to "turn off" in
order to maintain control. And this one I find hard to guarantee. How
do I grant rights to an inexperienced DHCP admin to be able to add
custom DHCP entry for turning on some useful feature like setting up a
local print server or back up server, and yet prevent them from adding
some content that is potentially disruptive for the normal business
operations of a corporation? 



Besides which, the flip side is also true. Since when has DHCP been
universally deployed and controlled?



I presume this has to be a DHCP (v4) option, because at the point the
record is requested there (may/will) be no IPv6 connectivity available
to a DHVPv6 server. Otherwise what's the benefit of 6to4? Chicken and
egg.



Once again firewalls and CPE routers creep in. The DHCP server behind a
firewall is often run on the CPE, and not centrally. So the end hosts
would probably not even see the central ISP setting. Or will that all
change in IPv6 and home users have to start trusting an ISP's DHCP and
DHCPv6?



All of this auto-configuration stuff is nice and works well in small
and homogeneous environments. But my experience in practice tells me
otherwise. Especially during a major transition. Remember Appletalk II
ZIP storms? I do.



As I wrote to Fred Templin, we wouldn't design an aircraft with
features
that deployed major functionality or configuration changes
automatically based on some remote and opaque dependency on external
content. I wouldn't want the wheels to go down automatically if the
aircraft thought it was at
100ft up, because the altimeter may be broken and the aircraft may be
at 30000 feet and flying at 600 mph. Why are we assuming that this
is a good idea to implement these features in network protocols, where
the deployment is at least
2 steps removed from IETF control (implementers / developers and then
network
managers)?



We shouldn't be in the business of second guessing the guys who are
managing the transition of the transport network.



best regards,

RayH



  

  

    
However, if you also mandate OFF as the default when adding this DHCP 
option, and so only a positive non NULL reply would enable 6to4 e.g..
    

  

  

  

  

    
/etc/dhclient.conf:
option 6to4-router code<tbd>  = ip-address ;
request subnet-mask, broadcast-address, time-offset, routers,
	domain-name, domain-name-servers, ntp-servers, 6to4-router;

/etc/dhclient-exit-hooks:

if [ "$new_6to4_router" != 0.0.0.0&&  "$new_6to4_router" != NULL]
then
	...
else
	...
fi


Then it well might be a marginal improvement, but of course would break 
existing all deployments unless they also tweaked their DHCP repsonse to 
include the option. So it's a bit of a no win situation (hence the +.2 
in my vote.)
    

  

  

  

  

    
But please don't make these transition mechanisms any worse / more 
complicated to control than they already are now that they're out there.

All IMVHO [and bear in mind that I am just the messenger relaying what 
these IT strategy guys are considering]

    

    

      
Blocking protocol 41*by ISPs*  is bad practice.  Blocking protocol
41 without sending back destination unreachable by enterprises is
bad practice.

   
      

    

    
Got it. Is is possible to make this small tweak and add the "destination 
unreachable" portion? I completely missed the significance of "silently" 
even though I read that phrase many times.

best regards,
RayH






Mark Andrews wrote:
    

    

      
Better still would be to specify a default in dhclient.conf if the
administrator wants to use the anycast address as a fallback and
adjust dhclient-exit-hooks appropriately.

Mark

/etc/dhclient.conf:
option 6to4-router code<tbd>  = ip-address ;
request subnet-mask, broadcast-address, time-offset, routers,
	domain-name, domain-name-servers, ntp-servers, 6to4-router;
default 6to4-router 192.88.99.1;

/etc/dhclient-exit-hooks:
if [ -n "$new_6to4_router"&&  "$new_6to4_router" != 0.0.0.0 ]
then
  	ether=`ifconfig $interface ether | sed -n s/ether//p | sed 's/:/ /g'`
  	local=`printf 2e%s:%sff:%s%s:%s%s $ether`
  	octets=`echo $new_ip_address | sed 's/\./ /g'`
  	stfaddress=2002:`printf %02x%02x:%02x%02x $octets`::$local
  	ifconfig stf0 inet6 $stfaddress prefixlen 16 alias
  	ifconfig stf0 inet6 | grep -v $stfaddress |
  		sed -n 's/inet6/ifconfig stf0 delete /p' | sh
  	octets=`echo $new_6to4_router | sed 's/\./ /g'`
	route add inet6 default 2002:`printf %02x%02x:%02x%02x $octets`::
	# configure internal interfaces.
elif [ -n "$new_6to4_router"&&  "$new_6to4_router" = 0.0.0.0 ]
then
  	route delete -inet6 default
  	ifconfig stf0 down
  	# deconfigure internal interfaces.
fi
   
      

    

    
    

  








--------------010806040304010402080402--

From marka@isc.org  Mon May  9 06:52: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 00035E06C0 for ; Mon,  9 May 2011 06:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=4.600,  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 zmwOnUhh-j-I for ; Mon,  9 May 2011 06:51:58 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id D1853E06B7 for ; Mon,  9 May 2011 06:51:58 -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 BA487C94BD; Mon,  9 May 2011 13:51:42 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 84559216C1E; Mon,  9 May 2011 13:51:42 +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 DA2F7E98499; Mon,  9 May 2011 23:52:02 +1000 (EST)
To: Ray Hunter 
From: Mark Andrews 
References: <20110509035345.2490FE957D0@drugs.dv.isc.org> <4DC7A852.6030801@globis.net> <20110509120551.C07B3E9815A@drugs.dv.isc.org> <4DC7EB2D.2070504@globis.net>
In-reply-to: Your message of "Mon, 09 May 2011 15:25:01 +0200." <4DC7EB2D.2070504@globis.net>
Date: Mon, 09 May 2011 23:52:02 +1000
Message-Id: <20110509135202.DA2F7E98499@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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, 09 May 2011 13:52:00 -0000

You make a assumption that the presence of the option indicates
that the client SHOULD perform 6to4.  It does not.

The option tells the client HOW to perform 6to4 and if it SHOULD
disable 6to4.  It does NOT tell the client to perform 6to4.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From fred@cisco.com  Mon May  9 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 B795EE06A2 for ; Mon,  9 May 2011 06:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.073
X-Spam-Level: 
X-Spam-Status: No, score=-110.073 tagged_above=-999 required=5 tests=[AWL=0.526, 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 w1a3He-7PAvs for ; Mon,  9 May 2011 06:55:02 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 30E30E0656 for ; Mon,  9 May 2011 06:55:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=140; q=dns/txt; s=iport; t=1304949302; x=1306158902; h=date:from:message-id:to:subject:cc; bh=2U09mCO6jaK+NjaotqxZ8YPJN0TGzBK/9jOmZCxSB7w=; b=B4hcUW2bQTFLhoLuTgc2Aknyx8rfSZUgoLZJjSgU2TxJpHEzHboVcO+W MRfJ6AiHhHdqfJ64GIR5wUKaa0uRDHWFJN+Zztq5vvOm+2Yj0/m8vAyv2 wtTHR5Yuj6H1zSSJhcoC3Q/QSZDEFqkWW+arXBolrbxAT3V9Vte5oWYgv 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ar0HANXxx02rRDoJ/2dsb2JhbACYDgEBjWx3qGmdVoYMBIZAmCI
X-IronPort-AV: E=Sophos;i="4.64,340,1301875200"; d="scan'208";a="694159501"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 09 May 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 p49Dt1DK018209; Mon, 9 May 2011 13:55:01 GMT
Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p49Dt1h12484; Mon, 9 May 2011 06:55:01 -0700 (PDT)
Date: Mon, 9 May 2011 06:55:01 -0700 (PDT)
From: 
Message-Id: <201105091355.p49Dt1h12484@ftpeng-update.cisco.com>
To: v6ops@ietf.org
Cc: draft-andrews-v6ops-6to4-router-option@tools.ietf.org
Subject: [v6ops] new draft: draft-andrews-v6ops-6to4-router-option-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, 09 May 2011 13:55:02 -0000

A new draft has been posted, at http://tools.ietf.org/html/draft-andrews-v6ops-6to4-router-option. Please take a look at it and comment.

From pch-b6B5344D9@u-1.phicoh.com  Mon May  9 07:44: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 C3713E072F for ; Mon,  9 May 2011 07:44:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.155
X-Spam-Level: 
X-Spam-Status: No, score=-8.155 tagged_above=-999 required=5 tests=[AWL=0.444,  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 Lvy+8ENaXUJd for ; Mon,  9 May 2011 07:44:33 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5D2E071C for ; Mon,  9 May 2011 07:44:32 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QJRXU-00006pC; Mon, 9 May 2011 16:34:24 +0200
Message-Id: 
To: fred@cisco.com
From: Philip Homburg 
Sender: pch-b6B5344D9@u-1.phicoh.com
In-reply-to: Your message of "Mon, 9 May 2011 06:55:01 -0700 (PDT) ." <201105091355.p49Dt1h12484@ftpeng-update.cisco.com> 
Date: Mon, 09 May 2011 16:34:18 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-andrews-v6ops-6to4-router-option-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, 09 May 2011 14:44:34 -0000

In your letter dated Mon, 9 May 2011 06:55:01 -0700 (PDT) you wrote:
>A new draft has been posted, at http://tools.ietf.org/html/draft-andrews-v6ops
>-6to4-router-option. Please take a look at it and comment.

The first question I have is why would anyone want to use an address other
than the RFC-3068 defined one?  What's the point? 

I think it is important to evaluate 6ot4 in the context of the measurements
done by Geoff Huston and others. And using a different IPv4 address for the
relay is most likely just going to break things.

The second question is the value of disabling 6to4 by returning 0.0.0.0. By
itself that sounds like a useful feature. But features are not for free. 
You have implement them, document them, test them. There may have unexpected
security or other operational implications, etc.

So assuming that in future 6to4 is disabled by default. The only thing this
feature does override the user's preference to turn 6to4 on. I don't think it
makes any sense to implement this feature.



From v6ops@globis.net  Mon May  9 07:58: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 71444E07A1 for ; Mon,  9 May 2011 07:58:48 -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 CtrWn20dI07z for ; Mon,  9 May 2011 07:58:48 -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 9376FE077C for ; Mon,  9 May 2011 07:58:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 65B558700B3; Mon,  9 May 2011 16:58:45 +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 vXggskop-QZl; Mon,  9 May 2011 16:58:40 +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 5DBA987007F; Mon,  9 May 2011 16:58:40 +0200 (CEST)
Message-ID: <4DC80113.9050007@globis.net>
Date: Mon, 09 May 2011 16:58:27 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Mark Andrews 
References: <20110509035345.2490FE957D0@drugs.dv.isc.org> <4DC7A852.6030801@globis.net> <20110509120551.C07B3E9815A@drugs.dv.isc.org> <4DC7EB2D.2070504@globis.net> <20110509135202.DA2F7E98499@drugs.dv.isc.org>
In-Reply-To: <20110509135202.DA2F7E98499@drugs.dv.isc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-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, 09 May 2011 14:58:48 -0000

You appear to be claiming to be agnostic as to whether 6to4 is enabled 
or not.

Your code fragment example that you attached to your original post would 
appear to have indeed assumed that 6to4 is on by default, unless of 
course there is some tweak elsewhere to detect the admin status of 6to4 
(which I couldn't find in all of maybe 5 minutes looking on my own local 
Linux box, so I don't discount it really exists). Hence my assumption 
that 6to4 was "on" by default, which is why I suggested the 
$new_6to4_router" != NULL edit.

So I think it was maybe a reasonable assumption to make at the time, 
given the context of the discussion and the information available so 
far. Apologies if that wasn't your intention.

I'd personally be delighted if your proposal would go one stage further 
and suggest that the default for 6to4 is "off", although you may argue 
that is not your problem and is outside your scope.

As a guy who transitions operational networks, I can't afford that 
luxury of selectivity. I can't close my eyes to the reality that 6to4 is 
"on" by default in many cases, and also to the reality that RC3484 is 
also the norm out there today (at least on some popular OS's), no matter 
how attractive another tweak in an RFC looks.

So the base line assumption of any new proposal should be made on the 
assumption that "6to4" is already "on" and we should heed the 
Hippocratic oath of "do no harm" IMHO. Adding yet another option for 
giving a different addresses to a 6to4 router is potentially harmful in 
my book, because the transport network manager can no longer filter them 
out and stay in control of the network (apparently all of protocol 41 
can't blocked, as then ISATAP would be disabled too if they ever wanted 
to use that protocol [I don't]). Yours and others perception may be 
different.

But most of all, I'd be delighted if we stopped trying to tweak a 
protocol (6to4) that we apparently all agree is broken, and instead 
started debating how to roll out and improve and support native IPv6.

I have seen precious few posts on the v6ops list on how to do that. And 
at the minute I am really struggling to see what tools are available to 
the typical transport network manager that supply sufficient 
granularity, together with an associated scalable  administrative model, 
to be able to remain in control of the IPv4 network and guarantee 
ongoing production, whilst at the same time introducing IPv6 gradually.

Good luck with developing your proposal further.

regards,
RayH

Mark Andrews wrote:
> You make a assumption that the presence of the option indicates
> that the client SHOULD perform 6to4.  It does not.
>
> The option tells the client HOW to perform 6to4 and if it SHOULD
> disable 6to4.  It does NOT tell the client to perform 6to4.
>
> Mark
>    


From K.Fleischhauer@telekom.de  Mon May  9 09:01: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 E3B04E07E9 for ; Mon,  9 May 2011 09:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 IcHBfWbAoiN6 for ; Mon,  9 May 2011 09:01:18 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7B222E06FD for ; Mon,  9 May 2011 09:01:15 -0700 (PDT)
Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 09 May 2011 18:01:08 +0200
Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.39]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Mon, 9 May 2011 18:01:08 +0200
From: 
To: , 
Date: Mon, 9 May 2011 18:01:06 +0200
Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 - traffic load considerations
Thread-Index: AQHMCZzqgewuui2dTEKFUhZWXW2in5R7bjWA///0gICABJFlgIAAShmA///NA4CAA3mpYA==
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840C5B42E@HE111648.emea1.cds.t-internal.com>
References: <4DC41BE5.8050403@bbiw.net> 
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 - traffic load considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 16:01:19 -0000

Dear Jason,

a more or less arbitrarily using of the AAAA whitelisting configuration
without coordination of all involved networks could lead IMHO to unexpected=
 traffic behaviour respectively traffic load in some segments of the intern=
et.
That should be valid as long as the internet is not complete Dual-Stack ena=
bled
or when no congruent IPv4/v6 network topology is available.
I would expect at least that the latter case will never occur.

Therefore I propose the following text in section 7.3.x of the draft.

"
7.3.x Unexpected changes and shifts in traffic load on links and network se=
gments

In the case when large content provider would using DNS whitelisting for DN=
S resolver of
access provider [is this now the right term?] to be whitelisted or not will=
 change significant
the traffic volume for IPv4 or IPv6 between both parties.
Also when the overall traffic is stable, in the case that there is not a co=
ngruent IPv4-IPv6 topology available whitelisting will lead to changes in t=
raffic load of individual links and network segments between the access and=
 the content provider.
In the case of creating a whitelist entry traffic will be shifted to IPv4 a=
nd the IPv4 capable links and network segments.
In the case of deleting a whitelist entry traffic will be shifted to IPv6 a=
nd the IPv6 capable links and network segments.
When the DNS whitelisting occur without coordination between the content an=
d the access provider this could cause challenges in the traffic engineerin=
g.
"


Best

KARSTEN

From Internet-Drafts@ietf.org  Mon May  9 09:30: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 7D9D7E087D; Mon,  9 May 2011 09:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.576
X-Spam-Level: 
X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 m1E1uXBSEHEj; Mon,  9 May 2011 09:30:12 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0955E086B; Mon,  9 May 2011 09:30: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.53
Message-ID: <20110509163003.30973.3663.idtracker@ietfa.amsl.com>
Date: Mon, 09 May 2011 09:30:03 -0700
Cc: v6ops@ietf.org
Subject: [v6ops] I-D ACTION:draft-ietf-v6ops-v6-in-mobile-networks-04.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, 09 May 2011 16:30:13 -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         : Mobile Networks Considerations for IPv6 Deployment
    Author(s)     : R. Koodli
    Filename      : draft-ietf-v6ops-v6-in-mobile-networks-04.txt
    Pages         : 18
    Date          : 2011-04-25
    
   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.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-in-mobile-networks-04.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-v6-in-mobile-networks-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2011-05-09092716.I-D@ietf.org>


--NextPart--

From lorenzo@google.com  Mon May  9 09:36: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 5E2ABE0912 for ; Mon,  9 May 2011 09:36:56 -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, J_CHICKENPOX_37=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 cAuMGDseoH8c for ; Mon,  9 May 2011 09:36:55 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1652AE0852 for ; Mon,  9 May 2011 09:36:38 -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 p49GF1Y7028952 for ; Mon, 9 May 2011 09:15:01 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304957701; bh=3OEbeHfjgzgvo1WHTAOME3bm8as=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=h01YKT53BGrsEln6lxGGR9gQQQe7An5HU0Nxhx65oey3BqTOj1B9T7JJ+TrjYhwG8 LJNG+OdmkZEUpI+hw5UUw==
Received: from gxk10 (gxk10.prod.google.com [10.202.11.10]) by kpbe11.cbf.corp.google.com with ESMTP id p49GEk5K003513 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 9 May 2011 09:15:00 -0700
Received: by gxk10 with SMTP id 10so2398680gxk.25 for ; Mon, 09 May 2011 09:15:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=724qXlI5MTKtBTZVhXwesupSpJVUMauX3AufLuV5nZY=; b=yxVb1PAqKeFi0VT9kh7tvhvDy8EyM2ZfuJb8ZOJcjYsWm/4m3RgyRNGcgNyLoZJF4D Ax6UzxcKLkPPripJJsyA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=uMOX4zonWh5yXk38aCfDvSGe8DqVc1mJj3feZY8GC5HSADfc/mP//VDF/ckQ6POHPO IqEdxhdZ8IA3+ILSGvlQ==
Received: by 10.150.195.18 with SMTP id s18mr5706727ybf.207.1304957699152; Mon, 09 May 2011 09:14:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Mon, 9 May 2011 09:14:39 -0700 (PDT)
In-Reply-To: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>
From: Lorenzo Colitti 
Date: Mon, 9 May 2011 09:14:39 -0700
Message-ID: 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=000e0cd4d83c1ade2604a2da241b
X-System-Of-Record: true
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 09 May 2011 16:36:56 -0000

--000e0cd4d83c1ade2604a2da241b
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 9, 2011 at 1:08 AM, Mark Andrews  wrote:

>
>        I just posted draft-andrews-v6ops-6to4-router-option-00.txt.
>        Feedback welcome.
>


I don't see any reason to do this.

First: if you're an operator (and you probably are, since you have the power
to control the DHCP server), you can already ensure 6to4 nodes to use your
relay by making sure that 192.88.99.1 is routed to it. You don't have to
change the OS stacks at all. Thus no RFC, no IANA DHCP option assignment, no
implementation changes on the server or on the client, ...

Second: this only makes the forward path more reliable. Reverse path is
still unreliable because it is not under your control (the server will just
pick whatever anycast 6to4 relay is closest to it). The only way to fix that
is by using 6rd or something like 6to4-PMT, which the WG did not adopt as an
item.

Third: as Erik says, you're really just reinventing a part of 6rd. More
specifically: RFC 3068-style anycast 6to4 is a special case of 6rd
where IPv4MaskLen = 0, 6rdPrefix = 2002::, 6rdPrefixLen = 16,
and 6rdBRIPv4Address = 192.88.99.1. From a protocol perspective, what you
are doing is adding the 6rdBRIPv4Address parameter, but not the other three
parameters, to 6to4. I think that instead of asking implementors to do this,
we should just ask them to implement 6rd instead.

--000e0cd4d83c1ade2604a2da241b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, May 9, 2011 at 1:08 AM, Mark Andrews <marka@isc.org> wrote:




 =A0 =A0 =A0 =A0I just posted draft-andrews-v6ops-6to4-router-option-00.txt=
.

 =A0 =A0 =A0 =A0Feedback welcome.


<=
/div>
I don't see any reason to do this.

<=
div>First: if you're an operator (and you probably are, since you have =
the power to control the DHCP server), you can already ensure 6to4 nodes to=
 use your relay by making sure that=A0192.88.99.1 is routed to it. You don&=
#39;t have to change the OS stacks at all. Thus no RFC, no IANA DHCP option=
 assignment, no implementation changes on the server or on the client, ...<=
/div>



Second: this only makes the forward path more rel=
iable. Reverse path is still unreliable because it is not under your contro=
l (the server will just pick whatever anycast 6to4 relay is closest to it).=
 The only way to fix that is by using 6rd or something like 6to4-PMT, which=
 the WG did not adopt as an item.




Third: as Erik says, you're really just reinventing=
 a part of 6rd.=A0More specifically: RFC 3068-style anycast 6to4 is a speci=
al case of 6rd where=A0IPv4MaskLen =3D 0,=A06rdPrefix =3D 2002::, 6rdPrefix=
Len =3D 16, and=A06rdBRIPv4Address =3D 192.88.99.1. From a protocol perspec=
tive,=A0what you are doing is adding the 6rdBRIPv4Address parameter, but no=
t the other three parameters, to 6to4.=A0I think that instead of asking imp=
lementors to do this, we should just ask them to implement 6rd instead.



--000e0cd4d83c1ade2604a2da241b--

From pch-b6B5344D9@u-1.phicoh.com  Mon May  9 10:12: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 88137E06DC for ; Mon,  9 May 2011 10:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.199
X-Spam-Level: 
X-Spam-Status: No, score=-8.199 tagged_above=-999 required=5 tests=[AWL=0.400,  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 9sE2Ym+7G2jf for ; Mon,  9 May 2011 10:12:22 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 02364E06C3 for ; Mon,  9 May 2011 10:12:21 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QJU0A-00021cC; Mon, 9 May 2011 19:12:10 +0200
Message-Id: 
To: Mark Andrews 
From: Philip Homburg 
Sender: pch-b6B5344D9@u-1.phicoh.com
References:  <20110509154020.DE031E99038@drugs.dv.isc.org> 
In-reply-to: Your message of "Tue, 10 May 2011 01:40:20 +1000 ." <20110509154020.DE031E99038@drugs.dv.isc.org> 
Date: Mon, 09 May 2011 19:11:52 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-andrews-v6ops-6to4-router-option-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, 09 May 2011 17:12:23 -0000

In your letter dated Tue, 10 May 2011 01:40:20 +1000 you wrote:
>In message , Philip Homburg writes:
>> The first question I have is why would anyone want to use an address other
>> than the RFC-3068 defined one?  What's the point? 
> 
>There is lots of value in not using the anycast relay routers.

I think you may have to add some text to your draft about this. My ISP runs an
6to4 relay for their clients and I absolutely no idea why 6to4 would work
better if they would run that relay on another address.

>> I think it is important to evaluate 6ot4 in the context of the measurements
>> done by Geoff Huston and others.
>
>The point is to use a relay that is local to the client (mostly
>eliminating the transmission delays causes by using a relay router)
>that is being run by someone the client has a contract with (allows
>faults to be reported).  Both of these are issues identified by
>Geoff and others.

A local relay is just of matter of injecting a route to the anycast address
in the local IGP. Why would that be easier if run it on another address? Well
then you don't have to add a route to the local IGP. Instead you have to make
sure that each and every 6to4 implementation on your local net supports the
new DHCP option.

>> And using a different IPv4 address for the relay is most likely just
>> going to break things.
>
>This is a unsubstanciated claim.

I don't have a specific reference, but i.r.c. at some point Geoff Huston 
reported a difference in failure rates of around 5% depending on whether the
relay router on the return path would use the anycast address as source 
address or not.

Sounds alike a good argument for sticking to the anycast address.

>> So assuming that in future 6to4 is disabled by default. The only thing this
>> feature does override the user's preference to turn 6to4 on. I don't think i
>t
>> makes any sense to implement this feature.
>
>Lots of equipment moves between networks.  In one network 6to4 will
>work and in another 6to4 won't work or it causes operational problems
>for the network when the 6to4 is misconfigured (rogue RAs which
>blackhole IPv6 traffic).  In the first you use the option to optimise
>traffic flows.  In the latter you set the option to 0.0.0.0 to
>disable 6to4.  The equipment can safely move between networks without
>requiring reconfiguration everytime it moves.

If you allow random hosts to orginate RAs then you have a big problem anyhow.
So I think we can ignore that.

6to4 doesn't work behind NAT. So, for this to be an issue you have to have 
devices that move between at least two networks that all have routable IPv4
addresses. Sounds like a corner case to me.

IMHO, effort would be much better spend making sure that a 6to4 implementations
honors ICMP destination unreachables for the anycast address or by
implementing the TTL=1 hack for verifying the actual reachability of the 
relay.



From cb.list6@gmail.com  Mon May  9 10:18: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 D79A7E06BE for ; Mon,  9 May 2011 10:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level: 
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_37=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 0vPvRGh4VQPY for ; Mon,  9 May 2011 10:18:41 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73D57E062A for ; Mon,  9 May 2011 10:18:40 -0700 (PDT)
Received: by eye13 with SMTP id 13so1972184eye.31 for ; Mon, 09 May 2011 10:18:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0AkD2jfVfFI6dPXZXMwFP4+7+HpODZYOXTCL/+C/GcY=; b=AYJZ47n4GvITTKcOErcNMgQE0/jvXaPU2Aj3uGP7Rmolt0tcnyhm83lPvSA4/ereIL 2sYQ+nj723PUSbg3CzK//vH7SWjjBLF+s3XRYh8R5rlQsxPt5TEkZqbeT33m4MkT6+y+ lgC8yX2HXfK7lffZpNZcyXZsVZs1D8+rKq1/k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CKNI1B81BFt4xH8/DqkaAIyI68vdeazyHeqrvIhs1SkWpZfXr1Fl8CtRih7jzhc6lp 4g8neNAmQAFhcwAm74Fs1TJ2Ag1nRMKR6kBum3GzHsist0/2KwWX7UABnmiSZKqbzdGT u/U1QMdMDZDknt0ryP+4AICAASYmfXh8dHc2A=
MIME-Version: 1.0
Received: by 10.14.122.201 with SMTP id t49mr3109797eeh.25.1304961041067; Mon, 09 May 2011 10:10:41 -0700 (PDT)
Received: by 10.14.37.143 with HTTP; Mon, 9 May 2011 10:10:41 -0700 (PDT)
In-Reply-To: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org> 
Date: Mon, 9 May 2011 10:10:41 -0700
Message-ID: 
From: Cameron Byrne 
To: Lorenzo Colitti 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 09 May 2011 17:18:43 -0000

On Mon, May 9, 2011 at 9:14 AM, Lorenzo Colitti  wrote:
> On Mon, May 9, 2011 at 1:08 AM, Mark Andrews  wrote:
>>
>> =A0 =A0 =A0 =A0I just posted draft-andrews-v6ops-6to4-router-option-00.t=
xt.
>> =A0 =A0 =A0 =A0Feedback welcome.
>
>
> I don't see any reason to do this.
> First: if you're an operator (and you probably are, since you have the po=
wer
> to control the DHCP server), you can already ensure 6to4 nodes to use you=
r
> relay by making sure that=A0192.88.99.1 is routed to it. You don't have t=
o
> change the OS stacks at all. Thus no RFC, no IANA DHCP option assignment,=
 no
> implementation changes on the server or on the client, ...
> Second: this only makes the forward path more reliable. Reverse path is
> still unreliable because it is not under your control (the server will ju=
st
> pick whatever anycast 6to4 relay is closest to it). The only way to fix t=
hat
> is by using 6rd or something like 6to4-PMT, which the WG did not adopt as=
 an
> item.
> Third: as Erik says, you're really just reinventing a part of 6rd.=A0More
> specifically: RFC 3068-style anycast 6to4 is a special case of 6rd
> where=A0IPv4MaskLen =3D 0,=A06rdPrefix =3D 2002::, 6rdPrefixLen =3D 16,
> and=A06rdBRIPv4Address =3D 192.88.99.1. From a protocol perspective,=A0wh=
at you
> are doing is adding the 6rdBRIPv4Address parameter, but not the other thr=
ee
> parameters, to 6to4.=A0I think that instead of asking implementors to do =
this,
> we should just ask them to implement 6rd instead.

+1 for v6ops rejecting this work.  v6ops has spent way too much time
on the topic of 6to4.

6to4 is a speed bump and a distraction for people really doing IPv6.

The Advisory and Historic drafts should end the conversation on 6to4
so we can get back to the real work of deploying real IPv6.

Cameron

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

From dhc@dcrocker.net  Mon May  9 10:19: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 2307CE088A; Mon,  9 May 2011 10:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.592
X-Spam-Level: 
X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007,  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 w3X9cPry4hYu; Mon,  9 May 2011 10:19:03 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B7257E0829; Mon,  9 May 2011 10:19:03 -0700 (PDT)
Received: from [192.168.1.5] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p49HIr8t018539 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 10:18:58 -0700
Message-ID: <4DC821FB.2050904@dcrocker.net>
Date: Mon, 09 May 2011 10:18:51 -0700
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: IETF Discussion 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 09 May 2011 10:19:00 -0700 (PDT)
Cc: "v6ops@ietf.org" , Apps Review 
Subject: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 May 2011 17:19:08 -0000

(This is an "official" and significantly extended version of an informal and 
narrow review I posted earlier.  /d)



Howdy.

I have been selected as the Applications Area Review Team reviewer for this 
draft (for background on apps-review, please see 
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you may 
receive. Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.



Review (v2):

Title:  IPv6 AAAA DNS Whitelisting Implications
I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

By:     D. Crocker 
Date:   <>



Summary
=======

This draft covers a a dual-stack problem in which a target host's DNS entry 
contains records for IPv4 and IPv6, but returning IPv6 information to a DNS 
client can cause problems. The paper discusses for resolving this through use of 
a a DNS-based mechanism that manually lists response preferences to select which 
DNS records to return.  The paper describes the mechanism and explores various 
effects and possibilities of its use, including the difference between using it 
selectively among a smaller number of sites, versus universally.

The draft is a serious effort to explore the use of such a mechanism and it 
touches many different issues.  It is generally well-organized and clearly 
written, although it very much needs the aid of a professional technical editor. 
The writing often assumes too much knowledge by the reader.

The paper's exploration of universal adoption seems to vary between considering 
that goal practical versus considering it only as a matter of completeness for 
discussing the full range of possibilities.  That is, it is not clear whether 
the paper views this alternative as practically possible and even preferred, 
versus only a matter for academic thoroughness. The paper needs to take a basic 
position about feasibility, explain it in terms of comparable adoption efforts 
at Internet-scale, and then make its treatment of universal adoption a bit more 
consistent.

When introducing terms, mechanisms, configurations and scenarios, the paper 
needs to be more careful to describe them adequately for a reader new to the 
topic.  This is not a matter of having a tutorial about the DNS, but rather a 
tutorial for this type of mechanism and when and how it can be used.

As a specific example, the document cites "domain-by-domain" use, but I am not 
clear how that would work, in terms of configuration and cross-net information 
exchange.  One question is how the server knows the 'domain' of the client?

The document should careful to distinguish what is existing practice, versus 
what is being explored as added possibilities.  The difference in concreteness 
and certitude between the two is substantial.

The document's use of the term whitelisting appears to continue an existing, 
recent use, for this type of mechanism.  Unfortunately it directly conflicts 
with long-standing use of the term by the anti-abuse community for whitelisting 
in the DNS. Its use here also seems to be a mismatch with the word's dictionary 
semantics, which is most naturally used to distinguish yes/no choices, rather 
than either/or choices.  So there is no intuitive sense of "goodness" (whitelist 
= yes) or "badness" (blacklist) for this use. The word "preferences" seems more 
in line with the meaning of the mechanism.



Detailed Comments
=================


> Abstract
>
>    The objective of this document is to describe what the whitelisting
>    of DNS AAAA resource records is, hereafter referred to as DNS

RRs are whitelisted?  Isn't it the addresses and not the records that are 
whitelisted?

Does this mean putting whitelisting records into the DNS or does it mean 
something else?

Comcast's own considerable expertise notwithstanding, has this doc been vetted 
with a range of organizations that actually DO whitelisting?  Has it been 
circulated through MAAWG and APWG?  Any comments from Spamhaus?  The 
Acknowledgements list does not seem to indicate a range of whitelist ops folks 
whose names I know.  (But then, I only know a few...)


>    whitelisting, as well as the implications of this emerging practice
>    and what alternatives may exist.  The audience for this document is
>    the Internet community generally, including the IETF and IPv6
>    implementers.

I suspect that product marketers won't have much interest in this.  I suspect 
that the target for this is anti-abuse technical and operations staff. In any 
event, the targetting statement should be more precise.


> 1.  Introduction
>
>    This document describes the emerging practice of whitelisting of DNS

One natural, semantic problem with the term 'whitelist' is that it does not 
really match the function being performed.  The white/black distinction implies 
goodness -- or as Wikipedia says, "priviledge".  Instead, the use here is for 
preference or priority.  What would a "blacklist" be, here?  Also note it is not 
obvious what it means to be whitelisted, here?  Does it mean to choose the AAAA 
records or the A records?

This is more like a 'Preference' or 'Configuration' list.

At the least, the name for this should be IPv6 Resolver Whitelisting.  It makes 
clear /what/ is being "whitelisted".


>    AAAA resource records (RRs), which contain IPv6 addresses, hereafter
>    referred to as DNS whitelisting.  The document explores the

This provides a name, but not a function.  That is, it does not say what this 
mechanisms actually /does/ or is /for/.


>    implications of this emerging practice are and what alternatives may
>    exist.
>
>    The practice of DNS whitelisting appears to have first been used by
>    major web content sites (sometimes described herein as "highly-

It's use for email anti-abuse dates back farther.

    

    

 


Specifically within the context of the DNS, the term whitelisting is therefore 
made ambiguous.

A google query for "whitelist dns" also demonstrates the history and current 
ambiguity.


>    trafficked domains" or "major domains").  These web site operators,
>    or domain operators, observed that when they added AAAA resource
>    records to their authoritative DNS servers in order to support IPv6
>    access to their content that a small fraction of end users had slow
>    or otherwise impaired access to a given web site with both AAAA and A
>    resource records.  The fraction of users with such impaired access
>    has been estimated to be roughly 0.078% of total Internet users
>    [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
>    Brokenness].  Thus, in an example Internet Service Provider (ISP)
>    network of 10 million users, approximately 7,800 of those users may
>    experience such impaired access.

At a minimum, these sorts of statistics need to be normalized across IPv6 
users/traffic, given how small a percentage that is, in total users and total 
traffic.  If that's what is meant it should be stated.  If it isn't, the 
statistic should be recalculated and explained a bit more precisely.


>    As a result of this impairment affecting end users of a given domain,
>    a few major domains have either implemented DNS whitelisting or are
>    considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].
>    When implemented, DNS whitelisting in practice means that a domain's
>    authoritative DNS will return a AAAA resource record to DNS recursive
>    resolvers [RFC1035] on the whitelist, while returning no AAAA
>    resource records to DNS resolvers which are not on the whitelist.  It

This explanation of the function should be offered sooner and should be 
summarized in the Abstract.


>    is important to note that these major domains are motivated by a
>    desire to maintain a high-quality user experience for all of their

Rather than being important to note, this sentence sounds oddly like marketing 
hype, in a technical specification.  It is gratuitous because specified features 
are never added to /lower/ the quality of the user experience, for example.

In addition, the mechanism also affects client activity that has no user 
directly involved.


>    users.  By engaging in DNS whitelisting, they are attempting to
>    shield users with impaired access from the symptoms of those
>    impairments.

The /technical/ statement that should be here is that they are attempting to 
provide a work-around for problematic behaviors in dual-stack IPv4/IPv6 
environments.

The paper should make more clear exactly where the problem lies and when. If it 
can occur for a number of reasons, explaining each of those scenarios would be 
useful.


>    Critics of the practice of DNS whitelisting have articulated several
>    concerns.  Among these are that:
>
>    o  DNS whitelisting is a very different behavior from the current
>       practice concerning the publishing of IPv4 address resource
>       records,
>
>    o  that it may create a two-tiered Internet,
>
>    o  that policies concerning whitelisting and de-whitelisting are
>       opaque,
>
>
>
>
>
> Livingood                Expires August 26, 2011                [Page 5]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    o  that DNS whitelisting reduces interest in the deployment of IPv6,
>
>    o  that new operational and management burdens are created,

well, yeah... in fact it should be noted that the burdens are particularly 
onerous at scale.


>    o  and that the costs and negative implications of DNS whitelisting
>       outweigh the perceived benefits, compared to fixing underlying
>       impairments.

and it doesn't scale.

and it violates an extremely basic premise of cross-Internet interoperability by 
requiring prior arrangement.


>    This document explores the reasons and motivations for DNS
>    whitelisting.  It also explores the outlined concerns regarding this
>    practice.  Readers will hopefully better understand what DNS
>    whitelisting is, why some parties are implementing it, and what
>    criticisms of the practice exist.
>
>
> 2.  How DNS Whitelisting Works

How IPv6 AAAA DNS Whitelisting Works.

(Anti-spam DNS Whitelisting works rather differently...)


>    DNS whitelisting is implemented in authoritative DNS servers.  These
>    servers implement IP address-based restrictions on AAAA query
>    responses.  So far, DNS whitelisting has been primarily implemented
>    by web server operators deploying IPv6-enabled services.  For a given

Really?  This is web-specific?  The same restrictions are not applied for other 
applications?

So if the same client-side hosts attempt to contact the server for email or 
xmpp, they won't get the same handling?


>    operator of a website, such as www.example.com, the operator
>    essentially applies an access control list (ACL) on the authoritative
>    DNS servers for the domain example.com.  The ACL is populated with

An ACL usually is a yes/no mechanism.  Here, however, the mechanism is for 
asserting a preference for IPv6 over IPv4.

That does not seem to match the definition of ACL that I'm used to, unless the 
semantic is defined as denying IPv4 access to the listed clients.

The term ACL is particularly odd to use if the mechanism pertains to responses 
rather than queries.


>    the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive

Either address type can be listed?  So this really is a pure 'preferences' 
mechanism?

Which settings count as whitelisting?  Do any count as blacklisting?



>    resolvers on the Internet, which have been authorized to receive AAAA
>    resource record responses.  These DNS recursive resolvers are
>    operated by third parties, such as ISPs, universities, governments,
>    businesses, and individual end users.  If a DNS recursive resolver IS
>    NOT matched in the ACL, then AAAA resource records will NOT be sent
>    in response to a query for a hostname in the example.com domain.

This configuration appears to ensure the maximum barrier to adoption for IPv6, 
since it means that IPv6 will not work automatically.  It will only work for 
hosts that are manually configured to receive responses with v6 records.

That's a rather major implication.  It's a default that is probably meant to 
apply during the very early stages of adoption, when there are few users of the 
newer mechanism.

It's probably worth discussing it in more detail, including discussing when to 
change the default...


>    However, if a DNS recursive resolver IS matched in the ACL, then AAAA
>    resource records will be sent in response to a query for a given
>    hostname in the example.com domain.  While these are not network-
>    layer access controls they are nonetheless access controls that are a
>    factor for end users and other parties like network operators,
>    especially as networks and hosts transition from one network address
>    family to another (IPv4 to IPv6).


Also, all of this clarifies the function of this listing mechanism and suggests 
a very different name, to be more precise and accurate in naming it:

     IPv6 DNS Response Preference List.


>    In practice, DNS whitelisting generally means that a very small
>    fraction of the DNS recursive resolvers on the Internet (those in the
>    whitelist ACL) will receive AAAA responses.  The large majority of
>    DNS resolvers on the Internet will therefore receive only A resource
>    records containing IPv4 addresses.  Thus, quite simply, the
>    authoritative server hands out different answers depending upon who
>    is asking; with IPv4 and IPv6 resource records for some on the
>    authorized whitelist, and only IPv4 resource records for everyone
>    else.  See Section 2.1 and Figure 1 for a description of how this
>
>
>
> Livingood                Expires August 26, 2011                [Page 6]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    works.
>
>    Finally, DNS whitelisting can be deployed in two primary ways:
>    universally on a global basis, or on an ad hoc basis.  Deployment on
>    a universal deployment basis means that DNS whitelisting is
>    implemented on all authoritative DNS servers, across the entire
>    Internet.  In contrast, deployment on an ad hoc basis means that only
>    some authoritative DNS servers, and perhaps even only a few,
>    implement DNS whitelisting.  These two potential deployment models
>    are described in Section 6.
>
> 2.1.  Description of the Operation of DNS Whitelisting
>
>    The system logic of DNS whitelisting is as follows:
>
>    1.  The authoritative DNS server for example.com receives DNS queries
>        for the A (IPv4) and AAAA (IPv6) address resource records for the
>        FQDN www.example.com, for which AAAA (IPv6) resource records
>        exist.

This means that the mechanism is /only/ triggered when /both/ address records 
are queried?  A query for only one type of address record won't trigger the list 
lookup?  I think that doesn't match other statements in the document.


>    2.  The authoritative DNS server examines the IP address of the DNS
>        recursive resolver sending the AAAA (IPv6) query.

"examines"?  Examines it for what?  What does this step mean?


>    3.  The authoritative DNS server checks this IP address against the
>        access control list (ACL) that is the DNS whitelist.
>
>    4.  If the DNS recursive resolver's IP address IS matched in the ACL,
>        then the response to that specific DNS recursive resolver can
>        contain AAAA (IPv6) address resource records.

Oh.  This is not about whether to send responses /over/ v6 vs. v4?  This is 
whether to /include/ a particular type of RR in responses???

In that case an appropriate name for this mechanism is more like:

    DNS Response Content Preference List

And this seems even less like an ACL than it did before.  (I assume the 
justification is that access is being prevented by virtue of not supplying the 
address, but still...)


>    5.  If the DNS recursive resolver's IP address IS NOT matched in the
>        ACL, then the response to that specific DNS recursive resolver
>        cannot contain AAAA (IPv6) address resource records.  In this
>        case, the server should return a response with the response code
>        (RCODE) being set to 0 (No Error) with an empty answer section
>        for the AAAA record query.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Livingood                Expires August 26, 2011                [Page 7]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    ---------------------------------------------------------------------
>    A query is sent from a DNS recursive resolver that IS NOT on the DNS
>    whitelist:
>
>                Request                      Request
>            www.example.com                  www.example.com
>                  AAAA    +-------------+     AAAA    +-----------------+
>      ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
>      ||  ||       A      | **IS NOT**  |      A      | IN A exists     |
>    +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
>    +--------+     A      | example.com |      A      |                 |
>       Host    <--------- |  WHITELIST  |  <--------- |                 |
>     Computer   A Record  +-------------+  A Record   +-----------------+
>                Response   DNS Recursive   Response       example.com
>               (only IPv4)   Resolver     (only IPv4)    Authoritative
>                               #1                           Server
>    ---------------------------------------------------------------------
>    A query is sent from a DNS recursive resolver that IS on the DNS
>    whitelist:
>
>                Request                      Request
>            www.example.com                  www.example.com
>                 AAAA     +-------------+     AAAA    +-----------------+
>      ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
>      ||  ||       A      |   **IS**    |      A      | IN A exists     |
>    +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
>    +--------+   AAAA     | example.com |     AAAA    |                 |
>       Host    <--------- |  WHITELIST  |  <--------- |                 |
>     Computer      A      |             |      A      |                 |
>               <--------- |             |  <--------- |                 |
>               A and AAAA +-------------+ A and AAAA  +-----------------+
>                Record     DNS Recursive   Record        example.com
>               Responses     Resolver     Responses      Authoritative
>               (IPv4+IPv6)      #2        (IPv4+IPv6)       Server
>    ---------------------------------------------------------------------
>
>               Figure 1: DNS Whitelisting - Functional Diagram

This diagram is confusing to me.  I suspect that a protocol exchange sequence 
format, in the style of:

      Host             Resolver 1            Authoritative

           ---------->
                                  --------->
                                 <---------
          <----------

will be considerably more helpful.


> 3.  What Problems Are Implementers Trying To Solve?

This is a very useful section and it is probably worth moving it higher, to 
precede the 'how it works' section.


>    As noted in Section 1, domains which implement DNS whitelisting are
>    attempting to protect a few users of their domain, who have impaired
>    IPv6 access, from having a negative experience (poor performance).

By the way, what does 'impaired v6 access' mean?

I think there needs to be a simple, direct description of what occurs without 
this mechanism.

For example, perhaps you mean that a host can send DNS queries using IPv6 but 
cannot receive DNS responses over IPv6? Perhaps you mean that the host can send 
IPv6 but cannot receive it.  (That's a different scale and scope of problem from 
the first example I gave.)

This brief, summary problem statement should be included in the Abstract, to 
make /much/ more clear what this mechanism is for.


>    While it is outside the scope of this document to explore the various
>    reasons why a particular user's system (host) may have impaired IPv6
>    access, for the users who experience this impairment it is a very
>    real performance impact.  It would affect access to all or most dual
>
>
>
> Livingood                Expires August 26, 2011                [Page 8]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    stack services to which the user attempts to connect.  This negative
>    end user experience can range from someone slower than usual (as
>    compared to native IPv4-based access), to extremely slow, to no
>    access to the domain whatsoever.

Rather than repeat that this is about end-users, it sounds more that this is 
about whether a service works or does not work, whether a user is directly 
present or not.


>    While one can debate whether DNS whitelisting is the optimal solution
>    to the end user experience problem, it is quite clear that DNS
>    whitelisting implementers are interested in maximizing the
>    performance of their services for end users as a primary motivation
>    for implementation.

You keep citing 'performance' but haven't described what sort of performance 
degradation takes place. Is this really about relatively better or worse 
performance -- and if so, how -- or is this about working or not working?

Also rather than saying what implementers are interested in, it's probably more 
helpful to note that the practice is now significantly established and therefore 
worth documenting, independent of its possible controversy.


>    At least one highly-trafficked domain has noted that they have
>    received requests to not send DNS responses with AAAA resource
>    records to particular resolvers.  In this case, the operators of

"At least one" seems a rather tiny statistic.  Perhaps the actual statistic is 
significantly larger?


>    those recursive resolvers have expressed a concern that their IPv6

I suspect that it's not resolvers that are doing the expressing, since their 
vocabulary is usually too limited...


>    network infrastructure is not yet ready to handle the large traffic
>    volume which may be associated with the hosts in their network
>    connecting to the websites of these domains.  This concern is clearly

So even though the site allows v6 DNS queries to go out from a host, it can't 
really support having the host use v6?

Wow. I do understand why service providers often have to work around silliness 
at the client side, but this problem at the client side seems particularly 
egregious.


>    a temporary consideration relating to the deployment of IPv6 network
>    infrastructure on the part of networks with end user hosts, rather
>    than a long-term concern.  These end user networks may also have

Again this goal of short-term usage is worth noting earlier, including in the 
Abstract.


>    other tools at their disposal in order to address this concern,
>    including applying rules to network equipment such as routers and
>    firewalls (this will necessarily vary by the type of network, as well
>    as the technologies used and the design of a given network), as well
>    as configuration of their recursive resolvers (though modifying or
>    suppressing AAAA resource records in a DNSSEC-signed domain on a
>    Security-Aware Resolver will be problematic Section 10.1).
>
>    Some implementers with highly-trafficked domains have explained that
>    DNS whitelisting is a necessary, though temporary, risk reduction
>    tactic intended to ease their transition to IPv6 and minimize any
>    perceived risk in such a transition.  As a result, they perceive this
>    as a tactic to enable them to incrementally enable IPv6 connectivity
>    to their domains during the early phases of their transition to IPv6.
>
>    Finally, some domains, have run IPv6 experiments whereby they added
>    AAAA resource records and observed and measured errors [Heise Online
>    Experiment], which should be important reading for any domain
>    contemplating either the use of DNS whitelisting or simply adding
>    IPv6 addressing to their site.
>
>
> 4.  Concerns Regarding DNS Whitelisting
>
>    There are a number of potential implications relating to DNS
>    whitelisting, which have been raised as concerns by some parts of the
>    Internet community.  Many of those potential implications are further

I think the implications are not conditional; they exist rather than being 
potential.  The 'potential' is that what is implicated will come to pass.



>
> Livingood                Expires August 26, 2011                [Page 9]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    enumerated here and in Section 7.

Pro forma question:  Why are implications discussed in multiple places?


>    Some parties in the Internet community, including ISPs, are concerned

This style of text personalizes the issues unnecessarily (IMO).  It does not 
really matter who holds the concerns, or else they'd be described more precisely.

I suggest merely noting that there are concerns and then listing and discussing 
the concerns, rather than adding text to attribute the concerns to others, even 
if the conclusion of your text is that a particular concern is not valid.


>    that the practice of DNS whitelisting for IPv6 address resource
>    records represents a departure from the generally accepted practices
>    regarding IPv4 address resource records in the DNS on the Internet
>    [Whitelisting Concerns].  These parties explain their belief that for

"These parties explain their belief" is an example of personalization that is 
not needed.  This isn't about the believers.  It is about possible problems.


>    A resource records, containing IPv4 addresses, once an authoritative
>    server operator adds the A record to the DNS, then any DNS recursive
>    resolver on the Internet can receive that A record in response to a

This does not appear to be a grammatically valid sentence.  My guess is that 
deleting "A resource... addresses" fixes this.

And by the way, the document's reference to "recursive" resolvers is mostly 
likely incorrect.  The problem is not restricted only to that very specific type 
of resolver, is it?

If in fact it /is/ specific to them -- and your following text describes an 
indirect effects scenario where it might be -- I suggest calling out the 
configuration at the beginning, along the lines of:

      One way the problem with returning AAAA records can be experienced is when 
recursive resolvers are used.  Although that resolver might support IPv6, its 
client hosts might not.  So, returning an AAAA record will mean that these 
limited hosts will be given an unusable address.

And this type of description belongs in the text describing the motivating 
problem(s), rather than buried in the 'concerns' discussion.

(The text, here, pertains to A records, but the problem I've described uses the 
same configuration but for AAAA records with mixed v6 support.)


>    query.  By extension, this means that any of the hosts connected to
>    any of these DNS recursive resolvers can receive the IPv4 address
>    resource records for a given FQDN.  This enables new server hosts
>    which are connected to the Internet, and for which a fully qualified
>    domain name (FQDN) such as www.example.com has been added to the DNS
>    with an IPv4 address record, to be almost immediately reachable by
>    any host on the Internet.  In this case, these new servers hosts
>    become more and more widely accessible as new networks and new end
>    user hosts connect to the Internet over time, capitalizing on and
>    increasing so-called "network effects" (also called network
>    externalities).  It also means that the new server hosts do not need
>    to know about these new networks and new end user hosts in order to
>    make their content and applications available to them, in essence
>    that each end in this end-to-end model is responsible for connecting
>    to the Internet and once they have done so they can connect to each
>    other without additional impediments or middle networks or
>    intervening networks or servers knowing about these end points and
>    whether one is allowed to contact the other.

Hmmm.  This rather lengthy bit of prose appears merely to be explaining the 
basic and long-standing DNS value proposition???


>    In contrast, the concern is that DNS whitelisting may fundamentally
>    change this model.  In the altered DNS whitelisting end-to-end model,
>    one end (where the end user is located) cannot readily connect to the
>    other end (where the content is located), without parts of the middle
>    (recursive resolvers) used by one end (the client, or end user hosts)
>    being known to an intermediary (authoritative nameservers) and
>    approved for access to the resource at the end.  As new networks
>    connect to the Internet over time, those networks need to contact any
>    and all domains which have implemented DNS whitelisting in order to
>    apply to be added to their DNS whitelist, in the hopes of making the
>    content and applications residing on named server hosts in those
>    domains accessible by the end user hosts on that new network.
>    Furthermore, this same need to contact all domains implementing DNS
>    whitelisting also applies to all pre-existing (but not whitelisted)
>    networks connected to the Internet.
>
>    In the current IPv4 Internet when a new server host is added to the
>    Internet it is generally widely available to all end user hosts and
>    networks, when DNS whitelisting of IPv6 resource records is used,

If it is available to the hosts, it is available to the network.

networks, when -> networks. When


>
>
>
> Livingood                Expires August 26, 2011               [Page 10]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    these new server hosts are not accessible to any end user hosts or
>    networks until such time as the operator of the authoritative DNS

They are still accessible.  The IP-level mechanisms still work.

They are not reachable when using the domain name.


>    servers for those new server hosts expressly authorizes access to
>    those new server hosts by adding DNS recursive resolvers around the
>    Internet to the ACL.  This has the potential to be a significant

This is a good example of the reason the term ACL is inappropriate:  It implies 
a security protection that does not actually exist.  The hosts are still accessible.


>    change in reachability of content and applications by end users and
>    networks as these end user hosts and networks transition to IPv6,
>    resulting in more (but different) breakage.  A concern expressed is
>    that if much of the content that end users are most interested in is
>    not accessible as a result, then end users and/or networks may resist
>    adoption of IPv6 or actively seek alternatives to it, such as using
>    multi-layer network address translation (NAT) techniques like NAT444
>    [I-D.shirasaki-nat444] on a long-term basis.  There is also concern
>    that this practice also could disrupt the continued increase in
>    Internet adoption by end users if they cannot simply access new
>    content and applications but must instead contact the operator of
>    their DNS recursive resolver, such as their ISP or another third
>    party, to have their DNS recursive resolver authorized for access to
>    the content or applications that interests them.  Meanwhile, these
>    parties say, over 99.9% of the other end users that are also using
>    that same network or DNS recursive resolver are unable to access the
>    IPv6-based content, despite their experience being a positive one.
>
>    While in Section 1 the level of IPv6-related impairment has been
>    estimated to be as high as 0.078% of Internet users, which is a

8 hundredths of one percent?

That's considered a high percentage?

Even if it is 8%, is that considered high?


> 5.2.  Similarities to DNS Load Balancing
>
>    DNS whitelisting also has some similarities to DNS load balancing.
>    There are of course many ways that DNS load balancing can be
>    performed.  In one example, multiple IP address resource records (A
>    and/or AAAA) can be added to the DNS for a given FQDN.  This approach
>    is referred to as DNS round robin [RFC1794].  DNS round robin may
>    also be employed where SRV resource records are used [RFC2782].

Right, but that's algorithmic rather than involving the manual method, described 
here. So it does not seem comparable.


> 6.  Likely Deployment Scenarios
>
>    In considering how DNS whitelisting may emerge more widely, there are
>    two likely deployment scenarios, which are explored below.
>
>    In either of these deployment scenarios, it is possible that
>    reputable third parties could create and maintain DNS whitelists, in
>    much the same way that blacklists are used for reducing email spam.
>    In the email context, a mail operator subscribes to one or more of
>    these lists and as such the operational processes for additions and
>    deletions to the list are managed by a third party.  A similar model
>    could emerge for DNS whitelisting, whether deployment occurs
>    universally or on an ad hoc basis.

The challenges of email whitelists and blacklists should be cited, since it 
provides a rich base of experience for such an effort, at scale.


> 6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis
>
>    The seemingly most likely deployment scenario is where some

Most likely?  This is not already established practice?


>    authoritative DNS server operators implement DNS whitelisting but
>    many or most others do not do so.  What can make this scenario
>    challenging from the standpoint of a DNS recursive resolver operator
>    is determining which domains implement DNS whitelisting, particularly
>    since a domain may not do so as they initially transition to IPv6,
>    and may instead do so later.  Thus, a DNS recursive resolver operator
>
>
>
> Livingood                Expires August 26, 2011               [Page 13]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    may initially believe that they can receive AAAA responses as a
>    domain adopts IPv6, but then notice via end user reports that they no
>    longer receive AAAA responses due to that domain adopting DNS
>    whitelisting.  Of course, a domain's IPv6 transition may be
>    effectively invisible to recursive server operators due to the effect
>    of DNS whitelisting.

This suggests that every listing at the server needs a contact record for 
periodic checks whether to renew the listing.


>
>    In contrast to a universal deployment of DNS whitelisting
>    Section 6.2, deployment on an ad hoc basis is likely to be
>    significantly more challenging from an operational, monitoring, and

Oh?  Use in small scale is more challenging than use of manual exceptions list 
at large scale?  That's a very unexpected view.


>    troubleshooting standpoint.  In this scenario, a DNS recursive
>    resolver operator will have no way to systematically determine
>    whether DNS whitelisting is or is not implemented for a domain, since
>    the absence of AAAA resource records may simply be indicative that
>    the domain has not yet added IPv6 addressing for the domain, rather
>    than that they have done so but have restricted query access via DNS

The premise is that, in large scale use, servers /will/ have a way to 
systematically determine whether it is implemented?  What are the existing 
examples of having such a capability for other Internet protocols and services?


>    whitelisting.  As a result, discovering which domains implement DNS
>    whitelisting, in order to differentiate them from those that do not,
>    is likely to be challenging.
>
>    One benefit of DNS whitelisting being deployed on an ad hoc basis is
>    that only the domains that are interested in doing so would have to
>    upgrade their authoritative DNS servers in order to implement the
>    ACLs necessary to perform DNS whitelisting.
>
>    In this potential deployment scenario, it is also possible that a
>    given domain will implement DNS whitelisting temporarily.  A domain,
>    particularly a highly-trafficked domain, may choose to do so in order
>    to ease their transition to IPv6 through a selective deployment and
>    minimize any perceived risk in such a transition.
>
> 6.2.  Deploying DNS Whitelisting Universally
>
>    The least likely deployment scenario is one where DNS whitelisting is
>    implemented on all authoritative DNS servers, across the entire
>    Internet.  While this scenario seems less likely than ad hoc
>    deployment due to some parties not sharing the concerns that have so
>    far motivated the use of DNS whitelisting, it is nonetheless
>    conceivable that it could be one of the ways in which DNS
>    whitelisting is deployed.

Significantly, the partial-deployment model casts this mechanism as a transition 
expedient -- as the document reasonably describes it -- whereas universal 
deployment casts it as a fundamental change to the architecture.

Given that it would take decades to achieve relatively full deployment of this 
'across the entire Internet', what is the benefit of discussing this highly 
unlikely scenario?  Is it really "conceivable"?  I doubt it. If you think 
otherwise, the paper needs to explore the deployment and adoption issues in much 
more detail, because I don't see how it could work.


>    In order for this deployment scenario to occur, it is likely that DNS
>    whitelisting functionality would need to be built into all
>    authoritative DNS server software, and that all operators of
>    authoritative DNS servers would have to upgrade their software and
>    enable this functionality.  It is likely that new Internet Draft
>    documents would need to be developed which describe how to properly
>    configure, deploy, and maintain DNS whitelisting.  As a result, it is
>
>
>
> Livingood                Expires August 26, 2011               [Page 14]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    unlikely that DNS whitelisting would, at least in the next several
>    years, become universally deployed.  Furthermore, these DNS
>    whitelists are likely to vary on a domain-by-domain basis, depending
>    upon a variety of factors.  Such factors may include the motivation
>    of each domain owner, the location of the DNS recursive resolvers in
>    relation to the source content, as well as various other parameters
>    that may be transitory in nature, or unique to a specific end user
>    host type.  It is probably unlikely that a single clearinghouse for
>    managing whitelisting is possible; it will more likely be unique to
>    the source content owners and/or domains which implement DNS
>    whitelists.
>
>    While this scenario may be unlikely, it may carry some benefits.
>    First, parties performing troubleshooting would not have to determine
>    whether or not DNS whitelisting was being used, as it always would be
>    in use.  In addition, if universally deployed, it is possible that
>    the criteria for being added to or removed from a DNS whitelist could
>    be standardized across the entire Internet.  Nevertheless, even if
>    uniform DNS whitelisting policies were not standardized, is also
>    possible that a central registry of these policies could be developed
>    and deployed in order to make it easier to discover them, a key part
>    of achieving transparency regarding DNS whitelisting.

Is any of this paragraph realistic?  Obviously my asking means I don't it is. 
These seem to be of theoretical rather than pragmatic interest.  ("If everyone 
refuses to shoot, there will be no wars.")

It's true that this is an "implications" paper rather than a BCP, but still...


>
> 7.  Implications of DNS Whitelisting
>
>    There are many potential implications of DNS whitelisting.  The key
>    potential implications are detailed below.
>
> 7.1.  Architectural Implications
>
>    DNS whitelisting could be perceived as modifying the end-to-end model
>    and/or the general notion of the architecture that prevails on the

I'll suggest that perception is not a major issue about a technical topic like 
this.  (It's not entirely irrelevant, of course, but I suspect it is quite minor.)

The major issue is whether it /actually/ modifies the end-to-end nature of the 
DNS.  And I think it does, as well as modifying the "spontaneous 
interoperability" expectation for most Internet mechanism, since it requires 
prior registration.


> 7.2.  Public IPv6 Address Reachability Implications
>
>    The predominant experience of end user hosts and servers on the IPv4-
>    addressed Internet today is that when a new server with a public IPv4
>    address is added to the DNS, that it is then globally accessible by

This sentence is not quite correct, in strict technical terms.  Since this is a 
technical discussion, we need to be precise:  the host is reachable when the 
routing tables make it reachable.  That's strictly a mapper of IP Address 
handling, not name-to-address mapping.

What you mean is that its domain name is immediately useful for reaching it.


>    IPv4-addressed hosts.  This is a generalization and in Section 5
>    there are examples of common cases where this may not necessarily be
>    the case.  For the purposes of this argument, that concept of
>    accessibility can be considered "pervasive reachability".  It has so
>    far been assumed that the same expectations of pervasive reachability
>    would exist in the IPv6-addressed Internet.  However, if DNS
>    whitelisting is deployed, this will not be the case since only end
>    user hosts using DNS recursive resolvers which are included in the

again, you mean /name-based/ reachability.


>
>
>
> Livingood                Expires August 26, 2011               [Page 16]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    ACL of a given domain using DNS whitelisting would be able to reach
>    new servers in that given domain via IPv6 addresses.  The expectation
>    of any end user host being able to connect to any server (essentially
>    both hosts, just at either end of the network), defined here as
>    "pervasive reachability", will change to "restricted reachability"
>    with IPv6.
>
>    Establishing DNS whitelisting as an accepted practice in the early
>    phases of mass IPv6 deployment could well establish it as an integral
>    part of how IPv6 DNS resource records are deployed globally.  As a
>    result, it is then possible that DNS whitelisting could live on for
>    decades on the Internet as a key foundational element of domain name
>    management that we will all live with for a long time.

(that last sentence could benefit from some editing.)


>    It is a critical to understand that the concept of reachability
>    described above depends upon a knowledge or awareness of an address
>    in the DNS.  Thus, in order to establish reachability to an end
>    point, a host is dependent upon looking up an IP address in the DNS

If this section were started with a sentence like this, then there would not be 
a problem with the other references' being confused with address-based routing 
reachability.


>    when a FQDN is used.  When DNS whitelisting is used, it is quite
>    likely the case that an IPv6-enabled end user host could ping or
>    connect to an example server host, even though the FQDN associated
>    with that server host is restricted via a DNS whitelist.  Since most

First, I suspect that "example" doesn't add meaning to the sentence.  Second, 
pinging and connecting might happen with or without the whitelist entry.  So I 
do not understand what import there is in this sentence.


>    Internet applications and hosts such as web servers depend upon the
>    DNS, and as end users connect to FQDNs such as www.example.com and do
>    not remember or wish to type in an IP address, the notion of
>    reachability described here should be understood to include knowledge
>    how to associate a name with a network address.

Again, this 'premise' statement should introduce the sub-section, not end it.


>
> 7.3.  Operational Implications
>
>    This section explores some of the operational implications which may
>    occur as a result of, are related to, or become necessary when
>    engaging in the practice of DNS whitelisting.
>
> 7.3.1.  De-Whitelisting May Occur

The more general version of this issue is 'synchronization'.  Entries in the 
whitelist need to be synchronized with host status and capabilities.


>    It is possible for a DNS recursive resolver added to a whitelist to
>    then be removed from the whitelist, also known as de-whitelisting.
>    Since de-whitelisting can occur, through a decision by the
>    authoritative server operator, the domain owner, or even due to a
>    technical error, an operator of a DNS recursive resolver will have
>    new operational and monitoring requirements and/or needs as noted in
>    Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5.
>
> 7.3.2.  Authoritative DNS Server Operational Implications
>
>    Operators of authoritative servers may need to maintain an ACL a

a -> on a (?)


>    server-wide basis affecting all domains, on a domain-by-domain basis,
>
>
> Livingood                Expires August 26, 2011               [Page 17]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    as well as on a combination of the two.  As a result, operational

I'm not really understanding the first sentence.  One problem might be that its 
discussing an implication of some configuration or usage options that have not 
been previously specified, so that the reference here might be overly cryptic.

For example, I don't know what "affecting all domains" actually means.  It 
almost sounds as if it could mean "everyone gets AAAA records" or "no one gets 
AAAA records" yet I'm reaonably certain that is /not/ what is meant.


>    practices and software capabilities may need to be developed in order
>    to support such functionality.  In addition, processes may need to be
>    put in place to protect against inadvertently adding or removing IP
>    addresses, as well as systems and/or processes to respond to such
>    incidents if and when they occur.  For example, a system may be
>    needed to record DNS whitelisting requests, report on their status
>    along a workflow, add IP addresses when whitelisting has been
>    approved, remove IP addresses when they have been de-whitelisted, log
>    the personnel involved and timing of changes, schedule changes to
>    occur in the future, and to roll back any inadvertent changes.

Might be worth starting with a simple, broad summary statement, possibly along 
the lines of:

    An AAAA DNS Whitelist serves as a critical infrastructure service; to be 
useful it needs careful and extensive administration, monitoring and operation. 
  Each new and essential mechanism creates substantial follow-on support costs.


>    Operators may also need implement new forms of monitoring in order to
>    apply change control, as noted briefly in Section 7.3.4.
>
> 7.3.3.  DNS Recursive Resolver Server Operational Implications
>
>    Operators of DNS recursive resolvers, which may include ISPs,
>    enterprises, universities, governments, individual end users, and
>    many other parties, are likely to need to implement new forms of
>    monitoring, as noted briefly in Section 7.3.4.  But more critically,
>    such operators may need to add people, processes, and systems in
>    order to manage large numbers of DNS whitelisting applications as
>    part of their own IPv6 transition, for all domains that the end users
>    of such servers are interested in now or in which they may be

I think the summary observation is simple and should be stated directly:  This 
is a manual mechanism that becomes expensive in time and personnel effort as it 
scales up.


>    interested in the future.  As anticipation of interesting domains is
>    likely infeasible, it is more likely that operators may either choose
>    to only apply to be whitelisted for a domain based upon one or more
>    end user requests, or that they will attempt to do so for all domains
>    that they can ascertain to be engaging in DNS whitelisting.

"attempt to do so for all domain that they can ascertain to be engaging in DNS 
whitelisting"  appears to be saying to do whitelisting for domains that do 
whitelisting.  I don't understand.


>
>    When operators apply for DNS whitelisting for all domains, that may

"apply for DNS whitelisting for all domains" -- again I'm not understanding what 
this means.


> 7.3.5.  Implications of Operational Momentum
>
>    It seems plausible that once DNS whitelisting is implemented it will
>    be very difficult to deprecate such technical and operational
>    practices.  This assumption is based in an understanding of human

in -> on


>    nature, not to mention physics.  For example, as Sir Issac Newton
>    noted, "Every object in a state of uniform motion tends to remain in
>    that state of motion unless an external force is applied to it" [Laws

Code does not have momenum.  Neither do configurations or lists.  This really 
isn't about physics.

It is entirely about group psychology, as you note, and the administrative 
challenges in the logistics of large-scale operational changes (which probably 
/does/ have something to with physics, but it seems a stretch to credit Newton. 
How about Heisenberg?...)


>    of Motion].  Thus, once DNS whitelisting is implemented it is quite
>    likely that it would take considerable effort to deprecate the
>    practice and remove it everywhere on the Internet - it will otherwise
>    simply remain in place in perpetuity.  To better illustrate this
>    point, one could consider one example (of many) that there are many
>    email servers continuing to attempt to query or otherwise check anti-
>
>
>
> Livingood                Expires August 26, 2011               [Page 19]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    spam DNS blocklists which have long ago ceased to exist.
>
> 7.3.6.  Troubleshooting Implications
>
>    The implications of DNS whitelisted present many challenges, which
>    have been detailed in Section 7.  These challenges may negatively

But this is /still/ section 7.  Can you be more specific?  Or perhaps say 
"throughout this section".


>    affect the end users' ability to troubleshoot, as well as that of DNS
>    recursive resolver operators, ISPs, content providers, domain owners
>    (where they may be different from the operator of the authoritative
>    DNS server for their domain), and other third parties.  This may make
>    the process of determining why a server is not reachable
>    significantly more complex.
>
> 7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis
>
>    Additional implications, should this be deployed on an ad hoc basis,
>    could include scalability problems relating to operational processes,

I'm pretty sure that scaling problems for this exist in all scenarios, not just 
ad hoc usage.


>    monitoring, and ACL updates.  In particular, it seems likely that as
>    the number of domains that are using DNS whitelisting increases, as
>    well as the number of IPv6-capable networks requesting to be
>    whitelisted, that there is an increased likelihood of configuration
>    and other operational errors, especially with respect to the ACLs
>    themselves.
>
>    It is unclear when and if it would be appropriate to change from
>    whitelisting to blacklisting, and whether or how this could feasibly
>    be coordinated across the Internet, which may be proposed or

Actually the question of coordination is quite clear and rather fundamental:

      No.

Anyone believing otherwise needs to cite a successful example, at Internet scale 
and diversity, more recently than the 1983 switch to IP (which didn't go all 
that well anyhow...)

Simple, unambiguous showstoppers should be stated in a simple and direct manner. 
  When there is room for debate, softer language makes sense.  Again, if the 
question of coordination really is subject to debate, then the basis needs to be 
stated.  (Good luck!)


>    implemented on an ad hoc basis when a majority of networks (or
>    allocated IPv6 address blocks) have been whitelisted.  Finally, some
>    parties implementing DNS whitelisting consider this to be a temporary
>    measure.  As such, it is not clear how these parties will judge the
>    network conditions to have changed sufficiently to justify disabling
>    DNS whitelisting and/or what the process and timing will be in order
>    to discontinue this practice.
>
>    One further potential implication is that an end user with only an
>    IPv4 address, using a DNS resolver which has not been whitelisted by
>    any domains, would not be able to get any AAAA resource records.  In
>    such a case, this could give that end user the incorrect impression
>    that there is no IPv6-based content on the Internet since they are
>    unable to discover any IPv6 addresses via the DNS.
>
> 7.4.  Homogeneity May Be Encouraged
>
>    A broad trend which has existed on the Internet appears to be a move
>    towards increasing levels of heterogeneity.  One manifestation of

increasing levels of heterogeneity -> more heterogeneity

(I think heterogeneity does not have 'levels'.)

Substantively:  say the nature of the heterogeneity within the initial claim. 
For example, there is /less/ heterogeneity of ISPs, given industry 
consolidation.  There is less heterogeneity of infrastructure equipment such as 
routers.  Etc.


>    this is in an increasing number, variety, and customization of end
>    user hosts, including home network, operating systems, client
>
>
>
> Livingood                Expires August 26, 2011               [Page 20]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    software, home network devices, and personal computing devices.  This
>    trend appears to have had a positive effect on the development and
>    growth of the Internet.  A key facet of this that has evolved is the
>    ability of the end user to connect any technically compliant device
>    or use any technically compatible software to connect to the
>    Internet.  Not only does this trend towards greater heterogeneity
>    reduce the control which is exerted in the middle of the network,
>    described in positive terms in [Tussle in Cyberspace], [Rethinking
>    the Internet], and [RFC3724], but it can also help to enable greater
>    and more rapid innovation at the edges.
>
>    An unfortunate implication of the adoption of DNS whitelisting may be
>    the encouragement of a reversal of this trend, which would be a move

the encouragement of -> to encourage


> 8.1.  Implement DNS Whitelisting Universally
>
>    One obvious solution is to implement DNS whitelisted universally, and
>    to do so using some sort of centralized registry of DNS whitelisting
>    policies, contracts, processes, or other information.  This potential
>    solution seems unlikely at the current time.

I'm pretty sure that the only thing that is obvious about a premise of universal 
adoption is that it's not practical.  Seriously.

At the least, this section needs to be less cavalier about putting this 
alternative forward as a "solution", especially given the rather serious 
drawbacks/problems with it.


> 8.2.  Implement DNS Whitelisting On An Ad Hoc Basis
>
>    If DNS whitelisting is to be adopted, it is likely to be adopted on

"is to be"?  I thought it already had a significant installed base.


>    this ad hoc, or domain-by-domain basis.  Therefore, only those
>    domains interested in DNS whitelisting would need to adopt the
>    practice, though as noted herein discovering that they a given domain
>    has done so may be problematic.  Also in this scenario, ad hoc use by
>    a particular domain may be a temporary measure that has been adopted
>    to ease the transition of the domain to IPv6 over some short-term
>    timeframe.
>
> 8.3.  Do Not Implement DNS Whitelisting
>
>    As an alternative to adopting DNS whitelisting, the Internet
>    community generally can choose to take no action whatsoever,
>    perpetuating the current predominant authoritative DNS operational
>    model on the Internet, and leave it up to end users with IPv6-related
>    impairments to discover and fix those impairments.
>

That is, place the burden of fixing a problem on those creating it?


>
>
>
>
> Livingood                Expires August 26, 2011               [Page 23]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
> 8.3.1.  Solving Current End User IPv6 Impairments
>
>    A further extension of not implementing DNS whitelisting, is to also
>    endeavor to actually fix the underlying technical problems that have
>    prompted the consideration of DNS whitelisting in the first place, as
>    an alternative to trying to apply temporary workarounds to avoid the
>    symptoms of underlying end user IPv6 impairments.  A first step is
>    obviously to identify which users have such impairments, which would
>    appear to be possible, and then to communicate this information to
>    end users.  Such end user communication is likely to be most helpful
>    if the end user is not only alerted to a potential problem but is
>    given careful and detailed advice on how to resolve this on their
>    own, or where they can seek help in doing so.  Section 11 may also be
>    relevant in this case.
>
>    One challenge with this option is the potential difficulty of
>    motivating members of the Internet community to work collectively
>    towards this goal, sharing the labor, time, and costs related to such
>    an effort.  Of course, since just such a community effort is now
>    underway for IPv6, it is possible that this would call for only a
>    moderate amount of additional work.

This 'challenge' is at the core of /all/ adoption efforts for Internet protocols 
and services that entail distributed adoption.


>    Despite any potential challenges, many in the Internet community are
>    already working towards this goal and/or have expressed a general
>    preference for this approach.

If this is not already an organized effort with a website, sponsoring 
consortium, or the like, it should be.  If it is, then cite it in this doc!

>
> 8.3.2.  Gain Experience Using IPv6 Transition Names
>
>    Another alternative is for domains to gain experience using an FQDN
>    which has become common for domains beginning the transition to IPv6;
>    ipv6.example.com and www.ipv6.example.com.  This can be a way for a
>    domain to gain IPv6 experience and increase IPv6 use on a relatively
>    controlled basis, and to inform any plans for DNS whitelisting with
>    experience.

I do not understand what this means.

What is it for?  What are the results?  How are theyused?


> 9.  Is DNS Whitelisting a Recommended Practice?
>
>    Opinions in the Internet community concerning whether or not DNS
>    whitelisting is a recommended practice are understandably quite
>    varied.  However, there is clear consensus that DNS whitelisting is
>    at best a useful temporary measure which a domain may choose to

If that is a clear consensus, then it makes even less sense to promote the idea 
of universal adoption, given the timescale needed to achieve it.


> 10.  Security Considerations
>
>    There are no particular security considerations if DNS whitelisting
>    is not adopted, as this is how the public Internet works today with A
>    resource records.

Or rather, failure to adopt a mechanism like this or repair the underlying 
problem, for those sites experiencing that problem, will result in a denial of 
service, albeit not an intentional one.  Still, that's a pretty basic security 
issue.


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From v6ops@globis.net  Mon May  9 10:57: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 C0217E0922 for ; Mon,  9 May 2011 10:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level: 
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 6CkwuL9sEWze for ; Mon,  9 May 2011 10:57:47 -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 E7088E06A4 for ; Mon,  9 May 2011 10:57:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6BD628700F2 for ; Mon,  9 May 2011 19:52:31 +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 hcnBqvYQziMf for ; Mon,  9 May 2011 19:52:26 +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 0F172870062 for ; Mon,  9 May 2011 19:52:26 +0200 (CEST)
Message-ID: <4DC829CC.80302@globis.net>
Date: Mon, 09 May 2011 19:52:12 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: "v6ops@ietf.org WG" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [v6ops]  Apologies
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 17:57:47 -0000

It has been brought to my attention (in a very polite way) that some 
recent posts to this list have not been received as being constructive, 
and that rather they are somehow perceived as part of a general attempt 
at spreading FUD and a DOS attack. That was certainly not the intention. 
It was suggested that if I had any honor then I would post a message 
apologizing to the list.

I understood that the v6ops list existed to solicit input from network 
operators and users to identify operational issues with the IPv4/IPv6 
Internet. Operational issues by their very nature may seem trivial or 
low level, but they may also make or break the roll out of IPv6. Not all 
users will have the same requirements or deployment methodology.

I can assure you that my only intention is to try to improve the end 
user experience and ease of roll out of IPv6, especially for large 
complex commercial environments who currently run production IPv4 
networks that are business critical. The issues I have raised seem to be 
of genuine operational concern to some large corporations who are 
planning on rolling out IPv6. In fact, some private answers from 
individuals have thanked me for my contribution and asked me to post 
further to the list to solicit opinions from a wider audience. Please 
also note that I have personally already observed several adverse 
effects arising from the unintentional deployment of IPv6 transition 
mechanisms in production IPv4 networks. These corporations seem unlikely 
or unwilling to post their operational problems to this list themselves, 
possibly for fear of reputational damage.

So please excuse me for not knowing the accepted "way of working" of the 
list. If you have any pointers on how contributions about operational 
issues from end users can be brought in a more positive and useful way 
to the WG, thus leading to the general good functioning of the WG in 
improving the overall end-user experience of IPv6, please do not be 
afraid to contact me in complete confidence.

In the meantime, I shall refrain from responding further to the list 
until I receive a clear "OK" to do so.

regards,
RayH

From marka@isc.org  Mon May  9 11:01: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 B9E19E069C for ; Mon,  9 May 2011 11:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.999
X-Spam-Level: 
X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 YBW1zVIgqnpT for ; Mon,  9 May 2011 11:01:43 -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 0CE77E06EC for ; Mon,  9 May 2011 11:01:43 -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 608685F98EC; Mon,  9 May 2011 15:40:03 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 AA9BC216C40; Mon,  9 May 2011 15:40:00 +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 DE031E99038; Tue, 10 May 2011 01:40:20 +1000 (EST)
To: Philip Homburg 
From: Mark Andrews 
References: 
In-reply-to: Your message of "Mon, 09 May 2011 16:34:18 +0200." 
Date: Tue, 10 May 2011 01:40:20 +1000
Message-Id: <20110509154020.DE031E99038@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-andrews-v6ops-6to4-router-option-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, 09 May 2011 18:01:43 -0000

In message , Philip Homburg writes:
> In your letter dated Mon, 9 May 2011 06:55:01 -0700 (PDT) you wrote:
> >A new draft has been posted, at http://tools.ietf.org/html/draft-andrews-v6o
> ps
> >-6to4-router-option. Please take a look at it and comment.
> 
> The first question I have is why would anyone want to use an address other
> than the RFC-3068 defined one?  What's the point? 
 
There is lots of value in not using the anycast relay routers.

> I think it is important to evaluate 6ot4 in the context of the measurements
> done by Geoff Huston and others.

The point is to use a relay that is local to the client (mostly
eliminating the transmission delays causes by using a relay router)
that is being run by someone the client has a contract with (allows
faults to be reported).  Both of these are issues identified by
Geoff and others.

> And using a different IPv4 address for the relay is most likely just
> going to break things.

This is a unsubstanciated claim.

> The second question is the value of disabling 6to4 by returning 0.0.0.0. By
> itself that sounds like a useful feature. But features are not for free. 
> You have implement them, document them, test them. There may have unexpected
> security or other operational implications, etc.
> 
> So assuming that in future 6to4 is disabled by default. The only thing this
> feature does override the user's preference to turn 6to4 on. I don't think it
> makes any sense to implement this feature.

Lots of equipment moves between networks.  In one network 6to4 will
work and in another 6to4 won't work or it causes operational problems
for the network when the 6to4 is misconfigured (rogue RAs which
blackhole IPv6 traffic).  In the first you use the option to optimise
traffic flows.  In the latter you set the option to 0.0.0.0 to
disable 6to4.  The equipment can safely move between networks without
requiring reconfiguration everytime it moves.

> _______________________________________________
> 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 gert@space.net  Mon May  9 11:10: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 910ECE0681 for ; Mon,  9 May 2011 11:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level: 
X-Spam-Status: No, score=-2.562 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 BfA9otn84+UI for ; Mon,  9 May 2011 11:10:45 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.97.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0A4E069F for ; Mon,  9 May 2011 11:10:44 -0700 (PDT)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 40B08F81F7 for ; Mon,  9 May 2011 20:10:31 +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 2DE3DF81D7 for ; Mon,  9 May 2011 20:10:31 +0200 (CEST)
Received: (qmail 39699 invoked by uid 1007); 9 May 2011 20:10:31 +0200
Date: Mon, 9 May 2011 20:10:31 +0200
From: Gert Doering 
To: Ray Hunter 
Message-ID: <20110509181031.GR30227@Space.Net>
References: <4DC829CC.80302@globis.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4DC829CC.80302@globis.net>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Apologies
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 18:10:54 -0000

Hi,

On Mon, May 09, 2011 at 07:52:12PM +0200, Ray Hunter wrote:
> In the meantime, I shall refrain from responding further to the list 
> until I receive a clear "OK" to do so.

I found your e-mails pretty direct at some points, but in a "well, this
is what I'm worried about, so you should know about!" way.

I'm running a small(ish) ISP network here, and we are facing completely
different issues - and so are our customers, most of them small or medium
enterprises, nothing multinational or anywhere near the scale you describe,
and we tend to "turn things on, see what breaks, and fix those things"
(which works if you're small enough to be able to fix in reasonable time).

So for me, it was quite educational to hear about your point of view
from a very different background.

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 fred@cisco.com  Mon May  9 11:21: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 1A3DCE0787 for ; Mon,  9 May 2011 11:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.506
X-Spam-Level: 
X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 i0skmTizdhTh for ; Mon,  9 May 2011 11:21:02 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 496C9E0780 for ; Mon,  9 May 2011 11:21:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=197; q=dns/txt; s=iport; t=1304965262; x=1306174862; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=eFcG2tzS2mJ7eM8+VdS09TqeTceQV3q+0mfZPsJLs+o=; b=LJunAkrMmtTa6v4gkB/ldT3lYNCfJqEJjX5pmT46blorr+tzCqUI/Swb JeATP9OMWm4JKr0e89DgWaMB8d4W4TNVGBABb3SZQIC0eh6EOOMRytFMV FyYkUQSrtvJaJB8Lb+tvs3diRTDgwooJ+/eqFHziitKNcFhe1GA/jTVZE E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAOwvyE2rRDoG/2dsb2JhbACmAneIcaAQnhiGDASGQIklhCiKVQ
X-IronPort-AV: E=Sophos;i="4.64,341,1301875200"; d="scan'208";a="353378336"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 09 May 2011 18:21:01 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p49IKA57014007; Mon, 9 May 2011 18:21:01 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Mon, 09 May 2011 11:21:01 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Mon, 09 May 2011 11:21:01 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: <20110509181031.GR30227@Space.Net>
Date: Mon, 9 May 2011 11:21:01 -0700
Message-Id: <59AC6771-F8D5-489F-AE65-B84B48EA5EF2@cisco.com>
References: <4DC829CC.80302@globis.net> <20110509181031.GR30227@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Apologies
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 18:21:03 -0000

On May 9, 2011, at 11:10 AM, Gert Doering wrote:

> So for me, it was quite educational to hear about your point of view
> from a very different background.

That has been my view as well.

From bs7652@att.com  Mon May  9 11:41: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 26CDCE06F0 for ; Mon,  9 May 2011 11:41:07 -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 j0Fc3YYDSeap for ; Mon,  9 May 2011 11:41:06 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6D4E06DD for ; Mon,  9 May 2011 11:41:06 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-12.tower-120.messagelabs.com!1304966066!16759766!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 18019 invoked from network); 9 May 2011 18:34:26 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 May 2011 18:34:26 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p49IXMn3014172; Mon, 9 May 2011 14:33:23 -0400
Received: from 01GAF5142010622.AD.BLS.COM (01GAF5142010622.ad.bls.com [139.76.131.83]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with SMTP id p49IXC80013911; Mon, 9 May 2011 14:33:19 -0400
Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 9 May 2011 14:33:59 -0400
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 9 May 2011 14:33:58 -0400
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: Mon, 9 May 2011 14:34:19 -0400
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F1C15E0DC@crexc50p>
In-Reply-To: <59AC6771-F8D5-489F-AE65-B84B48EA5EF2@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] Apologies
Thread-Index: AcwOddxv0PbGpw4fQfWB7PNVsgF5EwAAOt4A
References: <4DC829CC.80302@globis.net> <20110509181031.GR30227@Space.Net> <59AC6771-F8D5-489F-AE65-B84B48EA5EF2@cisco.com>
From: "STARK, BARBARA H (ATTSI)" 
To: "Fred Baker" , "Gert Doering" 
X-OriginalArrivalTime: 09 May 2011 18:33:59.0018 (UTC) FILETIME=[A93D84A0:01CC0E77]
Cc: Ray Hunter , v6ops@ietf.org
Subject: Re: [v6ops] Apologies
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 18:41:07 -0000

+1
Please don't stop posting! I thought your comments were great -- concise
and filled with real-world experience. And professionally stated.
Barbara

>=20
> > So for me, it was quite educational to hear about your point of view
> > from a very different background.
>=20
> That has been my view as well.

From ek@google.com  Mon May  9 12: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 1C919E069C for ; Mon,  9 May 2011 12:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.653
X-Spam-Level: 
X-Spam-Status: No, score=-106.653 tagged_above=-999 required=5 tests=[AWL=-0.676, 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 rFdGG3MMJfvl for ; Mon,  9 May 2011 12:38:07 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id DD80EE0663 for ; Mon,  9 May 2011 12:38:06 -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 p49JGflw012184 for ; Mon, 9 May 2011 12:16:41 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304968601; bh=ykTmVKTQNBpvkvfXQ4ub2/SshZc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=UdUYVCLptZzcWS2Uj7L0EwriigNeqTGb32QU6e/mI04cDba4VM5SDni5x8CikvgEK ESm4kDYXW0aqzprCzctOQ==
Received: from pxi20 (pxi20.prod.google.com [10.243.27.20]) by hpaq13.eem.corp.google.com with ESMTP id p49JGdM0027165 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 9 May 2011 12:16:40 -0700
Received: by pxi20 with SMTP id 20so4021052pxi.27 for ; Mon, 09 May 2011 12:16:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rHhYIrO9O4ZXWo0HRW/3c/Tl8zs3kNU5nVz429fz6zE=; b=TmPTojX2CMvZOwBtrt8f3EMusYL2BPc/wU++T5xCXheBQQ5IMwYITS7vPVEHNvo8cd R+3y13hVDtI7OrExdXPg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=L7DnJHI/w4IR6DWE7j8MW0zB9X1/vV+dIURPA3JP75sFD096AnlGWiJ1EuWAF9ikwy oRmwdLQP50Vi67QN4YTg==
MIME-Version: 1.0
Received: by 10.142.250.2 with SMTP id x2mr3786406wfh.381.1304968598724; Mon, 09 May 2011 12:16:38 -0700 (PDT)
Received: by 10.142.245.14 with HTTP; Mon, 9 May 2011 12:16:38 -0700 (PDT)
In-Reply-To: 
References:  <20110509154020.DE031E99038@drugs.dv.isc.org> 
Date: Mon, 9 May 2011 19:16:38 +0000
Message-ID: 
From: Erik Kline 
To: Mark Andrews 
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-andrews-v6ops-6to4-router-option-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, 09 May 2011 19:38:08 -0000

Even with this attempt to help make the "first hop" more reliable, it
will not and cannot address the return path failures.  This is
fundamental to the 2002::/16 aspect of 3068.

Geoff's numbers for failures when the server sees SYNs from 2002::/16
client addresses are remarkable, and don't satisfactorily diminish
even when the return route to 2002::/16 is on the server sending the
SYN-ACK (i.e. it encapsulates it directly).

The *return path* problem is what 6rd fixes.  Optimizing the client
proximity to its relay is insufficient to make the mechanism useful at
scale for IPv6 transition.

Let's let -advisory and -historic do their thing.

From rogerj@gmail.com  Mon May  9 12: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 B6612E088A for ; Mon,  9 May 2011 12:56:21 -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=[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 3rnZH4sp1Ld1 for ; Mon,  9 May 2011 12:56: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 C22B2E0855 for ; Mon,  9 May 2011 12:56:20 -0700 (PDT)
Received: by wyb29 with SMTP id 29so4853111wyb.31 for ; Mon, 09 May 2011 12:56:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6nh2UPkAn/K8qag71xDQ1xOGaH9zhAH7t3mEO6qSMis=; b=bgu5ykuzr+EUuyVR1vnYLCFM0NEwgUNT5tF/TLjdyGlN0s6P63xKn/Ep35ooRsug5/ U+iQGOPRQB+3UftJnzofiJ2glBH9yr5y9bfcAPDEu6N6nRUShGsMtWxPNdOm/Zi9c3Du xqNk/8XGQZKh7x+eAluSl5feRDxKzodHprQh4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Z7bDTEiVIjMu2h5m8Mnok37PX80t4hcXrsoL7Ko//DqBe9k941Ikkdn2mXT+CUbj2a cEs0ahpVzjLaPP+IhtoBofeZFvgi6vE0iIlWPFWkulY5STW+VN8aHjZR/Dp6izC2uWTH xP42Cn+kdKQu7mFKYdUWiNMzQiBWxG8CV1zA0=
MIME-Version: 1.0
Received: by 10.227.55.68 with SMTP id t4mr7254335wbg.78.1304970979073; Mon, 09 May 2011 12:56:19 -0700 (PDT)
Received: by 10.227.146.208 with HTTP; Mon, 9 May 2011 12:56:18 -0700 (PDT)
In-Reply-To: <4DC829CC.80302@globis.net>
References: <4DC829CC.80302@globis.net>
Date: Mon, 9 May 2011 21:56:18 +0200
Message-ID: 
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: Ray Hunter 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Apologies
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 19:56:21 -0000

Don't stop posting, we need all sort of views on this list to make the best
out of whats ahead:) Have to say as Gert, it was quite educational.


Earlier I worked for an ISP and was part of building their first big IPv6
network, but currently I work for something which is more of a
network/organization or maybe you could call us one of the Enterprises.


Right now I finally got around to do something real with IPv6 and the issue
I get into are quite different from what I saw on the ISP side.
And just like you I don't have the option of try and fail, I have to
get it right
the first time around when it comes to things that are facing our customers=
.

The biggest problem right now are howto not do NAT when doing IPv6.
It is not an option to not run NAT in some form or another.



On Mon, May 9, 2011 at 7:52 PM, Ray Hunter  wrote:




--=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 ek@google.com  Mon May  9 13:07: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 E3D4CE06B7 for ; Mon,  9 May 2011 13:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.466
X-Spam-Level: 
X-Spam-Status: No, score=-106.466 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 YFwK5eKxrVSI for ; Mon,  9 May 2011 13:07:54 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D394EE065D for ; Mon,  9 May 2011 13:07:53 -0700 (PDT)
Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p49K7qqA022337 for ; Mon, 9 May 2011 13:07:52 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304971672; bh=3I2YZVtHY1j3nGvd4xHeUjFAtHU=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=dxADzi3rd2LeZnMgTVfiKfR7L8mjpuYnoxVSjC+N/HydFaw0rN/qx37d275/iqTK5 2NuteiUgYDts2bfpjN2Iw==
Received: from pxi9 (pxi9.prod.google.com [10.243.27.9]) by kpbe20.cbf.corp.google.com with ESMTP id p49K7N6e016090 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 9 May 2011 13:07:51 -0700
Received: by pxi9 with SMTP id 9so4338195pxi.14 for ; Mon, 09 May 2011 13:07:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=kjZLIAqGwui1DQfj6LUliKbqwCRD7idefV1Ez4db6ak=; b=h9UxhFyj0RvkSHB5nfoq5VySMfEgXaMNGxaDa2cIxLYJNnahMCW8haRfOoMtqImzm3 jrLRfLmyyWPNrt0UxoDQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=jbcGmBF44ceTYFl9LvtW66drYkjQ2v/HdGIJLRpwc8+zxExbgJyV/7ZlWdylqcGbWL K4/r79wZXo8yN9a8nZcA==
MIME-Version: 1.0
Received: by 10.142.214.17 with SMTP id m17mr597800wfg.39.1304971670046; Mon, 09 May 2011 13:07:50 -0700 (PDT)
Received: by 10.142.245.14 with HTTP; Mon, 9 May 2011 13:07:50 -0700 (PDT)
Date: Mon, 9 May 2011 20:07:50 +0000
Message-ID: 
From: Erik Kline 
To: =?UTF-8?Q?Roger_J=C3=B8rgensen?= 
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
Cc: "v6ops@ietf.org WG" 
Subject: [v6ops] IPv6 Enterprise issues (was: Apologies)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 20:07:55 -0000

"""
The biggest problem right now are howto not do NAT when doing IPv6.
It is not an option to not run NAT in some form or another.
"""

Can you elaborate?

We have not found it necessary at all for the 10-20k+ corporate IPv6
users, but I'm fully prepared to believe that we see things
differently.

From rogerj@gmail.com  Mon May  9 13: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 47468E0959 for ; Mon,  9 May 2011 13:54:22 -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=[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 2WTSlC9vm1cr for ; Mon,  9 May 2011 13:54:20 -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 354B1E06A1 for ; Mon,  9 May 2011 13:54:20 -0700 (PDT)
Received: by wwa36 with SMTP id 36so4254622wwa.13 for ; Mon, 09 May 2011 13:54:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vlX3xq+YQahYR+J2GEF46jYEnv15tdgt3rDKfT4wEUQ=; b=nJM7zmcDRiPYQOQsA0pZPNW2Y8swCEJ0n9Fvl7lJBUAesXj+ZzezITqf1Hhg59tvxi no7od2aARsmoVZuqFWnpNh6mrp0pJK8OnT8NlxMO2C1CQuVpx0+TwbURro30FxCtupGg eVnPyGpOvuzDQ4wWiRz0EARmhB/x3FBBuVeZA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BCA8vouRBpmlSvSwirRy7a5jZJJeyg8LsdxzPg6FqqBteIVnriG6W10j2jhKH8pBDG tEg3+n0BPgn/Dwgs7RM5+nM4OHCSvLhvUKgO3xY0V1V2+Xjr+dfuGzXD8MAD0+qlJllv YEh9mGGTDQhAtLsLedXTKjUSZzRLHulqbQ3SU=
MIME-Version: 1.0
Received: by 10.227.198.10 with SMTP id em10mr6181546wbb.108.1304974458973; Mon, 09 May 2011 13:54:18 -0700 (PDT)
Received: by 10.227.146.208 with HTTP; Mon, 9 May 2011 13:54:18 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 9 May 2011 22:54:18 +0200
Message-ID: 
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: Erik Kline 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] IPv6 Enterprise issues (was: Apologies)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 20:54:22 -0000

On Mon, May 9, 2011 at 10:07 PM, Erik Kline  wrote:
> """
> The biggest problem right now are howto not do NAT when doing IPv6.
> It is not an option to not run NAT in some form or another.
> """
>
> Can you elaborate?
>
> We have not found it necessary at all for the 10-20k+ corporate IPv6
> users, but I'm fully prepared to believe that we see things
> differently.

We are not really an ISP or a real enterprise, we are set to run a closed
network.

Consider it a sort of Internet light which interconnect lots of other
end-sites and other networks. The entire  RFC1918 space are used
several times over and by several of the network we interconnect with,
and some are running public IP addresses. Some of the networks are
even more closed than ours. Internet light with tons of NATs.
(closed don't really hang together with security, more with practical
solutions combined with the thought of NAT is nice)



Everyone also agree there is a need for communications to/from Internet,
but how?


It is _not_ an option to let everyone freely communicate to/from Internet i=
n
any way. It sort of indirect mandate use of NAT or proxy services in one
form or  another. Forget the thought of changing that for the near term
future, we are set to run a _closed_ network.




Mail and DNS are the easy one, what about web traffic? streaming?
youtube etc... not so clear yet if we can do it with IPv6 at all.

Can we enable IPv6 for some of our customers? How do we give them
access to IPv4 _only_ services? Consider legacy software and hardcoded
IPv4 IP adresses... Maybe we can let some of our customer be IPv6 only?
Still, that don't lower the usage of IPv4 adresses.
Can we start using IPv6 on some part of our network, some of the
interconnect or VPNs? But guess what, we are also depending on ISPs
to deliver some of the links and not all of them support IPv6 at all....
and the list goes on.




Oh and the IPv4 shortage have already hit us hard.

We knew we would be running low on usable IPv4 adresses so we had started
the process towards RIPE to get a new block. But we ran low way faster than
planned combined with HD-ratio discussion which caused the process to get
new addresses to take longer. Problems....
The solution was to rearrange some tasks related to projects to get around
the HD-ratio discussion. So it also cost us resources both in manhour and
money.

But all of this just postpone what we know will hit us, we will run
out of usable
(public) IPv4 adresses.





My current project are to build an ISP-lite network isolated from the
rest to get
the outer edge of our network up'n'running, to see how we can build the res=
t
in one way or another. Try out some of the options and solutions safely.



--=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 mksmith@mac.com  Mon May  9 13:55: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 7D4E9E0968 for ; Mon,  9 May 2011 13:55:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level: 
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8KjXa-lPfmox for ; Mon,  9 May 2011 13:55:35 -0700 (PDT)
Received: from asmtpout012.mac.com (asmtpout012.mac.com [17.148.16.87]) by ietfa.amsl.com (Postfix) with ESMTP id 9C63AE08A7 for ; Mon,  9 May 2011 13:55:08 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_oGk3BncPBsYVdJKpu+Ot9g)"
Received: from spool002.mac.com ([10.150.69.52]) by asmtp012.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LKY00AAZ4QSCO90@asmtp012.mac.com> for v6ops@ietf.org; Mon, 09 May 2011 13:54:41 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-05-09_06:2011-05-09, 2011-05-09, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1105090138
Received: from localhost ([10.150.79.232]) by spool002.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LKY0037J4QX5C30@spool002.mac.com>; Mon, 09 May 2011 13:54:33 -0700 (PDT)
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1105090138
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-05-09_06:2011-05-09, 2011-05-09, 1970-01-01 signatures=0
To: Erik Kline 
From: Michael Smith 
Date: Mon, 09 May 2011 20:54:33 +0000 (GMT)
X-Mailer: MobileMe Mail (1C3224)
Message-id: <0ab753e2-a6ab-cae8-8ecb-e97af27c9976@me.com>
In-reply-to: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] IPv6 Enterprise issues (was: Apologies)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 20:55:35 -0000

--Boundary_(ID_oGk3BncPBsYVdJKpu+Ot9g)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: quoted-printable

On May 09, 2011, at 01:07 PM, Erik Kline  wrote:=0A=0A"""=0A=
The biggest problem right now are howto not do NAT when doing IPv6.=0AIt i=
s not an option to not run NAT in some form or another.=0A"""=0A=0ACan you=
 elaborate?=0A=0AWe have not found it necessary at all for the 10-20k+ cor=
porate IPv6=0Ausers, but I'm fully prepared to believe that we see things=0A=
differently.=0A=A0=0AThere are compliance models that require NAT (PCI amo=
ngst them) and a set corporate mindset that a "stateful firewall with NAT"=
 is one key component to defense-in-depth. =A0Many security policies are w=
ritten with a MUST for NAT, not a SHOULD.=0A=0AWe've had to carve out a po=
rtion of our /32 for "NAT", in as much as I terminate one set of addresses=
 on the outside of my edge device and translate them into another set of m=
y addresses. =A0It satisfies the auditors because the incoming session is =
inspected and rewritten. =A0It's also insane, but there are engineering ne=
eds and business needs, and monthly recurring revenue often trumps enginee=
ring decisions.=0A=0AMike=

--Boundary_(ID_oGk3BncPBsYVdJKpu+Ot9g)
Content-type: multipart/related;
 boundary="Boundary_(ID_NzaBiI5f3WBNyw7OPhCPGA)"; type="text/html"


--Boundary_(ID_NzaBiI5f3WBNyw7OPhCPGA)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT


On May 09, 2011, at 01:07 PM, Erik Kline <ek@google.com> wrote:

"""

The biggest problem right now are howto not do NAT when doing IPv6.

It is not an option to not run NAT in some form or another.

"""



Can you elaborate?



We have not found it necessary at all for the 10-20k+ corporate IPv6

users, but I'm fully prepared to believe that we see things

differently.
 
There are compliance models that require NAT (PCI amongst them) and a set corporate mindset that a "stateful firewall with NAT" is one key component to defense-in-depth.  Many security policies are written with a MUST for NAT, not a SHOULD.

We've had to carve out a portion of our /32 for "NAT", in as much as I terminate one set of addresses on the outside of my edge device and translate them into another set of my addresses.  It satisfies the auditors because the incoming session is inspected and rewritten.  It's also insane, but there are engineering needs and business needs, and monthly recurring revenue often trumps engineering decisions.

Mike


--Boundary_(ID_NzaBiI5f3WBNyw7OPhCPGA)--

--Boundary_(ID_oGk3BncPBsYVdJKpu+Ot9g)--

From rogerj@gmail.com  Mon May  9 13:57: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 0FB29E06BE for ; Mon,  9 May 2011 13:57:32 -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=[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 eJJcTk-yXdPt for ; Mon,  9 May 2011 13:57:31 -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 31410E06A4 for ; Mon,  9 May 2011 13:57:30 -0700 (PDT)
Received: by wwa36 with SMTP id 36so4256608wwa.13 for ; Mon, 09 May 2011 13:57:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3N5WF2oB1g7TsT0VPJAedJYfB1LkPW1Z0Bq+fvJs/W8=; b=YMRl3qltUGiY4PSJb2oEAIHhVTOcLcUTiAmdpqeoMleqe8PxieNTA2XtdpJ2AkJPdb ZM9vjP3U6l+CHIibI1GcCPo9Q7FTD3cROMuKvzTZBNSh4f3LAEogdXJyXk4EZvORdOhy F1RC80vCQRbqRWKJBYgnBQyDqln5SbKsSctI8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZLzwFSr1zGfflgIrVtCiW210tbQzhmVF+Vj08Ft0Le/JjzKPkcNExEew8iVJbxE+XR oxmYX9OfmyISSCfh5qhdCeBkQd+qzmEDBj3IIURi2G6EPcbp2aR2ubAmoGgCwN3ZIKaJ gr675ypiqhaoi875R6HoKdnM8Jmlvoz8c4Fpk=
MIME-Version: 1.0
Received: by 10.227.55.68 with SMTP id t4mr7298635wbg.78.1304974649921; Mon, 09 May 2011 13:57:29 -0700 (PDT)
Received: by 10.227.146.208 with HTTP; Mon, 9 May 2011 13:57:29 -0700 (PDT)
In-Reply-To: 
References:  
Date: Mon, 9 May 2011 22:57:29 +0200
Message-ID: 
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: Michael Smith 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] IPv6 Enterprise issues (was: Apologies)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 20:57:32 -0000

On Mon, May 9, 2011 at 10:51 PM, Michael Smith  wrote:



> We've had to carve out a portion of our /32 for "NAT", in as much as I
> terminate one set of addresses on the outside of my edge device and
> translate them into another set of my addresses. =A0It satisfies the audi=
tors
> because the incoming session is inspected and rewritten. =A0It's also ins=
ane,
> but there are engineering needs and business needs, and monthly recurring
> revenue often trumps engineering decisions.

What technical solution did you chose for that rewriting?
(I don't want to comment on the rest;)

--=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 mksmith@mac.com  Mon May  9 14:01: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 D8B59E0944 for ; Mon,  9 May 2011 14:01:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.052
X-Spam-Level: 
X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 hkVgD6eykD17 for ; Mon,  9 May 2011 14:01:15 -0700 (PDT)
Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by ietfa.amsl.com (Postfix) with ESMTP id 242B3E0887 for ; Mon,  9 May 2011 14:01:15 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_0MeleAGKAC0cgX82XxkvtQ)"
Received: from spool002.mac.com ([10.150.69.52]) by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LKY005NS51QGX20@asmtp024.mac.com> for v6ops@ietf.org; Mon, 09 May 2011 14:01:06 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-05-09_06:2011-05-09, 2011-05-09, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1105090139
Received: from localhost ([10.150.79.232]) by spool002.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LKY0032851P5C40@spool002.mac.com>; Mon, 09 May 2011 14:01:02 -0700 (PDT)
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1105090139
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-05-09_06:2011-05-09, 2011-05-09, 1970-01-01 signatures=0
To: =?ISO-8859-1?B?Um9nZXIgSvhyZ2Vuc2Vu?= 
From: Michael Smith 
Date: Mon, 09 May 2011 21:01:01 +0000 (GMT)
X-Mailer: MobileMe Mail (1C3224)
Message-id: <9ce3820a-b80a-64fb-a974-c3b39877ff06@me.com>
In-reply-to: 
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] IPv6 Enterprise issues (was: Apologies)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 21:01:16 -0000

--Boundary_(ID_0MeleAGKAC0cgX82XxkvtQ)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: quoted-printable

=0AOn May 09, 2011, at 01:57 PM, Roger J=F8rgensen  wrot=
e:=0A=0AOn Mon, May 9, 2011 at 10:51 PM, Michael Smith  wr=
ote:=0A=0A=0A=0A> We've had to carve out a portion of our /32 for "N=
AT", in as much as I=0A> terminate one set of addresses on the outside of =
my edge device and=0A> translate them into another set of my addresses. =A0=
It satisfies the auditors=0A> because the incoming session is inspected an=
d rewritten. =A0It's also insane,=0A> but there are engineering needs and =
business needs, and monthly recurring=0A> revenue often trumps engineering=
 decisions.=0A=0AWhat technical solution did you chose for that rewriting?=
=0A(I don't want to comment on the rest;)=0A=A0=0A=0AWe use FreeBSD and PF=
 =A0All addresses and mappings are statically assigned.=0A=0AMike=

--Boundary_(ID_0MeleAGKAC0cgX82XxkvtQ)
Content-type: multipart/related;
 boundary="Boundary_(ID_FywvSjUdRa2IRPzcd2jTag)"; type="text/html"


--Boundary_(ID_FywvSjUdRa2IRPzcd2jTag)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable



On May 09, 2011, at 01:57 PM, Roger J=F8rgensen <ro=
gerj@gmail.com> wrote:

On Mon, May 9, 2011 at 10:51 =
PM, Michael Smith <mksmith@me.com> wrote:
=0A<snip>
=0A<=
br>=0A
=0A> We've had to carve out a portion of our /32 for "NAT", i=
n as much as I
=0A> terminate one set of addresses on the outside of=
 my edge device and
=0A> translate them into another set of my addre=
sses.  It satisfies the auditors
=0A> because the incoming sess=
ion is inspected and rewritten.  It's also insane,
=0A> but the=
re are engineering needs and business needs, and monthly recurring
=0A&=
gt; revenue often trumps engineering decisions.
=0A
=0AWhat technica=
l solution did you chose for that rewriting?
=0A(I don't want to commen=
t on the rest;)
 
=

We use FreeBSD and PF.  All address=
es and mappings are statically assigned.

Mike
=

--Boundary_(ID_FywvSjUdRa2IRPzcd2jTag)--

--Boundary_(ID_0MeleAGKAC0cgX82XxkvtQ)--

From ipng@69706e6720323030352d30312d31340a.nosense.org  Mon May  9 14: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 50371E0863 for ; Mon,  9 May 2011 14:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.775
X-Spam-Level: 
X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.120,  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 ScccbeHOflvJ for ; Mon,  9 May 2011 14:26:29 -0700 (PDT)
Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id AE53FE072E for ; Mon,  9 May 2011 14:26:29 -0700 (PDT)
Received: from 219-90-162-60.ip.adam.com.au ([219.90.162.60] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QJXyE-0002va-Ui; Tue, 10 May 2011 06:56:27 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 41DFD3B338; Tue, 10 May 2011 06:56:26 +0930 (CST)
Date: Tue, 10 May 2011 06:56:26 +0930
From: Mark Smith 
To: Michael Smith 
Message-ID: <20110510065626.5cad38ba@opy.nosense.org>
In-Reply-To: <0ab753e2-a6ab-cae8-8ecb-e97af27c9976@me.com>
References:  <0ab753e2-a6ab-cae8-8ecb-e97af27c9976@me.com>
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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 WG" 
Subject: Re: [v6ops] IPv6 Enterprise issues (was: Apologies)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 21:26:30 -0000

On Mon, 09 May 2011 20:54:33 +0000 (GMT)
Michael Smith  wrote:

> On May 09, 2011, at 01:07 PM, Erik Kline  wrote:
>=20
> """
> The biggest problem right now are howto not do NAT when doing IPv6.
> It is not an option to not run NAT in some form or another.
> """
>=20
> Can you elaborate?
>=20
> We have not found it necessary at all for the 10-20k+ corporate IPv6
> users, but I'm fully prepared to believe that we see things
> differently.
> =C2=A0
> There are compliance models that require NAT (PCI amongst them) and a set=
 corporate mindset that a "stateful firewall with NAT" is one key component=
 to defense-in-depth. =C2=A0Many security policies are written with a MUST =
for NAT, not a SHOULD.
>=20
> We've had to carve out a portion of our /32 for "NAT", in as much as I te=
rminate one set of addresses on the outside of my edge device and translate=
 them into another set of my addresses. =C2=A0It satisfies the auditors bec=
ause the incoming session is inspected and rewritten. =C2=A0It's also insan=
e, but there are engineering needs and business needs, and monthly recurrin=
g revenue often trumps engineering decisions.
>=20

I expect DPI boxes are going to become more common for this task.
ISATAP could be used to hide the internal IPv6 topology. If hiding the
actual internal addresses is deemed necessary then specific application
proxies might be preferable because they'd also provide an application
use audit log, which is likely to also be required in that sort
of security context.

Regards,
Mark.

From rogerj@gmail.com  Mon May  9 15:02: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 13061E06BE for ; Mon,  9 May 2011 15:02:24 -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=[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 0VqsYCnmokoK for ; Mon,  9 May 2011 15:02:23 -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 01B69E085D for ; Mon,  9 May 2011 15:02:22 -0700 (PDT)
Received: by wyb29 with SMTP id 29so4938053wyb.31 for ; Mon, 09 May 2011 15:02:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6ps+i7FS/1ih8wU8RHYdrPO5XZAGwlI+d9gDsZm67hw=; b=I2gqkcnG3uAIenZHcbhQ1ZUQuBYeSPkbNFv8ZRUMcKUAG4/lwVZIOcyesKQ/p8j7F1 73rZZqa64Kv1+188Fk7d/eef4lEUAMqupSwtOxeI81cHU0+KwoH1+jnj+/nYAyQwmnxk RN26CScLdWOXUaPEZrqslT4Vtss4FvFoLA0c8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MhxPgoVAA77dZ30m8d424dsnr3/xsZV/sm5CW2gaG04FKr7G6abZSiia0LazXgDvbQ rDfI5oob8TwlhWAzO8JHTDXvV31Ap9e+ZCnDqdnS21+LZvDTLkp38Y5oR+7ULhIrt+65 cFaqX50pd3raLYWX7ET8k+KCGEbre33s1d5Jw=
MIME-Version: 1.0
Received: by 10.227.208.207 with SMTP id gd15mr4790934wbb.93.1304976812372; Mon, 09 May 2011 14:33:32 -0700 (PDT)
Received: by 10.227.146.208 with HTTP; Mon, 9 May 2011 14:33:32 -0700 (PDT)
In-Reply-To: <9ce3820a-b80a-64fb-a974-c3b39877ff06@me.com>
References:  <9ce3820a-b80a-64fb-a974-c3b39877ff06@me.com>
Date: Mon, 9 May 2011 23:33:32 +0200
Message-ID: 
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: Michael Smith 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] IPv6 Enterprise issues (was: Apologies)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 22:02:24 -0000

On Mon, May 9, 2011 at 11:01 PM, Michael Smith  wrote:
> On May 09, 2011, at 01:57 PM, Roger J=F8rgensen  wrote:
> On Mon, May 9, 2011 at 10:51 PM, Michael Smith  wrote:
> 
>> We've had to carve out a portion of our /32 for "NAT", in as much as I
>> terminate one set of addresses on the outside of my edge device and
>> translate them into another set of my addresses. =A0It satisfies the
>> auditors
>> because the incoming session is inspected and rewritten. =A0It's also
>> insane,
>> but there are engineering needs and business needs, and monthly recurrin=
g
>> revenue often trumps engineering decisions.
>
> What technical solution did you chose for that rewriting?
> (I don't want to comment on the rest;)
>
>
> We use FreeBSD and PF. =A0All addresses and mappings are statically assig=
ned.

Yeah thought so. My first attempt was going to be Linux but neither that or
FreeBSD is probably usable in the production environment for not only techn=
ical
reasons.
If I'm lucky my ASA box might help me, haven't yet got around to check
if it do...
only got it ~12hours ago:)



--=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 brian.e.carpenter@gmail.com  Mon May  9 15:08: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 E0FD8E093A for ; Mon,  9 May 2011 15:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.505
X-Spam-Level: 
X-Spam-Status: No, score=-103.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 3zzngryt1U5A for ; Mon,  9 May 2011 15:08:02 -0700 (PDT)
Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB6EE0848 for ; Mon,  9 May 2011 15:08:01 -0700 (PDT)
Received: by pxi2 with SMTP id 2so3492236pxi.38 for ; Mon, 09 May 2011 15:08:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kdAkweULY15aIG+aslarN0imSuZ28UHUHtmn6AqXjyI=; b=nTKOO6p5rrj+rswLWc4e3bqu1EGjUdO577sBstNkzdr4Chpw7MVohfglj4uLLL9iOp KpYIJQUnJWIslzx6jyBM12ln71srXGoh70xK6FhB64wCsgv+6miW/LSMu1qv7u2eMlkd dzlogdR/rnZ3WbesqnX+NjNKjHbAFAiZ/CbTY=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Hg9jW5Bm91uEKuZSFl8FbkSiL8AOK5FoiuECU6rEmtH9XbuwvK8nuwgfCv8cF+C6iN dJwWrPV9LLw/S/mrUY/jDQV8b726YSoyXkBADhUg3ckDBedfYi0e3aWszK9nN5UiByI2 H+hQB84eRwQGlMG83wIxnyLKZPEiF7gEcjwhM=
Received: by 10.68.69.14 with SMTP id a14mr7214343pbu.292.1304978881631; Mon, 09 May 2011 15:08:01 -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 q2sm4364159pbs.5.2011.05.09.15.07.59 (version=SSLv3 cipher=OTHER); Mon, 09 May 2011 15:08:00 -0700 (PDT)
Message-ID: <4DC865BD.3070605@gmail.com>
Date: Tue, 10 May 2011 10:07:57 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Philip Homburg 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-andrews-v6ops-6to4-router-option-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, 09 May 2011 22:08:03 -0000

On 2011-05-10 02:34, Philip Homburg wrote:
> And using a different IPv4 address for the
> relay is most likely just going to break things.

Not so. The issue with not using the anycast address for return packets
to the 6to4 user is that a stateful firewall will drop them, because
the outbound packet was sent to the anycast address. As long as the
outbound and return packets use the *same* IPv4 address for the relay,
a stateful firewall will not interfere.

   Brian

From marka@isc.org  Mon May  9 16:26: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 62730E06E1 for ; Mon,  9 May 2011 16:26:10 -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 e10QAF9XVCVm for ; Mon,  9 May 2011 16:26:09 -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 B5164E069E for ; Mon,  9 May 2011 16:26:09 -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 334AA5F98F2; Mon,  9 May 2011 23:25:55 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 0C727216C1E; Mon,  9 May 2011 23:25:53 +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 5E1AFE9A7CC; Tue, 10 May 2011 09:26:13 +1000 (EST)
To: Ray Hunter 
From: Mark Andrews 
References: <4DC829CC.80302@globis.net>
In-reply-to: Your message of "Mon, 09 May 2011 19:52:12 +0200." <4DC829CC.80302@globis.net>
Date: Tue, 10 May 2011 09:26:13 +1000
Message-Id: <20110509232613.5E1AFE9A7CC@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Apologies
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 09 May 2011 23:26:10 -0000

In message <4DC829CC.80302@globis.net>, Ray Hunter writes:
> It has been brought to my attention (in a very polite way) that some 
> recent posts to this list have not been received as being constructive, 
> and that rather they are somehow perceived as part of a general attempt 
> at spreading FUD and a DOS attack. That was certainly not the intention. 
> It was suggested that if I had any honor then I would post a message 
> apologizing to the list.
> 
> I understood that the v6ops list existed to solicit input from network 
> operators and users to identify operational issues with the IPv4/IPv6 
> Internet. Operational issues by their very nature may seem trivial or 
> low level, but they may also make or break the roll out of IPv6. Not all 
> users will have the same requirements or deployment methodology.
> 
> I can assure you that my only intention is to try to improve the end 
> user experience and ease of roll out of IPv6, especially for large 
> complex commercial environments who currently run production IPv4 
> networks that are business critical. The issues I have raised seem to be 
> of genuine operational concern to some large corporations who are 
> planning on rolling out IPv6. In fact, some private answers from 
> individuals have thanked me for my contribution and asked me to post 
> further to the list to solicit opinions from a wider audience. Please 
> also note that I have personally already observed several adverse 
> effects arising from the unintentional deployment of IPv6 transition 
> mechanisms in production IPv4 networks. These corporations seem unlikely 
> or unwilling to post their operational problems to this list themselves, 
> possibly for fear of reputational damage.
> 
> So please excuse me for not knowing the accepted "way of working" of the 
> list. If you have any pointers on how contributions about operational 
> issues from end users can be brought in a more positive and useful way 
> to the WG, thus leading to the general good functioning of the WG in 
> improving the overall end-user experience of IPv6, please do not be 
> afraid to contact me in complete confidence.
> 
> In the meantime, I shall refrain from responding further to the list 
> until I receive a clear "OK" to do so.

Ray, 
      I found benefit in your comments being one to which recent
comments were directed.  I'd rather see comments than not so please
don't stop commenting on my account.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From farmer@umn.edu  Mon May  9 16:55: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 7D93FE0820 for ; Mon,  9 May 2011 16:55:37 -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 qm3s7xiIhPz6 for ; Mon,  9 May 2011 16:55:36 -0700 (PDT)
Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE35E06E2 for ; Mon,  9 May 2011 16:55:36 -0700 (PDT)
Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 9 May 2011 18:40:22 -0500 (CDT)
X-Umn-Remote-Mta: [N] mail-iy0-f171.google.com [209.85.210.171] #+LO+TR
X-Umn-Classification: local
Received: by mail-iy0-f171.google.com with SMTP id 20so7368397iyi.16 for ; Mon, 09 May 2011 16:40:22 -0700 (PDT)
Received: by 10.42.136.198 with SMTP id v6mr2848947ict.346.1304984421639; Mon, 09 May 2011 16:40:21 -0700 (PDT)
Received: from x-128-101-235-69.uofm-secure.wireless.umn.edu (x-128-101-235-69.uofm-secure.wireless.umn.edu [128.101.235.69]) by mx.google.com with ESMTPS id 4sm2824078ibc.66.2011.05.09.16.40.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 16:40:20 -0700 (PDT)
Message-ID: <4DC87B62.3000402@umn.edu>
Date: Mon, 09 May 2011 18:40:18 -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.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Erik Kline 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] IPv6 Enterprise issues (was: Apologies)
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, 09 May 2011 23:55:37 -0000

On 5/9/11 15:07 CDT, Erik Kline wrote:
> """
> The biggest problem right now are howto not do NAT when doing IPv6.
> It is not an option to not run NAT in some form or another.
> """
>
> Can you elaborate?
>
> We have not found it necessary at all for the 10-20k+ corporate IPv6
> users, but I'm fully prepared to believe that we see things
> differently.

While it is not necessary to do NAT with IPv6, there are enough 
addresses, and there are many good reason not to do NAT at all in IPv6. 
  The problem is we are requiring many enterprises to make a significant 
change in their network architecture and/or philosophy to migrate to 
IPv6, beyond the size of address they use.  With IPv4 many of them are 
using NAT, with IPv6 we are currently telling them they shouldn't be, 
this NAT to no-NAT transition will be a much bigger change for many of 
them, than the IPv4 to IPv6 transition.

This will be a hurdle preventing many enterprises from transitioning to 
IPv6 on a timely basis.  Furthermore, I believe it is unfortunate that 
we are asking people to more or less do a cold turkey transition from 
NAT in order to do IPv6.  Yes, their networks will probably be better 
for it eventually.  But, do they really see and believe what we are 
telling them?  There are many reasons that enterprises do NAT, some are 
more perception than reality, but the transition to IPv6 doesn't 
necessarily change those perceptions or even all the realities behind 
why they are doing NAT.

An example, as a non-smoker it is difficult for me to understand what it 
takes for a 2 pack a day smoker to quite their habit.  Isn't it equally 
difficult for an operator of a non-NATed network to really understand 
how big of a change it really is to go no-NAT?

Asking everyone to do a cold turkey transition from NAT, isn't 
necessarily going to facilitate a transition to IPv6, just like going 
cold turkey doesn't always work as a way for people to quite smoking. 
To help smokers quit, there is everything from nicotine substitutes, to 
twelve-step programs, peer or professional counseling, non-nicotine drug 
treatments, etc...  I believe we need to take a more sophisticated view 
of how NATed IPv4 enterprises are going to transition to IPv6, rather 
than just telling them to do a cold turkey transition from NAT.

Therefore, we need to be looking at what kinds of strategies, other than 
a cold turkey  transition from NAT, that a NATed IPv4 Enterprise network 
can use for its transition to IPv6.  Such as, Dual-Stack Web and other 
application proxies at the current NAT boundary, Dual-Stack public 
facing servers in the DMZ network, and maybe even NAT66.  (I open to 
other ideas too, I'd love to hear them.)

Windows7, which is starting to be used in a lot of enterprises, has a 
lot of IPv6 features and is creating demand for IPv6 internal to many 
enterprises.  But many enterprises are not ready for the philosophical 
leap to go to global public addresses inside their network. Are we going 
to tell them not to do IPv6?  Do NAT66?  Something else?

So, I think it boils down to a question; Which is more important to the 
v6ops community, killing NAT or transitioning to IPv6?  And, what if we 
can't do both at the same time?

Personally, I believe transitioning to IPv6, is the more important of 
the two issues.  I believe NAT will die a natural death, if we 
successfully transition the Internet to IPv6 and solve the renumbering 
problem for enterprises to change providers cleanly without renumbering 
their entire network infrastructure.

By not providing NAT66 we have eliminate the primary mechanism that many 
enterprises understand and use to avoid renumbering their network. 
Right or wrong, NAT is fundamental to the network architecture that a 
large number of enterprises use to operate their networks.  If we are 
not going to provide NAT66, then we better figure out a number of viable 
alternative for those that are not going to be able to do a cold turkey 
transition from NAT as part of their transition to IPv6.  Otherwise, I 
afraid that our current strategy of requiring a cold turkey transition 
from NAT, will at best delay, and at worst prevent, a transition to IPv6 
for much of the Internet, either would be unfortunate.

-- 
===============================================
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 marka@isc.org  Mon May  9 18: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 7BCBAE0739 for ; Mon,  9 May 2011 18:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.738
X-Spam-Level: 
X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.862,  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 pVax+VSH3gwy for ; Mon,  9 May 2011 18:11: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 7B552E070E for ; Mon,  9 May 2011 18:11: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 6D7585F9863; Tue, 10 May 2011 01:10:55 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 2AE28216C1E; Tue, 10 May 2011 01:10:53 +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 03308E9BB43; Tue, 10 May 2011 11:11:15 +1000 (EST)
To: Erik Kline 
From: Mark Andrews 
References:  <20110509154020.DE031E99038@drugs.dv.isc.org>  
In-reply-to: Your message of "Mon, 09 May 2011 19:16:38 GMT." 
Date: Tue, 10 May 2011 11:11:14 +1000
Message-Id: <20110510011115.03308E9BB43@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-andrews-v6ops-6to4-router-option-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, 10 May 2011 01:11:12 -0000

In message , Erik Kline wri
tes:
> Even with this attempt to help make the "first hop" more reliable, it
> will not and cannot address the return path failures.

The option performs two roles.

1.  It identifies a local 6to4 relay.  Nothing prevents the operator
    putting 192.88.99.1 in the response however it you put 192.88.99.1
    in the response it is a indication that you are running the
    router and will accept fault reports.  ISPs have also indicated
    that they are not happy to deploy a router at 192.88.99.1 but
    would be willing to deploy a router at a different address.
    This provides a configuration mechanism for them to do so.

    It also provide a mechanism to distribute decapsulation load
    that is not dependent on the routing infrastructure.

2.  It provides a signal to 6to4 CPE/hosts that 6to4 will not work
    properly when you are connected to this network and that you
    should not use 6to4 when connected to this network.

> This is fundamental to the 2002::/16 aspect of 3068.

Actually it is a fundemental part of RFC 3056.  See 5.2.2 Summary
of relay router configuration.

> Geoff's numbers for failures when the server sees SYNs from 2002::/16
> client addresses are remarkable, and don't satisfactorily diminish
> even when the return route to 2002::/16 is on the server sending the
> SYN-ACK (i.e. it encapsulates it directly).

Which indicates that 6to4 is being attempted in environments where
it shouldn't be.  Being able to tell the CPE/host not to use 6to4
in those environments prevents the host attempting a IPv6 connection
using a 6to4 IPv6 address in the first place.  The day of week data
is enough to show that failures are due to environment and not load.

> The *return path* problem is what 6rd fixes.  Optimizing the client
> proximity to its relay is insufficient to make the mechanism useful at
> scale for IPv6 transition.

Actually I've yet to see evidence that it cannot scale.  I've seen
plenty of evidence that 6to4 is being used in environments where
it will not work for reasons that have nothing to do with scaling.

Getting 6to4 to scale is simply a matter of deploying enough 6to4
relay routers.  The fact that there is little change when the server
does encapsulation of the reply traffic indicates that there isn't
currently a scaling issue.  If there was as scaling issue then
performing local encapsulation would address it.

> Let's let -advisory and -historic do their thing.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From rogerj@gmail.com  Mon May  9 22:40: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 DB042E06BD for ; Mon,  9 May 2011 22:40:07 -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.000, 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 tH1VXAGzd3nw for ; Mon,  9 May 2011 22:40:06 -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 81109E067B for ; Mon,  9 May 2011 22:39:46 -0700 (PDT)
Received: by wwa36 with SMTP id 36so4451048wwa.13 for ; Mon, 09 May 2011 22:39:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WgDPPry7jEf85trGdpzWZRKZd2WHms9zNdJZ6szAODo=; b=G5l39wByshUN9BWokJRAq4uo8xGZKRWoT86v3V+b1jRAxNi9Nb7TkVrmwoqpPCdWQD u9ryNc3b+dIzKK16qaQdsTC4LR4qQCIDEAmINaK2UDPRYVbeH9Dlcv8BkJgBW1Vk42ma Xp4nMCs963AkjUi8Co+V9SE7Rim+fQndoAyUE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DwzNK/nuEPkgbc3fTp1VjtG2vwNxMHqE6kWJThgWkFdDV72xEA97auEa3y322T9kZP XNQuC7D4Pj18c8FEjo8cNQHoQnBj+uk8hyUpb1GPJeYQwZck6rYMK0AYjQSAeoNImw3T wMju848XK7gz4xit9gAd6rDXZhoHDHLC7MhYY=
MIME-Version: 1.0
Received: by 10.227.55.68 with SMTP id t4mr7698161wbg.78.1305005971670; Mon, 09 May 2011 22:39:31 -0700 (PDT)
Received: by 10.227.146.208 with HTTP; Mon, 9 May 2011 22:39:31 -0700 (PDT)
In-Reply-To: <4DC87B62.3000402@umn.edu>
References:  <4DC87B62.3000402@umn.edu>
Date: Tue, 10 May 2011 07:39:31 +0200
Message-ID: 
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: David Farmer , Fred Baker 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] IPv6 Enterprise issues (was: Apologies)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 10 May 2011 05:40:08 -0000

First of all, I do not believe NAT is the right thing todo, but that
don't change
the reality I and other do work under/with.


On Tue, May 10, 2011 at 1:40 AM, David Farmer  wrote:
> On 5/9/11 15:07 CDT, Erik Kline wrote:
>>
>> """
>> The biggest problem right now are howto not do NAT when doing IPv6.
>> It is not an option to not run NAT in some form or another.
>> """
>>
>> Can you elaborate?
>>
>> We have not found it necessary at all for the 10-20k+ corporate IPv6
>> users, but I'm fully prepared to believe that we see things
>> differently.
>


> An example, as a non-smoker it is difficult for me to understand what it
> takes for a 2 pack a day smoker to quite their habit. =A0Isn't it equally
> difficult for an operator of a non-NATed network to really understand how
> big of a change it really is to go no-NAT?

That an excellent way of looking at the NAT issue from "enterprise" side.

I am so very against NAT for many reasons, but that doesn't change the
reality I'm working under. And it is not so much a technical issue as a
educational issue, combined with a quite deep belief in NAT being good
for security.



> Therefore, we need to be looking at what kinds of strategies, other than =
a
> cold turkey =A0transition from NAT, that a NATed IPv4 Enterprise network =
can
> use for its transition to IPv6. =A0Such as, Dual-Stack Web and other
> application proxies at the current NAT boundary, Dual-Stack public facing
> servers in the DMZ network, and maybe even NAT66. =A0(I open to other ide=
as
> too, I'd love to hear them.)

I do not like NAT66 or any other NAT related technology at all... but as I =
said,
might not have any chance to not do some sort of _address translation_.


Something as "simple" as changing the entire prefix for any given /64,
from 2001:db8:1234:5678::/64 to 2001:db8:8765:4321::/64 might even be
enough to solve the "we need NAT" issue for some enterprises.
Combine that rewrite with some sort of anti virus/trojaner/something scanne=
r
device and I know some people would be happy:-)



--=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 newbery@gmail.com  Mon May  9 23:08: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 29978E0806 for ; Mon,  9 May 2011 23:08:06 -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.500,  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 1FkmJnadCMwe for ; Mon,  9 May 2011 23:08:05 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 711D6E07F2 for ; Mon,  9 May 2011 23:08:05 -0700 (PDT)
Received: by pwi5 with SMTP id 5so3624891pwi.31 for ; Mon, 09 May 2011 23:08:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:mime-version:content-type:subject:date :in-reply-to:to:references:message-id:x-mailer; bh=v0LcJxKcGJLIMggx9t8VbBrPpwLZ4g30jdrQiEOifZA=; b=qFEvA2T5+0FAEyNmrAj7PoaUxaAEzijVXOu6yTcUv2z4grYd/jyfdVNuRYTJIpgrl5 VfzKeNT+rhWShlfMThBhN9HBy71DIx3qiGmBdPtBXba7dR7eQnDD1Lz/vMBxvvsyG0Gw khX1Yk21iH6iQVHkequtZUe4pNC91iYjZ3TA0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=XGbQozxTlYKK2Vhcd5M8bdZYUSBjigFY5T/SER8T9FVcH2nqd8FJ6aJ8xWQVnnzfVc Ch3fKzjcqGQP8F/Cjfaqb1ofp0QFFah5RzWkmFHJ8vgej816aLcVifAxfebd5ummpTND fw4qbkC0Stm5/Gg9T+6DL6A/lkrasbQi1IWk8=
Received: by 10.142.162.9 with SMTP id k9mr572307wfe.174.1305007684904; Mon, 09 May 2011 23:08:04 -0700 (PDT)
Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id z10sm9077136wfj.3.2011.05.09.23.08.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 23:08:03 -0700 (PDT)
From: Michael Newbery 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-1-282964366; protocol="application/pkcs7-signature"; micalg=sha1
Date: Tue, 10 May 2011 18:07:54 +1200
In-Reply-To: 
To: "v6ops@ietf.org WG" 
References:  <4DC87B62.3000402@umn.edu> 
Message-Id: <0C636C07-CC07-4EED-99AB-2A5344E7D81A@gmail.com>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] IPv6 Enterprise issues (was: Apologies)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 10 May 2011 06:08:06 -0000

--Apple-Mail-1-282964366
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


On 10/05/2011, at 5:39 PM, Roger J=F8rgensen wrote:

> First of all, I do not believe NAT is the right thing todo, but that
> don't change
> the reality I and other do work under/with.
>=20

[snip]

> I am so very against NAT for many reasons, but that doesn't change the
> reality I'm working under. And it is not so much a technical issue as =
a
> educational issue, combined with a quite deep belief in NAT being good
> for security.

Then should not the correct response be to educate them?
"We need NAT"
No, you don't.

Because:
1. No NAT in IPv6
2. All the things that NAT does in IPv4 are done otherwise, and better, =
without NAT, in IPv6.

(Yes, I know there are some corner cases. Being a good geek and seeing =
both sides of the argument is counterproductive here. If you are arguing =
with someone who treats "NAT is Good" as an article of faith, then =
"There is no NAT in IPv6" is as far as you need to go in response. =
Anything else is just going to lead into dark paths of confusion).

The solution to faulty beliefs is education.

Should not the correct response of this WG to your request be =
information to counter the mistaken beliefs?=

--Apple-Mail-1-282964366
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw
ggMYoAMCAQICAwm5xTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTAxMjAyMTA2MjdaFw0x
MTA3MTkyMTA2MjdaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR
bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y
bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b
cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD
V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87
1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI
6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G
CSqGSIb3DQEBBQUAA4ICAQBlGZdPhl6SR3KKK1xXL41nqIAK9To0lIZXaqxtanIa083BHH07icuV
YydeekqgxqO6z0A/3HOEJOESV5eUB9bly7zHRh7CIOB++6WzaVrFTa4yoUmhXeHF3HJmaUaxJBSl
R4po3vPoii81nFIg4NSRLtRQw0ClVEvaJMkipgAWGu+b42tMNQolxBF6sCh6VOzoz9Q5t+4bwu+v
d94tSGoSfuyV0sBVVaIz08VZUPYKYEM6nYEMiJzDhgH09b4CtQJ46o+YyyDb59xcuEyEd00B1tWS
WUfqrYehN/W60FjopddWrG9+HaZu5+2Fz3L+da8Ggjj0g1r00cRcUURUpll+yH06D+YbhbH03kP9
P7juyvO9VfDMqYNh301h1g8PM/dDaHCUthpzedwwYeNsyTFGqzcFfsuxXvK/4BkHGPcFkyxQlqTc
cWGbdxXrz42zY/ndRvzEWZ5AnlIIOsWzIySEAzhmGdlc462/kCbO8SisJYfriMcGHrJKwA2X3o8E
DJ5tWayiInI/mv4BpKgIKKF5lNWgMVbYcTPtUCoCOl4mefFX+yCan/bxjRL6ae8HOMyUS6fg1v61
ypEh8WoXcoYbiGPmWP5uSpDK8Y2UGJ70T59RUgjyryFTIriZKJDZUtAD6gr0QPuQn+Fidb00OKYp
XrWcXFmOdxph1ZFNMgg5ETGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV
BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv
cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJucUwCQYFKw4DAhoFAKCC
AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNTEwMDYwNzU5
WjAjBgkqhkiG9w0BCQQxFgQUyXBTcdxqQNmTBwna7J1nppPCPrgwgZEGCSsGAQQBgjcQBDGBgzCB
gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg
BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA
Y2FjZXJ0Lm9yZwIDCbnFMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB
MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCbnFMA0GCSqG
SIb3DQEBAQUABIIBAIU/j67J6QP5RlpR3VIVy28CtPNZBY3lI+LDhdgJp7vz3ZrsW6WaFnhCEEPR
qTeRhYcT1S6X5ipVStPe5D3h2RR1wHLNw2jhKs5w5tG/VRz28ayzlaV1QoOsRxW3EMHx+rwuENWv
xDgsDiKDLsoWTcF3mqLcZRO7s7W2uJ7iug7cT9DZHpbkB7lgyZ6Qy66+xKxOd8ASkhL8uJK+vIGa
JiZ7ood3chxTRaRZQl0moGhxnQnXPVuBImFvQve1PL+a6MoxbryHW/TOCpcy92oFiqNf8YyGT2j6
+pLCYMM7scT+JWvP2KD09zbAQzw7APuBADt9fJNTwMxf1YeiAYHrjuIAAAAAAAA=

--Apple-Mail-1-282964366--

From tore.anderson@redpill-linpro.com  Mon May  9 23: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 49957E07DD for ; Mon,  9 May 2011 23:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.288
X-Spam-Level: 
X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_37=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 ClVQ7LH8jsQ0 for ; Mon,  9 May 2011 23:11:38 -0700 (PDT)
Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4667CE077B for ; Mon,  9 May 2011 23:11:37 -0700 (PDT)
Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 44493C41B8; Tue, 10 May 2011 08:11:36 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at linpro.no
Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id EwhWVzYJeNQS; Tue, 10 May 2011 08:11:36 +0200 (CEST)
Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Tue, 10 May 2011 08:11:35 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id D383B170C00B; Tue, 10 May 2011 08:11:35 +0200 (CEST)
X-Virus-Scanned: amavisd-new at claudius.linpro.no
Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWlWaRy8sMaE; Tue, 10 May 2011 08:11:35 +0200 (CEST)
Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 6C558170C00A; Tue, 10 May 2011 08:11:35 +0200 (CEST)
Message-ID: <4DC8D717.3080402@redpill-linpro.com>
Date: Tue, 10 May 2011 08:11:35 +0200
From: Tore Anderson 
Organization: Redpill Linpro AS
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Lorenzo Colitti 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 10 May 2011 06:11:39 -0000

* Lorenzo Colitti

> I don't see any reason to do this.

+1, opposed. Let's stop flogging the dead horse.

> First: if you're an operator (and you probably are, since you have the power
> to control the DHCP server), you can already ensure 6to4 nodes to use your
> relay by making sure that 192.88.99.1 is routed to it. You don't have to
> change the OS stacks at all. Thus no RFC, no IANA DHCP option assignment, no
> implementation changes on the server or on the client, ...
> 
> Second: this only makes the forward path more reliable. Reverse path is
> still unreliable because it is not under your control (the server will just
> pick whatever anycast 6to4 relay is closest to it). The only way to fix that
> is by using 6rd or something like 6to4-PMT, which the WG did not adopt as an
> item.
> 
> Third: as Erik says, you're really just reinventing a part of 6rd. More
> specifically: RFC 3068-style anycast 6to4 is a special case of 6rd
> where IPv4MaskLen = 0, 6rdPrefix = 2002::, 6rdPrefixLen = 16,
> and 6rdBRIPv4Address = 192.88.99.1. From a protocol perspective, what you
> are doing is adding the 6rdBRIPv4Address parameter, but not the other three
> parameters, to 6to4. I think that instead of asking implementors to do this,
> we should just ask them to implement 6rd instead.

Fourth: You'll cement an increased failure rate because the IPv4
destination address in the outbound proto-41 packets won't match the
IPv4 source address in the inbound replies. That confuses stateful
devices in the path.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27

From rogerj@gmail.com  Mon May  9 23:15: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 54411E07E4 for ; Mon,  9 May 2011 23:15:25 -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=[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 WF3eNgOW-DiG for ; Mon,  9 May 2011 23:15:24 -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 6D155E0769 for ; Mon,  9 May 2011 23:15:24 -0700 (PDT)
Received: by wyb29 with SMTP id 29so5137209wyb.31 for ; Mon, 09 May 2011 23:15:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fa1SsGNhomY0phCdSx47J2Q5acKXCehYYR+PYv0QCEU=; b=xOSQ4+DzH+NubCJe0x+FcccnrszU1ez6qHqJIGWqxpOKcefv4yFHXSn9p/1jQIh82Q qMfzpPN41ZEjditMgpgTZmA84w8P4Juz6avyVzH/CB1cbLn8U5WToXkfQa8I8Nxzeuuq 5j+jv10v/5V4UozSUMLUyUTIjyzwQMtqkmHfg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZS1EXv3wOxoQfDs514J7z4Zy9WjmS2JMt28weeQu4B7GzsNMIZUQeXxfsjK37Xlt+N UeJKlxCH0pr4pf7hnIVgS3BvztA2APWpmDaYxPV/qt2NViXKJxAhOagBkkrrLunrvyVc WpMQZ32LTjLoDROUme1iSzVPi/TD5o9KSptwU=
MIME-Version: 1.0
Received: by 10.227.60.194 with SMTP id q2mr2024158wbh.63.1305008123347; Mon, 09 May 2011 23:15:23 -0700 (PDT)
Received: by 10.227.146.208 with HTTP; Mon, 9 May 2011 23:15:23 -0700 (PDT)
In-Reply-To: <0C636C07-CC07-4EED-99AB-2A5344E7D81A@gmail.com>
References:  <4DC87B62.3000402@umn.edu>  <0C636C07-CC07-4EED-99AB-2A5344E7D81A@gmail.com>
Date: Tue, 10 May 2011 08:15:23 +0200
Message-ID: 
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: Michael Newbery 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] IPv6 Enterprise issues (was: Apologies)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 10 May 2011 06:15:25 -0000

On Tue, May 10, 2011 at 8:07 AM, Michael Newbery  wrote:

> The solution to faulty beliefs is education.

yes it is, but it might take time, what do we do in between?



--=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 mohacsi@niif.hu  Tue May 10 00: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 0C170E06A1 for ; Tue, 10 May 2011 00:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.063
X-Spam-Level: 
X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=-0.533,  BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_37=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 sLhMQ3ZyKxrc for ; Tue, 10 May 2011 00:25:25 -0700 (PDT)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [193.6.222.241]) by ietfa.amsl.com (Postfix) with ESMTP id E04BBE069B for ; Tue, 10 May 2011 00:25:24 -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 6733D87447; Tue, 10 May 2011 09:25:20 +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 5HlGSF10JBEL; Tue, 10 May 2011 09:24:58 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 094E786D42; Tue, 10 May 2011 09:24:58 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id EAEC786D2B; Tue, 10 May 2011 09:24:57 +0200 (CEST)
Date: Tue, 10 May 2011 09:24:57 +0200 (CEST)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Lorenzo Colitti 
In-Reply-To: 
Message-ID: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org> 
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-401323963-1305012297=:63146"
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 10 May 2011 07:25:26 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-401323963-1305012297=:63146
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT




On Mon, 9 May 2011, Lorenzo Colitti wrote:

> On Mon, May 9, 2011 at 1:08 AM, Mark Andrews  wrote:
>
>              I just posted draft-andrews-v6ops-6to4-router-option-00.txt.
>              Feedback welcome.
> 
> 
> 
> I don't see any reason to do this.
> 
> First: if you're an operator (and you probably are, since you have the power to control the DHCP server), you can already ensure 6to4 nodes
> to use your relay by making sure that 192.88.99.1 is routed to it. You don't have to change the OS stacks at all. Thus no RFC, no IANA DHCP
> option assignment, no implementation changes on the server or on the client, ...
> 
> Second: this only makes the forward path more reliable. Reverse path is still unreliable because it is not under your control (the server
> will just pick whatever anycast 6to4 relay is closest to it). The only way to fix that is by using 6rd or something like 6to4-PMT, which the
> WG did not adopt as an item.
> 
> Third: as Erik says, you're really just reinventing a part of 6rd. More specifically: RFC 3068-style anycast 6to4 is a special case of 6rd
> where IPv4MaskLen = 0, 6rdPrefix = 2002::, 6rdPrefixLen = 16, and 6rdBRIPv4Address = 192.88.99.1. From a protocol perspective, what you are
> doing is adding the 6rdBRIPv4Address parameter, but not the other three parameters, to 6to4. I think that instead of asking implementors to
> do this, we should just ask them to implement 6rd instead.

I completly agree with Lorenzo. Operators don't need 6to4 router option: 
if they need it they can emulate better with 6rd.

Best Regards,
 		Janos Mohacsi

--0-401323963-1305012297=:63146--

From gert@space.net  Tue May 10 00:39: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 D70A9E0813 for ; Tue, 10 May 2011 00:39:30 -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 aoFiONfVq9vK for ; Tue, 10 May 2011 00:39:30 -0700 (PDT)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id CB192E07B4 for ; Tue, 10 May 2011 00:39:28 -0700 (PDT)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id B5C58F816A for ; Tue, 10 May 2011 09:39:25 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 9C6D0F8182 for ; Tue, 10 May 2011 09:39:25 +0200 (CEST)
Received: (qmail 86833 invoked by uid 1007); 10 May 2011 09:39:25 +0200
Date: Tue, 10 May 2011 09:39:25 +0200
From: Gert Doering 
To: Brian E Carpenter 
Message-ID: <20110510073925.GY30227@Space.Net>
References:  <4DC865BD.3070605@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4DC865BD.3070605@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-andrews-v6ops-6to4-router-option-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, 10 May 2011 07:39:30 -0000

Hi,

On Tue, May 10, 2011 at 10:07:57AM +1200, Brian E Carpenter wrote:
> On 2011-05-10 02:34, Philip Homburg wrote:
> > And using a different IPv4 address for the
> > relay is most likely just going to break things.
> 
> Not so. The issue with not using the anycast address for return packets
> to the 6to4 user is that a stateful firewall will drop them, because
> the outbound packet was sent to the anycast address. As long as the
> outbound and return packets use the *same* IPv4 address for the relay,
> a stateful firewall will not interfere.

And how exactly will you get everyone else's relay to use this specific
source address?

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 pch-b6B5344D9@u-1.phicoh.com  Tue May 10 00: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 5C5E9E06BA for ; Tue, 10 May 2011 00:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.235
X-Spam-Level: 
X-Spam-Status: No, score=-8.235 tagged_above=-999 required=5 tests=[AWL=0.364,  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 PeGn1PL9oTam for ; Tue, 10 May 2011 00:46:05 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6F5E067E for ; Tue, 10 May 2011 00:46:04 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QJhAT-0001tTC; Tue, 10 May 2011 09:15:41 +0200
Message-Id: 
To: Brian E Carpenter 
From: Philip Homburg 
Sender: pch-b6B5344D9@u-1.phicoh.com
References:  <4DC865BD.3070605@gmail.com> 
In-reply-to: Your message of "Tue, 10 May 2011 10:07:57 +1200 ." <4DC865BD.3070605@gmail.com> 
Date: Tue, 10 May 2011 09:15:30 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-andrews-v6ops-6to4-router-option-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, 10 May 2011 07:46:06 -0000

In your letter dated Tue, 10 May 2011 10:07:57 +1200 you wrote:
>On 2011-05-10 02:34, Philip Homburg wrote:
>> And using a different IPv4 address for the
>> relay is most likely just going to break things.
>
>Not so. The issue with not using the anycast address for return packets
>to the 6to4 user is that a stateful firewall will drop them, because
>the outbound packet was sent to the anycast address. As long as the
>outbound and return packets use the *same* IPv4 address for the relay,
>a stateful firewall will not interfere.

I have no idea how that is supposed to work. Suppose an ISP is using
203.0.113.1 as the 6to4 relay address. How is a remote relay on the
return path supposed to know that it has to put 203.0.113.1 in the source
address instead of the regular 6to4 anycast address?



From marka@isc.org  Tue May 10 01:13: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 C99E7E07A5 for ; Tue, 10 May 2011 01:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.725
X-Spam-Level: 
X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.274,  BAYES_00=-2.599, J_CHICKENPOX_37=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 ahI0ajg3jn24 for ; Tue, 10 May 2011 01:13:51 -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 D0600E0670 for ; Tue, 10 May 2011 01:13:50 -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 5B3A9C94DE; Tue, 10 May 2011 06:48:43 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 E021A216C44; Tue, 10 May 2011 06:48:42 +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 B5081E9E11B; Tue, 10 May 2011 16:49:04 +1000 (EST)
To: Tore Anderson 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com>
In-reply-to: Your message of "Tue, 10 May 2011 08:11:35 +0200." <4DC8D717.3080402@redpill-linpro.com>
Date: Tue, 10 May 2011 16:49:04 +1000
Message-Id: <20110510064904.B5081E9E11B@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 10 May 2011 08:13:51 -0000

In message <4DC8D717.3080402@redpill-linpro.com>, Tore Anderson writes:
> * Lorenzo Colitti
> 
> > I don't see any reason to do this.
> 
> +1, opposed. Let's stop flogging the dead horse.
> 
> > First: if you're an operator (and you probably are, since you have the powe
> r
> > to control the DHCP server), you can already ensure 6to4 nodes to use your
> > relay by making sure that 192.88.99.1 is routed to it. You don't have to
> > change the OS stacks at all. Thus no RFC, no IANA DHCP option assignment, n
> o
> > implementation changes on the server or on the client, ...
> > 
> > Second: this only makes the forward path more reliable. Reverse path is
> > still unreliable because it is not under your control (the server will just
> > pick whatever anycast 6to4 relay is closest to it). The only way to fix tha
> t
> > is by using 6rd or something like 6to4-PMT, which the WG did not adopt as a
> n
> > item.

6to4-PMT was designed to keep 6to4 running in the presence of NATs
in the path.  This option is designed to disable 6to4 when there
are NATs in the path.

> > Third: as Erik says, you're really just reinventing a part of 6rd. More
> > specifically: RFC 3068-style anycast 6to4 is a special case of 6rd
> > where IPv4MaskLen = 0, 6rdPrefix = 2002::, 6rdPrefixLen = 16,
> > and 6rdBRIPv4Address = 192.88.99.1. From a protocol perspective, what you
> > are doing is adding the 6rdBRIPv4Address parameter, but not the other three
> > parameters, to 6to4. I think that instead of asking implementors to do this
> ,
> > we should just ask them to implement 6rd instead.

6rd is useless without ISPs turning on 6rd.  6rd is basically
undeployable if the ISP doesn't supply the CPE equipment.  This
isn't to say CPE vendors shouldn't implement 6rd.

> Fourth: You'll cement an increased failure rate because the IPv4
> destination address in the outbound proto-41 packets won't match the
> IPv4 source address in the inbound replies. That confuses stateful
> devices in the path.

6to4 really isn't designed to be deployed on equipment behind a
firewall.  I suspect most of the cases where setting the source
address of the returned packet to the anycast address helps are in
networks where the operator would disable 6to4 if they had a control
which would do it.  This option provides such a control.

All the +1 are indicating that you want 6to4 to crash and burn
rather than have a graceful landing.  One can actually install a
under carriage while the plane is in flight.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From Fred.L.Templin@boeing.com  Tue May 10 08:17: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 D6579E07EF for ; Tue, 10 May 2011 08:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.522
X-Spam-Level: 
X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599, 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 jUTTu65RBXpA for ; Tue, 10 May 2011 08:17:24 -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 52485E07B6 for ; Tue, 10 May 2011 08:17:23 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4AEHv4E014075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 May 2011 07:17:57 -0700 (PDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4AEHuft012430 for ; Tue, 10 May 2011 09:17:56 -0500 (CDT)
Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4AEHunT012402 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 10 May 2011 09:17:56 -0500 (CDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Tue, 10 May 2011 07:17:55 -0700
From: "Templin, Fred L" 
To: "v6ops@ietf.org WG" 
Date: Tue, 10 May 2011 07:17:55 -0700
Thread-Topic: [v6ops] new draft: draft-templin-v6ops-isops-00.txt
Thread-Index: AcwMH4Oy/p8WK185TjyMZcwzk/WQTAAAzo1gAL5UrfA=
Message-ID: 
References: <4DC44472.6080208@globis.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed; boundary="_002_E1829B60731D1740BB7A0626B4FAF0A65C6A6029AAXCHNW01Vnwnos_"
MIME-Version: 1.0
Subject: Re: [v6ops] new draft: draft-templin-v6ops-isops-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, 10 May 2011 15:17:28 -0000

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

Please see below for an update to this draft, plus
attached diffs. This version incorporates changes
that resulted mainly from list discussions. Please
review and send comments to the list.

Fred
fred.l.templin@boeing.com

--- cut here ---
From: internet-drafts@ietf.org=20
To: i-d-announce@ietf.org=20
Reply-to: internet-drafts@ietf.org=20
Subject: I-D Action: draft-templin-v6ops-isops-01.txt=20
X-RSN: 1/0/935/36699/40073=20
=20
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.=20
=20
Title : Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP=
=20
Author(s) : Fred L. Templin=20
Filename : draft-templin-v6ops-isops-01.txt=20
Pages : 19=20
Date : 2011-05-09=20
=20
Many end user sites in the Internet today still have predominantly=20
IPv4 internal infrastructures. These sites range in size from small=20
home/office networks to large corporate enterprise networks, but=20
share the commonality that IPv4 continues to provide satisfactory=20
internal routing and addressing services for most applications. As=20
more and more IPv6-only services are deployed in the Internet,=20
however, end user devices within such sites will increasingly require=20
at least basic IPv6 functionality for external access. It is also=20
expected that more and more IPv6-only devices will be deployed within=20
the site over time. This document therefore provides operational=20
guidance for deployment of IPv6 within predominantly IPv4 sites using=20
the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).=20
=20
=20
A URL for this Internet-Draft is:=20
http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-01.txt=20
=20
Internet-Drafts are also available by anonymous FTP at:=20
ftp://ftp.ietf.org/internet-drafts/=20
=20
This Internet-Draft can be retrieved at:=20
ftp://ftp.ietf.org/internet-drafts/draft-templin-v6ops-isops-01.txt=

--_002_E1829B60731D1740BB7A0626B4FAF0A65C6A6029AAXCHNW01Vnwnos_
Content-Type: text/html; name="wdiff 00b_txt 01_txt.htm"
Content-Description: wdiff 00b_txt 01_txt.htm
Content-Disposition: attachment; filename="wdiff 00b_txt 01_txt.htm";
	size=46408; creation-date="Tue, 10 May 2011 14:16:39 GMT";
	modification-date="Tue, 10 May 2011 14:16:39 GMT"
Content-Transfer-Encoding: base64

CjxodG1sPjxoZWFkPjx0aXRsZT53ZGlmZiAwMGIudHh0IDAxLnR4dDwvdGl0bGU+PC9oZWFkPjxi
b2R5Pgo8cHJlPgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBGLiBUZW1wbGluCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgQm9laW5nIFJlc2VhcmNoICZhbXA7IFRlY2hub2xvZ3kKSW50ZW5kZWQg
c3RhdHVzOiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWF5IDxz
dHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPjA1LDwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9u
dCBjb2xvcj0nZ3JlZW4nID4wOSw8L2ZvbnQ+PC9zdHJvbmc+IDIwMTEKRXhwaXJlczogTm92ZW1i
ZXIgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+Niw8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+
PGZvbnQgY29sb3I9J2dyZWVuJyA+MTAsPC9mb250Pjwvc3Ryb25nPiAyMDExCgogIE9wZXJhdGlv
bmFsIEd1aWRhbmNlIGZvciBJUHY2IERlcGxveW1lbnQgaW4gSVB2NCBTaXRlcyB1c2luZyBJU0FU
QVAKICAgICAgICAgICAgICAgICAgICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5kcmFmdC10
ZW1wbGluLXY2b3BzLWlzb3BzLTAwLnR4dDwvZm9udD48L3N0cmlrZT4KICAgICAgICAgICAgICAg
ICAgICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPmRyYWZ0LXRlbXBsaW4tdjZvcHMtaXNv
cHMtMDEudHh0PC9mb250Pjwvc3Ryb25nPgoKQWJzdHJhY3QKCiAgIE1hbnkgZW5kIHVzZXIgc2l0
ZXMgaW4gdGhlIEludGVybmV0IHRvZGF5IHN0aWxsIGhhdmUgcHJlZG9taW5hbnRseQogICBJUHY0
IGludGVybmFsIGluZnJhc3RydWN0dXJlcy4gIFRoZXNlIHNpdGVzIHJhbmdlIGluIHNpemUgZnJv
bSBzbWFsbAogICBob21lL29mZmljZSBuZXR3b3JrcyB0byBsYXJnZSBjb3Jwb3JhdGUgZW50ZXJw
cmlzZSBuZXR3b3JrcywgYnV0CiAgIHNoYXJlIHRoZSBjb21tb25hbGl0eSB0aGF0IElQdjQgY29u
dGludWVzIHRvIHByb3ZpZGUgc2F0aXNmYWN0b3J5CiAgIGludGVybmFsIHJvdXRpbmcgYW5kIGFk
ZHJlc3Npbmcgc2VydmljZXMgZm9yIG1vc3QgYXBwbGljYXRpb25zLiAgQXMKICAgbW9yZSBhbmQg
bW9yZSBJUHY2LW9ubHkgc2VydmljZXMgYXJlIGRlcGxveWVkIGluIHRoZSBJbnRlcm5ldCwKICAg
aG93ZXZlciwgZW5kIHVzZXIgZGV2aWNlcyB3aXRoaW4gc3VjaCBzaXRlcyB3aWxsIGluY3JlYXNp
bmdseSByZXF1aXJlCiAgIGF0IGxlYXN0IGJhc2ljIElQdjYgZnVuY3Rpb25hbGl0eSBmb3IgZXh0
ZXJuYWwgYWNjZXNzLiAgSXQgaXMgYWxzbwogICBleHBlY3RlZCB0aGF0IG1vcmUgYW5kIG1vcmUg
SVB2Ni1vbmx5IGRldmljZXMgd2lsbCBiZSBkZXBsb3llZCB3aXRoaW4KICAgdGhlIHNpdGUgb3Zl
ciB0aW1lLiAgVGhpcyBkb2N1bWVudCB0aGVyZWZvcmUgcHJvdmlkZXMgb3BlcmF0aW9uYWwKICAg
Z3VpZGFuY2UgZm9yIGRlcGxveW1lbnQgb2YgSVB2NiB3aXRoaW4gcHJlZG9taW5hbnRseSBJUHY0
IHNpdGVzIHVzaW5nCiAgIHRoZSBJbnRyYS1TaXRlIEF1dG9tYXRpYyBUdW5uZWwgQWRkcmVzc2lu
ZyBQcm90b2NvbCAoSVNBVEFQKS4KClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJu
ZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJv
dmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29y
a2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2Ug
KElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdv
cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQg
SW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJh
ZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFs
aWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVw
bGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJ
dCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAg
IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz
LiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTm92ZW1iZXIgPHN0cmlr
ZT48Zm9udCBjb2xvcj0ncmVkJyA+Niw8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29s
b3I9J2dyZWVuJyA+MTAsPC9mb250Pjwvc3Ryb25nPiAyMDExLgoKQ29weXJpZ2h0IE5vdGljZQoK
ICAgQ29weXJpZ2h0IChjKSAyMDExIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZp
ZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAg
VGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBM
ZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8v
dHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgog
ICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1
bWVudHMKICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0
cmljdGlvbnMgd2l0aCByZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVu
dHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmll
ZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUg
VHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkg
YXMKICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKVGFibGUgb2Yg
Q29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMwogICAyLiAgRW5hYmxpbmcgSVB2NiBTZXJ2aWNlcyB1
c2luZyBJU0FUQVAgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMKICAgMy4gIFNMQUFDIFNl
cnZpY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8
c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID40PC9mb250Pjwvc3RyaWtlPiAgPHN0cm9uZz48Zm9u
dCBjb2xvcj0nZ3JlZW4nID41PC9mb250Pjwvc3Ryb25nPgogICAgIDMuMS4gIElTQVRBUCBSb3V0
ZXIgQmVoYXZpb3IgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUKICAgICAz
LjIuICBJU0FUQVAgSG9zdCBCZWhhdmlvciAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuICA1CiAgICAgMy4zLiAgUmVmZXJlbmNlIE9wZXJhdGlvbmFsIFNjZW5hcmlvIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+NTwvZm9u
dD48L3N0cmlrZT4gIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+NjwvZm9udD48L3N0cm9u
Zz4KICAgICAzLjQuICBMb29wIEF2b2lkYW5jZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuICA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID43PC9mb250Pjwvc3Ry
aWtlPiAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID44PC9mb250Pjwvc3Ryb25nPgogICA0
LiAgREhDUHY2IFNlcnZpY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gIDgKICAgICA0LjEuICBJU0FUQVAgUm91dGVyIEJlaGF2aW9yIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgICAgNC4yLiAgSVNBVEFQIEhvc3QgQmVoYXZp
b3IgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHN0cmlrZT48Zm9udCBj
b2xvcj0ncmVkJyA+OTwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4n
ID4xMDwvZm9udD48L3N0cm9uZz4KICAgICA0LjMuICBSZWZlcmVuY2UgT3BlcmF0aW9uYWwgU2Nl
bmFyaW8gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgICAgNC40LiAgTG9vcCBBdm9p
ZGFuY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMwogICA1
LiAgU2NhbGluZyBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gMTMKICAgNi4gIE9uLURlbWFuZCBEeW5hbWljIFJvdXRpbmcgIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0CiAgIDcuICBTaXRlIFBhcnRpdGlvbmluZyBDb25z
aWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNAogICA4LiAgU2l0ZSBS
ZW51bWJlcmluZyBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
MTQKICAgOS4gIFBhdGggTVRVIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIDE1CiAgIDEwLiBBbHRlcm5hdGl2ZSBBcHByb2FjaGVzIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNQogICAxMS4gSUFOQSBDb25zaWRlcmF0
aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgMTIu
IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIDE2CiAgIDEzLiBBY2tub3dsZWRnbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAxNC4gUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYKICAgICAxNC4xLiBOb3Jt
YXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2
CiAgICAgMTQuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAxNwogICBBdXRob3IncyBBZGRyZXNzIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+
MTg8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+MTk8L2ZvbnQ+
PC9zdHJvbmc+CgoxLiAgSW50cm9kdWN0aW9uCgogICBFbmQgdXNlciBzaXRlcyBpbiB0aGUgSW50
ZXJuZXQgdG9kYXkgY3VycmVudGx5IHVzZSBJUHY0IHJvdXRpbmcgYW5kCiAgIGFkZHJlc3Npbmcg
aW50ZXJuYWxseSBmb3IgY29yZSBvcGVyYXRpbmcgZnVuY3Rpb25zIHN1Y2ggYXMgd2ViCiAgIGJy
b3dzaW5nLCBmaWxlc2hhcmluZywgbmV0d29yayBwcmludGluZywgZS1tYWlsLCB0ZWxlY29uZmVy
ZW5jaW5nIGFuZAogICBudW1lcm91cyBvdGhlciBzaXRlLWludGVybmFsIG5ldHdvcmtpbmcgc2Vy
dmljZXMuICBTdWNoIHNpdGVzCiAgIHR5cGljYWxseSBoYXZlIGFuIGFidW5kYW5jZSBvZiBwdWJs
aWMgb3IgcHJpdmF0ZSBJUHY0IGFkZHJlc3NlcyBmb3IKICAgaW50ZXJuYWwgbmV0d29ya2luZywg
YW5kIGFyZSBzZXBhcmF0ZWQgZnJvbSB0aGUgcHVibGljIEludGVybmV0IGJ5CiAgIGZpcmV3YWxs
cywgcGFja2V0IGZpbHRlcmluZyBnYXRld2F5cywgcHJveGllcywgYWRkcmVzcyB0cmFuc2xhdG9y
cwogICBhbmQgb3RoZXIgc2l0ZSBib3JkZXIgZGVtYXJjYXRpb24gZGV2aWNlcy4gIFRvIGRhdGUs
IHN1Y2ggc2l0ZXMgaGF2ZQogICBoYWQgbGl0dGxlIGluY2VudGl2ZSB0byBlbmFibGUgSVB2NiBz
ZXJ2aWNlcyBpbnRlcm5hbGx5IFtSRkMxNjg3XS4KCiAgIEVuZC11c2VyIHNpdGVzIHRoYXQgY3Vy
cmVudGx5IHVzZSBJUHY0IHNlcnZpY2VzIGludGVybmFsbHkgY29tZSBpbgogICBlbmRsZXNzIHNp
emVzIGFuZCB2YXJpZXRpZXMuICBGb3IgZXhhbXBsZSwgYSBob21lIG5ldHdvcmsgYmVoaW5kIGEK
ICAgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0b3IgKE5BVCkgbWF5IGNvbnNpc3Qgb2YgYSBzaW5n
bGUgbGluawogICBzdXBwb3J0aW5nIGEgZmV3IGxhcHRvcHMsIHByaW50ZXJzIGV0Yy4gIEFzIGEg
bGFyZ2VyIGV4YW1wbGUsIGEgc21hbGwKICAgYnVzaW5lc3MgbWF5IGNvbnNpc3Qgb2Ygb25lIG9y
IGEgZmV3IG9mZmljZXMgd2l0aCBzZXZlcmFsIG5ldHdvcmtzCiAgIGNvbm5lY3RpbmcgY29uc2lk
ZXJhYmx5IGxhcmdlciBudW1iZXJzIG9mIGNvbXB1dGVycywgcm91dGVycywKICAgaGFuZGhlbGQg
ZGV2aWNlcywgcHJpbnRlcnMsIGZheGVzLCBldGMuICBNb3ZpbmcgZnVydGhlciB1cCB0aGUgc2Nh
bGUsCiAgIGxhcmdlIGJhbmtzLCByZXN0YXVyYW50cywgbWFqb3IgcmV0YWlsZXJzLCBsYXJnZSBj
b3Jwb3JhdGlvbnMsIGV0Yy4KICAgbWF5IGNvbnNpc3Qgb2YgaHVuZHJlZHMgb3IgdGhvdXNhbmRz
IG9mIGJyYW5jaGVzIHdvcmxkd2lkZSB0aGF0IGFyZQogICB0aWVkIHRvZ2V0aGVyIGluIGEgY29t
cGxleCBnbG9iYWwgZW50ZXJwcmlzZSBuZXR3b3JrLiAgQWRkaXRpb25hbAogICBleGFtcGxlcyBp
bmNsdWRlIHBlcnNvbmFsLWFyZWEgbmV0d29ya3MsIG1vYmlsZSB2ZWhpY3VsYXIgbmV0d29ya3Ms
CiAgIGRpc2FzdGVyIHJlbGllZiBuZXR3b3JrcywgdGFjdGljYWwgbWlsaXRhcnkgbmV0d29ya3Ms
IGFuZCB2YXJpb3VzCiAgIGZvcm1zIG9mIE1vYmlsZSBBZC1ob2MgTmV0d29ya3MgKE1BTkVUcyku
ICBUaGVzZSBjYXNlcyBhbmQgbW9yZSBhcmUKICAgY29uc2lkZXJlZCBpbiBSQU5HRVJTW1JGQzYx
MzldLgoKICAgV2l0aCB0aGUgcHJvbGlmZXJhdGlvbiBvZiBJUHY2IGRldmljZXMgaW4gdGhlIHB1
YmxpYyBJbnRlcm5ldCwKICAgaG93ZXZlciwgZXhpc3RpbmcgSVB2NCBzaXRlcyB3aWxsIGluY3Jl
YXNpbmdseSByZXF1aXJlIGEgbWVhbnMgZm9yCiAgIGVuYWJsaW5nIElQdjYgc2VydmljZXMgc28g
dGhhdCBob3N0cyB3aXRoaW4gdGhlIHNpdGUgY2FuIGNvbW11bmljYXRlCiAgIHdpdGggSVB2Ni1v
bmx5IGNvcnJlc3BvbmRlbnRzLiAgU3VjaCBzZXJ2aWNlcyBtdXN0IGJlIGRlcGxveWFibGUgd2l0
aAogICBtaW5pbWFsIGNvbmZpZ3VyYXRpb24sIGFuZCBpbiBhIGZhc2hpb24gdGhhdCB3aWxsIG5v
dCBjYXVzZQogICBkaXNydXB0aW9ucyB0byBleGlzdGluZyBJUHY0IHNlcnZpY2VzLiAgVGhlIElu
dHJhLVNpdGUgQXV0b21hdGljCiAgIFR1bm5lbCBBZGRyZXNzaW5nIFByb3RvY29sIChJU0FUQVAp
IFtSRkM1MjE0XSBwcm92aWRlcyBhIHNpbXBsZS10by0KICAgdXNlIHNlcnZpY2UgdGhhdCBzaXRl
cyBjYW4gZGVwbG95IGluIHRoZSBuZWFyIHRlcm0gdG8gbWVldCB0aGVzZQogICByZXF1aXJlbWVu
dHMuICBUaGlzIGRvY3VtZW50IHRoZXJlZm9yZSBwcm92aWRlcyBvcGVyYXRpb25hbCBndWlkYW5j
ZQogICBmb3IgdXNpbmcgSVNBVEFQIHRvIGVuYWJsZSBJUHY2IHNlcnZpY2VzIHdpdGhpbiBwcmVk
b21pbmFudGx5IElQdjQKICAgc2l0ZXMgd2hpbGUgY2F1c2luZyBubyBkaXNydXB0aW9ucyB0byBl
eGlzdGluZyBJUHY0IHNlcnZpY2VzLgoKMi4gIEVuYWJsaW5nIElQdjYgU2VydmljZXMgdXNpbmcg
SVNBVEFQCgogICBNYW55IGV4aXN0aW5nIHNpdGVzIHdpdGhpbiB0aGUgSW50ZXJuZXQgcHJlZG9t
aW5hbnRseSB1c2UgSVB2NC1iYXNlZAogICBzZXJ2aWNlcyBmb3IgdGhlaXIgaW50ZXJuYWwgbmV0
d29ya2luZyBuZWVkcywgYnV0IHRoZXJlIGlzIGEgZ3Jvd2luZwogICByZXF1aXJlbWVudCBmb3Ig
ZW5hYmxpbmcgSVB2NiBzZXJ2aWNlcyB0byBzdXBwb3J0IGNvbW11bmljYXRpb25zIHdpdGgKICAg
SVB2Ni1vbmx5IGNvcnJlc3BvbmRlbnRzLiAgU21hbGxlciBzaXRlcyB0aGF0IHdpc2ggdG8gZW5h
YmxlIElQdjYKICAgdHlwaWNhbGx5IGFycmFuZ2UgdG8gb2J0YWluIHB1YmxpYyBJUHY2IHByZWZp
eGVzIGZyb20gYW4gSW50ZXJuZXQKICAgU2VydmljZSBQcm92aWRlciAoSVNQKSwgd2hlcmUgdGhl
IHByZWZpeGVzIG1heSBiZSBlaXRoZXIgcHVyZWx5CiAgIG5hdGl2ZSBvciB0aGUgbmVhci1uYXRp
dmUgcHJlZml4ZXMgb2ZmZXJlZCBieSA2cmQgW1JGQzU5NjldLiAgTGFyZ2VyCiAgIHNpdGVzIHR5
cGljYWxseSBvYnRhaW4gcHJvdmlkZXIgaW5kZXBlbmRlbnQgSVB2NiBwcmVmaXhlcyBmcm9tIGFu
CiAgIEludGVybmV0IHJlZ2lzdHJ5IGFuZCBhZHZlcnRpc2UgdGhlIHByZWZpeGVzIGludG8gdGhl
IElQdjYgcm91dGluZwogICBzeXN0ZW0gb24gdGhlaXIgb3duIGJlaGFsZiwgaS5lLiwgdGhleSBh
Y3QgYXMgYW4gSVNQIHVudG8gdGhlbXNlbHZlcy4KICAgSW4gZWl0aGVyIGNhc2UsIGFmdGVyIG9i
dGFpbmluZyBJUHY2IHByZWZpeGVzIHRoZSBzaXRlIGNhbgogICBhdXRvbWF0aWNhbGx5IGVuYWJs
ZSBJUHY2IHNlcnZpY2VzIGludGVybmFsbHkgYnkgY29uZmlndXJpbmcgSVNBVEFQLgoKICAgVGhl
IElTQVRBUCBzZXJ2aWNlIHVzZXMgYSBOb24tQnJvYWRjYXN0LCBNdWx0aXBsZSBBY2Nlc3MgKE5C
TUEpCiAgIHR1bm5lbCB2aXJ0dWFsIGludGVyZmFjZSBtb2RlbCBbUkZDMjQ5MV1bUkZDMjUyOV0g
YmFzZWQgb24gSVB2Ni1pbi0KICAgSVB2NCBlbmNhcHN1bGF0aW9uIFtSRkM0MjEzXS4gIFRoZSA8
c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPmVuY2Fwc3VsYXRpb24gZm9ybWF0IGNhbiBmdXJ0
aGVyCiAgIHVzZSBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlIChEUykgW1JGQzI5ODNdIGFuZCBFeHBs
aWNpdCBDb25nZXN0aW9uCiAgIE5vdGlmaWNhdGlvbiAoRUNOKSBbUkZDMzE2OF0gbWFwcGluZyBi
ZXR3ZWVuIHRoZSBpbm5lciBhbmQgb3V0ZXIgSVAKICAgaGVhZGVycyB0byBlbnN1cmUgZXhwZWN0
ZWQgcGVyLWhvcCBiZWhhdmlvciB3aXRoaW4gd2VsbC1tYW5hZ2VkCiAgIHNpdGVzLgoKICAgVGhl
IElTQVRBUDwvZm9udD48L3N0cm9uZz4gc2VydmljZSBpcyBmdXJ0aGVyIGJhc2VkIG9uIHRocmVl
IGJhc2ljIG5vZGUgdHlwZXMga25vd24KICAgYXMgYWR2ZXJ0aXNpbmcgSVNBVEFQIHJvdXRlcnMs
IG5vbi1hZHZlcnRpc2luZyBJU0FUQVAgcm91dGVycyBhbmQKICAgSVNBVEFQIGhvc3RzLiAgQWR2
ZXJ0aXNpbmcgSVNBVEFQIHJvdXRlcnMgY29uZmlndXJlIHRoZWlyIHNpdGUtZmFjaW5nCiAgIElT
QVRBUCBpbnRlcmZhY2VzIGFzIGFkdmVydGlzaW5nIHJvdXRlciBpbnRlcmZhY2VzIChzZWU6IFtS
RkM0ODYxXSwKICAgU2VjdGlvbiA2LjIuMikuICBOb24tYWR2ZXJ0aXNpbmcgSVNBVEFQIHJvdXRl
cnMgY29uZmlndXJlIHRoZWlyIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPnNpdGUtZmFjaW5n
PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPnNpdGUtCiAgIGZh
Y2luZzwvZm9udD48L3N0cm9uZz4gSVNBVEFQIGludGVyZmFjZXMgYXMgPHN0cmlrZT48Zm9udCBj
b2xvcj0ncmVkJyA+bm9uLQogICBhZHZlcnRpc2luZzwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48
Zm9udCBjb2xvcj0nZ3JlZW4nID5ub24tYWR2ZXJ0aXNpbmc8L2ZvbnQ+PC9zdHJvbmc+IHJvdXRl
ciBpbnRlcmZhY2VzIGFuZAogICBvYnRhaW4gSVB2NiBhZGRyZXNzZXMvcHJlZml4ZXMgdmlhIGF1
dG9jb25maWd1cmF0aW9uIGV4Y2hhbmdlcyB3aXRoCiAgIGFkdmVydGlzaW5nIElTQVRBUCByb3V0
ZXJzLiAgRmluYWxseSwgSVNBVEFQIGhvc3RzIGNvbmZpZ3VyZSB0aGVpcgogICBzaXRlLWZhY2lu
ZyBJU0FUQVAgaW50ZXJmYWNlcyBhcyBzaW1wbGUgaG9zdCBpbnRlcmZhY2VzIGFuZCBhbHNvCiAg
IGNvb3JkaW5hdGUgdGhlaXIgYXV0b2NvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyB3aXRoIGFkdmVy
dGlzaW5nIElTQVRBUAogICByb3V0ZXJzLiAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5J
biB0aGlzIHNlbnNlLCBhZHZlcnRpc2luZyBJU0FUQVAgcm91dGVycyBhcmUgInNlcnZlcnMiCiAg
IHdoaWxlIG5vbi1hZHZlcnRpc2luZyBJU0FUQVAgcm91dGVycyBhbmQgSVNBVEFQIGhvc3RzIGFy
ZSAiY2xpZW50cyIKICAgaW4gdGhlIHNlcnZpY2UgbW9kZWwuPC9mb250Pjwvc3Ryb25nPgoKICAg
QWR2ZXJ0aXNpbmcgSVNBVEFQIHJvdXRlcnMgYXJyYW5nZSB0byBhZGQgdGhlaXIgSVB2NCBhZGRy
ZXNzZXMgdG8gdGhlCiAgIFBvdGVudGlhbCBSb3V0ZXIgTGlzdCAoUFJMKSB3aXRoaW4gdGhlIHNp
dGUgbmFtZSBzZXJ2aWNlLiAgVGhlIG5hbWUKICAgc2VydmljZSBjb3VsZCBiZSBlaXRoZXIgdGhl
IEROUyBvciBzb21lIG90aGVyIHNpdGUtaW50ZXJuYWwgbmFtZQogICByZXNvbHV0aW9uIHN5c3Rl
bSwgYnV0IHRoZSBQUkwgc2hvdWxkIGJlIHB1Ymxpc2hlZCBpbiBzdWNoIGEgd2F5IHRoYXQKICAg
SVNBVEFQIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPm5vZGVzPC9mb250Pjwvc3RyaWtlPiA8
c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPmNsaWVudHM8L2ZvbnQ+PC9zdHJvbmc+IGNhbiBy
ZXNvbHZlIHRoZSBuYW1lICJpc2F0YXAuZG9tYWlubmFtZSIgZm9yIHRoZQogICAiZG9tYWlubmFt
ZSIgc3VmZml4IGFzc29jaWF0ZWQgd2l0aCB0aGVpciBhdHRhY2hlZCBsaW5rLiAgRm9yCiAgIGV4
YW1wbGUsIGlmIHRoZSBkb21haW5uYW1lIHN1ZmZpeCBhc3NvY2lhdGVkIHdpdGggYW4gSVNBVEFQ
IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPm5vZGUnczwvZm9udD48L3N0cmlrZT4gPHN0cm9u
Zz48Zm9udCBjb2xvcj0nZ3JlZW4nID5jbGllbnQnczwvZm9udD48L3N0cm9uZz4KICAgYXR0YWNo
ZWQgbGluayBpcyAiZXhhbXBsZS5jb20iLCB0aGVuIHRoZSBuYW1lIG9mIHRoZSBQUkwgZm9yIHRo
YXQKICAgbGluayBhdHRhY2htZW50IHBvaW50IGlzICJpc2F0YXAuZXhhbXBsZS5jb20iLiAgT24g
dGhlIG90aGVyIGhhbmQsIGlmCiAgIHRoZSBzaXRlIG5hbWUgc2VydmljZSBpcyBvcGVyYXRpbmcg
d2l0aG91dCBhIGRvbWFpbm5hbWUgc3VmZml4LCB0aGVuCiAgIHRoZSBuYW1lIG9mIHRoZSBQUkwg
aXMgc2ltcGx5ICJpc2F0YXAiLgoKICAgQWZ0ZXIgdGhlIFBSTCBpcyBwdWJsaXNoZWQsIElTQVRB
UCA8c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5ub2RlczwvZm9udD48L3N0cmlrZT4gPHN0cm9u
Zz48Zm9udCBjb2xvcj0nZ3JlZW4nID5jbGllbnRzPC9mb250Pjwvc3Ryb25nPiB3aXRoaW4gdGhl
IHNpdGUgd2lsbAogICBhdXRvbWF0aWNhbGx5IDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPmRp
c2NvdmVyIGFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXJzIGFuZDwvZm9udD48L3N0cmlrZT4gcGVy
Zm9ybSBhIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+c3RhbmRhcmQgSVB2NiBOZWlnaGJv
ciBEaXNjb3Zlcnk8L2ZvbnQ+PC9zdHJvbmc+IFJvdXRlcgogICBTb2xpY2l0YXRpb24gKFJTKSAv
IFJvdXRlciBBZHZlcnRpc2VtZW50IChSQSkgZXhjaGFuZ2UgPHN0cm9uZz48Zm9udCBjb2xvcj0n
Z3JlZW4nID5bUkZDNDg2MV0gd2l0aAogICBhZHZlcnRpc2luZyBJU0FUQVAgcm91dGVycy4gIFRo
ZSBJU0FUQVAgY2xpZW50IGNvdWxkIGZ1cnRoZXIgdGVzdCB0aGUKICAgZGVsYXlzIHRvIG11bHRp
cGxlIGFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXJzIGFuZCBzZWxlY3QgdGhlIG9uZSB3aXRoCiAg
IGEgZmF2b3JhYmxlIGRlbGF5LiAgTW9yZW92ZXIsIG9uZSBvciBtb3JlIG9mIHRoZSBJUHY0IGFk
ZHJlc3NlcyBpbgogICB0aGUgUFJMIGNvdWxkIGluIGZhY3QgYmUgYW55Y2FzdCBhZGRyZXNzZXMs
IGFuZCBjb3VsZCB0aGVyZWZvcmUgYmUKICAgYXNzaWduZWQgdG8gdGhlIElQdjQgaW50ZXJmYWNl
cyBvZiBtdWx0aXBsZSBhZHZlcnRpc2luZyBJU0FUQVAKICAgcm91dGVycy4gIEluIHRoYXQgY2Fz
ZSwgSVB2NCByb3V0aW5nIHdpdGhpbiB0aGUgc2l0ZSB3b3VsZCBkaXJlY3QgdGhlCiAgIElTQVRB
UCBjbGllbnQ8L2ZvbnQ+PC9zdHJvbmc+IHRvIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+
dGhlIG5lYXJlc3QgYWR2ZXJ0aXNpbmcgSVNBVEFQIHJvdXRlci4KCiAgIEZvbGxvd2luZyByb3V0
ZXIgZGlzY292ZXJ5LCBJU0FUQVAgY2xpZW50czwvZm9udD48L3N0cm9uZz4gaW5pdGlhdGUgU3Rh
dGVsZXNzIEFkZHJlc3MKICAgQXV0b0NvbmZpZ3VyYXRpb24gKFNMQUFDKSwgdGhlIER5bmFtaWMg
SG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sCiAgIGZvciBJUHY2IChESENQdjYpIG9yIDxzdHJp
a2U+PGZvbnQgY29sb3I9J3JlZCcgPmJvdGguPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250
IGNvbG9yPSdncmVlbicgPmJvdGggYXMgZGlyZWN0ZWQgYnkgdGhlIHJlY2VpdmVkIFJBcy48L2Zv
bnQ+PC9zdHJvbmc+ICBUaGUgPHN0cmlrZT48Zm9udCBjb2xvcj0ncmVkJyA+bm9kZXM8L2ZvbnQ+
PC9zdHJpa2U+CiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+Y2xpZW50czwvZm9udD48
L3N0cm9uZz4gY2FuIHRoZW4gdXNlIFNMQUFDLXByb3ZpZGVkIElQdjYgYWRkcmVzc2VzIGZvciBi
YXNpYyBJUHY2CiAgIHNlcnZpY2VzIGFuZCBESENQdjYtcHJvdmlkZWQgSVB2NiBhZGRyZXNzZXMv
cHJlZml4ZXMgZm9yIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPmZ1bGx5LXF1YWxpZmllZDwv
Zm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4nID5mdWxseS0KICAgcXVh
bGlmaWVkPC9mb250Pjwvc3Ryb25nPiBJUHY2IHNlcnZpY2VzLgoKMy4gIFNMQUFDIFNlcnZpY2Vz
CgogICBQcmVkb21pbmFudGx5IElQdjQgc2l0ZXMgY2FuIGVuYWJsZSBJU0FUQVAgU0xBQUMgc2Vy
dmljZXMgZm9yIHRoZQogICBwdXJwb3NlIG9mIHByb3ZpZGluZyBiYXNpYyBJUHY2IHNlcnZpY2Vz
IHRvIElQdjQgaG9zdHMgdGhhdCBuZWVkIHRvCiAgIGNvbW11bmljYXRlIHdpdGggSVB2Ni1vbmx5
IGNvcnJlc3BvbmRlbnRzLiAgSW4gb3JkZXIgdG8gcHJvdmlkZSBhCiAgIHNpbXBsZSBzZXJ2aWNl
IHRoYXQgZG9lcyBub3QgaW50ZXJhY3QgcG9vcmx5IHdpdGggZXhpc3Rpbmcgc2l0ZQogICB0b3Bv
bG9naWNhbCBhcnJhbmdlbWVudHMsIHRoZSBzaXRlIHNob3VsZCBub3QgcHVibGlzaCBhbnkgSVNB
VEFQLQogICBwcm92aWRlZCBJUHY2IGFkZHJlc3NlcyB0aGF0IHdlcmUgY29uZmlndXJlZCB1c2lu
ZyBTTEFBQyB3aXRoaW4gdGhlCiAgIHNpdGUgbmFtZSBzZXJ2aWNlLiAgSGVuY2UsIElTQVRBUC1w
cm92aWRlZCBTTEFBQyBzZXJ2aWNlcyBhcmUKICAgdHlwaWNhbGx5IHVzZWQgcHJpbWFyeSBmb3Ig
Y2xpZW50LXNpZGUgb3BlcmF0aW9uLiAgVGhlIGZvbGxvd2luZwogICBzZWN0aW9ucyBkaXNjdXNz
IG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zIGZvciBlbmFibGluZyBJU0FUQVAgU0xBQUMKICAg
c2VydmljZXMgd2l0aGluIHByZWRvbWluYW50bHkgSVB2NCBzaXRlcy4KCjMuMS4gIElTQVRBUCBS
b3V0ZXIgQmVoYXZpb3IKCiAgIEFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXJzIHRoYXQgc3VwcG9y
dCBTTEFBQyBzZXJ2aWNlcyBzZW5kIFJBCiAgIG1lc3NhZ2VzIGluIHJlc3BvbnNlIHRvIFJTIG1l
c3NhZ2VzIHJlY2VpdmVkIG9uIGFuIGFkdmVydGlzaW5nIElTQVRBUAogICBpbnRlcmZhY2UuICBT
TEFBQyBzZXJ2aWNlcyBhcmUgZW5hYmxlZCB3aGVuIGFkdmVydGlzaW5nIElTQVRBUAogICByb3V0
ZXJzIGFkdmVydGlzZSBub24tbGluay1sb2NhbCBJUHY2IHByZWZpeGVzLiAgV2hlbiB0aGVyZSBh
cmUKICAgbXVsdGlwbGUgYWR2ZXJ0aXNpbmcgSVNBVEFQIHJvdXRlcnMsIHRoZSByb3V0ZXJzIGNh
biBhZHZlcnRpc2UgdGhlCiAgIHNhbWUgSVB2NiBwcmVmaXhlcyBvciBhIGRpZmZlcmVudCBzZXQg
b2YgSVB2NiBwcmVmaXhlcy4gIEZvciBleGFtcGxlLAogICBhIGZpcnN0IHJvdXRlciBtYXkgYWR2
ZXJ0aXNlIDIwMDE6ZGI4OjE6Oi82NCwgYSBzZWNvbmQgbWF5IGFkdmVydGlzZQogICAyMDAxOmRi
ODoyOjovNjQsIGV0Yy4KCiAgIFRoZSByb3V0ZXJzIGNhbiBmdXJ0aGVyIGJlIGNvbmZpZ3VyZWQg
dG8gYWR2ZXJ0aXNlIGRpZmZlcmVudCBwcmVmaXhlcwogICB0byBkaWZmZXJlbnQgc2V0cyBvZiBo
b3N0cyB3aXRoaW4gdGhlIHNpdGUgKGUuZy4sIGFzIGlkZW50aWZpZWQgYnkKICAgdGhlIGhvc3Qn
cyBJUHY0IHByZWZpeCkgZm9yIHRoZSBwdXJwb3NlIG9mIHNpdGUgcGFydGl0aW9uaW5nLiAgVG8K
ICAgZGlzY291cmFnZSBkaXJlY3QgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiBJU0FUQVAgaG9zdHMg
dXNpbmcgU0xBQUMtCiAgIHByb3ZpZGVkIGFkZHJlc3NlcywgYWR2ZXJ0aXNpbmcgSVNBVEFQIHJv
dXRlcnMgY2FuIHNlbmQgUkFzIHRoYXQKICAgaW5jbHVkZSBQcmVmaXggSW5mb3JtYXRpb24gT3B0
aW9ucyAoUElPcykgd2l0aCB0aGUgKEEsIEwpIGZsYWdzIHNldAogICB0byAoMSwwKSBbUkZDNDg2
MV0uCgozLjIuICBJU0FUQVAgSG9zdCBCZWhhdmlvcgoKICAgSVNBVEFQIGhvc3RzIHJlc29sdmUg
dGhlIFBSTCBhbmQgc2VuZCBSUyBtZXNzYWdlcyB0byBvYnRhaW4gUkEKICAgbWVzc2FnZXMgZnJv
bSBhbiBhZHZlcnRpc2luZyBJU0FUQVAgcm91dGVyLiAgSVNBVEFQIHJvdXRlcnMgdGhhdAogICBh
ZHZlcnRpc2UgcHJlZml4ZXMgZm9yIFNMQUFDIHB1cnBvc2VzIHdpbGwgdHlwaWNhbGx5IGFkdmVy
dGlzZQogICBwcmVmaXhlcyBpbiBQSU9zIHdpdGggdGhlIChBLCBMKSBmbGFncyBzZXQgdG8gKDEs
MCkuICBJbiB0aGF0IGNhc2UsCiAgIHRoZSBJU0FUQVAgaG9zdCBhdXRvY29uZmlndXJlcyBhbiBh
ZGRyZXNzIGZyb20gdGhlIGFkdmVydGlzZWQgSVB2NgogICBwcmVmaXggYW5kIGFzc2lnbnMgdGhl
IGFkZHJlc3MgdG8gdGhlIElTQVRBUCBpbnRlcmZhY2UsIGJ1dCB0aGUgaG9zdAogICBkb2VzIG5v
dCBhc3NpZ24gYW4gSVB2NiBwcmVmaXggdG8gdGhlIElTQVRBUCBpbnRlcmZhY2UuICBUaGVyZWZv
cmUsCiAgIGFsbCBJUHY2IGNvbW11bmljYXRpb25zIGZyb20gdGhlIGhvc3RzIHdpbGwgKGluaXRp
YWxseSkgZmxvdyB0aHJvdWdoCiAgIHRoZSBhZHZlcnRpc2luZyBJU0FUQVAgcm91dGVyLiAgVGhp
cyBhcnJhbmdlbWVudCBwcmV2ZW50cwogICBjb21tdW5pY2F0aW9uIGZhaWx1cmUgbW9kZXMgaW4g
d2hpY2ggYSBwYWlyIG9mIElTQVRBUCBob3N0cyB0aGF0IHVzZQogICBTTEFBQyBhcmUgc2VwYXJh
dGVkIGJ5IGEgcGFja2V0IGZpbHRlcmluZyBnYXRld2F5IHRoYXQgd291bGQgcHJldmVudAogICBk
aXJlY3QgY29tbXVuaWNhdGlvbnMgdmlhIHRoZSB0dW5uZWxlZCBJUHY2IHNlcnZpY2UuCgozLjMu
ICBSZWZlcmVuY2UgT3BlcmF0aW9uYWwgU2NlbmFyaW8KCiAgIEZpZ3VyZSAxIGRlcGljdHMgYSBy
ZWZlcmVuY2UgSVNBVEFQIG5ldHdvcmsgdG9wb2xvZ3kgZm9yIGFsbG93aW5nCiAgIGhvc3RzIHdp
dGhpbiBhIHByZWRvbWluYW50bHkgSVB2NCBzaXRlIHRvIGNvbmZpZ3VyZSBJUHY2IHNlcnZpY2Vz
CiAgIHVzaW5nIElTQVRBUCB3aXRoIFNMQUFDLiAgVGhlIHNjZW5hcmlvIHNob3dzIHR3byBhZHZl
cnRpc2luZyBJU0FUQVAKICAgcm91dGVycyAoJ0EnLCAnQicpLCB0d28gSVNBVEFQIGhvc3RzICgn
QycsICdEJyksIGFuZCBhbiBvcmRpbmFyeSBJUHY2CiAgIGhvc3QgKCdFJykgb3V0c2lkZSBvZiB0
aGUgc2l0ZSBpbiBhIHR5cGljYWwgZGVwbG95bWVudCBjb25maWd1cmF0aW9uOgogICAgICAgICAg
ICAgICAgICAuLSg6Ojo6Ojo6OikgICAgICAyMDAxOmRiODozOjoxCiAgICAgICAgICAgICAgIC4t
KDo6OiBJUHY2IDo6OiktLiAgKy0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgKDo6OjogSW50
ZXJuZXQgOjo6OikgfCBJUHY2IEhvc3QgRSB8CiAgICAgICAgICAgICAgIGAtKDo6Ojo6Ojo6Ojo6
OiktJyAgKy0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgIGAtKDo6Ojo6OiktJwogICAg
ICArLS0tLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tKwogICAgICB8ICBSb3V0ZXIgQSAg
fC0tLS4tLS18ICBSb3V0ZXIgQiAgfC4KICAgICAsfCAgKGlzYXRhcCkgIHwgICAgICAgfCAgKGlz
YXRhcCkgIHwgYFwKICAgIC8gKy0tLS0tLS0tLS0tLSsgICAgICAgKy0tLS0tLS0tLS0tLSsgICAg
XAogICA6ICBmZTgwOjoqOjE5Mi4wLjEuMSAgICBmZTgwOjoqOjE5Mi4wLjEuMiAgOgogICAgXCAy
MDAxOmRiODoxOjovNjQgICAgICAyMDAxOmRiODoyOjovNjQgICAvCiAgICAgOiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgOgogICAgICA6ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICA6CiAgICAgICstICAgICAgICAgICAgIElQdjQgU2l0ZSAgICAgICAgIC0r
CiAgICAgOyAgICAgKFBSTDogMTkyLjAuMi4xLCAxOTIuMC4yLjIpICAgOgogICAgIHwgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsKICAgICA6ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAtKy0nCiAgICAgIGAtLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4p
CiAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICBfKQogICAgICAgICAgYC0tLS0t
Ky0tLS0tLS0tKS0tLS0rJy0tLS0nCiAgICAgIGZlODA6Oio6MTkyLjAuMi4zICAgICAgICAgICBm
ZTgwOjoqOjE5Mi4wLjIuNAogICAyMDAxOmRiODoxOjoqOjE5Mi4wLjIuMyAgICAgMjAwMTpkYjg6
Mjo6KjoxOTIuMC4yLjQKICAgICArLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICArLS0tLS0tLS0t
LS0tLS0rCiAgICAgfCAgIChpc2F0YXApICAgfCAgICAgICAgICAgfCAgIChpc2F0YXApICAgfAog
ICAgIHwgICAgSG9zdCBDICAgIHwgICAgICAgICAgIHwgICAgSG9zdCBEICAgIHwKICAgICArLS0t
LS0tLS0tLS0tLS0rICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rCgogICAoKiA9PSAiNWVmZSIp
CgogICAgICAgICAgRmlndXJlIDE6IFJlZmVyZW5jZSBJU0FUQVAgTmV0d29yayBUb3BvbG9neSB1
c2luZyBTTEFBQwoKICAgSW4gRmlndXJlIDEsIGFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXJzICdB
JyBhbmQgJ0InIHdpdGhpbiB0aGUgSVB2NAogICBzaXRlIGNvbm5lY3QgdG8gdGhlIElQdjYgSW50
ZXJuZXQuICAoTm90ZSB0aGF0IHRoZSByb3V0ZXJzIG1heQogICBpbnN0ZWFkIGNvbm5lY3QgdG8g
dGhlIElQdjYgSW50ZXJuZXQgdmlhIGEgY29tcGFuaW9uIGdhdGV3YXkgYXMgc2hvd24KICAgaW4g
RmlndXJlIDIuKSAgQWR2ZXJ0aXNpbmcgSVNBVEFQIHJvdXRlciAnQScgY29uZmlndXJlcyBhIHNp
dGUtCiAgIGludGVyaW9yIElQdjQgaW50ZXJmYWNlIHdpdGggYWRkcmVzcyAxOTIuMC4yLjEgYW5k
IGFycmFuZ2VzIHRvIGFkZAogICB0aGUgYWRkcmVzcyB0byB0aGUgc2l0ZSdzIFBSTC4gICdBJyBu
ZXh0IGNvbmZpZ3VyZXMgYW4gYWR2ZXJ0aXNpbmcKICAgSVNBVEFQIHJvdXRlciBpbnRlcmZhY2Ug
d2l0aCBsaW5rLWxvY2FsIElQdjYgYWRkcmVzcyBmZTgwOjo1ZWZlOgogICAxOTIuMC4yLjEgb3Zl
ciB0aGUgSVB2NCBpbnRlcmZhY2UuICBJbiB0aGUgc2FtZSBmYXNoaW9uLCAnQicKICAgY29uZmln
dXJlcyB0aGUgSVB2NCBpbnRlcmZhY2UgYWRkcmVzcyAxOTIuMC4yLjIsIGFkZHMgdGhlIGFkZHJl
c3MgdG8KICAgdGhlIFBSTCwgdGhlbiBjb25maWd1cmVzIGl0cyBhZHZlcnRpc2luZyBJU0FUQVAg
cm91dGVyIGludGVyZmFjZSB3aXRoCiAgIGxpbmstbG9jYWwgYWRkcmVzcyBmZTgwOjo1ZWZlOjE5
Mi4wLjIuMi4KCiAgIElTQVRBUCBob3N0ICdDJyBjb25uZWN0cyB0byB0aGUgc2l0ZSB2aWEgYW4g
SVB2NCBpbnRlcmZhY2Ugd2l0aAogICBhZGRyZXNzIDE5Mi4wLjIuMywgYW5kIGFsc28gY29uZmln
dXJlcyBhbiBJU0FUQVAgaG9zdCBpbnRlcmZhY2Ugd2l0aAogICBsaW5rLWxvY2FsIGFkZHJlc3Mg
ZmU4MDo6NWVmZToxOTIuMC4yLjMgb3ZlciB0aGUgSVB2NCBpbnRlcmZhY2UuICAnQycKICAgbmV4
dCByZXNvbHZlcyB0aGUgUFJMIHRvIGRpc2NvdmVyIHRoZSBhZGRyZXNzIDE5Mi4wLjIuMSBhbmQg
cGVyZm9ybXMKICAgYW4gUlMvUkEgZXhjaGFuZ2Ugd2l0aCAnQScuICBCYXNlZCBvbiB0aGUgUkEg
aW5mb3JtYXRpb24sICdDJyBuZXh0CiAgIGNvbmZpZ3VyZXMgYSBkZWZhdWx0IElQdjYgcm91dGUg
d2l0aCBuZXh0LWhvcCBhZGRyZXNzIGZlODA6OjVlZmU6CiAgIDE5Mi4wLjIuMSB2aWEgdGhlIElT
QVRBUCBpbnRlcmZhY2UgYW5kIHByb2Nlc3NlcyB0aGUgSVB2NiBwcmVmaXgKICAgMjAwMTpkYjg6
MTo6LzY0IGFkdmVydGlzZWQgaW4gdGhlIFBJTy4gIFdoZW4gJ0MnIHByb2Nlc3NlcyB0aGUKICAg
cHJlZml4LCBpdCB1c2VzIFNMQUFDIHRvIGF1dG9tYXRpY2FsbHkgY29uZmlndXJlIHRoZSBhZGRy
ZXNzIDIwMDE6CiAgIGRiODoxOjo1ZWZlOjE5Mi4wLjIuMy4gICdDJyB0aGVuIGFzc2lnbnMgdGhl
IGFkZHJlc3MgdG8gdGhlIElTQVRBUAogICBpbnRlcmZhY2UsIGJ1dCBkb2VzIG5vdCBhc3NpZ24g
dGhlIHByZWZpeCBpdHNlbGYgdG8gdGhlIGludGVyZmFjZSBpZgogICB0aGUgJ0wnIGJpdCBpbiB0
aGUgUElPIGlzIDAuCgogICBJbiB0aGUgc2FtZSBmYXNoaW9uLCBJU0FUQVAgaG9zdCAnRCcgY29u
ZmlndXJlcyBpdHMgSVB2NCBpbnRlcmZhY2UKICAgd2l0aCBhZGRyZXNzIDE5Mi4wLjIuNCBhbmQg
Y29uZmlndXJlcyBpdHMgSVNBVEFQIGludGVyZmFjZSB3aXRoIGxpbmstCiAgIGxvY2FsIGFkZHJl
c3MgZmU4MDo6NWVmZToxOTIuMC4yLjQuICAnRCcgbmV4dCBwZXJmb3JtcyBhbiBSUy9SQQogICBl
eGNoYW5nZSB3aXRoICdCJywgdGhlbiB1c2VzIFNMQUFDIHRvIGF1dG9jb25maWd1cmUgdGhlIGFk
ZHJlc3MgMjAwMToKICAgZGI4OjI6OjVlZmU6MTkyLjAuMi40LgoKICAgRmluYWxseSwgSVB2NiBo
b3N0ICdFJyBjb25uZWN0cyB0byBhbiBJUHY2IG5ldHdvcmsgb3V0c2lkZSBvZiB0aGUKICAgc2l0
ZS4gICdFJyBjb25maWd1cmVzIGl0cyBJUHY2IGludGVyZmFjZSBpbiBhIG1hbm5lciBzcGVjaWZp
YyB0byBpdHMKICAgYXR0YWNoZWQgSVB2NiBsaW5rLCBhbmQgYXV0b2NvbmZpZ3VyZXMgdGhlIElQ
djYgYWRkcmVzcwogICAyMDAxOmRiODozOjoxLgoKICAgRm9sbG93aW5nIHRoaXMgYXV0b2NvbmZp
Z3VyYXRpb24sIHdoZW4gaG9zdCAnQycgaGFzIGFuIElQdjYgcGFja2V0IHRvCiAgIHNlbmQgdG8g
aG9zdCAnRScsIGl0IHByZXBhcmVzIHRoZSBwYWNrZXQgd2l0aCBzb3VyY2UgYWRkcmVzcyAyMDAx
OgogICBkYjg6OjVlZmU6MTkyLjAuMi4zIGFuZCBkZXN0aW5hdGlvbiBhZGRyZXNzIDIwMDE6ZGI4
OjM6OjEuICAnQycgdGhlbgogICB1c2VzIElQdjYtaW4tSVB2NCBlbmNhcHN1bGF0aW9uIHRvIGZv
cndhcmQgdGhlIHBhY2tldCB0byByb3V0ZXIgJ0EnLAogICB3aGljaCBpbiB0dXJuIGRlY2Fwc3Vs
YXRlcyB0aGUgcGFja2V0IGFuZCBmb3J3YXJkcyBpdCBpbnRvIHRoZSBwdWJsaWMKICAgSVB2NiBJ
bnRlcm5ldCB3aGVyZSBpdCB3aWxsIGJlIGNvbnZleWVkIHRvICdFJyB2aWEgbm9ybWFsIElQdjYK
ICAgcm91dGluZy4gIChOb3RlIHRoYXQgJ0EnIG1heSAidHJhbnNsYXRlIiB0aGUgcGFja2V0IGFz
IGl0IGlzCiAgIGZvcndhcmRlZCBhY3Jvc3MgdGhlIHNpdGUgYm91bmRhcnkgc3VjaCB0aGF0IGl0
IGFwcGVhcnMgdG8gY29tZSBmcm9tCiAgIGEgZGlmZmVyZW50IHNvdXJjZSBhZGRyZXNzIHRoYW4g
dGhlIG9uZSB1c2VkIGJ5IGhvc3QgJ0MnIHdpdGhpbiB0aGUKICAgc2l0ZS4pICBJbiB0aGUgc2Ft
ZSBmYXNoaW9uLCBob3N0ICdEJyB1c2VzIElQdjYtaW4tSVB2NCBlbmNhcHN1bGF0aW9uCiAgIHZp
YSBpdHMgZGVmYXVsdCByb3V0ZXIgJ0InIHRvIHNlbmQgSVB2NiBwYWNrZXRzIHRvIElQdjYgSW50
ZXJuZXQKICAgaG9zdHMgc3VjaCBhcyAnRScuCgogICBXaGVuIGhvc3QgJ0MnIGhhcyBhbiBJUHY2
IHBhY2tldCB0byBzZW5kIHRvIGhvc3QgJ0QnIChpLmUuLCBhbm90aGVyCiAgIElTQVRBUCBob3N0
IHdpdGhpbiB0aGUgc2l0ZSksIGl0IHVzZXMgSVB2Ni1pbi1JUHY0IGVuY2Fwc3VsYXRpb24gdG8K
ICAgZm9yd2FyZCB0aGUgcGFja2V0IHRvIGFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXIgJ0EnLiAg
J0EnIGluIHR1cm4KICAgY29udmV5cyB0aGUgcGFja2V0IHRvICdEJyBlaXRoZXIgZGlyZWN0bHkg
b3IgdmlhICdCJyBhcyBhbgogICBpbnRlcm1lZGlhcnkuICBIb3dldmVyLCBpdCBpcyBub3QgZXhw
ZWN0ZWQgdGhhdCBob3N0cyAnQycgYW5kICdEJwogICB3aWxsIG5vcm1hbGx5IHVzZSBJU0FUQVAg
c2VydmljZXMgd2hlbiBjb21tdW5pY2F0aW5nIHdpdGggZWFjaCBvdGhlcgogICB3aXRoaW4gdGhl
IHNpdGUuICBJbnN0ZWFkLCB0aGV5IHdpbGwgY29udGludWUgdG8gdXNlIGxlZ2FjeSBJUHY0CiAg
IHNlcnZpY2VzIHVudGlsIGEgZnVsbHktcXVhbGlmaWVkIElQdjYgaW50cmEtc2l0ZSBzZXJ2aWNl
IGJlY29tZXMKICAgYXZhaWxhYmxlLgoKMy40LiAgTG9vcCBBdm9pZGFuY2UKCiAgIEluIHNpdGVz
IHRoYXQgcHJvdmlkZSBJUHY2IHNlcnZpY2VzIHRocm91Z2ggSVNBVEFQIHdpdGggU0xBQUMgYXMK
ICAgZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbiwgYWR2ZXJ0aXNpbmcgSVNBVEFQIHJvdXRlcnMg
bXVzdCB0YWtlCiAgIG9wZXJhdGlvbmFsIHByZWNhdXRpb25zIHRvIGF2b2lkIHJvdXRpbmcgbG9v
cHMuICBGb3IgZXhhbXBsZSwgd2l0aAogICByZWZlcmVuY2UgdG8gRmlndXJlIDEgYW4gSVB2NiBw
YWNrZXQgdGhhdCBlbnRlcnMgdGhlIHNpdGUgdmlhCiAgIGFkdmVydGlzaW5nIElTQVRBUCByb3V0
ZXIgJ0EnIG11c3Qgbm90IGJlIGFsbG93ZWQgdG8gZXhpdCB0aGUgc2l0ZQogICB2aWEgYWR2ZXJ0
aXNpbmcgSVNBVEFQIHJvdXRlciAnQicgYmFzZWQgb24gYW4gaW52YWxpZCBTTEFBQyBhZGRyZXNz
LgoKICAgQXMgYSBzaW1wbGUgbWl0aWdhdGlvbiwgZWFjaCBhZHZlcnRpc2luZyBJU0FUQVAgcm91
dGVyIHNob3VsZCBkcm9wCiAgIGFueSBwYWNrZXRzIGNvbWluZyBmcm9tIHRoZSBJUHY2IEludGVy
bmV0IHRoYXQgd291bGQgYmUgZm9yd2FyZGVkCiAgIGJhY2sgdG8gdGhlIEludGVybmV0IHZpYSBh
bm90aGVyIGFkdmVydGlzaW5nIHJvdXRlci4gIEFkZGl0aW9uYWxseSwKICAgZWFjaCBhZHZlcnRp
c2luZyBJU0FUQVAgcm91dGVyIHNob3VsZCBkcm9wIGFueSBlbmNhcHN1bGF0ZWQgcGFja2V0cwog
ICByZWNlaXZlZCBmcm9tIGFub3RoZXIgYWR2ZXJ0aXNpbmcgcm91dGVyIHRoYXQgd291bGQgYmUg
Zm9yd2FyZGVkIHRvCiAgIHRoZSBJUHY2IEludGVybmV0LiAgKE5vdGUgdGhhdCBJUHY2IHBhY2tl
dHMgd2l0aCBsaW5rLWxvY2FsIGFkZHJlc3NlcwogICBhcmUgZXhjbHVkZWQgZnJvbSB0aGVzZSBj
aGVja3MsIHNpbmNlIHRoZXkgY2Fubm90IGJlIGZvcndhcmRlZCBieSBhbgogICBJUHY2IHJvdXRl
ciBhbmQgbWF5IGJlIG5lY2Vzc2FyeSBmb3Igcm91dGVyLXRvLXJvdXRlciBjb29yZGluYXRpb25z
LikKICAgVGhpcyBjb3JyZXNwb25kcyB0byB0aGUgbWl0aWdhdGlvbiBkb2N1bWVudGVkIGluIFNl
Y3Rpb24gMy4yLjMgb2YKICAgW0ktRC5pZXRmLXY2b3BzLXR1bm5lbC1sb29wc10sIGJ1dCBvdGhl
ciBtaXRpZ2F0aW9ucyBzdWNoIGFzIHRoZQogICB0dW5uZWwgZW5kcG9pbnQgdmVyaWZpY2F0aW9u
IGNoZWNrcyBsaXN0ZWQgaW4gU2VjdGlvbiAzLjEgb2YgdGhhdAogICBkb2N1bWVudCBjYW4gYWxz
byBiZSBlbXBsb3llZC4KCiAgIEFnYWluIHdpdGggcmVmZXJlbmNlIHRvIEZpZ3VyZSAxLCB3aGVu
ICdBJyByZWNlaXZlcyBhIHBhY2tldCBjb21pbmcKICAgZnJvbSB0aGUgSVB2NiBJbnRlcm5ldCB3
aXRoIGRlc3RpbmF0aW9uIGFkZHJlc3MgMjAwMTpkYjg6MTo6NWVmZToKICAgMTkyLjAuMi4yLCBp
dCBkcm9wcyB0aGUgcGFja2V0IHNpbmNlIHRoZSBJUHY0IGFkZHJlc3MgMTkyLjAuMi4yCiAgIGNv
cnJlc3BvbmRzIHRvIGFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXIgJ0InLiAgU2ltaWxhcmx5LCB3
aGVuICdCJwogICByZWNlaXZlcyBhIHBhY2tldCBjb21pbmcgZnJvbSB0aGUgdHVubmVsIHdpdGgg
YW4gSVB2NiBkZXN0aW5hdGlvbgogICBhZGRyZXNzIHRoYXQgd291bGQgY2F1c2UgdGhlIHBhY2tl
dCB0byBiZSBmb3J3YXJkZWQgYmFjayBvdXQgdG8gdGhlCiAgIElQdjYgSW50ZXJuZXQgYW5kIHdp
dGggYW4gSVB2NCBzb3VyY2UgYWRkcmVzcyAxOTIuMC4yLjEsIGl0IGRyb3BzIHRoZQogICBwYWNr
ZXQgc2luY2UgMTkyLjAuMi4xIGNvcnJlc3BvbmRzIHRvIGFkdmVydGlzaW5nIElTQVRBUCByb3V0
ZXIgJ0EnLgoKNC4gIERIQ1B2NiBTZXJ2aWNlcwoKICAgV2hldGhlciBvciBub3QgYWR2ZXJ0aXNp
bmcgSVNBVEFQIHJvdXRlcnMgbWFrZSBiYXNpYyBJUHY2IHNlcnZpY2VzCiAgIGF2YWlsYWJsZSB1
c2luZyBTTEFBQywgdGhleSBjYW4gYWxzbyBwcm92aWRlIGZ1bGx5LXF1YWxpZmllZCBJUHY2CiAg
IHNlcnZpY2VzIHRvIElTQVRBUCBjbGllbnRzIChpLmUuLCBib3RoIGhvc3RzIGFuZCBub24tYWR2
ZXJ0aXNpbmcKICAgSVNBVEFQIHJvdXRlcnMpIHVzaW5nIHRoZSBEeW5hbWljIEhvc3QgQ29uZmln
dXJhdGlvbiBQcm90b2NvbCBmb3IKICAgSVB2NiAoREhDUHY2KS4gIEFueSBhZGRyZXNzZXMvcHJl
Zml4ZXMgb2J0YWluZWQgdmlhIERIQ1B2NiBhcmUKICAgZGlzdGluY3QgZnJvbSBhbnkgSVB2NiBw
cmVmaXhlcyBhc3NpZ25lZCB0byB0aGUgSVNBVEFQIGludGVyZmFjZSBmb3IKICAgU0xBQUMgcHVy
cG9zZXMsIGhvd2V2ZXIuICBJbiB0aGlzIHdheSwgREhDUHY2IGFkZHJlc3Nlcy9wcmVmaXhlcyBh
cmUKICAgcmVhY2hlZCBieSB2aWV3aW5nIHRoZSBJU0FUQVAgdHVubmVsIGludGVyZmFjZSBhcyBh
ICJ0cmFuc2l0IiByYXRoZXIKICAgdGhhbiB2aWV3aW5nIGl0IGFzIGFuIG9yZGluYXJ5IElQdjYg
aG9zdCBpbnRlcmZhY2UuCgogICBJU0FUQVAgbm9kZXMgZW1wbG95IHRoZSBzb3VyY2UgYWRkcmVz
cyB2ZXJpZmljYXRpb24gY2hlY2tzIHNwZWNpZmllZAogICBpbiBTZWN0aW9uIDcuMyBvZiBbUkZD
NTIxNF0gYXMgYSBwcmVyZXF1aXNpdGUgZm9yIGRlY2Fwc3VsYXRpb24gb2YKICAgcGFja2V0cyBy
ZWNlaXZlZCBvbiBhbiBJU0FUQVAgaW50ZXJmYWNlLiAgSW4gb3JkZXIgdG8gYWNjb21tb2RhdGUK
ICAgZGlyZWN0IGNvbW11bmljYXRpb25zIHdpdGggaG9zdHMgYW5kIG5vbi1hZHZlcnRpc2luZyBJ
U0FUQVAgcm91dGVycwogICB0aGF0IHVzZSBESENQdjYsIElTQVRBUCBub2RlcyB0aGF0IHN1cHBv
cnQgcm91dGUgb3B0aW1pemF0aW9uIG11c3QKICAgZW1wbG95IGFuIGFkZGl0aW9uYWwgc291cmNl
IGFkZHJlc3MgdmVyaWZpY2F0aW9uIGNoZWNrLiAgTmFtZWx5LCB0aGUKICAgbm9kZSBhbHNvIGNv
bnNpZGVycyB0aGUgb3V0ZXIgSVB2NCBzb3VyY2UgYWRkcmVzcyBjb3JyZWN0IGZvciB0aGUKICAg
aW5uZXIgSVB2NiBzb3VyY2UgYWRkcmVzcyBpZjoKCiAgIG8gIGEgZm9yd2FyZGluZyB0YWJsZSBl
bnRyeSBleGlzdHMgdGhhdCBsaXN0cyB0aGUgcGFja2V0J3MgSVB2NAogICAgICBzb3VyY2UgYWRk
cmVzcyBhcyB0aGUgbGluay1sYXllciBhZGRyZXNzIGNvcnJlc3BvbmRpbmcgdG8gdGhlCiAgICAg
IGlubmVyIElQdjYgc291cmNlIGFkZHJlc3MgdmlhIHRoZSBJU0FUQVAgaW50ZXJmYWNlLgoKICAg
VGhlIGZvbGxvd2luZyBzZWN0aW9ucyBkaXNjdXNzIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25z
IGZvcgogICBlbmFibGluZyBJU0FUQVAgREhDUHY2IHNlcnZpY2VzIHdpdGhpbiBwcmVkb21pbmFu
dGx5IElQdjQgc2l0ZXMuCgo0LjEuICBJU0FUQVAgUm91dGVyIEJlaGF2aW9yCgogICBBZHZlcnRp
c2luZyBJU0FUQVAgcm91dGVycyB0aGF0IHN1cHBvcnQgREhDUHY2IHNlcnZpY2VzIHNlbmQgUkEK
ICAgbWVzc2FnZXMgaW4gcmVzcG9uc2UgdG8gUlMgbWVzc2FnZXMgcmVjZWl2ZWQgb24gYW4gYWR2
ZXJ0aXNpbmcgSVNBVEFQCiAgIGludGVyZmFjZS4gIEFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXJz
IGFsc28gY29uZmlndXJlIGVpdGhlciBhIERIQ1B2NgogICByZWxheSBvciBzZXJ2ZXIgZnVuY3Rp
b24gdG8gc2VydmljZSBESENQdjYgcmVxdWVzdHMgcmVjZWl2ZWQgZnJvbQogICA8c3RyaWtlPjxm
b250IGNvbG9yPSdyZWQnID5vdGhlcjwvZm9udD48L3N0cmlrZT4KICAgSVNBVEFQIDxzdHJpa2U+
PGZvbnQgY29sb3I9J3JlZCcgPm5vZGVzLjwvZm9udD48L3N0cmlrZT4gPHN0cm9uZz48Zm9udCBj
b2xvcj0nZ3JlZW4nID5jbGllbnRzLjwvZm9udD48L3N0cm9uZz4KCiAgIEluIG1hbnkgdXNlIGNh
c2Ugc2NlbmFyaW9zIChlLmcuLCBzbWFsbCBlbnRlcnByaXNlIG5ldHdvcmtzLCBNQU5FVHMsCiAg
IGV0Yy4pLCBhZHZlcnRpc2luZyBhbmQgbm9uLWFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXJzIGNh
biBlbmdhZ2UgaW4gYQogICBwcm9hY3RpdmUgZHluYW1pYyBJUHY2IHJvdXRpbmcgcHJvdG9jb2wg
KGUuZy4sIE9TUEZ2MywgUklQbmcsIGV0Yy4pCiAgIG92ZXIgdGhlaXIgSVNBVEFQIGludGVyZmFj
ZXMgc28gdGhhdCBJUHY2IHJvdXRpbmcvZm9yd2FyZGluZyB0YWJsZXMKICAgY2FuIGJlIHBvcHVs
YXRlZCBhbmQgc3RhbmRhcmQgSVB2NiBmb3J3YXJkaW5nIGJldHdlZW4gSVNBVEFQIHJvdXRlcnMK
ICAgY2FuIGJlIHVzZWQuICBJbiBvdGhlciBzY2VuYXJpb3MgKGUuZy4sIGxhcmdlIGVudGVycHJp
c2UgbmV0d29ya3MsCiAgIGhpZ2hseSBtb2JpbGUgTUFORVRzLCBldGMuKSwgdGhpcyBtaWdodCBi
ZSBpbXByYWN0aWNhbCBkdWVzIHRvCiAgIHNjYWxpbmcgaXNzdWVzLiAgV2hlbiBhIHByb2FjdGl2
ZSBkeW5hbWljIHJvdXRpbmcgcHJvdG9jb2wgY2Fubm90IGJlCiAgIHVzZWQsIG5vbi1hZHZlcnRp
c2luZyBJU0FUQVAgcm91dGVycyBzZW5kIFJTIG1lc3NhZ2VzIHRvIG9idGFpbiBSQQogICBtZXNz
YWdlcyBmcm9tIGFuIGFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXIsIGkuZS4sIHRoZXkgYWN0IGFz
ICJob3N0cyIKICAgb24gdGhlaXIgbm9uLWFkdmVydGlzaW5nIElTQVRBUCBpbnRlcmZhY2VzLgoK
ICAgTm9uLWFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXJzIGNhbiBhbHNvIGFjcXVpcmUgSVB2NiBw
cmVmaXhlcywgZS5nLiwKICAgdGhyb3VnaCB0aGUgdXNlIG9mIERIQ1B2NiBQcmVmaXggRGVsZWdh
dGlvbiBbUkZDMzYzM10gdmlhIGFuCiAgIGFkdmVydGlzaW5nIHJvdXRlciBpbiB0aGUgc2FtZSBm
YXNoaW9uIGFzIGRlc2NyaWJlZCBmb3IgaG9zdC1iYXNlZAogICBESENQdjYgc3RhdGVmdWwgYWRk
cmVzcyBhdXRvY29uZmlndXJhdGlvbiBpbiBTZWN0aW9uIDQuMi4gIFRoZQogICBhZHZlcnRpc2lu
ZyByb3V0ZXIgaW4gdHVybiBtYWludGFpbnMgSVB2NiBmb3J3YXJkaW5nIHRhYmxlIGVudHJpZXMK
ICAgdGhhdCBsaXN0IHRoZSBJUHY0IGFkZHJlc3Mgb2YgdGhlIG5vbi1hZHZlcnRpc2luZyByb3V0
ZXIgYXMgdGhlIGxpbmstCiAgIGxheWVyIGFkZHJlc3Mgb2YgdGhlIG5leHQgaG9wIHRvd2FyZCB0
aGUgZGVsZWdhdGVkIElQdjYgcHJlZml4ZXMuCgogICBBZnRlciB0aGUgbm9uLWFkdmVydGlzaW5n
IElTQVRBUCByb3V0ZXIgYWNxdWlyZXMgSVB2NiBwcmVmaXhlcywgaXQKICAgY2FuIHN1Yi1kZWxl
Z2F0ZSB0aGVtIHRvIHJvdXRlcnMgYW5kIGxpbmtzIHdpdGhpbiBpdHMgYXR0YWNoZWQgSVB2Ngog
ICBlZGdlIG5ldHdvcmtzLCB0aGVuIGNhbiBmb3J3YXJkIGFueSBvdXRib3VuZCBJUHY2IHBhY2tl
dHMgY29taW5nIGZyb20KICAgaXRzIGVkZ2UgbmV0d29ya3MgdmlhIG90aGVyIElTQVRBUCBub2Rl
cyBvbiB0aGUgbGluay4KCjQuMi4gIElTQVRBUCBIb3N0IEJlaGF2aW9yCgogICBJU0FUQVAgaG9z
dHMgcmVzb2x2ZSB0aGUgUFJMIGFuZCBzZW5kIFJTIG1lc3NhZ2VzIHRvIG9idGFpbiBSQQogICBt
ZXNzYWdlcyBmcm9tIGFuIGFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXIuICBXaGV0aGVyIG9yIG5v
dCBJUHY2CiAgIHByZWZpeGVzIGZvciBTTEFBQyBhcmUgYWR2ZXJ0aXNlZCwgdGhlIGhvc3QgY2Fu
IGFjcXVpcmUgSVB2NgogICBhZGRyZXNzZXMsIGUuZy4sIHRocm91Z2ggdGhlIHVzZSBvZiBESENQ
djYgc3RhdGVmdWwgYWRkcmVzcwogICBhdXRvY29uZmlndXJhdGlvbiBbUkZDMzMxNV0uICBUbyBh
Y3F1aXJlIGFkZHJlc3NlcywgdGhlIGhvc3QgcGVyZm9ybXMKICAgc3RhbmRhcmQgREhDUHY2IGV4
Y2hhbmdlcyB3aGlsZSBtYXBwaW5nIHRoZSBJUHY2CiAgICJBbGxfREhDUF9SZWxheV9BZ2VudHNf
YW5kX1NlcnZlcnMiIGxpbmstc2NvcGVkIG11bHRpY2FzdCBhZGRyZXNzIHRvCiAgIHRoZSBJUHY0
IGFkZHJlc3Mgb2YgYW4gYWR2ZXJ0aXNpbmcgSVNBVEFQIHJvdXRlci4KCiAgIEFmdGVyIHRoZSBo
b3N0IHJlY2VpdmVzIElQdjYgYWRkcmVzc2VzLCBpdCBhc3NpZ25zIHRoZW0gdG8gaXRzIElTQVRB
UAogICBpbnRlcmZhY2UgYW5kIGZvcndhcmRzIGFueSBvZiBpdHMgb3V0Ym91bmQgSVB2NiBwYWNr
ZXRzIHZpYSB0aGUKICAgYWR2ZXJ0aXNpbmcgcm91dGVyIGFzIGEgZGVmYXVsdCByb3V0ZXIuICBU
aGUgYWR2ZXJ0aXNpbmcgcm91dGVyIGluCiAgIHR1cm4gbWFpbnRhaW5zIElQdjYgZm9yd2FyZGlu
ZyB0YWJsZSBlbnRyaWVzIHRoYXQgbGlzdCB0aGUgSVB2NAogICBhZGRyZXNzIG9mIHRoZSBob3N0
IGFzIHRoZSBsaW5rLWxheWVyIGFkZHJlc3Mgb2YgdGhlIGRlbGVnYXRlZCBJUHY2CiAgIGFkZHJl
c3Nlcy4KCjQuMy4gIFJlZmVyZW5jZSBPcGVyYXRpb25hbCBTY2VuYXJpbwoKICAgRmlndXJlIDIg
ZGVwaWN0cyBhIHJlZmVyZW5jZSBJU0FUQVAgbmV0d29yayB0b3BvbG9neSB0aGF0IHVzZXMKICAg
REhDUHY2LiAgVGhlIHNjZW5hcmlvIHNob3dzIHR3byBhZHZlcnRpc2luZyBJU0FUQVAgcm91dGVy
cyAoJ0EnLAogICAnQicpLCB0d28gbm9uLWFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXJzICgnQycs
ICdFJyksIGFuIElTQVRBUCBob3N0CiAgICgnRycpLCBhbmQgdGhyZWUgb3JkaW5hcnkgSVB2NiBo
b3N0cyAoJ0QnLCAnRicsICdIJykgaW4gYSB0eXBpY2FsCiAgIGRlcGxveW1lbnQgY29uZmlndXJh
dGlvbjoKCiAgICAgICAgICAgICAgICAgICAgLi0oOjo6Ojo6OjopICAgICAgMjAwMTpkYjg6Mzo6
MQogICAgICAgICAgICAgICAgIC4tKDo6OiBJUHY2IDo6OiktLiAgKy0tLS0tLS0tLS0tLS0rCiAg
ICAgICAgICAgICAgICAoOjo6OiBJbnRlcm5ldCA6Ojo6KSB8IElQdjYgSG9zdCBIIHwKICAgICAg
ICAgICAgICAgICBgLSg6Ojo6Ojo6Ojo6OjopLScgICstLS0tLS0tLS0tLS0tKwogICAgICAgICAg
ICAgICAgICAgIGAtKDo6Ojo6OiktJwogICAgICAgICAgICAgICAgLH5+fn5+fn5+fn5+fn5+fn5+
LAogICAgICAgICAgICwtLS0tfGNvbXBhbmlvbiBnYXRld2F5fC0tLgogICAgICAgICAgLyAgICAg
J35+fn5+fn5+fn5+fn5+fn5+JyAgOgogICAgICAgICAvICAgICAgICAgICAgICAgICAgICAgICAg
ICAgfC4KICAgICAgLC0nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYC4KICAgICA7ICAr
LS0tLS0tLS0tLS0tKyAgICstLS0tLS0tLS0tLS0rICApCiAgICAgOiAgfCAgUm91dGVyIEEgIHwg
ICB8ICBSb3V0ZXIgQiAgfCAgLyAgICBmZTgwOjoqMTo5Mi4wLjIuNQogICAgICA6IHwgIChpc2F0
YXApICB8ICAgfCAgKGlzYXRhcCkgIHwgOyAgICAgICAyMDAxOmRiODoyOjoxCiAgICAgICsgKy0t
LS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLS0tKyAgXCAgICArLS0tLS0tLS0tLS0tLS0rCiAgICAg
ZmU4MDo6KjoxOTIuMC4yLjEgICBmZTgwOjoqOjE5Mi4wLjIuMiAgICB8ICAgKGlzYXRhcCkgICB8
CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyAgICB8ICAgIEhvc3Qg
RyAgICB8CiAgICAgOiAgICAgICAgICAgICAgSVB2NCBTaXRlICAgICAgICAgLSstJyAgICArLS0t
LS0tLS0tLS0tLS0rCiAgICAgIGAtLiAoUFJMOiAxOTIuMC4yLjEsIDE5Mi4wLjIuMikgIC4pCiAg
ICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICBfKQogICAgICAgICAgYC0tLS0tKy0t
LS0tLS0tKS0tLS0rJy0tLS0nCiAgICAgZmU4MDo6KjoxOTIuMC4yLjMgICAgICAgIGZlODA6Oio6
MTkyLjAuMi40ICAgICAgICAgLi0uCiAgICAgKy0tLS0tLS0tLS0tLS0tKyAgICAgICAgICstLS0t
LS0tLS0tLS0tLSsgICAgICAgLC0oICBfKS0uCiAgICAgfCAgIChpc2F0YXApICAgfCAgICAgICAg
IHwgICAoaXNhdGFwKSAgIHwgICAgLi0oXyBJUHY2ICApLS4KICAgICB8ICAgUm91dGVyIEMgICB8
ICAgICAgICAgfCAgIFJvdXRlciBFICAgfC0tKF9fRWRnZSBOZXR3b3JrICkKICAgICArLS0tLS0t
LS0tLS0tLS0rICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKyAgICAgYC0oX19fX19fKS0nCiAgICAg
IDIwMDE6ZGI4OjA6Oi80OCAgICAgICAgICAyMDAxOmRiODoxOjovNDggICAgICAgICAgIHwKICAg
ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjAwMTpkYjg6
MTo6MQogICAgICAgICAgICAuLS4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICst
LS0tLS0tLS0tLS0tKwogICAgICAgICAsLSggIF8pLS4gICAgICAgMjAwMTpkYjg6OjEgICAgICAg
ICAgICAgIHwgSVB2NiBIb3N0IEYgfAogICAgICAuLShfIElQdjYgICktLiAgICstLS0tLS0tLS0t
LS0tKyAgICAgICAgICAgICstLS0tLS0tLS0tLS0tKwogICAgKF9fRWRnZSBOZXR3b3JrICktLXwg
SVB2NiBIb3N0IEQgfAogICAgICAgYC0oX19fX19fKS0nICAgICstLS0tLS0tLS0tLS0tKwoKICAg
KCogPT0gIjVlZmUiKQoKICAgICAgICAgRmlndXJlIDI6IFJlZmVyZW5jZSBJU0FUQVAgTmV0d29y
ayBUb3BvbG9neSB1c2luZyBESENQdjYKCiAgIEluIEZpZ3VyZSAyLCBhZHZlcnRpc2luZyBJU0FU
QVAgcm91dGVycyAnQScgYW5kICdCJyB3aXRoaW4gdGhlIElQdjQKICAgc2l0ZSBjb25uZWN0IHRv
IHRoZSBJUHY2IEludGVybmV0IHZpYSBhIGNvbXBhbmlvbiBnYXRld2F5LiAgKE5vdGUKICAgdGhh
dCB0aGUgcm91dGVycyBtYXkgaW5zdGVhZCBjb25uZWN0IHRvIHRoZSBJUHY2IEludGVybmV0IGRp
cmVjdGx5IGFzCiAgIHNob3duIGluIEZpZ3VyZSAxLikgIEFkdmVydGlzaW5nIElTQVRBUCByb3V0
ZXIgJ0EnIGNvbmZpZ3VyZXMgYQogICBwcm92aWRlciBuZXR3b3JrIElQdjQgaW50ZXJmYWNlIHdp
dGggYWRkcmVzcyAxOTIuMC4yLjEgYW5kIGFycmFuZ2VzCiAgIHRvIGFkZCB0aGUgYWRkcmVzcyB0
byB0aGUgcHJvdmlkZXIgbmV0d29yayBQUkwuICAnQScgbmV4dCBjb25maWd1cmVzCiAgIGFuIGFk
dmVydGlzaW5nIElTQVRBUCByb3V0ZXIgaW50ZXJmYWNlIHdpdGggbGluay1sb2NhbCBJUHY2IGFk
ZHJlc3MKICAgZmU4MDo6NWVmZToxOTIuMC4yLjEgb3ZlciB0aGUgSVB2NCBpbnRlcmZhY2UuICBJ
biB0aGUgc2FtZSBmYXNoaW9uLAogICBhZHZlcnRpc2luZyBJU0FUQVAgcm91dGVyICdCJyBjb25m
aWd1cmVzIHRoZSBJUHY0IGludGVyZmFjZSBhZGRyZXNzCiAgIDE5Mi4wLjIuMiwgYWRkcyB0aGUg
YWRkcmVzcyB0byB0aGUgUFJMLCB0aGVuIGNvbmZpZ3VyZXMgdGhlIElQdjYKICAgSVNBVEFQIGlu
dGVyZmFjZSBsaW5rLWxvY2FsIGFkZHJlc3MgZmU4MDo6NWVmZToxOTIuMC4yLjIuCgogICBOb24t
YWR2ZXJ0aXNpbmcgSVNBVEFQIHJvdXRlciAnQycgY29ubmVjdHMgdG8gb25lIG9yIG1vcmUgSVB2
NiBlZGdlCiAgIG5ldHdvcmtzIGFuZCBhbHNvIGNvbm5lY3RzIHRvIHRoZSBzaXRlIHZpYSBhbiBJ
UHY0IGludGVyZmFjZSB3aXRoCiAgIGFkZHJlc3MgMTkyLjAuMi4zLCBidXQgaXQgZG9lcyBub3Qg
YWRkIHRoZSBJUHY0IGFkZHJlc3MgdG8gdGhlIHNpdGUncwogICBQUkwuICAnQycgbmV4dCBjb25m
aWd1cmVzIGEgbm9uLWFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXIgaW50ZXJmYWNlCiAgIHdpdGgg
bGluay1sb2NhbCBhZGRyZXNzIGZlODA6OjVlZmU6MTkyLjAuMi4zLCB0aGVuIHJlY2VpdmVzIHRo
ZSBJUHY2CiAgIHByZWZpeCAyMDAxOmRiODo6LzQ4IHRocm91Z2ggYSBESENQdjYgcHJlZml4IGRl
bGVnYXRpb24gZXhjaGFuZ2UgdmlhCiAgIG9uZSBvZiAnQScgb3IgJ0InLiAgJ0MnIHRoZW4gZW5n
YWdlcyBpbiBhbiBJUHY2IHJvdXRpbmcgcHJvdG9jb2wgb3ZlcgogICBpdHMgSVNBVEFQIGludGVy
ZmFjZSBhbmQgYW5ub3VuY2VzIHRoZSBkZWxlZ2F0ZWQgSVB2NiBwcmVmaXguICAnQycKICAgZmlu
YWxseSBzdWItZGVsZWdhdGVzIHRoZSBwcmVmaXggdG8gaXRzIGF0dGFjaGVkIGVkZ2UgbmV0d29y
a3MsIHdoZXJlCiAgIElQdjYgaG9zdCAnRCcgYXV0b2NvbmZpZ3VyZXMgdGhlIGFkZHJlc3MgMjAw
MTpkYjg6OjEuCgogICBOb24tYWR2ZXJ0aXNpbmcgSVNBVEFQIHJvdXRlciAnRScgY29ubmVjdHMg
dG8gdGhlIHNpdGUsIGNvbmZpZ3VyZXMKICAgaXRzIElTQVRBUCBpbnRlcmZhY2UsIHJlY2VpdmVz
IGEgREhDUHY2IHByZWZpeCBkZWxlZ2F0aW9uLCBhbmQKICAgZW5nYWdlcyBpbiB0aGUgSVB2NiBy
b3V0aW5nIHByb3RvY29sIHRoZSBzYW1lIGFzIGZvciAnQycuICBJbgogICBwYXJ0aWN1bGFyLCAn
RScgY29uZmlndXJlcyB0aGUgSVB2NCBhZGRyZXNzIDE5Mi4wLjIuNCwgdGhlIElTQVRBUAogICBs
aW5rLWxvY2FsIGFkZHJlc3MgZmU4MDo6NWVmZToxOTIuMC4yLjQsIGFuZCB0aGUgZGVsZWdhdGVk
IElQdjYKICAgcHJlZml4IDIwMDE6ZGI4OjE6Oi80OC4gICdFJyBmaW5hbGx5IHN1Yi1kZWxlZ2F0
ZXMgdGhlIHByZWZpeCB0byBpdHMKICAgYXR0YWNoZWQgZWRnZSBuZXR3b3Jrcywgd2hlcmUgSVB2
NiBob3N0ICdGJyBhdXRvY29uZmlndXJlcyBJUHY2CiAgIGFkZHJlc3MgMjAwMTpkYjg6MTo6MS4K
CiAgIElTQVRBUCBob3N0ICdHJyBjb25uZWN0cyB0byB0aGUgc2l0ZSB2aWEgYW4gSVB2NCBpbnRl
cmZhY2Ugd2l0aAogICBhZGRyZXNzIDE5Mi4wLjIuNSwgYW5kIGFsc28gY29uZmlndXJlcyBhbiBJ
U0FUQVAgaG9zdCBpbnRlcmZhY2Ugd2l0aAogICBsaW5rLWxvY2FsIGFkZHJlc3MgZmU4MDo6NWVm
ZToxOTIuMC4yLjUgb3ZlciB0aGUgSVB2NCBpbnRlcmZhY2UuICAnRycKICAgbmV4dCBwZXJmb3Jt
cyBhbiBSUy9SQSBleGNoYW5nZSB3aXRoICdCJyB0byBjb25maWd1cmUgZGVmYXVsdCBJUHY2CiAg
IHJvdXRlIHdpdGggbmV4dC1ob3AgYWRkcmVzcyBmZTgwOjo1ZWZlOjE5Mi4wLjIuMiwgdGhlbiBy
ZWNlaXZlcyB0aGUKICAgSVB2NiBhZGRyZXNzIDIwMDE6ZGI4OjI6OjEgZnJvbSBhIERIQ1B2NiBh
ZGRyZXNzIGNvbmZpZ3VyYXRpb24KICAgZXhjaGFuZ2UgdmlhICdCJy4gIFdoZW4gJ0cnIHJlY2Vp
dmVzIHRoZSBJUHY2IGFkZHJlc3MsIGl0IGFzc2lnbnMgdGhlCiAgIGFkZHJlc3MgdG8gdGhlIElT
QVRBUCBpbnRlcmZhY2UgYnV0IGRvZXMgbm90IGFzc2lnbiBhIG5vbi1saW5rLWxvY2FsCiAgIElQ
djYgcHJlZml4IHRvIHRoZSBpbnRlcmZhY2UuCgogICBGaW5hbGx5LCBJUHY2IGhvc3QgJ0gnIGNv
bm5lY3RzIHRvIGFuIElQdjYgbmV0d29yayBvdXRzaWRlIG9mIHRoZQogICBJU0FUQVAgZG9tYWlu
LiAgJ0gnIGNvbmZpZ3VyZXMgaXRzIElQdjYgaW50ZXJmYWNlIGluIGEgbWFubmVyCiAgIHNwZWNp
ZmljIHRvIGl0cyBhdHRhY2hlZCBJUHY2IGxpbmssIGFuZCBhdXRvY29uZmlndXJlcyB0aGUgSVB2
NgogICBhZGRyZXNzIDIwMDE6ZGI4OjM6OjEuCgogICBGb2xsb3dpbmcgdGhpcyBhdXRvY29uZmln
dXJhdGlvbiwgd2hlbiBob3N0ICdEJyBoYXMgYW4gSVB2NiBwYWNrZXQgdG8KICAgc2VuZCB0byBo
b3N0ICdGJywgaXQgcHJlcGFyZXMgdGhlIHBhY2tldCB3aXRoIHNvdXJjZSBhZGRyZXNzIDIwMDE6
CiAgIGRiODo6MSBhbmQgZGVzdGluYXRpb24gYWRkcmVzcyAyMDAxOmRiODoxOjoxLCB0aGVuIHNl
bmRzIHRoZSBwYWNrZXQKICAgaW50byB0aGUgZWRnZSBuZXR3b3JrIHdoZXJlIElQdjYgZm9yd2Fy
ZGluZyB3aWxsIGV2ZW50dWFsbHkgY29udmV5IGl0CiAgIHRvIHJvdXRlciAnQycuICAnQycgdGhl
biB1c2VzIElQdjYtaW4tSVB2NCBlbmNhcHN1bGF0aW9uIHRvIGZvcndhcmQKICAgdGhlIHBhY2tl
dCB0byByb3V0ZXIgJ0UnLCBzaW5jZSBpdCBoYXMgZGlzY292ZXJlZCBhIHJvdXRlIHRvIDIwMDE6
CiAgIGRiODoxOjovNDggd2l0aCBuZXh0IGhvcCAnRScgdmlhIGR5bmFtaWMgcm91dGluZyBvdmVy
IHRoZSBJU0FUQVAKICAgaW50ZXJmYWNlLiAgUm91dGVyICdFJyBmaW5hbGx5IHNlbmRzIHRoZSBw
YWNrZXQgaW50byB0aGUgZWRnZSBuZXR3b3JrCiAgIHdoZXJlIElQdjYgZm9yd2FyZGluZyB3aWxs
IGV2ZW50dWFsbHkgY29udmV5IGl0IHRvIGhvc3QgJ0YnLgoKICAgSW4gYSBzZWNvbmQgc2NlbmFy
aW8sIHdoZW4gJ0QnIGhhcyBhIHBhY2tldCB0byBzZW5kIHRvIElTQVRBUCBob3N0CiAgICdHJywg
aXQgcHJlcGFyZXMgdGhlIHBhY2tldCB3aXRoIHNvdXJjZSBhZGRyZXNzIDIwMDE6ZGI4OjoxIGFu
ZAogICBkZXN0aW5hdGlvbiBhZGRyZXNzIDIwMDE6ZGI4OjI6OjEsIHRoZW4gc2VuZHMgdGhlIHBh
Y2tldCBpbnRvIHRoZQogICBlZGdlIG5ldHdvcmsgd2hlcmUgaXQgd2lsbCBldmVudHVhbGx5IGJl
IGZvcndhcmRlZCB0byByb3V0ZXIgJ0MnIHRoZQogICBzYW1lIGFzIGFib3ZlLiAgJ0MnIHRoZW4g
dXNlcyBJUHY2LWluLUlQdjQgZW5jYXBzdWxhdGlvbiB0byBmb3J3YXJkCiAgIHRoZSBwYWNrZXQg
dG8gcm91dGVyICdBJyAoaS5lLiwgYSByb3V0ZXIgdGhhdCBhZHZlcnRpc2VzICJkZWZhdWx0Iiks
CiAgIHdoaWNoIGluIHR1cm4gZm9yd2FyZHMgdGhlIHBhY2tldCB0byAnRycuICBOb3RlIHRoYXQg
dGhpcyBvcGVyYXRpb24KICAgZW50YWlscyB0d28gaG9wcyBhY3Jvc3MgdGhlIElTQVRBUCBsaW5r
IChpLmUuLCBvbmUgZnJvbSAnQycgdG8gJ0EnLAogICBhbmQgYSBzZWNvbmQgZnJvbSAnQScgdG8g
J0cnKS4gIElmICdHJyBhbHNvIHBhcnRpY2lwYXRlcyBpbiB0aGUKICAgZHluYW1pYyBJUHY2IHJv
dXRpbmcgcHJvdG9jb2wsIGhvd2V2ZXIsICdDJyBjb3VsZCBpbnN0ZWFkIGZvcndhcmQgdGhlCiAg
IHBhY2tldCBkaXJlY3RseSB0byAnRycgd2l0aG91dCBpbnZvbHZpbmcgJ0EnLgoKICAgSW4gYSB0
aGlyZCBzY2VuYXJpbywgd2hlbiAnRCcgaGFzIGEgcGFja2V0IHRvIHNlbmQgdG8gaG9zdCAnSCcg
aW4gdGhlCiAgIElQdjYgSW50ZXJuZXQsIHRoZSBwYWNrZXQgaXMgZm9yd2FyZGVkIHRvICdDJyB0
aGUgc2FtZSBhcyBhYm92ZS4gICdDJwogICB0aGVuIGZvcndhcmRzIHRoZSBwYWNrZXQgdG8gJ0En
LCB3aGljaCBmb3J3YXJkcyB0aGUgcGFja2V0IGludG8gdGhlCiAgIElQdjYgSW50ZXJuZXQuCgog
ICBJbiBhIGZpbmFsIHNjZW5hcmlvLCB3aGVuICdHJyBoYXMgYSBwYWNrZXQgdG8gc2VuZCB0byBo
b3N0ICdIJyBpbiB0aGUKICAgSVB2NiBJbnRlcm5ldCwgdGhlIHBhY2tldCBpcyBmb3J3YXJkZWQg
ZGlyZWN0bHkgdG8gJ0InLCB3aGljaAogICBmb3J3YXJkcyB0aGUgcGFja2V0IGludG8gdGhlIElQ
djYgSW50ZXJuZXQuCgo0LjQuICBMb29wIEF2b2lkYW5jZQoKICAgSW4gYSBwdXJlbHkgREhDUHY2
LWJhc2VkIElTQVRBUCBkZXBsb3ltZW50LCBubyBub24tbGluay1sb2NhbCBJUHY2CiAgIHByZWZp
eGVzIGFyZSBhc3NpZ25lZCB0byBJU0FUQVAgcm91dGVyIGludGVyZmFjZXMuICBUaGVyZWZvcmUs
IGFuCiAgIElTQVRBUCByb3V0ZXIgY2Fubm90IG1pc3Rha2UgYW5vdGhlciByb3V0ZXIgZm9yIGFu
IElTQVRBUCBob3N0IGR1ZSB0bwogICBhbiBhZGRyZXNzIHRoYXQgbWF0Y2hlcyBhbiBvbi1saW5r
IHByZWZpeC4gIFRoaXMgY29ycmVzcG9uZHMgdG8gdGhlCiAgIG1pdGlnYXRpb24gZG9jdW1lbnRl
ZCBpbiBTZWN0aW9uIDMuMi40IG9mCiAgIFtJLUQuaWV0Zi12Nm9wcy10dW5uZWwtbG9vcHNdLgoK
ICAgQW55IHJvdXRpbmcgbG9vcHMgaW50cm9kdWNlZCBpbiB0aGUgREhDUHY2IHNjZW5hcmlvIHdv
dWxkIHRoZXJlZm9yZQogICBiZSBkdWUgdG8gYSBtaXNjb25maWd1cmF0aW9uIGluIElQdjYgcm91
dGluZyB0aGUgc2FtZSBhcyBmb3IgYW55IElQdjYKICAgcm91dGVyLCBhbmQgaGVuY2UgYXJlIG91
dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVudC4KCjUuICBTY2FsaW5nIENvbnNpZGVyYXRpb25z
CgogICBGaWd1cmUgMSBhbmQgRmlndXJlIDIgZGVwaWN0IElTQVRBUCBuZXR3b3JrIHRvcG9sb2dp
ZXMgd2l0aCBvbmx5IHR3bwogICBhZHZlcnRpc2luZyBJU0FUQVAgcm91dGVycyB3aXRoaW4gdGhl
IHNpdGUuICBJbiBvcmRlciB0byBzdXBwb3J0CiAgIGxhcmdlciBudW1iZXJzIG9mIElTQVRBUCA8
c3RyaWtlPjxmb250IGNvbG9yPSdyZWQnID5ub2Rlcyw8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+
PGZvbnQgY29sb3I9J2dyZWVuJyA+Y2xpZW50cyw8L2ZvbnQ+PC9zdHJvbmc+IHRoZSBzaXRlIGNh
biBkZXBsb3kgbW9yZQogICBhZHZlcnRpc2luZyBJU0FUQVAgcm91dGVycyB0byBzdXBwb3J0IGxv
YWQgYmFsYW5jaW5nIGFuZCBnZW5lcmFsbHkKICAgc2hvcnRlc3QtcGF0aCByb3V0aW5nLgoKICAg
U3VjaCBhbiBhcnJhbmdlbWVudCByZXF1aXJlcyB0aGF0IHRoZSBhZHZlcnRpc2luZyBJU0FUQVAg
cm91dGVycwogICBwYXJ0aWNpcGF0ZSBpbiBhbiBJUHY2IHJvdXRpbmcgcHJvdG9jb2wgaW5zdGFu
Y2Ugc28gdGhhdCBJUHY2CiAgIGFkZHJlc3Nlcy9wcmVmaXhlcyBjYW4gYmUgbWFwcGVkIHRvIHRo
ZSBjb3JyZWN0IElTQVRBUCByb3V0ZXIuICBUaGUKICAgcm91dGluZyBwcm90b2NvbCBpbnN0YW5j
ZSBjYW4gYmUgY29uZmlndXJlZCBhcyBlaXRoZXIgYSBmdWxsIG1lc2gKICAgdG9wb2xvZ3kgaW52
b2x2aW5nIGFsbCBhZHZlcnRpc2luZyBJU0FUQVAgcm91dGVycywgb3IgYXMgYSBwYXJ0aWFsCiAg
IG1lc2ggdG9wb2xvZ3kgd2l0aCBlYWNoIGFkdmVydGlzaW5nIElTQVRBUCByb3V0ZXIgYXNzb2Np
YXRpbmcgd2l0aAogICBvbmUgb3IgbW9yZSBjb21wYW5pb24gZ2F0ZXdheXMuICBFYWNoIHN1Y2gg
Y29tcGFuaW9uIGdhdGV3YXkgd291bGQgaW4KICAgdHVybiBwYXJ0aWNpcGF0ZSBpbiBhIGZ1bGwg
bWVzaCBiZXR3ZWVuIGFsbCBjb21wYW5pb24gZ2F0ZXdheXMuCgo2LiAgT24tRGVtYW5kIER5bmFt
aWMgUm91dGluZwoKICAgV2l0aCByZXNwZWN0IHRvIHRoZSByZWZlcmVuY2Ugb3BlcmF0aW9uYWwg
c2NlbmFyaW9zIGRlcGljdGVkIGluCiAgIEZpZ3VyZSAyLCB0aGVyZSBtYXkgYmUgdXNlIGNhc2Vz
IGluIHdoaWNoIGEgcHJvYWN0aXZlIGR5bmFtaWMgSVB2NgogICByb3V0aW5nIHByb3RvY29sIGNh
bm5vdCBiZSB1c2VkLiAgRm9yIGV4YW1wbGUsIGluIGxhcmdlIGVudGVycHJpc2UKICAgbmV0d29y
ayBkZXBsb3ltZW50cyBpdCB3b3VsZCBiZSBpbXByYWN0aWNhbCBmb3IgYWxsIElTQVRBUCByb3V0
ZXJzIHRvCiAgIGVuZ2FnZSBpbiBhIGNvbW1vbiByb3V0aW5nIHByb3RvY29sIGluc3RhbmNlIGR1
ZSB0byBzY2FsaW5nCiAgIGNvbnNpZGVyYXRpb25zLgoKICAgSW4gdGhvc2UgY2FzZXMsIGFuIG9u
LWRlbWFuZCByb3V0aW5nIGNhcGFiaWxpdHkgY2FuIGJlIGVuYWJsZWQgaW4KICAgd2hpY2ggSVNB
VEFQIG5vZGVzIHNlbmQgaW5pdGlhbCBwYWNrZXRzIHZpYSBhbiBhZHZlcnRpc2luZyBJU0FUQVAK
ICAgcm91dGVyIGFuZCByZWNlaXZlIHJlZGlyZWN0aW9uIG1lc3NhZ2VzIGJhY2suICBGb3IgZXhh
bXBsZSwgd2hlbiBhCiAgIG5vbi1hZHZlcnRpc2luZyBJU0FUQVAgcm91dGVyICdDJyBoYXMgYSBw
YWNrZXQgdG8gc2VuZCB0byBhIGhvc3QKICAgbG9jYXRlZCBiZWhpbmQgbm9uLWFkdmVydGlzaW5n
IElTQVRBUCByb3V0ZXIgJ0UnLCBpdCBjYW4gc2VuZCB0aGUKICAgaW5pdGlhbCBwYWNrZXRzIHZp
YSBhZHZlcnRpc2luZyByb3V0ZXIgJ0EnIHdoaWNoIHdpbGwgcmV0dXJuCiAgIHJlZGlyZWN0aW9u
IG1lc3NhZ2VzIHRvIGluZm9ybSAnQycgdGhhdCAnRScgaXMgYSBiZXR0ZXIgZmlyc3QgaG9wLgog
ICBQcm90b2NvbCBkZXRhaWxzIGZvciB0aGlzIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPklT
QVRBUDwvZm9udD48L3N0cmlrZT4gcmVkaXJlY3Rpb24gPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3Jl
ZW4nID5wcm9jZWR1cmUgKGluY2x1ZGluZyBhIG1lYW5zCiAgIGZvciBkZXRlY3Rpbmcgd2hldGhl
ciB0aGUgZGlyZWN0IHBhdGggaXMgdXNhYmxlKTwvZm9udD48L3N0cm9uZz4gYXJlIHNwZWNpZmll
ZCBpbgogICBbSS1ELnRlbXBsaW4tYWVyb10uCgo3LiAgU2l0ZSBQYXJ0aXRpb25pbmcgQ29uc2lk
ZXJhdGlvbnMKCiAgIEluIGNvbW1vbiBwcmFjdGljZSwgc2l0ZSBhZG1pbmlzdHJhdG9ycyBvZnRl
biBkZXBsb3kgcGFja2V0IGZpbHRlcmluZwogICBkZXZpY2VzIG9mIHZhcmlvdXMgZm9ybXMgaW4g
b3JkZXIgdG8gZGl2aWRlIHRoZSBzaXRlIGludG8gc2VwYXJhdGUKICAgcGFydGl0aW9ucy4gIFRo
ZXNlIGRldmljZXMgbWF5IHByZXZlbnQgSVB2Ni1pbi1JUHY0IGVuY2Fwc3VsYXRlZAogICBwYWNr
ZXRzIGZyb20gdHJhdmVyc2luZyBwYXJ0aXRpb24gYm91bmRhcmllcy4KCiAgIEluIG9yZGVyIHRv
IGF2b2lkIGNvbW11bmljYXRpb24gZmFpbHVyZXMgdGhhdCBtYXkgcmVzdWx0IGZyb20KICAgZmls
dGVyaW5nLCBJU0FUQVAgY2xpZW50cyAoaS5lLiwgaG9zdHMgYW5kIG5vbi1hZHZlcnRpc2luZyBy
b3V0ZXJzKQogICBzaG91bGQgb25seSBlbmFibGUgdGhlIHNlcnZpY2UgYWZ0ZXIgYW4gaW5pdGlh
bCByZWFjaGFiaWxpdHkgZXhjaGFuZ2UKICAgd2l0aCBhbiBhZHZlcnRpc2luZyBJU0FUQVAgcm91
dGVyIChlLmcuLCBpbiBhbiBpbml0aWFsIFJTL1JBCiAgIGV4Y2hhbmdlKS4gIElTQVRBUCBjbGll
bnQgdG8gY2xpZW50IGNvbW11bmljYXRpb25zIHNob3VsZCB0aGVyZWZvcmUKICAgYWxzbyBvbmx5
IGJlIHVzZWQgd2hlbiB0aGUgcGF0aCBiZXR3ZWVuIHRoZSBjbGllbnRzIGlzIGZpcnN0IHRlc3Rl
ZAogICBpbiBhbiBpbml0aWFsIHJlYWNoYWJpbGl0eSBleGNoYW5nZS4KCjguICBTaXRlIFJlbnVt
YmVyaW5nIENvbnNpZGVyYXRpb25zCgogICBBZHZlcnRpc2luZyBJU0FUQVAgcm91dGVycyBkaXN0
cmlidXRlIElQdjYgcHJlZml4ZXMgdG8gSVNBVEFQIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcg
Pm5vZGVzPC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPmNsaWVu
dHM8L2ZvbnQ+PC9zdHJvbmc+CiAgIHdpdGhpbiB0aGUgc2l0ZSB2aWEgREhDUHY2IGFuZC9vciBT
TEFBQy4gIElmIHRoZSBzaXRlIHN1YnNlcXVlbnRseQogICByZWNvbm5lY3RzIHRvIGEgZGlmZmVy
ZW50IElTUCwgaG93ZXZlciwgdGhlIHNpdGUgbXVzdCByZW51bWJlciB0byB1c2UKICAgYWRkcmVz
c2VzIGRlcml2ZWQgZnJvbSB0aGUgbmV3IElQdjYgcHJlZml4ZXMKICAgW1JGQzE5MDBdW1JGQzQx
OTJdW1JGQzU4ODddLgoKICAgRm9yIGJhc2ljIElQdjYgc2VydmljZXMgcHJvdmlkZWQgYnkgU0xB
QUMsIHNpdGUgcmVudW1iZXJpbmcgaW4gdGhlCiAgIGV2ZW50IG9mIGEgY2hhbmdlIGluIGFuIElT
UC1zZXJ2ZWQgSVB2NiBwcmVmaXggZW50YWlscyBhIHNpbXBsZQogICByZW51bWJlcmluZyBvZiBJ
UHY2IGFkZHJlc3NlcyBhbmQvb3IgcHJlZml4ZXMgdGhhdCBhcmUgYXNzaWduZWQgdG8KICAgdGhl
IElTQVRBUCBpbnRlcmZhY2VzIG9mIGhvc3RzIHdpdGhpbiB0aGUgc2l0ZS4gIEluIHNvbWUgY2Fz
ZXMsCiAgIGZpbHRlcmluZyBydWxlcyAoZS5nLiwgd2l0aGluIHNpdGUgYm9yZGVyIGZpcmV3YWxs
IGZpbHRlcmluZyB0YWJsZXMpCiAgIG1heSBhbHNvIHJlcXVpcmUgcmVudW1iZXJpbmcsIGJ1dCB0
aGlzIG9wZXJhdGlvbiBjYW4gYmUgYXV0b21hdGVkIGFuZAogICBsaW1pdGVkIHRvIG9ubHkgb25l
IG9yIGEgZmV3IGFkbWluaXN0cmF0aXZlICJ0b3VjaCBwb2ludHMiLiAgSW4gb3JkZXIKICAgdG8g
cmVudW1iZXIgdGhlIElTQVRBUCBpbnRlcmZhY2VzIG9mIGhvc3RzIHdpdGhpbiB0aGUgc2l0ZSB1
c2luZwogICBTTEFBQywgYWR2ZXJ0aXNpbmcgSVNBVEFQIHJvdXRlcnMgbmVlZCBvbmx5IHNjaGVk
dWxlIHRoZSBzZXJ2aWNlcwogICBvZmZlcmVkIGJ5IHRoZSBvbGQgSVNQIGZvciBkZXByZWNhdGlv
biB3aGlsZSBiZWdpbm5pbmcgdG8gYWR2ZXJ0aXNlCiAgIHRoZSBJUHY2IHByZWZpeGVzIHByb3Zp
ZGVkIGJ5IHRoZSBuZXcgSVNQLiAgSVNBVEFQIGhvc3QgaW50ZXJmYWNlCiAgIGFkZHJlc3MgbGlm
ZXRpbWVzIHdpbGwgZXZlbnR1YWxseSBleHBpcmUsIGFuZCB0aGUgaG9zdCB3aWxsIHJlbnVtYmVy
CiAgIGl0cyBpbnRlcmZhY2VzIHdpdGggYWRkcmVzc2VzIGRlcml2ZWQgZnJvbSB0aGUgbmV3IHBy
ZWZpeGVzLgoKICAgRm9yIGZ1bGx5LXF1YWxpZmllZCBJUHY2IHNlcnZpY2VzIHByb3ZpZGVkIGJ5
IERIQ1B2Niwgc2l0ZQogICByZW51bWJlcmluZyBpbiB0aGUgZXZlbnQgb2YgYSBjaGFuZ2UgaW4g
YW4gSVNQLXNlcnZlZCBJUHY2IHByZWZpeAogICBmdXJ0aGVyIGVudGFpbHMgbG9jYXRpbmcgYW5k
IHJld3JpdGluZyBhbGwgSVB2NiBhZGRyZXNzZXMgaW4gbmFtaW5nCiAgIHNlcnZpY2VzLCBkYXRh
YmFzZXMsIGNvbmZpZ3VyYXRpb24gZmlsZXMsIHBhY2tldCBmaWx0ZXJpbmcgcnVsZXMsCiAgIGRv
Y3VtZW50YXRpb24sIGV0Yy4gIElmIHRoZSBzaXRlIGhhcyBwdWJsaXNoZWQgdGhlIElQdjYgYWRk
cmVzc2VzIG9mCiAgIGFueSBzaXRlLSBpbnRlcm5hbCBub2RlcyB3aXRoaW4gdGhlIHB1YmxpYyBJ
bnRlcm5ldCBETlMgc3lzdGVtLCB0aGVuCiAgIHRoZSBjb3JyZXNwb25kaW5nIHJlc291cmNlIHJl
Y29yZHMgd2lsbCBhbHNvIG5lZWQgdG8gYmUgdXBkYXRlZAogICBkdXJpbmcgdGhlIHJlbnVtYmVy
aW5nIG9wZXJhdGlvbi4gIFRoaXMgY2FuIGJlIGFjY29tcGxpc2hlZCB2aWEKICAgc2VjdXJlIGR5
bmFtaWMgdXBkYXRlcyB0byB0aGUgRE5TLgoKOS4gIFBhdGggTVRVIENvbnNpZGVyYXRpb25zCgog
ICBJUHY2LWluLUlQdjQgZW5jYXBzdWxhdGlvbiBvdmVyaGVhZCBlZmZlY3RpdmVseSByZWR1Y2Vz
IHRoZSBzaXplIG9mCiAgIElQdjYgcGFja2V0cyB0aGF0IGNhbiB0cmF2ZXJzZSB0aGUgdHVubmVs
IGluIHJlbGF0aW9uIHRvIHRoZSBhY3R1YWwKICAgTWF4aW11bSBUcmFuc21pc3Npb24gVW5pdCAo
TVRVKSBvZiB0aGUgdW5kZXJseWluZyBJUHY0IG5ldHdvcmsgcGF0aAogICBiZXR3ZWVuIHRoZSBl
bmNhcHN1bGF0b3IgYW5kIGRlY2Fwc3VsYXRvci4gIFR3byBtZXRob2RzIGZvcgogICBhY2NvbW1v
ZGF0aW5nIElQdjYgcGF0aCBNVFUgZGlzY292ZXJ5IG92ZXIgSVB2Ni1pbi1JUHY0IHR1bm5lbHMK
ICAgKGkuZS4sIHRoZSBzdGF0aWMgYW5kIGR5bmFtaWMgbWV0aG9kcykgYXJlIGRvY3VtZW50ZWQg
aW4gU2VjdGlvbiAzLjIKICAgb2YgW1JGQzQyMTNdLgoKICAgVGhlIHN0YXRpYyBtZXRob2QgcGxh
Y2VzIGEgInNhZmUiIHVwcGVyIGJvdW5kIG9uIHRoZSBzaXplIG9mIElQdjYKICAgcGFja2V0cyBw
ZXJtaXR0ZWQgdG8gZW50ZXIgdGhlIHR1bm5lbCwgaG93ZXZlciB0aGUgbWV0aG9kIGNhbiBiZQog
ICBvdmVybHkgY29uc2VydmF0aXZlIHdoZW4gbGFyZ2VyIElQdjQgcGF0aCBNVFVzIGFyZSBhdmFp
bGFibGUuICBUaGUKICAgZHluYW1pYyBtZXRob2QgY2FuIGFjY29tbW9kYXRlIG11Y2ggbGFyZ2Vy
IElQdjYgcGFja2V0IHNpemVzIGluIHNvbWUKICAgY2FzZXMsIGJ1dCBjYW4gZmFpbCBzaWxlbnRs
eSBpZiB0aGUgdW5kZXJseWluZyBJUHY0IG5ldHdvcmsgcGF0aCBkb2VzCiAgIG5vdCByZXR1cm4g
dGhlIG5lY2Vzc2FyeSBlcnJvciBtZXNzYWdlcy4KCiAgIFRoaXMgZG9jdW1lbnQgbm90ZXMgdGhh
dCBzaXRlcyB0aGF0IGluY2x1ZGUgd2VsbC1tYW5hZ2VkIElQdjQgbGlua3MsCiAgIHJvdXRlcnMg
YW5kIG90aGVyIG5ldHdvcmsgbWlkZGxlYm94ZXMgYXJlIGNhbmRpZGF0ZXMgZm9yIHVzZSBvZiB0
aGUKICAgZHluYW1pYyBNVFUgZGV0ZXJtaW5hdGlvbiBtZXRob2QsIHdoaWNoIG1heSBwcm92aWRl
IGZvciBhIGJldHRlcgogICBvcGVyYXRpb25hbCBJUHY2IGV4cGVyaWVuY2UgaW4gdGhlIHByZXNl
bmNlIG9mIElQdjYtaW4tSVB2NCB0dW5uZWxzLgoKMTAuICBBbHRlcm5hdGl2ZSBBcHByb2FjaGVz
CgogICBbUkZDNDU1NF0gcHJvcG9zZXMgYSB1c2Ugb2YgVkxBTnMgZm9yIElQdjQtSVB2NiBjb2V4
aXN0ZW5jZSBpbgogICBlbnRlcnByaXNlIG5ldHdvcmtzLiAgVGhlIElTQVRBUCBhcHByb2FjaCBw
cm92aWRlcyBhIG1vcmUgZmxleGlibGUKICAgYW5kIGJyb2FkbHktYXBwbGljYWJsZSBhbHRlcm5h
dGl2ZSwgYW5kIHdpdGggZmV3ZXIgYWRtaW5pc3RyYXRpdmUKICAgdG91Y2ggcG9pbnRzLgoKICAg
VGhlIHR1bm5lbCBicm9rZXIgc2VydmljZSBbUkZDMzA1M10gdXNlcyBwb2ludC10by1wb2ludCB0
dW5uZWxzIHRoYXQKICAgcmVxdWlyZSBlbmQgdXNlcnMgdG8gZXN0YWJsaXNoIGFuIGV4cGxpY2l0
IGFkbWluaXN0cmF0aXZlCiAgIGNvbmZpZ3VyYXRpb24gb2YgdGhlIHR1bm5lbCBmYXIgZW5kLCB3
aGljaCBtYXkgYmUgb3V0c2lkZSBvZiB0aGUKICAgYWRtaW5pc3RyYXRpdmUgYm91bmRhcmllcyBv
ZiB0aGUgc2l0ZS4KCiAgIDZ0bzQgW1JGQzMwNTZdIGFuZCBUZXJlZG8gW1JGQzQzODBdIHByb3Zp
ZGUgImxhc3QgcmVzb3J0IiB1bm1hbmFnZWQKICAgYXV0b21hdGljIHR1bm5lbGluZyBzZXJ2aWNl
cyB3aGVuIG5vIG90aGVyIG1lYW5zIGZvciBJUHY2CiAgIGNvbm5lY3Rpdml0eSBpcyBhdmFpbGFi
bGUuICBUaGVzZSBzZXJ2aWNlcyBhcmUgZ2l2ZW4gbG93ZXIgcHJpb3JpdHkKICAgd2hlbiB0aGUg
SVNBVEFQIG1hbmFnZWQgc2VydmljZSBhbmQvb3IgbmF0aXZlIElQdjYgc2VydmljZXMgYXJlCiAg
IGVuYWJsZWQuCgogICBJUk9OIFtSRkM2MTc5XSwgUkFOR0VSIFtSRkM1NzIwXSwgVkVUIFtSRkM1
NTU4XSBhbmQgU0VBTCBbUkZDNTMyMF0KICAgYXJlIGEgdHJpYnV0ZSB0byB0aG9zZSBpbiBhbGwg
d2Fsa3Mgb2YgbGlmZSB3aG8gc2VydmUgd2l0aCBkaWduaXR5CiAgIGFuZCBob25vciBmb3IgdGhl
IGJlbmVmaXQgb2Ygb3RoZXJzLgoKMTEuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRv
Y3VtZW50IGhhcyBubyBJQU5BIGNvbnNpZGVyYXRpb25zLgoKMTIuICBTZWN1cml0eSBDb25zaWRl
cmF0aW9ucwoKICAgSW4gYWRkaXRpb24gdG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRv
Y3VtZW50ZWQgaW4gW1JGQzUyMTRdLAogICBzaXRlcyB0aGF0IHVzZSBJU0FUQVAgc2hvdWxkIHRh
a2UgY2FyZSB0byBlbnN1cmUgdGhhdCBubyByb3V0aW5nCiAgIGxvb3BzIGFyZSBlbmFibGVkIFtJ
LUQuaWV0Zi12Nm9wcy10dW5uZWwtbG9vcHNdLiAgPHN0cm9uZz48Zm9udCBjb2xvcj0nZ3JlZW4n
ID5BZGRpdGlvbmFsIHNlY3VyaXR5CiAgIGNvbmNlcm5zIHdpdGggSVAgdHVubmVsaW5nIGFyZSBk
b2N1bWVudGVkIGluIFtSRkM2MTY5XS48L2ZvbnQ+PC9zdHJvbmc+CgoxMy4gIEFja25vd2xlZGdt
ZW50cwoKICAgVGhlIGZvbGxvd2luZyBhcmUgYWNrbm93bGVkZ2VkIGZvciB0aGVpciBpbnNpZ2h0
cyB0aGF0IGhlbHBlZCBzaGFwZQogICB0aGlzIHdvcms6IEZyZWQgQmFrZXIsIEJyaWFuIENhcnBl
bnRlciwgVGhvbWFzIEhlbmRlcnNvbiwgUGhpbGlwCiAgIEhvbWJ1cmcsIExlZSBIb3dhcmQsIDxz
dHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+UmF5IEh1bnRlciw8L2ZvbnQ+PC9zdHJvbmc+IEpv
ZWwgSmFlZ2dsaSwgR2FiaSBOYWtpYmx5LCBIZW1hbnQKICAgU2luZ2gsIE1hcmsgU21pdGgsIE9s
ZSBUcm9hbiwgR3VudGVyIFZhbiBkZSBWZWxkZSwgLi4uCgoxNC4gIFJlZmVyZW5jZXMKCjE0LjEu
ICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzE5MThdICBSZWtodGVyLCBZLiwgTW9za293
aXR6LCBSLiwgS2FycmVuYmVyZywgRC4sIEdyb290LCBHLiwgYW5kCiAgICAgICAgICAgICAgRS4g
TGVhciwgIkFkZHJlc3MgQWxsb2NhdGlvbiBmb3IgUHJpdmF0ZSBJbnRlcm5ldHMiLAogICAgICAg
ICAgICAgIEJDUCA1LCBSRkMgMTkxOCwgRmVicnVhcnkgMTk5Ni4KCiAgIFtSRkMzMzE1XSAgRHJv
bXMsIFIuLCBCb3VuZCwgSi4sIFZvbHosIEIuLCBMZW1vbiwgVC4sIFBlcmtpbnMsIEMuLAogICAg
ICAgICAgICAgIGFuZCBNLiBDYXJuZXksICJEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBQcm90
b2NvbCBmb3IKICAgICAgICAgICAgICBJUHY2IChESENQdjYpIiwgUkZDIDMzMTUsIEp1bHkgMjAw
My4KCiAgIFtSRkMzNjMzXSAgVHJvYW4sIE8uIGFuZCBSLiBEcm9tcywgIklQdjYgUHJlZml4IE9w
dGlvbnMgZm9yIER5bmFtaWMKICAgICAgICAgICAgICBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9j
b2wgKERIQ1ApIHZlcnNpb24gNiIsIFJGQyAzNjMzLAogICAgICAgICAgICAgIERlY2VtYmVyIDIw
MDMuCgogICBbUkZDNDIxM10gIE5vcmRtYXJrLCBFLiBhbmQgUi4gR2lsbGlnYW4sICJCYXNpYyBU
cmFuc2l0aW9uIE1lY2hhbmlzbXMKICAgICAgICAgICAgICBmb3IgSVB2NiBIb3N0cyBhbmQgUm91
dGVycyIsIFJGQyA0MjEzLCBPY3RvYmVyIDIwMDUuCgogICBbUkZDNDg2MV0gIE5hcnRlbiwgVC4s
IE5vcmRtYXJrLCBFLiwgU2ltcHNvbiwgVy4sIGFuZCBILiBTb2xpbWFuLAogICAgICAgICAgICAg
ICJOZWlnaGJvciBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24gNiAoSVB2NikiLCBSRkMgNDg2MSwK
ICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjAwNy4KCiAgIFtSRkM1MjE0XSAgVGVtcGxpbiwgRi4s
IEdsZWVzb24sIFQuLCBhbmQgRC4gVGhhbGVyLCAiSW50cmEtU2l0ZQogICAgICAgICAgICAgIEF1
dG9tYXRpYyBUdW5uZWwgQWRkcmVzc2luZyBQcm90b2NvbCAoSVNBVEFQKSIsIFJGQyA1MjE0LAog
ICAgICAgICAgICAgIE1hcmNoIDIwMDguCgoxNC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoK
ICAgW0ktRC5pZXRmLXY2b3BzLXR1bm5lbC1sb29wc10KICAgICAgICAgICAgICBOYWtpYmx5LCBH
LiBhbmQgRi4gVGVtcGxpbiwgIlJvdXRpbmcgTG9vcCBBdHRhY2sgdXNpbmcKICAgICAgICAgICAg
ICBJUHY2IEF1dG9tYXRpYyBUdW5uZWxzOiBQcm9ibGVtIFN0YXRlbWVudCBhbmQgUHJvcG9zZWQK
ICAgICAgICAgICAgICBNaXRpZ2F0aW9ucyIsIDxzdHJpa2U+PGZvbnQgY29sb3I9J3JlZCcgPmRy
YWZ0LWlldGYtdjZvcHMtdHVubmVsLWxvb3BzLTA2PC9mb250Pjwvc3RyaWtlPiA8c3Ryb25nPjxm
b250IGNvbG9yPSdncmVlbicgPmRyYWZ0LWlldGYtdjZvcHMtdHVubmVsLWxvb3BzLTA3PC9mb250
Pjwvc3Ryb25nPiAod29yayBpbgogICAgICAgICAgICAgIHByb2dyZXNzKSwgPHN0cmlrZT48Zm9u
dCBjb2xvcj0ncmVkJyA+TWFyY2g8L2ZvbnQ+PC9zdHJpa2U+IDxzdHJvbmc+PGZvbnQgY29sb3I9
J2dyZWVuJyA+TWF5PC9mb250Pjwvc3Ryb25nPiAyMDExLgoKICAgW0ktRC50ZW1wbGluLWFlcm9d
CiAgICAgICAgICAgICAgVGVtcGxpbiwgRi4sICJBc3ltbWV0cmljIEV4dGVuZGVkIFJvdXRlIE9w
dGltaXphdGlvbgogICAgICAgICAgICAgIChBRVJPKSIsIGRyYWZ0LXRlbXBsaW4tYWVyby0wMCAo
d29yayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAgICAgTWFyY2ggMjAxMS4KCiAgIFtSRkMxNjg3
XSAgRmxlaXNjaG1hbiwgRS4sICJBIExhcmdlIENvcnBvcmF0ZSBVc2VyJ3MgVmlldyBvZiBJUG5n
IiwKICAgICAgICAgICAgICBSRkMgMTY4NywgQXVndXN0IDE5OTQuCgogICBbUkZDMTkwMF0gIENh
cnBlbnRlciwgQi4gYW5kIFkuIFJla2h0ZXIsICJSZW51bWJlcmluZyBOZWVkcyBXb3JrIiwKICAg
ICAgICAgICAgICBSRkMgMTkwMCwgRmVicnVhcnkgMTk5Ni4KCiAgIFtSRkMyNDkxXSAgQXJtaXRh
Z2UsIEcuLCBTY2h1bHRlciwgUC4sIEpvcmssIE0uLCBhbmQgRy4gSGFydGVyLCAiSVB2NgogICAg
ICAgICAgICAgIG92ZXIgTm9uLUJyb2FkY2FzdCBNdWx0aXBsZSBBY2Nlc3MgKE5CTUEpIG5ldHdv
cmtzIiwKICAgICAgICAgICAgICBSRkMgMjQ5MSwgSmFudWFyeSAxOTk5LgoKICAgW1JGQzI1Mjld
ICBDYXJwZW50ZXIsIEIuIGFuZCBDLiBKdW5nLCAiVHJhbnNtaXNzaW9uIG9mIElQdjYgb3ZlciBJ
UHY0CiAgICAgICAgICAgICAgRG9tYWlucyB3aXRob3V0IEV4cGxpY2l0IFR1bm5lbHMiLCBSRkMg
MjUyOSwgTWFyY2ggMTk5OS4KCiAgIDxzdHJvbmc+PGZvbnQgY29sb3I9J2dyZWVuJyA+W1JGQzI5
ODNdICBCbGFjaywgRC4sICJEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBhbmQgVHVubmVscyIsCiAg
ICAgICAgICAgICAgUkZDIDI5ODMsIE9jdG9iZXIgMjAwMC48L2ZvbnQ+PC9zdHJvbmc+CgogICBb
UkZDMzA1M10gIER1cmFuZCwgQS4sIEZhc2FubywgUC4sIEd1YXJkaW5pLCBJLiwgYW5kIEQuIExl
bnRvLCAiSVB2NgogICAgICAgICAgICAgIFR1bm5lbCBCcm9rZXIiLCBSRkMgMzA1MywgSmFudWFy
eSAyMDAxLgoKICAgW1JGQzMwNTZdICBDYXJwZW50ZXIsIEIuIGFuZCBLLiBNb29yZSwgIkNvbm5l
Y3Rpb24gb2YgSVB2NiBEb21haW5zCiAgICAgICAgICAgICAgdmlhIElQdjQgQ2xvdWRzIiwgUkZD
IDMwNTYsIEZlYnJ1YXJ5IDIwMDEuCgogICA8c3Ryb25nPjxmb250IGNvbG9yPSdncmVlbicgPltS
RkMzMTY4XSAgUmFtYWtyaXNobmFuLCBLLiwgRmxveWQsIFMuLCBhbmQgRC4gQmxhY2ssICJUaGUg
QWRkaXRpb24KICAgICAgICAgICAgICBvZiBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlv
biAoRUNOKSB0byBJUCIsCiAgICAgICAgICAgICAgUkZDIDMxNjgsIFNlcHRlbWJlciAyMDAxLjwv
Zm9udD48L3N0cm9uZz4KCiAgIFtSRkM0MTkyXSAgQmFrZXIsIEYuLCBMZWFyLCBFLiwgYW5kIFIu
IERyb21zLCAiUHJvY2VkdXJlcyBmb3IKICAgICAgICAgICAgICBSZW51bWJlcmluZyBhbiBJUHY2
IE5ldHdvcmsgd2l0aG91dCBhIEZsYWcgRGF5IiwgUkZDIDQxOTIsCiAgICAgICAgICAgICAgU2Vw
dGVtYmVyIDIwMDUuCgogICBbUkZDNDM4MF0gIEh1aXRlbWEsIEMuLCAiVGVyZWRvOiBUdW5uZWxp
bmcgSVB2NiBvdmVyIFVEUCB0aHJvdWdoCiAgICAgICAgICAgICAgTmV0d29yayBBZGRyZXNzIFRy
YW5zbGF0aW9ucyAoTkFUcykiLCBSRkMgNDM4MCwKICAgICAgICAgICAgICBGZWJydWFyeSAyMDA2
LgoKICAgW1JGQzQ1NTRdICBDaG93biwgVC4sICJVc2Ugb2YgVkxBTnMgZm9yIElQdjQtSVB2NiBD
b2V4aXN0ZW5jZSBpbgogICAgICAgICAgICAgIEVudGVycHJpc2UgTmV0d29ya3MiLCBSRkMgNDU1
NCwgSnVuZSAyMDA2LgoKICAgW1JGQzUzMjBdICBUZW1wbGluLCBGLiwgIlRoZSBTdWJuZXR3b3Jr
IEVuY2Fwc3VsYXRpb24gYW5kIEFkYXB0YXRpb24KICAgICAgICAgICAgICBMYXllciAoU0VBTCki
LCBSRkMgNTMyMCwgRmVicnVhcnkgMjAxMC4KCiAgIFtSRkM1NTU4XSAgVGVtcGxpbiwgRi4sICJW
aXJ0dWFsIEVudGVycHJpc2UgVHJhdmVyc2FsIChWRVQpIiwKICAgICAgICAgICAgICBSRkMgNTU1
OCwgRmVicnVhcnkgMjAxMC4KCiAgIFtSRkM1NzIwXSAgVGVtcGxpbiwgRi4sICJSb3V0aW5nIGFu
ZCBBZGRyZXNzaW5nIGluIE5ldHdvcmtzIHdpdGgKICAgICAgICAgICAgICBHbG9iYWwgRW50ZXJw
cmlzZSBSZWN1cnNpb24gKFJBTkdFUikiLCBSRkMgNTcyMCwKICAgICAgICAgICAgICBGZWJydWFy
eSAyMDEwLgoKICAgW1JGQzU4ODddICBDYXJwZW50ZXIsIEIuLCBBdGtpbnNvbiwgUi4sIGFuZCBI
LiBGbGluY2ssICJSZW51bWJlcmluZwogICAgICAgICAgICAgIFN0aWxsIE5lZWRzIFdvcmsiLCBS
RkMgNTg4NywgTWF5IDIwMTAuCgogICBbUkZDNTk2OV0gIFRvd25zbGV5LCBXLiBhbmQgTy4gVHJv
YW4sICJJUHY2IFJhcGlkIERlcGxveW1lbnQgb24gSVB2NAogICAgICAgICAgICAgIEluZnJhc3Ry
dWN0dXJlcyAoNnJkKSAtLSBQcm90b2NvbCBTcGVjaWZpY2F0aW9uIiwKICAgICAgICAgICAgICBS
RkMgNTk2OSwgQXVndXN0IDIwMTAuCgogICBbUkZDNjEzOV0gIFJ1c3NlcnQsIFMuLCBGbGVpc2No
bWFuLCBFLiwgYW5kIEYuIFRlbXBsaW4sICJSb3V0aW5nIGFuZAogICAgICAgICAgICAgIEFkZHJl
c3NpbmcgaW4gTmV0d29ya3Mgd2l0aCBHbG9iYWwgRW50ZXJwcmlzZSBSZWN1cnNpb24KICAgICAg
ICAgICAgICAoUkFOR0VSKSBTY2VuYXJpb3MiLCBSRkMgNjEzOSwgRmVicnVhcnkgPHN0cm9uZz48
Zm9udCBjb2xvcj0nZ3JlZW4nID4yMDExLgoKICAgW1JGQzYxNjldICBLcmlzaG5hbiwgUy4sIFRo
YWxlciwgRC4sIGFuZCBKLiBIb2FnbGFuZCwgIlNlY3VyaXR5CiAgICAgICAgICAgICAgQ29uY2Vy
bnMgd2l0aCBJUCBUdW5uZWxpbmciLCBSRkMgNjE2OSwgQXByaWw8L2ZvbnQ+PC9zdHJvbmc+IDIw
MTEuCgogICBbUkZDNjE3OV0gIFRlbXBsaW4sIEYuLCAiVGhlIEludGVybmV0IFJvdXRpbmcgT3Zl
cmxheSBOZXR3b3JrCiAgICAgICAgICAgICAgKElST04pIiwgUkZDIDYxNzksIE1hcmNoIDIwMTEu
CgpBdXRob3IncyBBZGRyZXNzCgogICBGcmVkIEwuIFRlbXBsaW4KICAgQm9laW5nIFJlc2VhcmNo
ICZhbXA7IFRlY2hub2xvZ3kKICAgUC5PLiBCb3ggMzcwNyBNQyA3TC00OQogICBTZWF0dGxlLCBX
QSAgOTgxMjQKICAgVVNBCgogICBFbWFpbDogZmx0ZW1wbGluQGFjbS5vcmcKPC9wcmU+CjwvYm9k
eT48L2h0bWw+Cg==

--_002_E1829B60731D1740BB7A0626B4FAF0A65C6A6029AAXCHNW01Vnwnos_--

From sm@resistor.net  Tue May 10 09:30: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 5E729E07C5; Tue, 10 May 2011 09:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level: 
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 7cYPBGSMPMzQ; Tue, 10 May 2011 09:30:49 -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 1D2E4E0729; Tue, 10 May 2011 09:30:48 -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 p49JJTfL018849;  Mon, 9 May 2011 12:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1304968778; bh=nTrdkuMFMmv5EGqs3D5PlNi/cvRDzcI5x4rrj8E84I0=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=brFVrByJA+QVFREtn01LXNFhxUg1pRPerDjjyXlbzoSoMbpUss335fWHeGYc7oIkI CvbrN4VUllmUNxB9muI04R+PjMwi/UPGLKX12W/Oe3akxXSpNzXKUgFpokM8DJUKEu bR4AQ/NW0zuZndvB/AuzJKly7RRfi6HFZAVPJjHo=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1304968778; bh=nTrdkuMFMmv5EGqs3D5PlNi/cvRDzcI5x4rrj8E84I0=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=EPADWZMiKTV7alxS6sFBoQ8ge4d9TitvZkbKWUHzrfJiZIPXzK3XKOMLV6GvLrQ8N B6I+c9Mr6cCtU2va/g0yDtgAAmWZNJyr//BBzkssQNT/XrVN9gNRES02hGRXGKIDMy oH1HQtNOgTHS7eWVzHuO2cJAebEnHdXXCxlo0d7I=
Message-Id: <6.2.5.6.2.20110509120705.04a75b68@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 09 May 2011 12:13:46 -0700
To: Doug Barton 
From: SM 
In-Reply-To: <4DC1E7C2.8010405@dougbarton.us>
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>  <6.2.5.6.2.20110502215922.05513e20@resistor.net> <4DC1E7C2.8010405@dougbarton.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: v6ops@ietf.org, IETF Discussion 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 10 May 2011 16:30:50 -0000

Hi Doug,
At 16:56 04-05-2011, Doug Barton wrote:
>"Blessed" is rather strong. There are a non-zero number of people in 
>both groups (of which I am one) who don't like the draft, and don't 
>agree that documenting bad ideas is its own virtue.

If I have to go by the document shepherd write-up, only one person 
expressed discontent about this proposal, hence the above comment.

[snip]

>Meanwhile, the discussion about whether or not to call this 
>"whitelisting" is pointless. The term is already well-established.

No comment for obvious reasons.

Regards,
-sm 


From fred@cisco.com  Tue May 10 10:18: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 ABF24E08AC for ; Tue, 10 May 2011 10:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.44
X-Spam-Level: 
X-Spam-Status: No, score=-109.44 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=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 WrYVP6SxtAzU for ; Tue, 10 May 2011 10:18:43 -0700 (PDT)
Received: from sj-iport-3.cisco.com (unknown [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id B413FE07F4 for ; Tue, 10 May 2011 10:18:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=814; q=dns/txt; s=iport; t=1305047923; x=1306257523; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=SNWwoCSkAyHc2C2UTuQQgSblogadc49D3zcZSWMv4Kw=; b=Laj7yMxIxRf0ekVlZzaqlR9d855RDR0Ifz+oYcFm1ONS8UXz0fGZVCsd Rf/p/v5I06BIipA2TY8k1evBi9MiK22U0yxN4lqy644Turks748YO4KTf A6qgAy01I4OZ8rI3fTXRmtgvOL5GR+j3+pXAsUC2KyyWN2LABeBjZccmW Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKxyyU2rRDoJ/2dsb2JhbACmC3enaoEdnkOGDwSGQokuhCeKVw
X-IronPort-AV: E=Sophos;i="4.64,346,1301875200"; d="scan'208";a="312562923"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 10 May 2011 17:18:43 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4AHIcD0021974 for ; Tue, 10 May 2011 17:18:42 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Tue, 10 May 2011 10:18:43 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Tue, 10 May 2011 10:18:43 -0700
From: Fred Baker 
Date: Tue, 10 May 2011 10:18:27 -0700
Message-Id: <3CF3E905-E526-4847-A9AC-D6A28828B208@cisco.com>
To: IPv6 Operations Working Group 
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-sarikaya-v6ops-prefix-delegation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 10 May 2011 17:18:45 -0000

The authors have asked me about=20
http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation
  "DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks",
  Behcet Sarikaya, Frank Xia, 19-Apr-11

When we discussed this at IETF-79, a number of views were expressed, =
varying from "let's adopt this as a working group draft and immediately =
publish as a BCP" to "ignore and abandon this draft, if anything it =
belongs in some other SDO or NOG", and all points in between. Several =
folks indicated that they would post comments to the list, and the =
comments didn't materialize.

Question for the assembled hordes: what needs to happen in this draft to =
make it useful/interesting for mobile network operators? What needs to =
happen to make it interesting to other operators?=

From dwcarder@wisc.edu  Tue May 10 13:39: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 9FF0EE06FD for ; Tue, 10 May 2011 13:39:45 -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 XEMYhCPil6bv for ; Tue, 10 May 2011 13:39:45 -0700 (PDT)
Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by ietfa.amsl.com (Postfix) with ESMTP id EA915E0663 for ; Tue, 10 May 2011 13:39:44 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII
Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LKZ00F1EYQ78T00@smtpauth3.wiscmail.wisc.edu> for v6ops@ietf.org; Tue, 10 May 2011 15:39:43 -0500 (CDT)
Received: from dyn-72-33-195-206.uwnet.wisc.edu (dyn-193-110.vpn.wisc.edu [146.151.193.110]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LKZ00AELYQ54W30@smtpauth3.wiscmail.wisc.edu>; Tue, 10 May 2011 15:39:42 -0500 (CDT)
Date: Tue, 10 May 2011 15:39:40 -0500
From: "Dale W. Carder" 
In-reply-to: 
To: Erik Kline 
Message-id: <20110510203939.GB9004@dyn-72-33-195-206.uwnet.wisc.edu>
X-Spam-PmxInfo: Server=avs-9, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.10.202718, SenderIP=146.151.193.110
References: <4DC29A96.6020709@globis.net>  <20110506005809.C526CE848C9@drugs.dv.isc.org> 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 10 May 2011 20:39:45 -0000

Thus spake Erik Kline (ek@google.com) on Fri, May 06, 2011 at 09:10:40AM +0200:
> >> The whitelisting is indeed designed to avoid the problems and allow
> >> IPv6 to be more broadly served to those who are properly able to make
> >> use of it.
> >
> > And there are plenty that can use IPv6 but can't get AAAA records
> > due to whitelisting.

Our site would fall into this category (for small cases of "plenty").

Since some of our recursive servers are used by a diverse group of users 
in managed and unmanaged academic and residentual settings it is my 
understanding that it would be inappropriate to whitelist our servers 
because of the alleged brokenness of some amount of the hosts using those 
resolvers.

However, many of the hosts have native v6 service today but obviously
don't get AAAA responses from some large content sites that use
whitelisting.

For the sites doing whitelisting it would be benificial to the operator
community to have feedback as to what the percived brokenness would be
for a site if it were whitelisted.  Maybe IPv6-day will be a starting
point for that.

Dale

From ichiroumakino@gmail.com  Wed May 11 00:25: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 7EFAEE067B for ; Wed, 11 May 2011 00:25:49 -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 sF0A0otAFz5w for ; Wed, 11 May 2011 00:25:49 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3C2DE06C1 for ; Wed, 11 May 2011 00:25:48 -0700 (PDT)
Received: by eye13 with SMTP id 13so80532eye.31 for ; Wed, 11 May 2011 00:25:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Q4+vV4jASBBbpR5Sm7Wv+CpO9I0Vc5HCsOIiN7zmlKA=; b=tj2vImFO5ZEpf0a2skHU/xKu4Nq9p27w1z13e+LmQsxTerCv6AHqaL9U8jPxtJIf57 N0NS280CxQt+E7pfOTEhH99yiSIdJP2AsuX/s6cQN98y7YTIRiqJb6qfqejie/3tiNpW DW5oZxKZ5kTruLlpl+Ny0IUkT65zbFTwwYM1k=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=vfG12ng/C20usa6GtrzyyozWQzfGqa2bWPgD1Cirna3+z0LuvOO4SUURvca7rxDIap iNjD7sHQiiqKEBhSiDtddDO+x4/GczFGa0AhWBmHnCjdyGAPJeWQL2HpC/zJ7wIGQ8Ef UTYsGq60AUTFt2YHL5SrIJ/BNHh8TEeFH0SgE=
Received: by 10.213.109.85 with SMTP id i21mr65274ebp.39.1305098746612; Wed, 11 May 2011 00:25:46 -0700 (PDT)
Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id s1sm4864241ees.17.2011.05.11.00.25.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 00:25:45 -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: <3CF3E905-E526-4847-A9AC-D6A28828B208@cisco.com>
Date: Wed, 11 May 2011 09:25:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <3CF3E905-E526-4847-A9AC-D6A28828B208@cisco.com>
To: Fred Baker 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations Working Group 
Subject: Re: [v6ops] draft-sarikaya-v6ops-prefix-delegation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 11 May 2011 07:25:49 -0000

_is_ this best current practice?

does this conflict when DHCPv6 PD is used between UE and AR?
I'm concerned about section 3.2, where the AR DHCPv6 relay should add an =
IA_PD option to the DHCPv6 client - server exchange.
has that new protocol behaviour been reviewed in the DHC WG? in other =
scenarios that functionality has been solved either with snooping or the =
proposed RAAN option.

cheers,
Ole

> The authors have asked me about=20
> http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation
>  "DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks",
>  Behcet Sarikaya, Frank Xia, 19-Apr-11
>=20
> When we discussed this at IETF-79, a number of views were expressed, =
varying from "let's adopt this as a working group draft and immediately =
publish as a BCP" to "ignore and abandon this draft, if anything it =
belongs in some other SDO or NOG", and all points in between. Several =
folks indicated that they would post comments to the list, and the =
comments didn't materialize.
>=20
> Question for the assembled hordes: what needs to happen in this draft =
to make it useful/interesting for mobile network operators? What needs =
to happen to make it interesting to other operators?
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From john.mann@monash.edu  Wed May 11 00:39: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 71069E0707 for ; Wed, 11 May 2011 00:39: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 IWI6UQNH8xaz for ; Wed, 11 May 2011 00:39:56 -0700 (PDT)
Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCC8E06C1 for ; Wed, 11 May 2011 00:39:56 -0700 (PDT)
Received: from mail-vw0-f47.google.com ([209.85.212.47]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTco9SxzPJ6E8f/y591/ohfESSm9h7eIr@postini.com; Wed, 11 May 2011 00:39:56 PDT
Received: by mail-vw0-f47.google.com with SMTP id 2so224987vws.34 for ; Wed, 11 May 2011 00:39:55 -0700 (PDT)
Received: by 10.52.98.5 with SMTP id ee5mr1457607vdb.200.1305099595062; Wed, 11 May 2011 00:39:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.108.134 with HTTP; Wed, 11 May 2011 00:39:35 -0700 (PDT)
In-Reply-To: <20110510203939.GB9004@dyn-72-33-195-206.uwnet.wisc.edu>
References: <4DC29A96.6020709@globis.net>  <20110506005809.C526CE848C9@drugs.dv.isc.org>  <20110510203939.GB9004@dyn-72-33-195-206.uwnet.wisc.edu>
From: "John Mann (ITS)" 
Date: Wed, 11 May 2011 17:39:35 +1000
Message-ID: 
To: "Dale W. Carder" 
Content-Type: multipart/alternative; boundary=20cf307f34a6c29e9704a2fb2d28
Cc: Erik Kline , "v6ops@ietf.org WG" , Ray Hunter 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 11 May 2011 07:39:57 -0000

--20cf307f34a6c29e9704a2fb2d28
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On 11 May 2011 06:39, Dale W. Carder  wrote:

> ...
> Since some of our recursive servers are used by a diverse group of users
> in managed and unmanaged academic and residentual settings it is my
> understanding that it would be inappropriate to whitelist our servers
> because of the alleged brokenness of some amount of the hosts using those
> resolvers.
>

You should be able to measure brokenness of your users by adding a web bug
to the front page of a few of your own commonly visited sites
e.g. add
http://www.getipv6.info/index.php/Warning_broken_users_with_JavaScript
to  www.example.com  mail.example.com  portal.example.com ...
This will flag to users that they have problems.
Analysing the logs carefully should tell you who and how many work or have
problems.

Then dual-stack one of your own web servers.
Fix any user/network problems, dual-stack something else ... repeat

Is the USA academic year finishing about now?
Do disruptive changes after exams, and if the residences are empty, you can
get normal staff happy
before having to worry about residences.
Then, when the students do come back, if it doesn't work for them, it's
_their_ fault not _yours_ ;-) ;-)

Going through all this should give you the confidence to ask for your
resolvers to be whitelisted.

For the sites doing whitelisting it would be benificial to the operator
> community to have feedback as to what the percived brokenness would be
> for a site if it were whitelisted.  Maybe IPv6-day will be a starting
> point for that.


It should be possible for site operators to add invisible web bugs such as
http://labs.apnic.net/ or http://www.potaroo.net/ispcol/2011-05/ip6test.html
or [  thing which logs locally that I can't find at the moment. ]
and then be able to answer queries about netblocks of "users" rather than
"resolvers"
that are IPv6 capable.

More work for content providers, but that may be part of the cost of doing
whitelisting.

    John

--20cf307f34a6c29e9704a2fb2d28
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

On 11 May 2011 06:39, Dale W. Carder =
<dwcarder@wisc.ed=
u> wrote:


...

Since some of our recursive servers are used by a diverse group of users
in managed and unmanaged academic and residentual settings it is my

understanding that it would be inappropriate to whitelist our servers

because of the alleged brokenness of some amount of the hosts using those
resolvers.

You should be able to measur=
e brokenness of your users by adding a web bug to the front page of a few o=
f your own commonly visited sites



This will flag to use=
rs that they have problems.



Analysing the logs carefully should tell you who and how many work or =
have problems.

Then dual-stack one of your own web=
 servers.
Fix any user/network problems, dual-stack something els=
e ... repeat




Is the USA academic year finishing about now?
Do disruptive changes after exams, and if the residences are empty, you ca=
n get normal staff happy
before having to worry about residences.=




Then, when the students do come back, if it doesn't work for them,=
 it's _their_ fault not _yours_ ;-) ;-)

Going th=
rough all this should give you the confidence to ask for your resolvers to =
be whitelisted.





For the sites doing whitelisting it would be benificial to the operator

community to have feedback as to what the percived brokenness would be

for a site if it were whitelisted. =A0Maybe IPv6-day will be a starting

point for that.

It should be possible for s=
ite operators to add invisible web bugs such as=A0



or [ =A0thing which logs locally that I can't find at the moment. =
]
and then be able to answer queries about netblocks of "use=
rs" rather than "resolvers"
that are IPv6 capable.=





More work for content providers, but that may be part o=
f the cost of doing whitelisting.

=A0 =A0 John


--20cf307f34a6c29e9704a2fb2d28--

From tore.anderson@redpill-linpro.com  Wed May 11 02:04: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 74681E06BA for ; Wed, 11 May 2011 02:04: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 uYNJVJ49nSkF for ; Wed, 11 May 2011 02:04:37 -0700 (PDT)
Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id 69E78E064E for ; Wed, 11 May 2011 02:04:37 -0700 (PDT)
Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 54C62CC0B9; Wed, 11 May 2011 11:04:35 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at linpro.no
Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id OnnWVTebPlCj; Wed, 11 May 2011 11:04:34 +0200 (CEST)
Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Wed, 11 May 2011 11:04:33 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id D3640170C00B; Wed, 11 May 2011 11:04:33 +0200 (CEST)
X-Virus-Scanned: amavisd-new at claudius.linpro.no
Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuJ-+xUvv4G0; Wed, 11 May 2011 11:04:33 +0200 (CEST)
Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 719EF170C00A; Wed, 11 May 2011 11:04:33 +0200 (CEST)
Message-ID: <4DCA5121.9010809@redpill-linpro.com>
Date: Wed, 11 May 2011 11:04:33 +0200
From: Tore Anderson 
Organization: Redpill Linpro AS
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org>
In-Reply-To: <20110510064904.B5081E9E11B@drugs.dv.isc.org>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 11 May 2011 09:04:38 -0000

* Mark Andrews

> 6rd is useless without ISPs turning on 6rd.  6rd is basically
> undeployable if the ISP doesn't supply the CPE equipment.  This
> isn't to say CPE vendors shouldn't implement 6rd.

The same thing can be said about your draft. Without ISP and CPE
support, it is dead in the water. And, just like with 6RD, the only way
an ISP can be sure that your new functionality is used by all of its
customers is to be supplying the CPE to all of them.

> 6to4 really isn't designed to be deployed on equipment behind a
> firewall.

Only in theory does reality match theory...

> I suspect most of the cases where setting the source
> address of the returned packet to the anycast address helps are in
> networks where the operator would disable 6to4 if they had a control
> which would do it.  This option provides such a control.

I would much rather recommend simply disabling it by default (i.e.
-historic). Implementing that change is much easier than implementing
your new DHCP option, and I believe it is therefore more likely to
actually happen. Also, it will help for access models that does not use
DHCP too, like PPP[oX].

> All the +1 are indicating that you want 6to4 to crash and burn
> rather than have a graceful landing.

Not at all, I'd very much like to see 6to4 land as gracefully as
possible, which is why I support the -advisory draft.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27

From marka@isc.org  Wed May 11 05:14: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 205FEE06C7 for ; Wed, 11 May 2011 05:14:39 -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 E+MuI44pz0Sd for ; Wed, 11 May 2011 05:14:38 -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 32779E0670 for ; Wed, 11 May 2011 05:14:37 -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 D1845C949D; Wed, 11 May 2011 12:14:24 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 3B70A216C1E; Wed, 11 May 2011 12:14:24 +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 D438CEAA1A5; Wed, 11 May 2011 22:14:53 +1000 (EST)
To: Tore Anderson 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com>
In-reply-to: Your message of "Wed, 11 May 2011 11:04:33 +0200." <4DCA5121.9010809@redpill-linpro.com>
Date: Wed, 11 May 2011 22:14:53 +1000
Message-Id: <20110511121453.D438CEAA1A5@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 11 May 2011 12:14:39 -0000

In message <4DCA5121.9010809@redpill-linpro.com>, Tore Anderson writes:
> * Mark Andrews
> 
> > 6rd is useless without ISPs turning on 6rd.  6rd is basically
> > undeployable if the ISP doesn't supply the CPE equipment.  This
> > isn't to say CPE vendors shouldn't implement 6rd.
> 
> The same thing can be said about your draft. Without ISP and CPE
> support, it is dead in the water. And, just like with 6RD, the only way
> an ISP can be sure that your new functionality is used by all of its
> customers is to be supplying the CPE to all of them.

One of the prime uses of this would be to turn off 6to4.  Lots of
machines that run 6to4 could be updated by their users today to
check for 0.0.0.0 if they only had the code point.  This can be
done with end user configuration.

Adding this to a dhcpd.conf would allow it to tell any machine that
had been updated that 6to4 will not work with addresses returned
from this dhcp server.

	option 6to4rro code  ip-address;
	option 6to4rro 0.0.0.0;

You don't have to have upgrade everyone.  This option won't make
things worse.  It will just make things better.   It 10% of machines
get upgraded to understand this it is 10% less machines which are
causing problems.

> > 6to4 really isn't designed to be deployed on equipment behind a
> > firewall.
> 
> Only in theory does reality match theory...
> 
> > I suspect most of the cases where setting the source
> > address of the returned packet to the anycast address helps are in
> > networks where the operator would disable 6to4 if they had a control
> > which would do it.  This option provides such a control.
> 
> I would much rather recommend simply disabling it by default (i.e.
> -historic). Implementing that change is much easier than implementing
> your new DHCP option, and I believe it is therefore more likely to
> actually happen. Also, it will help for access models that does not use
> DHCP too, like PPP[oX].

Disabling by default is fine but it does not help mobile machines
which move networks.  These machines often have had 6to4 explicitly
enabled.  The network itself needs to be able to tell the machines
which are running 6to4 perfectly fine when connected to their home
ISP that 6to4 shouldn't be turned on when they connect to the network
at work, at university, at the local hotspot.  Expecting the user
to turn 6to4 on and off as they move is not reasonable.

The option does not say "turn 6to4 when you see me".  It says if
you are already wanting to do 6to4 there are routers you can use
or I don't want you to do 6to4.

Similarly 6rd shouldn't be turned on just because you see the 6rd
option.  The 6rd option is about how to do 6rd not whether you want
to do 6rd.

> > All the +1 are indicating that you want 6to4 to crash and burn
> > rather than have a graceful landing.
> 
> Not at all, I'd very much like to see 6to4 land as gracefully as
> possible, which is why I support the -advisory draft.
> 
> -- 
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com
> Tel: +47 21 54 41 27
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From ichiroumakino@gmail.com  Wed May 11 05:26: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 23DDDE06D1 for ; Wed, 11 May 2011 05:26:22 -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 VoM3DNtIXF5v for ; Wed, 11 May 2011 05:26: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 4B9BDE0746 for ; Wed, 11 May 2011 05:26:21 -0700 (PDT)
Received: by wyb29 with SMTP id 29so396373wyb.31 for ; Wed, 11 May 2011 05:26:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=MvHeFiGBaCCQ1WKby1qDIpJYfU3I94Ay48+yxveTpw0=; b=uACEzEHtjf+DMef0Wevz3JwfXhnNmYKKHGccFz3wJZrWH+U3bGUyNcHNb/H+gDAl/Z 0UDcy3/xtJ8qA3Ctp+bhGG2lcdsui9oxehcTbRnNkZTtMaxBtaQ7w7RC913FNV6jSYjM dlcqekuGYMSKjCXLAkOLhFIILvIff84FWQY1g=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=l2AFqw8sEe83EVnVr6se2+8aPTtYJ5OCeekKW7Fg/Ie3FXa0Ql7FHNjzU3ccN6nXZg NZ/Yb17Q8f7h8EKSMpqQZL+LeP1jcLJKjpTK4H8m+rzNOe/PZ4St5tljCExI/rZ4o/Rz yOjBgFuLIochDaXgQkt0IK3zTaIDjyvCRvNQk=
Received: by 10.227.198.133 with SMTP id eo5mr9789794wbb.38.1305116780235; Wed, 11 May 2011 05:26:20 -0700 (PDT)
Received: from dhcp-osl-vl300-64-103-53-245.cisco.com (dhcp-osl-vl300-64-103-53-245.cisco.com [64.103.53.245]) by mx.google.com with ESMTPS id w12sm70952wby.7.2011.05.11.05.26.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 05:26:19 -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: <20110511121453.D438CEAA1A5@drugs.dv.isc.org>
Date: Wed, 11 May 2011 14:26:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org>
To: Mark Andrews 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 11 May 2011 12:26:22 -0000

Mark,

>>> 6rd is useless without ISPs turning on 6rd.  6rd is basically
>>> undeployable if the ISP doesn't supply the CPE equipment.  This
>>> isn't to say CPE vendors shouldn't implement 6rd.
>>=20
>> The same thing can be said about your draft. Without ISP and CPE
>> support, it is dead in the water. And, just like with 6RD, the only =
way
>> an ISP can be sure that your new functionality is used by all of its
>> customers is to be supplying the CPE to all of them.
>=20
> One of the prime uses of this would be to turn off 6to4.  Lots of
> machines that run 6to4 could be updated by their users today to
> check for 0.0.0.0 if they only had the code point.  This can be
> done with end user configuration.

if those users could be convinced to upgrade their system for this =
option,
why couldn't the also then be convinced to just disable 6to4?

[...]

> Disabling by default is fine but it does not help mobile machines
> which move networks.  These machines often have had 6to4 explicitly
> enabled.  The network itself needs to be able to tell the machines
> which are running 6to4 perfectly fine when connected to their home
> ISP that 6to4 shouldn't be turned on when they connect to the network
> at work, at university, at the local hotspot.  Expecting the user
> to turn 6to4 on and off as they move is not reasonable.

there appears to be some confusion here. the local network operator has =
no control over 6to4. that's one of the main problems with it.
the network operator can only affect the forward path, the remote-path =
is dependent on some unknown entity close to the destination.

why do have 6to4 been explicitly enabled on mobile machines? examples?
I've always thought 6to4 on by default as well-meaning vendors getting =
it wrong...
I rather want _no_ IPv6 than broken IPv6. but apparently there is a big =
use case I've missed where broken for 20% of the users is better than =
using IPv4 or no connectivity at all?

> The option does not say "turn 6to4 when you see me".  It says if
> you are already wanting to do 6to4 there are routers you can use
> or I don't want you to do 6to4.
>=20
> Similarly 6rd shouldn't be turned on just because you see the 6rd
> option.  The 6rd option is about how to do 6rd not whether you want
> to do 6rd.

well, depends. we'll specify this closer in the cpe-router-advanced =
document.
but normal behaviour on the WAN interface would be to include the 6rd =
DHCP option in the PRL list.

>>> All the +1 are indicating that you want 6to4 to crash and burn
>>> rather than have a graceful landing.
>>=20
>> Not at all, I'd very much like to see 6to4 land as gracefully as
>> possible, which is why I support the -advisory draft.

I don't see how this gives a graceful landing either.
even though you now have an option stating that 'the local network =
supports 6to4' doesn't fix any of the other failure cases with 6to4.

cheers,
Ole


From ek@google.com  Wed May 11 01:15: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 6EE10E0686 for ; Wed, 11 May 2011 01:15:23 -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 XoS2p43e3ewI for ; Wed, 11 May 2011 01:15: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 CFA47E067B for ; Wed, 11 May 2011 01:15:17 -0700 (PDT)
Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p4B8FCpx029669 for ; Wed, 11 May 2011 01:15:16 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305101717; bh=kuCvReAVVfaEGytfvwnMZ7taTqo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=upPtGcqSWspMojGHR4bXSlubwTydgQQnZ3gNX6VjGoZdvkuc6goDSnNmh1i+VDtTg BjsclCOANmj1Sfw+SVD6g==
Received: from qwb7 (qwb7.prod.google.com [10.241.193.71]) by kpbe17.cbf.corp.google.com with ESMTP id p4B8FA1p005698 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 11 May 2011 01:15:11 -0700
Received: by qwb7 with SMTP id 7so153429qwb.40 for ; Wed, 11 May 2011 01:15:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HchKkzihSGRdtzRfZQyk42ufXWSCQaw/82WXdVAejwA=; b=LydL7D4s8YiixjA20TANubc2pgcwt4qdoX/nSqseqWTT2zZiCCdLnwQiGlROpgaDaa Fbra+thC19/ufRnz1ERQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jiK5H4n7kuN6zOZgxBEqoHaDBPXDEiF236BGIPJPQ0xnqtU96Rr11LMGuFML9+3yZq kzCkEQUcWTnd7Q2ju97A==
MIME-Version: 1.0
Received: by 10.229.46.74 with SMTP id i10mr7070168qcf.64.1305101710336; Wed, 11 May 2011 01:15:10 -0700 (PDT)
Received: by 10.229.78.157 with HTTP; Wed, 11 May 2011 01:15:10 -0700 (PDT)
In-Reply-To: 
References: <4DC29A96.6020709@globis.net>  <20110506005809.C526CE848C9@drugs.dv.isc.org>  <20110510203939.GB9004@dyn-72-33-195-206.uwnet.wisc.edu> 
Date: Wed, 11 May 2011 17:15:10 +0900
Message-ID: 
From: Erik Kline 
To: "John Mann (ITS)" 
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
X-Mailman-Approved-At: Wed, 11 May 2011 05:38:11 -0700
Cc: "v6ops@ietf.org WG" , Ray Hunter 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 11 May 2011 08:15:23 -0000

> More work for content providers, but that may be part of the cost of doing
> whitelisting.

Indeed.  But there is a cost to not doing whitelisting.  

From ek@google.com  Wed May 11 02:34: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 731CAE0737 for ; Wed, 11 May 2011 02:34:57 -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 kikeACUq1hAb for ; Wed, 11 May 2011 02:34:57 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id C95F7E06BA for ; Wed, 11 May 2011 02:34:56 -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 p4B9YuOa031481 for ; Wed, 11 May 2011 02:34:56 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305106496; bh=cNbiw3R5k3/dPxNHgNPfrtBXVqU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=PheOE0ZqrZo6mBdXI/E//PRQXuQR6tEYQXAPw1j2FE9b5CdlSL7bY9RsTC6/wuZdX WeXvDYZtERNa7g879F2eA==
Received: from qyk7 (qyk7.prod.google.com [10.241.83.135]) by wpaz17.hot.corp.google.com with ESMTP id p4B9YXph009797 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 11 May 2011 02:34:55 -0700
Received: by qyk7 with SMTP id 7so2197178qyk.19 for ; Wed, 11 May 2011 02:34:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k8/RQ5yuY+qChQoerldixQtD66qTb9t3b35iX5/QL98=; b=fc1MCoonVNqYx+p8slOM0TELoeWuFOrqlUBLIiJ7UyNphItjrxh1/3wpkzwKvNuq2X Auw3TjvvjHBpbdb+463Q==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FvCxQwuVW65gNmRQKfNCupQA/XeEZfvfWYI6vNgrhcFTp8M+4Vb+XYLyIHL98CPK7t v/vDMJkhMyjpzpubA49w==
MIME-Version: 1.0
Received: by 10.229.8.195 with SMTP id i3mr7202484qci.26.1305106494603; Wed, 11 May 2011 02:34:54 -0700 (PDT)
Received: by 10.229.78.157 with HTTP; Wed, 11 May 2011 02:34:54 -0700 (PDT)
In-Reply-To: <9A13B378-9FC9-42D0-BB46-BCFD1FCFC8FB@cisco.com>
References:  <9A13B378-9FC9-42D0-BB46-BCFD1FCFC8FB@cisco.com>
Date: Wed, 11 May 2011 18:34:54 +0900
Message-ID: 
From: Erik Kline 
To: Fred Baker 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
X-Mailman-Approved-At: Wed, 11 May 2011 05:38:11 -0700
Cc: v6ops@ietf.org, Qiong 
Subject: Re: [v6ops] new draft: draft-sunq-v6ops-contents-transition-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, 11 May 2011 09:34:57 -0000

> Path MTU is mandatory in IPv6, so in the IPv6->IPv4 direction that should=
 be sufficient for any fragmentation issues. In the IPv4->IPv6 direction, P=
ath MTU addresses any case in which IPv4 DF is set. If DF is zero (the end =
system is expecting the network to fragment), I would expect you would look=
 to section 4 for guidance. The section is too long to quote, but in essenc=
e the datagram is fragmented as an IPv4 datagram and then the fragments are=
 translated into IPv6 datagrams containing the fragment header.
>
> The reason to not reassemble and then re-fragment is that datagrams can b=
e load-shared - they might not all go through the same translator.

Absolutely understood.  But there's lots of $VENDOR gear that does not
process IPv6 Fragment headers, or doesn't keep state to know which
ACLs to apply to fragments as they arrive.  Usually this means they
get dropped.  Thus, fragmenting toward IPv6 hosts has always seemed
risky to me.  We've seen this in real life.

In practice, I think this would only affect a UDP application running
on an IPv6 client where the IPv4 side sent the largest possible UDP
datagrams that it could.  It would have to get fragmented going toward
the IPv6 destination (after pathmtu discovery, of course), and then
that's when the packet is at the mercy of anything inspecting packets
and not supporting fragments.

Yes, this is certainly broken, but it's most definitely out there.

Now, if it turns out that was /not/ a concern in the authors'
experience, i.e. for all of their normal operations they never noticed
such a problem, then that's cool.  In which I think "To the best of
our knowledge we encountered no trouble with IPv4/IPv6 MTU mismatch."
is a perfectly worthy note to add to the experiences gained from the
deployment.

That's all I meant.

From marka@isc.org  Wed May 11 07:47: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 6D5E6E069E for ; Wed, 11 May 2011 07:47: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 7BfKxEnWYmtY for ; Wed, 11 May 2011 07:47:23 -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 E6DB8E0679 for ; Wed, 11 May 2011 07:47:22 -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 EE037C94DA; Wed, 11 May 2011 14:47:07 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 41EC7216C1E; Wed, 11 May 2011 14:47: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 77E3AEAAEDA; Thu, 12 May 2011 00:47:36 +1000 (EST)
To: Ole Troan 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org>
In-reply-to: Your message of "Wed, 11 May 2011 14:26:18 +0200." <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org>
Date: Thu, 12 May 2011 00:47:36 +1000
Message-Id: <20110511144736.77E3AEAAEDA@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 11 May 2011 14:47:24 -0000

In message <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org>, Ole Troan writ
es:
> Mark,
> 
> >>> 6rd is useless without ISPs turning on 6rd.  6rd is basically
> >>> undeployable if the ISP doesn't supply the CPE equipment.  This
> >>> isn't to say CPE vendors shouldn't implement 6rd.
> >>=20
> >> The same thing can be said about your draft. Without ISP and CPE
> >> support, it is dead in the water. And, just like with 6RD, the only =
> way
> >> an ISP can be sure that your new functionality is used by all of its
> >> customers is to be supplying the CPE to all of them.
> >=20
> > One of the prime uses of this would be to turn off 6to4.  Lots of
> > machines that run 6to4 could be updated by their users today to
> > check for 0.0.0.0 if they only had the code point.  This can be
> > done with end user configuration.
> 
> if those users could be convinced to upgrade their system for this =
> option,
> why couldn't the also then be convinced to just disable 6to4?

Because they NEED IPv6 and 6to4 is the option the currently have
working.  The alternatives: 6rd needs ISP support.  Tunnel brokers,
similar issues to 6to4 (experienced most of them over the last 7
years of using such a tunnel) and will likely break with CGN.  Native
needs ISP support.

> > Disabling by default is fine but it does not help mobile machines
> > which move networks.  These machines often have had 6to4 explicitly
> > enabled.  The network itself needs to be able to tell the machines
> > which are running 6to4 perfectly fine when connected to their home
> > ISP that 6to4 shouldn't be turned on when they connect to the network
> > at work, at university, at the local hotspot.  Expecting the user
> > to turn 6to4 on and off as they move is not reasonable.
> 
> there appears to be some confusion here. the local network operator has =
> no control over 6to4. that's one of the main problems with it.
> the network operator can only affect the forward path, the remote-path =
> is dependent on some unknown entity close to the destination.

And you just want to shoot down options which will give then some
control.

Sites that care about 6to4 reverse performance configure their dual
stack servers to do the encapsulation or install dedicated boxes
to do the encapsulation.  Neither of these is hard.

For most 6to4 users, who arn't sitting behind a firewall they don't
control, 6to4 works and the worst problem it usually causes is non
optimal routes.

> why do have 6to4 been explicitly enabled on mobile machines? examples?

You have a cable/dls modem.  You connect your laptop to it.  You
turn on 6to4 because you need it.  You suspend your laptop and go
to work, uni.  You open your laptop up.  It resumes from suspend
and gets a new lease.  6to4 is still on.

Not everyone has, needs or can afford a router.

This sort of thing has been documented as happening many times.

> I've always thought 6to4 on by default as well-meaning vendors getting =
> it wrong...

No. Thats just one way it gets turned on.

> I rather want _no_ IPv6 than broken IPv6. but apparently there is a big =
> use case I've missed where broken for 20% of the users is better than =
> using IPv4 or no connectivity at all?

You see Geoff 20% failure as saying 6to4 doesn't work.   I see the
20% failure rate as 20% of boxes with 6to4 on when it shouldn't be.

I know plenty of people who have been using 6to4 for years without
operational problem.  It isn't broken for them.  They get reasonable
performance sometime better than IPv4.

> > The option does not say "turn 6to4 when you see me".  It says if
> > you are already wanting to do 6to4 there are routers you can use
> > or I don't want you to do 6to4.
> >=20
> > Similarly 6rd shouldn't be turned on just because you see the 6rd
> > option.  The 6rd option is about how to do 6rd not whether you want
> > to do 6rd.
> 
> well, depends. we'll specify this closer in the cpe-router-advanced =
> document.
> but normal behaviour on the WAN interface would be to include the 6rd =
> DHCP option in the PRL list.

There is nothing wrong with requesting the information all the time.  It's
what you do with the information that in important.
 
> >>> All the +1 are indicating that you want 6to4 to crash and burn
> >>> rather than have a graceful landing.
> >>=20
> >> Not at all, I'd very much like to see 6to4 land as gracefully as
> >> possible, which is why I support the -advisory draft.
> 
> I don't see how this gives a graceful landing either.
> even though you now have an option stating that 'the local network =
> supports 6to4' doesn't fix any of the other failure cases with 6to4.
>
> cheers,
> Ole
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From Fred.L.Templin@boeing.com  Wed May 11 08:57: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 76A4CE0659 for ; Wed, 11 May 2011 08:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=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 3fF5zOAimzh1 for ; Wed, 11 May 2011 08:57:47 -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 B880AE082F for ; Wed, 11 May 2011 08:57:47 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4BFvc7n009540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 May 2011 10:57:38 -0500 (CDT)
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 p4BFQirx003271; Wed, 11 May 2011 08:26:44 -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 p4BFQf2v003147 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 11 May 2011 08:26:44 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Wed, 11 May 2011 08:57:38 -0700
From: "Templin, Fred L" 
To: Ray Hunter 
Date: Wed, 11 May 2011 08:57:36 -0700
Thread-Topic: [v6ops]  new draft: draft-templin-v6ops-isops-00.txt
Thread-Index: AcwM8oc0eJ+Ym1bAR76XpuGvMeGohgC+TCHQ
Message-ID: 
References: <4DC44472.6080208@globis.net>  <4DC50DEE.7040402@globis.net> <4DC5A69D.1040700@globis.net>
In-Reply-To: <4DC5A69D.1040700@globis.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: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] new draft: draft-templin-v6ops-isops-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, 11 May 2011 15:57:48 -0000

Ray,

Most of your grievances wrt ISATAP seem to stem from
an application in sites with either poor or ad-hoc
adminstrative coordination. ISATAP is only enabled
when the site administrators explicitly enable it,
and hosts should be able to assume that the site
administrators have done their homework beforehand
the same as for any other managed networking services
offered by the site.

You asked about latency to ISATAP routers, and I
responded that anycast is an alternative. The anycast
model for ISATAP is similar to that for 6rd, and the
6rd guys seem to have done a good job of convincing the
ISPs that the model is valid. And, remember that this
is a *managed* anycast service and not an unmanaged one.
Even without anycast, a host when presented with a PRL
that includes multiple IPv4 addresses could fire off a
salvo of RS messages (one to each PRL IPv4 address)
and simply accept the first RA reply it receives.

You seem also to be concerned about ISATAP'ing around
between hosts within the site, and in the SLAAC-based
model suggested in my draft that would still work. But,
my draft is advocating the SLAAC-based ISATAP service
as primarily a way for hosts within the site to access
IPv6 content outside of the site, i.e., all external
IPv6 communications would need to flow through a site
border router in any event. IPv4 within the site would
still be preferred.

About QoS, you were concerned that RFC2983 is IPv4
only, but that is not correct. RFC2983 talks about
IP in IP tunnels, but IP can be read within this
context as "either IP protocol version". RFC2983
cites RFC2474, which says:

   "This document defines the IP header field, called the DS (for
   differentiated services) field.  In IPv4, it defines the layout of
   the TOS octet; in IPv6, the Traffic Class octet."

i.e, the DS field is treated in the same fashion for
both IP protocol versions.

So, two options seem to be to roll out the ISATAP
service via well-planned and coordinated
administrative actions or to somehow overhaul the
entire site to understand native IPv6 - possibly
at great expense. Some sites may see it as much
simpler and cost-effective to roll out the ISATAP
service and to not have to update all of their
existing IPv4 infrastructure (apps, routers,
bridges, switches, etc.) to also recognize IPv6.

Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: Ray Hunter [mailto:v6ops@globis.net]=20
> Sent: Saturday, May 07, 2011 1:08 PM
> To: Templin, Fred L
> Cc: v6ops@ietf.org WG
> Subject: Re: [v6ops] new draft: draft-templin-v6ops-isops-00.txt
>=20
> Ray Hunter wrote:
> > It certainly helped clarify an awful lot, and I appreciate=20
> you taking=20
> > the time to look at my questions, but I still don't have workable=20
> > solutions for:
> > 1) managing security of ISATAP automatic tunnels between network=20
> > security zones (and every multinational has these, but it's outside=20
> > the scope of your document),
> > 2) setting correct QoS at a new point in the network (at an=20
> end node=20
> > tunnel) (and many multinationals use DSCP),
> > 3) really being able to mange latency introduced by=20
> tunneling (apart=20
> > from via DNS content, which is not under the direct control of the=20
> > network transport guys)
> > 4) protecting against the odd rogue/incompetent DNS admin.=20
> (and I have=20
> > seen them)
> > 5) being able to set and manage default behavior and protocol=20
> > preference settings with the granularity I need, which is a real=20
> > concern. Relying on DNS content is not an acceptable=20
> solution for this=20
> > IMHO.
> > 6) there's still that question about Windows specific behavior and=20
> > whether it registers SLAAC derived IPv6 addresses=20
> automatically in DNS=20
> > by default (which would be a broken implementation)

From tore.anderson@redpill-linpro.com  Wed May 11 10:24: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 8E455E0844 for ; Wed, 11 May 2011 10:24:31 -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 U30N5VUeIltB for ; Wed, 11 May 2011 10:24:30 -0700 (PDT)
Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id 85F64E073C for ; Wed, 11 May 2011 10:24:30 -0700 (PDT)
Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 5C37ECC1E5; Wed, 11 May 2011 19:24:29 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at linpro.no
Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id OmTcEtFZEnww; Wed, 11 May 2011 19:24:29 +0200 (CEST)
Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Wed, 11 May 2011 19:24:29 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 0592C170C00A; Wed, 11 May 2011 19:24:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at claudius.linpro.no
Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUUt9g64Gsov; Wed, 11 May 2011 19:24:28 +0200 (CEST)
Received: from envy.fud.no (unknown [77.40.198.54]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 7E81A170C00B; Wed, 11 May 2011 19:24:28 +0200 (CEST)
Message-ID: <4DCAC64C.7030607@redpill-linpro.com>
Date: Wed, 11 May 2011 19:24:28 +0200
From: Tore Anderson 
Organization: Redpill Linpro AS
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org>
In-Reply-To: <20110511144736.77E3AEAAEDA@drugs.dv.isc.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 11 May 2011 17:24:31 -0000

* Mark Andrews

>>> One of the prime uses of this would be to turn off 6to4.  Lots
>>> of machines that run 6to4 could be updated by their users today
>>> to check for 0.0.0.0 if they only had the code point.  This can
>>> be done with end user configuration.
>> 
>> if those users could be convinced to upgrade their system for this
>> option, why couldn't the also then be convinced to just disable
>> 6to4?
> 
> Because they NEED IPv6 and 6to4 is the option the currently have 
> working.

I'm really confused as to how you mean your proposed DHCP option will
help these users. If the user NEEDS 6to4 to work, yet is in a network
where 6to4 DOESN'T work, how does the DHCP server informing him of that
fact make him any less SOL?

> The alternatives: 6rd needs ISP support.  Tunnel brokers, similar
> issues to 6to4 (experienced most of them over the last 7 years of
> using such a tunnel) and will likely break with CGN.  Native needs
> ISP support.

I find it very difficult to imagine a network environment where 6to4 can
succeed but where a brokered proto-41 tunnel fails. Do you have any
examples?

Then there's also the tunnel brokers that use UDP-based encapsulation
protocols (e.g. SixXS' AYIYA) which pierce nicely through NATs. A user
that NEEDS IPv6 to work, no matter what network he connects to, would be
much better off using something like that instead of 6to4, IMO.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

From joelja@bogus.com  Wed May 11 10:36: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 A2C23E072B for ; Wed, 11 May 2011 10:36:28 -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 nXTxCmDPNSLE for ; Wed, 11 May 2011 10:36:28 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E636BE0684 for ; Wed, 11 May 2011 10:36:27 -0700 (PDT)
Received: from 23173jjaeggli.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p4BHaO5L095847 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 11 May 2011 17:36:25 GMT (envelope-from joelja@bogus.com)
Message-ID: <4DCAC912.6080205@bogus.com>
Date: Wed, 11 May 2011 10:36:18 -0700
From: Joel Jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Tore Anderson 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>		<4DC8D717.3080402@redpill-linpro.com>	<20110510064904.B5081E9E11B@drugs.dv.isc.org>	<4DCA5121.9010809@redpill-linpro.com>	<20110511121453.D438CEAA1A5@drugs.dv.isc.org>	<0F0C1186-50F6-4305-92E0-B833C0520127@employees.org>	<20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com>
In-Reply-To: <4DCAC64C.7030607@redpill-linpro.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 11 May 2011 17:36:26 +0000 (UTC)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 11 May 2011 17:36:28 -0000

On 5/11/11 10:24 AM, Tore Anderson wrote:
> * Mark Andrews
> 
>>>> One of the prime uses of this would be to turn off 6to4.  Lots
>>>> of machines that run 6to4 could be updated by their users today
>>>> to check for 0.0.0.0 if they only had the code point.  This can
>>>> be done with end user configuration.
>>>
>>> if those users could be convinced to upgrade their system for this
>>> option, why couldn't the also then be convinced to just disable
>>> 6to4?
>>
>> Because they NEED IPv6 and 6to4 is the option the currently have 
>> working.
> 
> I'm really confused as to how you mean your proposed DHCP option will
> help these users. If the user NEEDS 6to4 to work, yet is in a network
> where 6to4 DOESN'T work, how does the DHCP server informing him of that
> fact make him any less SOL?

being informed that you're hosed has some merit, you will however intuit
it rather quickly, more to the point does the device handing out
addresses always know when you're hosed?

>> The alternatives: 6rd needs ISP support.  Tunnel brokers, similar
>> issues to 6to4 (experienced most of them over the last 7 years of
>> using such a tunnel) and will likely break with CGN.  Native needs
>> ISP support.
> 
> I find it very difficult to imagine a network environment where 6to4 can
> succeed but where a brokered proto-41 tunnel fails. Do you have any
> examples?
> 
> Then there's also the tunnel brokers that use UDP-based encapsulation
> protocols (e.g. SixXS' AYIYA) which pierce nicely through NATs. A user
> that NEEDS IPv6 to work, no matter what network he connects to, would be
> much better off using something like that instead of 6to4, IMO.

client vpn's are a pretty well established technology for dealing with
the local or remote network access restrictions. they are of coruse
contingent on the client having access to s network where the policy
suites their needs on which they can anchor the vpn endpoint.



From marka@isc.org  Wed May 11 16:21: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 1BF2BE06D4 for ; Wed, 11 May 2011 16:21:19 -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 m+iwhSiHCUKh for ; Wed, 11 May 2011 16:21:18 -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 EC646E065A for ; Wed, 11 May 2011 16:21:17 -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 EE4B85F9973; Wed, 11 May 2011 23:20:59 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 9CA84216C31; Wed, 11 May 2011 23:20:57 +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 A5DFDEAD470; Thu, 12 May 2011 09:21:29 +1000 (EST)
To: Tore Anderson 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com>
In-reply-to: Your message of "Wed, 11 May 2011 19:24:28 +0200." <4DCAC64C.7030607@redpill-linpro.com>
Date: Thu, 12 May 2011 09:21:29 +1000
Message-Id: <20110511232129.A5DFDEAD470@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 11 May 2011 23:21:19 -0000

In message <4DCAC64C.7030607@redpill-linpro.com>, Tore Anderson writes:
> * Mark Andrews
> 
> >>> One of the prime uses of this would be to turn off 6to4.  Lots
> >>> of machines that run 6to4 could be updated by their users today
> >>> to check for 0.0.0.0 if they only had the code point.  This can
> >>> be done with end user configuration.
> >> 
> >> if those users could be convinced to upgrade their system for this
> >> option, why couldn't the also then be convinced to just disable
> >> 6to4?
> > 
> > Because they NEED IPv6 and 6to4 is the option the currently have 
> > working.
> 
> I'm really confused as to how you mean your proposed DHCP option will
> help these users. If the user NEEDS 6to4 to work, yet is in a network
> where 6to4 DOESN'T work, how does the DHCP server informing him of that
> fact make him any less SOL?

Please re-read what is needed.  It is *IPv6* not 6to4.  6to4 is the
means.

There are networks with IPv6, maybe even supplied by another 6to4
router which does have a path carved through the firewall for it
or it the external router, but machines connecting to it don't stop
trying to establish their own 6to4 tunnels.  We have had plenty of
reports of that happening as well.

You can filter protocol-41 to everyone but yourself.  You then
filter the IPv6 traffic inbound on the virtual interface after
de-encapsulating it.  For outbound you do the filtering before you
encapsulate it.  You have 6to4 address working fine internally but
you can't bring up a different 6to4 tunnel.

> > The alternatives: 6rd needs ISP support.  Tunnel brokers, similar
> > issues to 6to4 (experienced most of them over the last 7 years of
> > using such a tunnel) and will likely break with CGN.  Native needs
> > ISP support.
> 
> I find it very difficult to imagine a network environment where 6to4 can
> succeed but where a brokered proto-41 tunnel fails. Do you have any
> examples?

Look at all the complaints about 6to4.   Most of them are applicable
to brokered tunnels.  Remote tunnel endpoint, overloaded tunnels,
no dead tunnel detection, non responsive tunnel administators.  HE
have been good to me on that last point but there are other tunnel
brokers that arn't anywhere near as responsive.  Remember most of
the tunnel brokers arn't being paid to run the service.

> Then there's also the tunnel brokers that use UDP-based encapsulation
> protocols (e.g. SixXS' AYIYA) which pierce nicely through NATs. A user
> that NEEDS IPv6 to work, no matter what network he connects to, would be
> much better off using something like that instead of 6to4, IMO.

And there are firewall administrators that filter that as well.
 
> -- 
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com/
> Tel: +47 21 54 41 27
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From marka@isc.org  Wed May 11 16:39: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 CF849E08B7 for ; Wed, 11 May 2011 16:39: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=[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 I3y6fnqQ0cnW for ; Wed, 11 May 2011 16:39:30 -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 E61F8E065A for ; Wed, 11 May 2011 16:39:29 -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 CBA475F98E1; Wed, 11 May 2011 23:39:15 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 3C79C216C1E; Wed, 11 May 2011 23:39:13 +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 63275EAD4F4; Thu, 12 May 2011 09:39:45 +1000 (EST)
To: Joel Jaeggli 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <4DCAC912.6080205@bogus.com>
In-reply-to: Your message of "Wed, 11 May 2011 10:36:18 MST." <4DCAC912.6080205@bogus.com>
Date: Thu, 12 May 2011 09:39:45 +1000
Message-Id: <20110511233945.63275EAD4F4@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 11 May 2011 23:39:30 -0000

In message <4DCAC912.6080205@bogus.com>, Joel Jaeggli writes:
> On 5/11/11 10:24 AM, Tore Anderson wrote:
> > * Mark Andrews
> > 
> >>>> One of the prime uses of this would be to turn off 6to4.  Lots
> >>>> of machines that run 6to4 could be updated by their users today
> >>>> to check for 0.0.0.0 if they only had the code point.  This can
> >>>> be done with end user configuration.
> >>>
> >>> if those users could be convinced to upgrade their system for this
> >>> option, why couldn't the also then be convinced to just disable
> >>> 6to4?
> >>
> >> Because they NEED IPv6 and 6to4 is the option the currently have 
> >> working.
> > 
> > I'm really confused as to how you mean your proposed DHCP option will
> > help these users. If the user NEEDS 6to4 to work, yet is in a network
> > where 6to4 DOESN'T work, how does the DHCP server informing him of that
> > fact make him any less SOL?
> 
> being informed that you're hosed has some merit, you will however intuit
> it rather quickly, more to the point does the device handing out
> addresses always know when you're hosed?

Not always but there are plenty of network admins that would like
to have a switch they could use to turn off 6to4 on machines
connecting to their networks.  They would set the switch even if
it only stopped a single machine they would think that the 3 seconds
it took to install the option was worth it.

Then when they chase down the next machine that doesn't support the
options they could tell it owner that they need to upgrade to
something that does support the option.

Lots of the problem machines here do have automated maintenance
paths or no cost upgrade paths.

DHCP server vendors could default this to 0.0.0.0 when returning
RFC 1918 addresses.  Belts and braces network administration.

> >> The alternatives: 6rd needs ISP support.  Tunnel brokers, similar
> >> issues to 6to4 (experienced most of them over the last 7 years of
> >> using such a tunnel) and will likely break with CGN.  Native needs
> >> ISP support.
> > 
> > I find it very difficult to imagine a network environment where 6to4 can
> > succeed but where a brokered proto-41 tunnel fails. Do you have any
> > examples?
> > 
> > Then there's also the tunnel brokers that use UDP-based encapsulation
> > protocols (e.g. SixXS' AYIYA) which pierce nicely through NATs. A user
> > that NEEDS IPv6 to work, no matter what network he connects to, would be
> > much better off using something like that instead of 6to4, IMO.
> 
> client vpn's are a pretty well established technology for dealing with
> the local or remote network access restrictions. they are of coruse
> contingent on the client having access to s network where the policy
> suites their needs on which they can anchor the vpn endpoint.
> 
> 
-- 
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 May 11 17:01: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 D629DE0901 for ; Wed, 11 May 2011 17:01:22 -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 fd2RiUx81BaF for ; Wed, 11 May 2011 17:01:22 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93AA3E0900 for ; Wed, 11 May 2011 17:01:21 -0700 (PDT)
Received: by ewy19 with SMTP id 19so357769ewy.31 for ; Wed, 11 May 2011 17:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rAu+ZJCx9rsb9XVrDDJjr5EWX09dRES9A25+5TzXeUs=; b=Mlu3ek63R2AZZMg+leR6neNvutanjb6YPtdl2B3dOh9w8c9O2H2Phs9HyuhWUMOJgv VM8GUMOlFN1PeyKxi+NqqTHZTXyqffNUrM7iQYh/zM20+xTz4Gmz7+keSnCEL3pX7XXL rcJg+z9lPMfm1+BmaDaGg25bNPEMp5gaTq/HM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vL/fd8ec+2ew/sSfP561jYrdeG8f5G2HsMxp/EDMjxZUiBcSrGefehdSX7ccjfvqZe g7lzWGgbXO2fiuOssGFa2mg2/lOZU84vNDn312RwnqN2SDDoQhRVcAK/BT6esYXXb7/2 +23R+REGM14FNLpxEDYMbCiMcukXBCrBVyn5Y=
MIME-Version: 1.0
Received: by 10.14.123.205 with SMTP id v53mr4592933eeh.217.1305158480602; Wed, 11 May 2011 17:01:20 -0700 (PDT)
Received: by 10.14.37.143 with HTTP; Wed, 11 May 2011 17:01:20 -0700 (PDT)
Received: by 10.14.37.143 with HTTP; Wed, 11 May 2011 17:01:20 -0700 (PDT)
In-Reply-To: <20110511233945.63275EAD4F4@drugs.dv.isc.org>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <4DCAC912.6080205@bogus.com> <20110511233945.63275EAD4F4@drugs.dv.isc.org>
Date: Wed, 11 May 2011 17:01:20 -0700
Message-ID: 
From: Cameron Byrne 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=e0cb4e6ff23f9ca84104a308e37b
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 00:01:22 -0000

--e0cb4e6ff23f9ca84104a308e37b
Content-Type: text/plain; charset=ISO-8859-1

On May 11, 2011 4:39 PM, "Mark Andrews"  wrote:
>
>
> In message <4DCAC912.6080205@bogus.com>, Joel Jaeggli writes:
> > On 5/11/11 10:24 AM, Tore Anderson wrote:
> > > * Mark Andrews
> > >
> > >>>> One of the prime uses of this would be to turn off 6to4.  Lots
> > >>>> of machines that run 6to4 could be updated by their users today
> > >>>> to check for 0.0.0.0 if they only had the code point.  This can
> > >>>> be done with end user configuration.
> > >>>
> > >>> if those users could be convinced to upgrade their system for this
> > >>> option, why couldn't the also then be convinced to just disable
> > >>> 6to4?
> > >>
> > >> Because they NEED IPv6 and 6to4 is the option the currently have
> > >> working.
> > >
> > > I'm really confused as to how you mean your proposed DHCP option will
> > > help these users. If the user NEEDS 6to4 to work, yet is in a network
> > > where 6to4 DOESN'T work, how does the DHCP server informing him of
that
> > > fact make him any less SOL?
> >
> > being informed that you're hosed has some merit, you will however intuit
> > it rather quickly, more to the point does the device handing out
> > addresses always know when you're hosed?
>
> Not always but there are plenty of network admins that would like
> to have a switch they could use to turn off 6to4 on machines
> connecting to their networks.

You speak for them? And they want to support  sufficient upgrades to
process  this "switch"?

 They would set the switch even if
> it only stopped a single machine they would think that the 3 seconds
> it took to install the option was worth it.
>
> Then when they chase down the next machine that doesn't support the
> options they could tell it owner that they need to upgrade to
> something that does support the option.
>
> Lots of the problem machines here do have automated maintenance
> paths or no cost upgrade paths.
>
> DHCP server vendors could default this to 0.0.0.0 when returning
> RFC 1918 addresses.  Belts and braces network administration.
>
> > >> The alternatives: 6rd needs ISP support.  Tunnel brokers, similar
> > >> issues to 6to4 (experienced most of them over the last 7 years of
> > >> using such a tunnel) and will likely break with CGN.  Native needs
> > >> ISP support.
> > >
> > > I find it very difficult to imagine a network environment where 6to4
can
> > > succeed but where a brokered proto-41 tunnel fails. Do you have any
> > > examples?
> > >
> > > Then there's also the tunnel brokers that use UDP-based encapsulation
> > > protocols (e.g. SixXS' AYIYA) which pierce nicely through NATs. A user
> > > that NEEDS IPv6 to work, no matter what network he connects to, would
be
> > > much better off using something like that instead of 6to4, IMO.
> >
> > client vpn's are a pretty well established technology for dealing with
> > the local or remote network access restrictions. they are of coruse
> > contingent on the client having access to s network where the policy
> > suites their needs on which they can anchor the vpn endpoint.
> >
> >
> --
> 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

--e0cb4e6ff23f9ca84104a308e37b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On May 11, 2011 4:39 PM, "Mark Andrews" <marka@isc.org> wrote:

>

>

> In message <4DCAC912.=
6080205@bogus.com>, Joel Jaeggli writes:

> > On 5/11/11 10:24 AM, Tore Anderson wrote:

> > > * Mark Andrews

> > >

> > >>>> One of the prime uses of this would be to turn o=
ff 6to4. =A0Lots

> > >>>> of machines that run 6to4 could be updated by th=
eir users today

> > >>>> to check for 0.0.0.0 if they only had the code p=
oint. =A0This can

> > >>>> be done with end user configuration.

> > >>>

> > >>> if those users could be convinced to upgrade their s=
ystem for this

> > >>> option, why couldn't the also then be convinced =
to just disable

> > >>> 6to4?

> > >>

> > >> Because they NEED IPv6 and 6to4 is the option the curren=
tly have

> > >> working.

> > >

> > > I'm really confused as to how you mean your proposed DHC=
P option will

> > > help these users. If the user NEEDS 6to4 to work, yet is in =
a network

> > > where 6to4 DOESN'T work, how does the DHCP server inform=
ing him of that

> > > fact make him any less SOL?

> >

> > being informed that you're hosed has some merit, you will how=
ever intuit

> > it rather quickly, more to the point does the device handing out<=
br>
> > addresses always know when you're hosed?

>

> Not always but there are plenty of network admins that would like

> to have a switch they could use to turn off 6to4 on machines

> connecting to their networks.


You speak for them? And they want to support=A0 sufficient upgrades to p=
rocess=A0 this "switch"?


 =A0They would set the switch even if

> it only stopped a single machine they would think that the 3 seconds
> it took to install the option was worth it.

>

> Then when they chase down the next machine that doesn't support th=
e

> options they could tell it owner that they need to upgrade to

> something that does support the option.

>

> Lots of the problem machines here do have automated maintenance

> paths or no cost upgrade paths.

>

> DHCP server vendors could default this to 0.0.0.0 when returning

> RFC 1918 addresses. =A0Belts and braces network administration.

>

> > >> The alternatives: 6rd needs ISP support. =A0Tunnel broke=
rs, similar

> > >> issues to 6to4 (experienced most of them over the last 7=
 years of

> > >> using such a tunnel) and will likely break with CGN. =A0=
Native needs

> > >> ISP support.

> > >

> > > I find it very difficult to imagine a network environment wh=
ere 6to4 can

> > > succeed but where a brokered proto-41 tunnel fails. Do you h=
ave any

> > > examples?

> > >

> > > Then there's also the tunnel brokers that use UDP-based =
encapsulation

> > > protocols (e.g. SixXS' AYIYA) which pierce nicely throug=
h NATs. A user

> > > that NEEDS IPv6 to work, no matter what network he connects =
to, would be

> > > much better off using something like that instead of 6to4, I=
MO.

> >

> > client vpn's are a pretty well established technology for dea=
ling with

> > the local or remote network access restrictions. they are of coru=
se

> > contingent on the client having access to s network where the pol=
icy

> > suites their needs on which they can anchor the vpn endpoint.

> >

> >

> --

> 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




--e0cb4e6ff23f9ca84104a308e37b--

From lorenzo@google.com  Wed May 11 17:12: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 6DEB8E069C for ; Wed, 11 May 2011 17:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 yfU3+qzc2z1C for ; Wed, 11 May 2011 17:12:53 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6D929E0691 for ; Wed, 11 May 2011 17:12:44 -0700 (PDT)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p4C0ChQB008036 for ; Wed, 11 May 2011 17:12:43 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305159163; bh=3Q3+ejvW0OEOxxWrHWkFbXkv7qs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ITEckrUHOcwxsG1BnHcG6ALACrpls08nSQWPIh+muWOOxP8ysXsYJkT8IzNWO7qPd PTuXQ7pEz9RoRLYGm4/nA==
Received: from gwaa18 (gwaa18.prod.google.com [10.200.27.18]) by wpaz33.hot.corp.google.com with ESMTP id p4C0C5cb006560 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 11 May 2011 17:12:42 -0700
Received: by gwaa18 with SMTP id a18so497021gwa.33 for ; Wed, 11 May 2011 17:12:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vfnUfpMk6QEEBqYcTwS4Txedz2O6/kRPRx8H5aCDWYI=; b=XUoVVjmhJ55LotTJTDlu0XKmRDRT8FBsf9gvNB2AVdBBnrgvZorrs4nfKSDwDiSlXR UN4KWTQKYQSpaVqyFzZA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=JAuxahgatZBoM8LbjBCvqUNZDao4zmnFnol2+MvpstqKWNAxtZFoEZVSWLYUhHGfKg Q1zp2RHqZokIWiaKB7QQ==
Received: by 10.151.86.3 with SMTP id o3mr1397644ybl.150.1305159162110; Wed, 11 May 2011 17:12:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Wed, 11 May 2011 17:12:22 -0700 (PDT)
In-Reply-To: <20110511233945.63275EAD4F4@drugs.dv.isc.org>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <4DCAC912.6080205@bogus.com> <20110511233945.63275EAD4F4@drugs.dv.isc.org>
From: Lorenzo Colitti 
Date: Wed, 11 May 2011 17:12:22 -0700
Message-ID: 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=000e0cd28fee3ba47d04a3090c56
X-System-Of-Record: true
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 00:12:53 -0000

--000e0cd28fee3ba47d04a3090c56
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 11, 2011 at 4:39 PM, Mark Andrews  wrote:

> Not always but there are plenty of network admins that would like
> to have a switch they could use to turn off 6to4 on machines
> connecting to their networks.  They would set the switch even if
> it only stopped a single machine they would think that the 3 seconds
> it took to install the option was worth it.
>

Actually, if I were such a network admin, I think I would prefer my machines
to turn off 6to4 unconditionally, not based on some DHCP option. Either way
it's a code upgrade...

--000e0cd28fee3ba47d04a3090c56
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Wed, May 11, 2011 at 4:39 PM, Mark Andrews <marka@isc.org><=
/span> wrote:



Not always but there are plenty of network admins that wo=
uld like

to have a switch they could use to turn off 6to4 on machines

connecting to their networks. =A0They would set the switch even if

it only stopped a single machine they would think that the 3 seconds

it took to install the option was worth it.

=

Actually, if I were such a network admin, I think I would prefer my ma=
chines to turn off 6to4 unconditionally, not based on some DHCP option. Eit=
her way it's a code upgrade...





--000e0cd28fee3ba47d04a3090c56--

From touch@isi.edu  Wed May 11 17:26: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 F3CA7E06DA; Wed, 11 May 2011 17:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.869
X-Spam-Level: 
X-Spam-Status: No, score=-102.869 tagged_above=-999 required=5 tests=[AWL=-0.270, 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 ZGUI9Bb8W5ej; Wed, 11 May 2011 17:26:10 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by ietfa.amsl.com (Postfix) with ESMTP id 821A8E0691; Wed, 11 May 2011 17:26:10 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id p4C0Pj9q013494 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 11 May 2011 17:25:45 -0700 (PDT)
Message-ID: <4DCB2909.3040506@isi.edu>
Date: Wed, 11 May 2011 17:25:45 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Doug Barton 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net> <4DC1E7C2.8010405@dougbarton.us>
In-Reply-To: <4DC1E7C2.8010405@dougbarton.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: p4C0Pj9q013494
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: v6ops@ietf.org, IETF Discussion 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 12 May 2011 00:26:11 -0000

Hi, all,

Although this is a minor point, it's also easy to address:

On 5/4/2011 4:56 PM, Doug Barton wrote:
...
> Meanwhile, the discussion about whether or not to call this
> "whitelisting" is pointless. The term is already well-established.

That's true, but equally true that the terms for disk drives used to use 
terms "master" and "slave" - equally antiquated and potentially racially 
charged terms. FWIW, the Los Angeles County banned the terms in 2003 
when used for various purposes - including technology, preferring 
"primary" and "secondary", in specific. The terms don't even appear in 
the ATA spec after version 1.

For the terms in this doc, alternatives that do not require explanation 
(and aren't potentially racially charged) include "permit list" and 
"deny list".

Joe

From marka@isc.org  Wed May 11 17:45: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 AD2C9E084F for ; Wed, 11 May 2011 17:45:29 -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 OG3kYDHuOjJn for ; Wed, 11 May 2011 17:45:29 -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 C54ACE0711 for ; Wed, 11 May 2011 17:45: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.ams1.isc.org (Postfix) with ESMTPS id A1CBE5F9973; Thu, 12 May 2011 00:45:09 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 7B90C216C40; Thu, 12 May 2011 00:45: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 8CB1EEAE03A; Thu, 12 May 2011 10:45:39 +1000 (EST)
To: Cameron Byrne 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <4DCAC912.6080205@bogus.com> <20110511233945.63275EAD4F4@drugs.dv.isc.org> 
In-reply-to: Your message of "Wed, 11 May 2011 17:01:20 MST." 
Date: Thu, 12 May 2011 10:45:39 +1000
Message-Id: <20110512004539.8CB1EEAE03A@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 00:45:29 -0000

In message , Cameron Byrne writes:
> --e0cb4e6ff23f9ca84104a308e37b
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On May 11, 2011 4:39 PM, "Mark Andrews"  wrote:
> >
> >
> > In message <4DCAC912.6080205@bogus.com>, Joel Jaeggli writes:
> > > On 5/11/11 10:24 AM, Tore Anderson wrote:
> > > > * Mark Andrews
> > > >
> > > >>>> One of the prime uses of this would be to turn off 6to4.  Lots
> > > >>>> of machines that run 6to4 could be updated by their users today
> > > >>>> to check for 0.0.0.0 if they only had the code point.  This can
> > > >>>> be done with end user configuration.
> > > >>>
> > > >>> if those users could be convinced to upgrade their system for this
> > > >>> option, why couldn't the also then be convinced to just disable
> > > >>> 6to4?
> > > >>
> > > >> Because they NEED IPv6 and 6to4 is the option the currently have
> > > >> working.
> > > >
> > > > I'm really confused as to how you mean your proposed DHCP option will
> > > > help these users. If the user NEEDS 6to4 to work, yet is in a network
> > > > where 6to4 DOESN'T work, how does the DHCP server informing him of
> that
> > > > fact make him any less SOL?
> > >
> > > being informed that you're hosed has some merit, you will however intuit
> > > it rather quickly, more to the point does the device handing out
> > > addresses always know when you're hosed?
> >
> > Not always but there are plenty of network admins that would like
> > to have a switch they could use to turn off 6to4 on machines
> > connecting to their networks.
> 
> You speak for them? And they want to support  sufficient upgrades to
> process  this "switch"?

I've got 10 year old DHCP servers and DHCP clients that can support
this once a code point is allocated.  This is configuration file
change for those servers and clients that is no harder than changing
a nameserver address.   They were designed to support the addition
of new code points.  They were designed to allow the user to change
what happens when a lease request is answered.

Not all servers and clients can do this but a large percentage of
them can.

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  Wed May 11 18:14: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 D50EFE07E8 for ; Wed, 11 May 2011 18:14:40 -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 Tc4i1Y+dLFaX for ; Wed, 11 May 2011 18:14:39 -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 4338AE0711 for ; Wed, 11 May 2011 18:14:39 -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 AA2085F98EC; Thu, 12 May 2011 01:14:24 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 851B2216C1E; Thu, 12 May 2011 01:14:22 +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 2A2AAEAE1E7; Thu, 12 May 2011 11:14:53 +1000 (EST)
To: Lorenzo Colitti 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <4DCAC912.6080205@bogus.com> <20110511233945.63275EAD4F4@drugs.dv.isc.org> 
In-reply-to: Your message of "Wed, 11 May 2011 17:12:22 MST." 
Date: Thu, 12 May 2011 11:14:53 +1000
Message-Id: <20110512011453.2A2AAEAE1E7@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 01:14:40 -0000

In message , Lorenzo Colitti writes:
> On Wed, May 11, 2011 at 4:39 PM, Mark Andrews  wrote:
> 
> > Not always but there are plenty of network admins that would like
> > to have a switch they could use to turn off 6to4 on machines
> > connecting to their networks.  They would set the switch even if
> > it only stopped a single machine they would think that the 3 seconds
> > it took to install the option was worth it.
> >
> 
> Actually, if I were such a network admin, I think I would prefer my machines
> to turn off 6to4 unconditionally, not based on some DHCP option. Either way
> it's a code upgrade...

It's minor configuration changes in many cases.  Real life configs.
The "default 6to4rro 192.88.99.1;" isn't strictly needed as this
is a outbound 6to4 interface for return traffic, however if you
were using 6to4 for forward traffic it sets the address of the
anycast relay.

Old:
interface "sis0" {
        request subnet-mask, broadcast-address, time-offset, routers,
                domain-name, domain-name-servers, ntp-servers;
        require subnet-mask, domain-name-servers;
        supersede domain-name "dv.isc.org isc.org rc.vix.com";
        prepend domain-name-servers 127.0.0.1;
        send dhcp-lease-time 7200;
}

octets=`echo $new_ip_address | sed 's/\./ /g'`
ifconfig stf0 inet6 2002:`printf %02x%02x:%02x%02x $octets`:: \
        prefixlen 16 alias anycast link0
route add -inet6 2002:: -prefixlen 16 ::1
route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0

New:
option 6to4rro code  ip-address;
interface "sis0" {
        request subnet-mask, broadcast-address, time-offset, routers,
                domain-name, domain-name-servers, ntp-servers, 6to4rro;
        require subnet-mask, domain-name-servers;
        supersede domain-name "dv.isc.org isc.org rc.vix.com";
        prepend domain-name-servers 127.0.0.1;
        send dhcp-lease-time 7200;
	default 6to4rro 192.88.99.1;
}

if [ -n "$new_6to4rro" -a "$6to4rro" != 0.0.0.0 ]
then
	octets=`echo $new_ip_address | sed 's/\./ /g'`
	ifconfig stf0 inet6 2002:`printf %02x%02x:%02x%02x $octets`:: \
		prefixlen 16 alias anycast link0
	route add -inet6 2002:: -prefixlen 16 ::1
	route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0
elif [ "$6to4rro" = 0.0.0.0 ]
then
	route delete -inet6 2002:: -prefixlen 16
	ifconfig stf0 down
fi

-- 
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 May 11 18:25: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 19506E06FE for ; Wed, 11 May 2011 18:25:44 -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 U4h79f4gHbTl for ; Wed, 11 May 2011 18:25:39 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F89CE06B9 for ; Wed, 11 May 2011 18:25:39 -0700 (PDT)
Received: by ewy19 with SMTP id 19so371437ewy.31 for ; Wed, 11 May 2011 18:25:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=HmU6vbERJBTFR9pUjEZ+eJLlzCgRUqx07/LCSdRK0w8=; b=c/WZ8ltoKBQ7GRYNQjstNTPU1ZtIIK6bxmEJnnTjL8zRfjxLXigUhiVasreJ+zjEIK GJutqav8kWdBDvtFaDZtnOq1posTV8fThwrWrP7Ir5V13ELTU/lg7O6XzslKiDNel2gj lgZc4fJpuND5EytFX6P3GwAk66ifZaYtBr9m0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=IHjPFYc+NehGDSUsEFrwwVd3LRPUH0HWNSTkITpKook3JPnfmqdCeIYQX8bYm/gnkR 9g2fkWVc6SfSkiX4UbfR3jxrAmcCV8ZO+SJjQydLClJKGyuEICUyhTPzTq9nsfEF8sA9 h2RQt6gnuXiGMUykBe/MCizjJchYHTKn288OM=
MIME-Version: 1.0
Received: by 10.14.122.201 with SMTP id t49mr4183479eeh.25.1305163536738; Wed, 11 May 2011 18:25:36 -0700 (PDT)
Received: by 10.14.37.143 with HTTP; Wed, 11 May 2011 18:25:36 -0700 (PDT)
Received: by 10.14.37.143 with HTTP; Wed, 11 May 2011 18:25:36 -0700 (PDT)
Date: Wed, 11 May 2011 18:25:36 -0700
Message-ID: 
From: Cameron Byrne 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=e0cb4e43d0b7fb292a04a30a10ab
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 01:25:44 -0000

--e0cb4e43d0b7fb292a04a30a10ab
Content-Type: text/plain; charset=ISO-8859-1

On May 11, 2011 6:14 PM, "Mark Andrews"  wrote:
>
>
> In message , Lorenzo
Colitti writes:
> > On Wed, May 11, 2011 at 4:39 PM, Mark Andrews  wrote:
> >
> > > Not always but there are plenty of network admins that would like
> > > to have a switch they could use to turn off 6to4 on machines
> > > connecting to their networks.  They would set the switch even if
> > > it only stopped a single machine they would think that the 3 seconds
> > > it took to install the option was worth it.
> > >
> >
> > Actually, if I were such a network admin, I think I would prefer my
machines
> > to turn off 6to4 unconditionally, not based on some DHCP option. Either
way
> > it's a code upgrade...
>
> It's minor configuration changes in many cases.  Real life configs.
> The "default 6to4rro 192.88.99.1;" isn't strictly needed as this
> is a outbound 6to4 interface for return traffic, however if you
> were using 6to4 for forward traffic it sets the address of the
> anycast relay.
>
> Old:
> interface "sis0" {
>        request subnet-mask, broadcast-address, time-offset, routers,
>                domain-name, domain-name-servers, ntp-servers;
>        require subnet-mask, domain-name-servers;
>        supersede domain-name "dv.isc.org isc.org rc.vix.com";
>        prepend domain-name-servers 127.0.0.1;
>        send dhcp-lease-time 7200;
> }
>
> octets=`echo $new_ip_address | sed 's/\./ /g'`
> ifconfig stf0 inet6 2002:`printf %02x%02x:%02x%02x $octets`:: \
>        prefixlen 16 alias anycast link0
> route add -inet6 2002:: -prefixlen 16 ::1
> route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0
>
> New:
> option 6to4rro code  ip-address;
> interface "sis0" {
>        request subnet-mask, broadcast-address, time-offset, routers,
>                domain-name, domain-name-servers, ntp-servers, 6to4rro;
>        require subnet-mask, domain-name-servers;
>        supersede domain-name "dv.isc.org isc.org rc.vix.com";
>        prepend domain-name-servers 127.0.0.1;
>        send dhcp-lease-time 7200;
>        default 6to4rro 192.88.99.1;
> }
>
> if [ -n "$new_6to4rro" -a "$6to4rro" != 0.0.0.0 ]
> then
>        octets=`echo $new_ip_address | sed 's/\./ /g'`
>        ifconfig stf0 inet6 2002:`printf %02x%02x:%02x%02x $octets`:: \
>                prefixlen 16 alias anycast link0
>        route add -inet6 2002:: -prefixlen 16 ::1
>        route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0
> elif [ "$6to4rro" = 0.0.0.0 ]
> then
>        route delete -inet6 2002:: -prefixlen 16
>        ifconfig stf0 down
> fi
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>

I am lost.

I click on the windows button in bottom left and then?

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

--e0cb4e43d0b7fb292a04a30a10ab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On May 11, 2011 6:14 PM, "Mark Andrews" <marka@isc.org> wrote:

>

>

> In message <BANLkTin_O+QnOHebwjO0hzGfL_9pr8vU4w@mail.gmail.com>=
, Lorenzo Colitti writes:

> > On Wed, May 11, 2011 at 4:39 PM, Mark Andrews <marka@isc.org> wrote:

> >

> > > Not always but there are plenty of network admins that would=
 like

> > > to have a switch they could use to turn off 6to4 on machines=


> > > connecting to their networks. =A0They would set the switch e=
ven if

> > > it only stopped a single machine they would think that the 3=
 seconds

> > > it took to install the option was worth it.

> > >

> >

> > Actually, if I were such a network admin, I think I would prefer =
my machines

> > to turn off 6to4 unconditionally, not based on some DHCP option. =
Either way

> > it's a code upgrade...

>

> It's minor configuration changes in many cases. =A0Real life confi=
gs.

> The "default 6to4rro 192.88.99.1;" isn't strictly needed=
 as this

> is a outbound 6to4 interface for return traffic, however if you

> were using 6to4 for forward traffic it sets the address of the

> anycast relay.

>

> Old:

> interface "sis0" {

> =A0 =A0 =A0 =A0request subnet-mask, broadcast-address, time-offset, ro=
uters,

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain-name, domain-name-servers, ntp-s=
ervers;

> =A0 =A0 =A0 =A0require subnet-mask, domain-name-servers;

> =A0 =A0 =A0 =A0supersede domain-name "dv.isc.org isc.org rc.vix.com";

> =A0 =A0 =A0 =A0prepend domain-name-servers 127.0.0.1;

> =A0 =A0 =A0 =A0send dhcp-lease-time 7200;

> }

>

> octets=3D`echo $new_ip_address | sed 's/\./ /g'`

> ifconfig stf0 inet6 2002:`printf %02x%02x:%02x%02x $octets`:: \

> =A0 =A0 =A0 =A0prefixlen 16 alias anycast link0

> route add -inet6 2002:: -prefixlen 16 ::1

> route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0

>

> New:

> option 6to4rro code <tbd> ip-address;

> interface "sis0" {

> =A0 =A0 =A0 =A0request subnet-mask, broadcast-address, time-offset, ro=
uters,

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domain-name, domain-name-servers, ntp-s=
ervers, 6to4rro;

> =A0 =A0 =A0 =A0require subnet-mask, domain-name-servers;

> =A0 =A0 =A0 =A0supersede domain-name "dv.isc.org isc.org rc.vix.com";

> =A0 =A0 =A0 =A0prepend domain-name-servers 127.0.0.1;

> =A0 =A0 =A0 =A0send dhcp-lease-time 7200;

> =A0 =A0 =A0 =A0default 6to4rro 192.88.99.1;

> }

>

> if [ -n "$new_6to4rro" -a "$6to4rro" !=3D 0.0.0.0 =
]

> then

> =A0 =A0 =A0 =A0octets=3D`echo $new_ip_address | sed 's/\./ /g'=
`

> =A0 =A0 =A0 =A0ifconfig stf0 inet6 2002:`printf %02x%02x:%02x%02x $oct=
ets`:: \

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prefixlen 16 alias anycast link0

> =A0 =A0 =A0 =A0route add -inet6 2002:: -prefixlen 16 ::1

> =A0 =A0 =A0 =A0route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0<=
br>
> elif [ "$6to4rro" =3D 0.0.0.0 ]

> then

> =A0 =A0 =A0 =A0route delete -inet6 2002:: -prefixlen 16

> =A0 =A0 =A0 =A0ifconfig stf0 down

> fi

>

> --

> 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: mar=
ka@isc.org

>


I am lost. 


I click on the windows button in bottom left and then?


Cb _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

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


--e0cb4e43d0b7fb292a04a30a10ab--

From marka@isc.org  Wed May 11 19:19: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 76CA9E0681 for ; Wed, 11 May 2011 19:19: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=[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 jlcpzLKcTv8a for ; Wed, 11 May 2011 19:19:06 -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 1B495E0662 for ; Wed, 11 May 2011 19:19:06 -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 66BF35F9982; Thu, 12 May 2011 02:18:49 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 42CD4216C1E; Thu, 12 May 2011 02:18:47 +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 5B0A4EAF4B4; Thu, 12 May 2011 12:19:16 +1000 (EST)
To: Cameron Byrne 
From: Mark Andrews 
References: 
In-reply-to: Your message of "Wed, 11 May 2011 18:25:36 MST." 
Date: Thu, 12 May 2011 12:19:16 +1000
Message-Id: <20110512021916.5B0A4EAF4B4@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 02:19:08 -0000

In message , Cameron Byrne writes:
> --e0cb4e43d0b7fb292a04a30a10ab
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On May 11, 2011 6:14 PM, "Mark Andrews"  wrote:
> >
> >
> > In message , Lorenzo
> Colitti writes:
> > > On Wed, May 11, 2011 at 4:39 PM, Mark Andrews  wrote:
> > >
> > > > Not always but there are plenty of network admins that would like
> > > > to have a switch they could use to turn off 6to4 on machines
> > > > connecting to their networks.  They would set the switch even if
> > > > it only stopped a single machine they would think that the 3 seconds
> > > > it took to install the option was worth it.
> > > >
> > >
> > > Actually, if I were such a network admin, I think I would prefer my
> machines
> > > to turn off 6to4 unconditionally, not based on some DHCP option. Either
> way
> > > it's a code upgrade...
> >
> > It's minor configuration changes in many cases.  Real life configs.
> > The "default 6to4rro 192.88.99.1;" isn't strictly needed as this
> > is a outbound 6to4 interface for return traffic, however if you
> > were using 6to4 for forward traffic it sets the address of the
> > anycast relay.
> >
> > Old:
> > interface "sis0" {
> >        request subnet-mask, broadcast-address, time-offset, routers,
> >                domain-name, domain-name-servers, ntp-servers;
> >        require subnet-mask, domain-name-servers;
> >        supersede domain-name "dv.isc.org isc.org rc.vix.com";
> >        prepend domain-name-servers 127.0.0.1;
> >        send dhcp-lease-time 7200;
> > }
> >
> > octets=`echo $new_ip_address | sed 's/\./ /g'`
> > ifconfig stf0 inet6 2002:`printf %02x%02x:%02x%02x $octets`:: \
> >        prefixlen 16 alias anycast link0
> > route add -inet6 2002:: -prefixlen 16 ::1
> > route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0
> >
> > New:
> > option 6to4rro code  ip-address;
> > interface "sis0" {
> >        request subnet-mask, broadcast-address, time-offset, routers,
> >                domain-name, domain-name-servers, ntp-servers, 6to4rro;
> >        require subnet-mask, domain-name-servers;
> >        supersede domain-name "dv.isc.org isc.org rc.vix.com";
> >        prepend domain-name-servers 127.0.0.1;
> >        send dhcp-lease-time 7200;
> >        default 6to4rro 192.88.99.1;
> > }
> >
> > if [ -n "$new_6to4rro" -a "$6to4rro" != 0.0.0.0 ]
> > then
> >        octets=`echo $new_ip_address | sed 's/\./ /g'`
> >        ifconfig stf0 inet6 2002:`printf %02x%02x:%02x%02x $octets`:: \
> >                prefixlen 16 alias anycast link0
> >        route add -inet6 2002:: -prefixlen 16 ::1
> >        route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0
> > elif [ "$6to4rro" = 0.0.0.0 ]
> > then
> >        route delete -inet6 2002:: -prefixlen 16
> >        ifconfig stf0 down
> > fi
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> >
> 
> I am lost.
> 
> I click on the windows button in bottom left and then?

You need to ask a Window guy about a Windows box.  The above works
with most Linux and BSD boxes with minor tweaks.  The actual example
was from a FreeBSD box.  I haven't delved deep enough into MacOS
to know whether you can do this with end user changes or not.

Before some else points it out the two "$6to4rro" should be
"$new_6to4rro". 

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  Wed May 11 19:26: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 7E01DE06F0 for ; Wed, 11 May 2011 19:26:02 -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 dYzR9YiEt+S1 for ; Wed, 11 May 2011 19:26:02 -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 ED349E068D for ; Wed, 11 May 2011 19:26:01 -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 5BCC2C9432; Thu, 12 May 2011 02:25:53 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 EC50A216C44; Thu, 12 May 2011 02:25: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 10E46EAF75D; Thu, 12 May 2011 12:26:25 +1000 (EST)
To: Lorenzo Colitti 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <4DCAC912.6080205@bogus.com> <20110511233945.63275EAD4F4@drugs.dv.isc.org> 
In-reply-to: Your message of "Wed, 11 May 2011 17:12:22 MST." 
Date: Thu, 12 May 2011 12:26:25 +1000
Message-Id: <20110512022625.10E46EAF75D@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 02:26:02 -0000

In message , Lorenzo Colitti writes:
> --000e0cd28fee3ba47d04a3090c56
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Wed, May 11, 2011 at 4:39 PM, Mark Andrews  wrote:
> 
> > Not always but there are plenty of network admins that would like
> > to have a switch they could use to turn off 6to4 on machines
> > connecting to their networks.  They would set the switch even if
> > it only stopped a single machine they would think that the 3 seconds
> > it took to install the option was worth it.
> >
> 
> Actually, if I were such a network admin, I think I would prefer my machines
> to turn off 6to4 unconditionally, not based on some DHCP option. Either way
> it's a code upgrade...

Remember having 0.0.0.0 turn 6to4 off is mainly for when the machines
arn't yours or they move.  If the machines are yours then turning
6to4 off unconditionally is definitely a option.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From dougb@dougbarton.us  Wed May 11 19:37: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 10BD0E068D for ; Wed, 11 May 2011 19:37:18 -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 VUtVp1OSxBQf for ; Wed, 11 May 2011 19:37:17 -0700 (PDT)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7D8E0681 for ; Wed, 11 May 2011 19:37:17 -0700 (PDT)
Received: (qmail 13679 invoked by uid 399); 12 May 2011 02:37:13 -0000
Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 12 May 2011 02:37:13 -0000
X-Originating-IP: 65.241.43.5
X-Sender: dougb@dougbarton.us
Message-ID: <4DCB47D7.1000603@dougbarton.us>
Date: Wed, 11 May 2011 19:37:11 -0700
From: Doug Barton 
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>		<4DC8D717.3080402@redpill-linpro.com>	<20110510064904.B5081E9E11B@drugs.dv.isc.org>	<4DCA5121.9010809@redpill-linpro.com>	<20110511121453.D438CEAA1A5@drugs.dv.isc.org>	<0F0C1186-50F6-4305-92E0-B833C0520127@employees.org>	<20110511144736.77E3AEAAEDA@drugs.dv.isc.org>	<4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org>
In-Reply-To: <20110511232129.A5DFDEAD470@drugs.dv.isc.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
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 02:37:18 -0000

On 05/11/2011 16:21, Mark Andrews wrote:
> Look at all the complaints about 6to4.   Most of them are applicable
> to brokered tunnels.  Remote tunnel endpoint, overloaded tunnels,
> no dead tunnel detection, non responsive tunnel administators.  HE
> have been good to me on that last point but there are other tunnel
> brokers that arn't anywhere near as responsive.  Remember most of
> the tunnel brokers arn't being paid to run the service.

My experience (albeit limited, anecdotal, etc.) has been universally 
positive with both HE and sixxs. I've had minor speed-bumps with both, 
and got the help I needed from either the vendor, the community forums, 
or both.

I also feel compelled to make the periodic repetition of a point I've 
made before, no one _needs_ IPv6 right now. There is no IPv6-only 
content, and there isn't going to be for years to come.

Having read some of the discussion about this on NANOG I would also take 
this a step further and say that if somehow we *do* reach a point where 
IPv6-only content is widespread enough to create an actual need for 
reliable IPv6 tunnels that the market will cause them to be created.


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 marka@isc.org  Wed May 11 20:08: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 7440EE0692 for ; Wed, 11 May 2011 20:08:25 -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 fx6BxQrDJsqR for ; Wed, 11 May 2011 20:08:24 -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 75ADCE0691 for ; Wed, 11 May 2011 20:08:24 -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 CF7D05F9863; Thu, 12 May 2011 03:08:03 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 8CF35216C31; Thu, 12 May 2011 03:08:01 +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 B477EEAFCC8; Thu, 12 May 2011 13:08:33 +1000 (EST)
To: Doug Barton 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB47D7.1000603@dougbarton.us>
In-reply-to: Your message of "Wed, 11 May 2011 19:37:11 MST." <4DCB47D7.1000603@dougbarton.us>
Date: Thu, 12 May 2011 13:08:33 +1000
Message-Id: <20110512030833.B477EEAFCC8@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 03:08:25 -0000

In message <4DCB47D7.1000603@dougbarton.us>, Doug Barton writes:
> On 05/11/2011 16:21, Mark Andrews wrote:
> > Look at all the complaints about 6to4.   Most of them are applicable
> > to brokered tunnels.  Remote tunnel endpoint, overloaded tunnels,
> > no dead tunnel detection, non responsive tunnel administators.  HE
> > have been good to me on that last point but there are other tunnel
> > brokers that arn't anywhere near as responsive.  Remember most of
> > the tunnel brokers arn't being paid to run the service.
> 
> My experience (albeit limited, anecdotal, etc.) has been universally 
> positive with both HE and sixxs. I've had minor speed-bumps with both, 
> and got the help I needed from either the vendor, the community forums, 
> or both.
> 
> I also feel compelled to make the periodic repetition of a point I've 
> made before, no one _needs_ IPv6 right now. There is no IPv6-only 
> content, and there isn't going to be for years to come.

You may not need IPv6 but I do need IPv6.  Different people, different
needs.

> Having read some of the discussion about this on NANOG I would also take 
> this a step further and say that if somehow we *do* reach a point where 
> IPv6-only content is widespread enough to create an actual need for 
> reliable IPv6 tunnels that the market will cause them to be created.
> 
> 
> 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/
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From dougb@dougbarton.us  Wed May 11 20:29: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 F0C30E06DA for ; Wed, 11 May 2011 20:29: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 VyZwAQOs6CFZ for ; Wed, 11 May 2011 20:29:43 -0700 (PDT)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 239AEE06CD for ; Wed, 11 May 2011 20:29:42 -0700 (PDT)
Received: (qmail 9614 invoked by uid 399); 12 May 2011 03:29:40 -0000
Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 12 May 2011 03:29:40 -0000
X-Originating-IP: 65.241.43.5
X-Sender: dougb@dougbarton.us
Message-ID: <4DCB5423.4050801@dougbarton.us>
Date: Wed, 11 May 2011 20:29:39 -0700
From: Doug Barton 
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB47D7.1000603@dougbarton.us> <20110512030833.B477EEAFCC8@drugs.dv.isc.org>
In-Reply-To: <20110512030833.B477EEAFCC8@drugs.dv.isc.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
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 03:29:44 -0000

On 05/11/2011 20:08, Mark Andrews wrote:
> You may not need IPv6 but I do need IPv6.  Different people, different
> needs.

And neither of us fall into the "average user" category.

Regardless, you made the point earlier, the need (such as it is) is 
IPv6, not 6to4.


-- 

	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 newbery@gmail.com  Wed May 11 20:50: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 E7FDDE0691 for ; Wed, 11 May 2011 20:50:10 -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 fl5zFVio3opN for ; Wed, 11 May 2011 20:50:10 -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 4AB60E065D for ; Wed, 11 May 2011 20:50:10 -0700 (PDT)
Received: by yic13 with SMTP id 13so500508yic.31 for ; Wed, 11 May 2011 20:50:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:mime-version:content-type:subject:date :in-reply-to:to:references:message-id:x-mailer; bh=+GwXtdaPeejK+RIiYknN6qKX8H4q/3ol5d/cylBnXrA=; b=Xidj8DRV2JRYlHU3SHkJLtopsmOBxph6lcbij1VP7MUizODpovWN8axzoJ9RmEXjRK wZlZxLA3pI4s/rkhVjPwTDJlhxqehTG5b3TqFNqjPPmQ9xGXOwg3YWGqEyuYndvIhAL+ WDLLNUweZtKNsAhJGaNYjrW9jtVotJhMVm1VI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=JSM06n2SGo/bLuZIqln0iI6+lYbXcFU6IRE7wtQ6OTbB4pz9vdTenyAvpyG0oZGS6P bFZwNHu1KD0Iq4O0mMZ4bfiO8ZO+BCk3BVavkCZ3Cqlop8hGpxKhV+PgGRvnVAbLGY5e 54kuxooGXXQWrQlIJzIMdUVOtx9I0xMighIOY=
Received: by 10.151.8.12 with SMTP id l12mr8696642ybi.423.1305172209732; Wed, 11 May 2011 20:50:09 -0700 (PDT)
Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id v35sm2399636yba.4.2011.05.11.20.50.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 20:50:09 -0700 (PDT)
From: Michael Newbery 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-1-447488203; protocol="application/pkcs7-signature"; micalg=sha1
Date: Thu, 12 May 2011 15:49:57 +1200
In-Reply-To: <4DCB47D7.1000603@dougbarton.us>
To: "v6ops@ietf.org WG" 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>		<4DC8D717.3080402@redpill-linpro.com>	<20110510064904.B5081E9E11B@drugs.dv.isc.org>	<4DCA5121.9010809@redpill-linpro.com>	<20110511121453.D438CEAA1A5@drugs.dv.isc.org>	<0F0C1186-50F6-4305-92E0-B833C0520127@employees.org>	<20110511144736.77E3AEAAEDA@drugs.dv.isc.org>	<4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB47D7.1000603@dougbarton.us>
Message-Id: 
X-Mailer: Apple Mail (2.1084)
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 03:50:11 -0000

--Apple-Mail-1-447488203
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On 12/05/2011, at 2:37 PM, Doug Barton wrote:
> I also feel compelled to make the periodic repetition of a point I've =
made before, no one _needs_ IPv6 right now. There is no IPv6-only =
content, and there isn't going to be for years to come.
>=20

That mischaracterizes the Internet as being just the Web (or a few =
content providers and many content consumers). The Internet has, and has =
always had, a significant amount of direct communication.

Right now there is a tiny amount of users with only IPv6. If you want to =
communicate with these users: play an on-line game, VoIP (including =
video), etc. then YOU need IPv6. Right now.

As the number of such users increases, the need for IPv6 in the general =
Internet will increase, and not in a linear fashion. LTE for instance is =
about to magnify the amount of IPv6 users dramatically. Very soon, NOT =
"years to come", there will be enough of the Internet (end users) that =
are accessible only via IPv6 that to be connected to the Internet will =
mean having an IPv6 address. At which point, the hosting sites will =
start to think about saving costs by not bothering with IPv4.

Imagine "Irritated Avians 2" comes out with a cooperative direct network =
play mode. You enjoy playing it, and want to match up with your friend =
on Berizontal LTE. But you can't because YOUR ISP doesn't support =
IPv6---but your other friend next door with a different ISP has no such =
problems...


--Apple-Mail-1-447488203
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw
ggMYoAMCAQICAwm5xTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL
ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp
dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMTAxMjAyMTA2MjdaFw0x
MTA3MTkyMTA2MjdaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR
bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y
bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b
cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD
V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87
1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI
6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC
AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo
dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE
AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB
hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G
CSqGSIb3DQEBBQUAA4ICAQBlGZdPhl6SR3KKK1xXL41nqIAK9To0lIZXaqxtanIa083BHH07icuV
YydeekqgxqO6z0A/3HOEJOESV5eUB9bly7zHRh7CIOB++6WzaVrFTa4yoUmhXeHF3HJmaUaxJBSl
R4po3vPoii81nFIg4NSRLtRQw0ClVEvaJMkipgAWGu+b42tMNQolxBF6sCh6VOzoz9Q5t+4bwu+v
d94tSGoSfuyV0sBVVaIz08VZUPYKYEM6nYEMiJzDhgH09b4CtQJ46o+YyyDb59xcuEyEd00B1tWS
WUfqrYehN/W60FjopddWrG9+HaZu5+2Fz3L+da8Ggjj0g1r00cRcUURUpll+yH06D+YbhbH03kP9
P7juyvO9VfDMqYNh301h1g8PM/dDaHCUthpzedwwYeNsyTFGqzcFfsuxXvK/4BkHGPcFkyxQlqTc
cWGbdxXrz42zY/ndRvzEWZ5AnlIIOsWzIySEAzhmGdlc462/kCbO8SisJYfriMcGHrJKwA2X3o8E
DJ5tWayiInI/mv4BpKgIKKF5lNWgMVbYcTPtUCoCOl4mefFX+yCan/bxjRL6ae8HOMyUS6fg1v61
ypEh8WoXcoYbiGPmWP5uSpDK8Y2UGJ70T59RUgjyryFTIriZKJDZUtAD6gr0QPuQn+Fidb00OKYp
XrWcXFmOdxph1ZFNMgg5ETGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV
BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv
cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJucUwCQYFKw4DAhoFAKCC
AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNTEyMDM1MDAz
WjAjBgkqhkiG9w0BCQQxFgQUczPeJgWSKkRHCVlMAA6n7AQeoREwgZEGCSsGAQQBgjcQBDGBgzCB
gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg
BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA
Y2FjZXJ0Lm9yZwIDCbnFMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB
MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCbnFMA0GCSqG
SIb3DQEBAQUABIIBAIj4w//oJ4jSNyLxawM8WlwCSHGn2exuLjLdRa7fDYHbGNLJvv+Feg8OEz2n
oJLAx2FXKt1c0vB49DegC2TVlH0/362wparhP7api2PwDSDGce1Ce6u1Zb7lb3xMxyyEVmKdDWmF
/X8H4hfzRf9Twu1l8R6pDAi0l4jAoUjMpLME6cq2YfNozwq4xrdnp4Avoh1WLprHrXZlO1geBOpO
LxoPTUSjkl5l+o7MKmtQb1FNW3U2btQ/sgb9JaQFIHe70Tk/9pUmkI8cyIpiMklh5vJOa+ljdBGg
Nq68cj/3EyMWpTEWIHob8gmgANtDq+gfh8Qm7DGXB7V0W8JXQQVQQV8AAAAAAAA=

--Apple-Mail-1-447488203--

From tore.anderson@redpill-linpro.com  Wed May 11 22:54: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 192D8E06AD for ; Wed, 11 May 2011 22:54:29 -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 aJxnZTx6NIOz for ; Wed, 11 May 2011 22:54:28 -0700 (PDT)
Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id ECA25E06A7 for ; Wed, 11 May 2011 22:54:27 -0700 (PDT)
Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id E544BCC1AA; Thu, 12 May 2011 07:54:25 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at linpro.no
Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id jhWBIUVsojIs; Thu, 12 May 2011 07:54:24 +0200 (CEST)
Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Thu, 12 May 2011 07:54:24 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 52D1B170C00B; Thu, 12 May 2011 07:54:24 +0200 (CEST)
X-Virus-Scanned: amavisd-new at claudius.linpro.no
Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEmUtDtvojW3; Thu, 12 May 2011 07:54:23 +0200 (CEST)
Received: from envy.fud.no (221-42-232.connect.netcom.no [178.232.42.221]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 6D9DC170C00A; Thu, 12 May 2011 07:54:19 +0200 (CEST)
Message-ID: <4DCB7609.3020802@redpill-linpro.com>
Date: Thu, 12 May 2011 07:54:17 +0200
From: Tore Anderson 
Organization: Redpill Linpro AS
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org>
In-Reply-To: <20110511232129.A5DFDEAD470@drugs.dv.isc.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 05:54:29 -0000

* Mark Andrews

> In message <4DCAC64C.7030607@redpill-linpro.com>, Tore Anderson writes:
>> * Mark Andrews
>>
>>>>> One of the prime uses of this would be to turn off 6to4.  Lots
>>>>> of machines that run 6to4 could be updated by their users today
>>>>> to check for 0.0.0.0 if they only had the code point.  This can
>>>>> be done with end user configuration.
>>>>
>>>> if those users could be convinced to upgrade their system for this
>>>> option, why couldn't the also then be convinced to just disable
>>>> 6to4?
>>>
>>> Because they NEED IPv6 and 6to4 is the option the currently have 
>>> working.
>>
>> I'm really confused as to how you mean your proposed DHCP option will
>> help these users. If the user NEEDS 6to4 to work, yet is in a network
>> where 6to4 DOESN'T work, how does the DHCP server informing him of that
>> fact make him any less SOL?
> 
> Please re-read what is needed.  It is *IPv6* not 6to4.  6to4 is the
> means.

You wrote that the users in question could not disable 6to4 because they
NEEDED IPv6, implying that 6to4 was the only usable option avaliable to
them. It follows logically, then, that they NEED 6to4. If they don't,
your reason why they cannot disable it makes no sense.

In any case, the talk about non-6to4 based connectivity, whether
brokered tunnels or native, is a red herring. Your draft is about 6to4,
after all.

So, If I have understood correctly, the arguments you made in the
message I was replying to, were:

1) There are users that have an absolute need for IPv6 connectivity
2) Use of 6to4 is the only solution available to them
3) They will therefore override a 6to4-default-off setting
4) They are possibly completely happy using 6to4
5) Making 6to4 «crash and burn» would be a disservice to these user

They way I see it, your arguments seems to support Brian's -advisory
draft, and perhaps also oppose Ole's -to-historic draft, instead of
actually make the case for why your own draft is a good idea.

At least I fail to understand how your draft will have any effect on
these 6to4 users you're talking about. Either 1) they are already
happily using 6to4 and will be able to continue to do so without any new
DHCP options, or 2) they're in a network where 6to4 doesn't work and
they'll be without their much-needed IPv6 connectivity, regardless of
any new DHCP options.

How exactly does your draft benefit the 6to4 users you're concerned
about? Or, if the draft doesn't benefit them, how are their problems
relevant to the discussion?

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

From marka@isc.org  Thu May 12 00:33: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 67F45E070C for ; Thu, 12 May 2011 00:33: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=[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 er7i+Hew5Y23 for ; Thu, 12 May 2011 00:33:42 -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 E46D8E0700 for ; Thu, 12 May 2011 00:33:41 -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 309445F9936; Thu, 12 May 2011 07:33:26 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 D4336216C31; Thu, 12 May 2011 07:33:23 +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 EB4CCEB0BC6; Thu, 12 May 2011 17:33:53 +1000 (EST)
To: Tore Anderson 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com>
In-reply-to: Your message of "Thu, 12 May 2011 07:54:17 +0200." <4DCB7609.3020802@redpill-linpro.com>
Date: Thu, 12 May 2011 17:33:53 +1000
Message-Id: <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 07:33:43 -0000

In message <4DCB7609.3020802@redpill-linpro.com>, Tore Anderson writes:
> * Mark Andrews
> 
> > In message <4DCAC64C.7030607@redpill-linpro.com>, Tore Anderson writes:
> >> * Mark Andrews
> >>
> >>>>> One of the prime uses of this would be to turn off 6to4.  Lots
> >>>>> of machines that run 6to4 could be updated by their users today
> >>>>> to check for 0.0.0.0 if they only had the code point.  This can
> >>>>> be done with end user configuration.
> >>>>
> >>>> if those users could be convinced to upgrade their system for this
> >>>> option, why couldn't the also then be convinced to just disable
> >>>> 6to4?
> >>>
> >>> Because they NEED IPv6 and 6to4 is the option the currently have 
> >>> working.
> >>
> >> I'm really confused as to how you mean your proposed DHCP option will
> >> help these users. If the user NEEDS 6to4 to work, yet is in a network
> >> where 6to4 DOESN'T work, how does the DHCP server informing him of that
> >> fact make him any less SOL?
> > 
> > Please re-read what is needed.  It is *IPv6* not 6to4.  6to4 is the
> > means.
> 
> You wrote that the users in question could not disable 6to4 because they
> NEEDED IPv6, implying that 6to4 was the only usable option avaliable to
> them. It follows logically, then, that they NEED 6to4. If they don't,
> your reason why they cannot disable it makes no sense.

Take 2 networks.  1 with IPv6, one without IPv6.  You have a machine
that is moving between the two networks.  You don't want the machine
to use 6to4 on the first.  You do want it to use 6to4 on the second.
Expecting the user to remember to enable and disable 6to4 everytime
the machine moves is 1. unrealistic and 2. error prone.   Having
network 1 tell the machine to not use 6to4 as part of the process of
connecting to the network prevents the error condition.

> In any case, the talk about non-6to4 based connectivity, whether
> brokered tunnels or native, is a red herring. Your draft is about 6to4,
> after all.

When the default reply is "Just kill 6to4" you need to justify why
the alternatives don't work or are just as bad.

> So, If I have understood correctly, the arguments you made in the
> message I was replying to, were:
> 
> 1) There are users that have an absolute need for IPv6 connectivity
> 2) Use of 6to4 is the only solution available to them
> 3) They will therefore override a 6to4-default-off setting
> 4) They are possibly completely happy using 6to4
> 5) Making 6to4 «crash and burn» would be a disservice to these user

> They way I see it, your arguments seems to support Brian's -advisory
> draft, and perhaps also oppose Ole's -to-historic draft, instead of
> actually make the case for why your own draft is a good idea.
> 
> At least I fail to understand how your draft will have any effect on
> these 6to4 users you're talking about. Either 1) they are already
> happily using 6to4 and will be able to continue to do so without any new
> DHCP options, or 2) they're in a network where 6to4 doesn't work and
> they'll be without their much-needed IPv6 connectivity, regardless of
> any new DHCP options.

The problem is that you are failing to take into account that
machines move between networks.  DHCP is about configuring the
machine for the network it is currently connecting to.

> How exactly does your draft benefit the 6to4 users you're concerned
> about? Or, if the draft doesn't benefit them, how are their problems
> relevant to the discussion?

It benefits them by allowing the machine to correctly configure
itself to the properties of the network it is connecting to.

> Best regards,
> -- 
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com/
> Tel: +47 21 54 41 27
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From pch-b6B5344D9@u-1.phicoh.com  Thu May 12 02: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 250B3E0748 for ; Thu, 12 May 2011 02:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 pvwiTSLS5UdB for ; Thu, 12 May 2011 02:02:09 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0D6E0745 for ; Thu, 12 May 2011 02:02:08 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QKRmZ-0001izC; Thu, 12 May 2011 11:02:07 +0200
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> 
In-reply-to: Your message of "Thu, 12 May 2011 17:33:53 +1000 ." <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> 
Sender: pch-b6B5344D9@u-1.phicoh.com
Date: Thu, 12 May 2011 11:02:06 +0200
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 09:02:10 -0000

In your letter dated Thu, 12 May 2011 17:33:53 +1000 you wrote:
>Take 2 networks.  1 with IPv6, one without IPv6.  You have a machine
>that is moving between the two networks.  You don't want the machine
>to use 6to4 on the first.  You do want it to use 6to4 on the second.
>Expecting the user to remember to enable and disable 6to4 everytime
>the machine moves is 1. unrealistic and 2. error prone.   Having
>network 1 tell the machine to not use 6to4 as part of the process of
>connecting to the network prevents the error condition.

So, write a script that hooks to the dhcp client and enables 6to4 only if 
the IPv4 address is in a certain range. Problem solved.



From tore.anderson@redpill-linpro.com  Thu May 12 04:18: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 D19A8E0770 for ; Thu, 12 May 2011 04:18:23 -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 uuxenxMYQeyH for ; Thu, 12 May 2011 04:18:19 -0700 (PDT)
Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id 85CE0E0768 for ; Thu, 12 May 2011 04:18:19 -0700 (PDT)
Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id 8570A1DD6EA; Thu, 12 May 2011 13:18:17 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at linpro.no
Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id ugBLwhNG5kV6; Thu, 12 May 2011 13:18:17 +0200 (CEST)
Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Thu, 12 May 2011 13:18:16 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id C4ED7170C00B; Thu, 12 May 2011 13:18:15 +0200 (CEST)
X-Virus-Scanned: amavisd-new at claudius.linpro.no
Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tv5sfbvHeabz; Thu, 12 May 2011 13:18:11 +0200 (CEST)
Received: from envy.fud.no (unknown [91.214.253.101]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 9BD87170C00A; Thu, 12 May 2011 13:18:10 +0200 (CEST)
Message-ID: <4DCBC1F1.7030600@redpill-linpro.com>
Date: Thu, 12 May 2011 13:18:09 +0200
From: Tore Anderson 
Organization: Redpill Linpro AS
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>
In-Reply-To: <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 11:18:23 -0000

* Mark Andrews

> Take 2 networks.  1 with IPv6, one without IPv6.  You have a machine
> that is moving between the two networks.  You don't want the machine
> to use 6to4 on the first.  You do want it to use 6to4 on the second.
> Expecting the user to remember to enable and disable 6to4 everytime
> the machine moves is 1. unrealistic and 2. error prone.   Having
> network 1 tell the machine to not use 6to4 as part of the process of
> connecting to the network prevents the error condition.

Okay. I think I understand now. The point is to make the failure mode
when in networks that don't support 6to4 somewhat more smooth in that
the 6to4 interface won't come up at all, instead of becoming a black
hole. Correct?

In that case, I can see that there is some value in it, but I don't
think that benefit justifies the effort. There's a lot of
implementations out there that needs to be changed, CPE/hosts and
networks needs to implement both in order for it to be effective. I
think it's simply not worth while to begin such an endeavour at this
point in time, considering that you're not actually solving the user's
main problem, i.e., no IPv6 connectivity.

That said, I'd be more inclined to support a draft, or perhaps a new
section in the -advisory document, that instructed the hosts/CPEs to
probe the reliability of the outbound relay. For example by sending an
encapsulated ICMPv6 packet to 192.88.99.1 with IPv6 SRC=DST=[it's own
6to4 address]. If it doesn't come back, then don't enable the 6to4
interface. This would, as far as I can tell, accomplish the same
smoother failure mode as your draft when in networks that don't support
6to4, without requiring explicit support from the ISP (or the use of
DHCP for that matter).

Furthermore, I understand that major vendors such as Apple and Microsoft
have implemented, or are about to implement, [something similar] to this
already.

>> In any case, the talk about non-6to4 based connectivity, whether
>> brokered tunnels or native, is a red herring. Your draft is about 6to4,
>> after all.
> 
> When the default reply is "Just kill 6to4" you need to justify why
> the alternatives don't work or are just as bad.

Your draft isn't about the killing or not killing of 6to4, so again,
this is a red herring.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

From tjc@ecs.soton.ac.uk  Thu May 12 04:23: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 231F0E0779 for ; Thu, 12 May 2011 04:23:23 -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 y-C0AYlAJDeF for ; Thu, 12 May 2011 04:23: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 D1FB0E0777 for ; Thu, 12 May 2011 04:23:17 -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 p4CBNCf4031333 for ; Thu, 12 May 2011 12:23:12 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p4CBNCf4031333
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1305199393; bh=fPzd4cJ+Kpyr79/hCk3H54wtJ4s=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=bvHayQaoGbkUxpA3WP4W+BTQ0B2SwmrD08nB34ffK44Tv+tH11yRuHTBzt1Jzmilb euFDHk1QI+ou7ThU6offmHU9Xl5S2OJBFBuWfrZ7P8Uzmij9UVHY/4/B6q0S1eDVvq F076Ct1UAL8CbFM54/dPezblcgZU4hI01sQwHpPU=
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 n4BCNC0035606993ly ret-id none; Thu, 12 May 2011 12:23:12 +0100
Received: from dhcp-152-78-94-75.ecs.soton.ac.uk (dhcp-152-78-94-75.ecs.soton.ac.uk [152.78.94.75]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p4CBN9mi007149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 12 May 2011 12:23:10 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
From: Tim Chown 
In-Reply-To: <20110510203939.GB9004@dyn-72-33-195-206.uwnet.wisc.edu>
Date: Thu, 12 May 2011 12:23:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <4DC29A96.6020709@globis.net>  <20110506005809.C526CE848C9@drugs.dv.isc.org>  <20110510203939.GB9004@dyn-72-33-195-206.uwnet.wisc.edu> <0A63FDF8-594D-4D8F-A44C-90BDE7E31D72@ecs.soton.ac.uk>
To: "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.1082)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n4BCNC003560699300; tid=n4BCNC0035606993ly; 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: p4CBNCf4031333
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 12 May 2011 11:23:23 -0000

On 10 May 2011, at 21:39, Dale W. Carder wrote:

> Thus spake Erik Kline (ek@google.com) on Fri, May 06, 2011 at =
09:10:40AM +0200:
>>>> The whitelisting is indeed designed to avoid the problems and allow
>>>> IPv6 to be more broadly served to those who are properly able to =
make
>>>> use of it.
>>>=20
>>> And there are plenty that can use IPv6 but can't get AAAA records
>>> due to whitelisting.
>=20
> Our site would fall into this category (for small cases of "plenty").

I would assume a lot of universities fall into this category; certainly =
ones in the UK I've spoken to about it do.   The academic networks, at =
least the backbones, have been at the forefront of IPv6 deployment.

We have dual-stack in our internal network, and publicly facing =
services, and have done for many years. =20
We have native connectivity to our academic ISP (JANET)
JANET is natively dual-stacked (at 100Gbit/s now)
JANET has a fat dual-stack peering (10G?) with Google.
Yet we don't get AAAA for Google services, because we're not in the =
'experiment'.
At least until June 8th :)

I would have hoped Google to be production AAAA by the end of 2011, so =
we're not *that* concerned about it.  Or maybe this whitelisting =
approach will be longer-term.  We'll see :)

Tim=

From marka@isc.org  Thu May 12 05:05: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 E0AC8E074E for ; Thu, 12 May 2011 05:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 Fm+aryocNixI for ; Thu, 12 May 2011 05:05:29 -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 85343E0772 for ; Thu, 12 May 2011 05:05:29 -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 617EFC94D9; Thu, 12 May 2011 12:05:17 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 07910216C31; Thu, 12 May 2011 12:05:17 +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 D86CCEB14E6; Thu, 12 May 2011 22:05:51 +1000 (EST)
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <101EB3C5-9FD2-48CB-9BA7-7452F08E19E0@free.fr>
In-reply-to: Your message of "Thu, 12 May 2011 11:03:11 +0200." <101EB3C5-9FD2-48CB-9BA7-7452F08E19E0@free.fr>
Date: Thu, 12 May 2011 22:05:51 +1000
Message-Id: <20110512120551.D86CCEB14E6@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 12:05:35 -0000

In message <101EB3C5-9FD2-48CB-9BA7-7452F08E19E0@free.fr>, =?iso-8859-1?Q?R=E9m
i_Despr=E9s?= writes:
> 
> Le 10 mai 2011 =E0 08:49, Mark Andrews a =E9crit :
> > ... 6rd is basically
> > undeployable if the ISP doesn't supply the CPE equipment. =20
> 
> See lists.cluenet.de/pipermail/ipv6-ops/2011-January/004711.html
> Some vendor CPE's do support 6rd.

Which is good and I encourage more.
 
> Regards,
> RD=
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From dwcarder@wisc.edu  Thu May 12 05:07: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 C3BD2E06D7 for ; Thu, 12 May 2011 05:07: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 nEtV3PBg6jkt for ; Thu, 12 May 2011 05:07:48 -0700 (PDT)
Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by ietfa.amsl.com (Postfix) with ESMTP id 950C8E069B for ; Thu, 12 May 2011 05:07:48 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LL300A000CZIB00@smtpauth3.wiscmail.wisc.edu> for v6ops@ietf.org; Thu, 12 May 2011 07:07:47 -0500 (CDT)
Received: from dc119.internet2.edu ([unknown] [192.52.179.119]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LL300A0R0CYGA00@smtpauth3.wiscmail.wisc.edu>; Thu, 12 May 2011 07:07:46 -0500 (CDT)
Date: Thu, 12 May 2011 07:07:45 -0500
From: "Dale W. Carder" 
In-reply-to: 
To: John Mann  (ITS)
Message-id: 
X-Mailer: Apple Mail (2.1084)
X-Spam-PmxInfo: Server=avs-10, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.12.114816, SenderIP=192.52.179.119
References: <4DC29A96.6020709@globis.net>  <20110506005809.C526CE848C9@drugs.dv.isc.org>  <20110510203939.GB9004@dyn-72-33-195-206.uwnet.wisc.edu> 
Cc: Erik Kline , "v6ops@ietf.org WG" , Ray Hunter 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 12 May 2011 12:07:52 -0000

On May 11, 2011, at 2:39 AM, John Mann (ITS) wrote:
> 
> On 11 May 2011 06:39, Dale W. Carder  wrote:
> ...
> Since some of our recursive servers are used by a diverse group of users
> in managed and unmanaged academic and residentual settings it is my
> understanding that it would be inappropriate to whitelist our servers
> because of the alleged brokenness of some amount of the hosts using those
> resolvers.
> 
> You should be able to measure brokenness of your users by adding a web bug to the front page of a few of your own commonly visited sites
> e.g. add http://www.getipv6.info/index.php/Warning_broken_users_with_JavaScript
> to  www.example.com  mail.example.com  portal.example.com ...
> This will flag to users that they have problems.
> Analysing the logs carefully should tell you who and how many work or have problems.

This would scale fine for our main campus (AS 59), but it's half of 
the million or so users of our statewide isp service (AS 2381) is the 
real issue...  basically the schools where the "IT guy" is really the
math teacher.

It is my hope that data collection from v6-day and/or the "happy-eyeballs"
approach could be the planned obsolescence of whitelisting.  I just now 
realize I don't see a reference to happy-eyeballs in the draft.  Would 
that be appropriate?

Dale


From pekkas@netcore.fi  Thu May 12 05:48: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 543E3E0710 for ; Thu, 12 May 2011 05:48:58 -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 9M+t7CExq09C for ; Thu, 12 May 2011 05:48:57 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F797E069B for ; Thu, 12 May 2011 05:48:57 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p4CCmjaN010589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 May 2011 15:48:45 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p4CCmjuK010586; Thu, 12 May 2011 15:48:45 +0300
Date: Thu, 12 May 2011 15:48:44 +0300 (EEST)
From: Pekka Savola 
To: Tore Anderson 
In-Reply-To: <4DCBC1F1.7030600@redpill-linpro.com>
Message-ID: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi
X-Virus-Status: Clean
Cc: v6ops@ietf.org
Subject: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 12 May 2011 12:48:58 -0000

On Thu, 12 May 2011, Tore Anderson wrote:
> That said, I'd be more inclined to support a draft, or perhaps a new
> section in the -advisory document, that instructed the hosts/CPEs to
> probe the reliability of the outbound relay. For example by sending an
> encapsulated ICMPv6 packet to 192.88.99.1 with IPv6 SRC=DST=[it's own
> 6to4 address]. If it doesn't come back, then don't enable the 6to4
> interface. This would, as far as I can tell, accomplish the same
> smoother failure mode as your draft when in networks that don't support
> 6to4, without requiring explicit support from the ISP (or the use of
> DHCP for that matter).
>
> Furthermore, I understand that major vendors such as Apple and Microsoft
> have implemented, or are about to implement, [something similar] to this
> already.

Nit-pick:

The relay is not supposed to get address where both the source and 
destination are from 2002::/16 prefix, so it could legitimately drop 
it. (That's recommended in RFC3964.) I'm not sure if relays in general 
do this or not.

But in any case, the test e.g. done by MS has at least 5-6 years of 
deployment experience behind it and it accomplishes almost the same 
thing -- also not requiring any support.

FWIW, I agree that recommending a connectivity test procedure is much 
better than providing a DHCP option.  I'm not adamant on adding a 
recommendation to do the test prodecure in -advisory (as I can see the 
argument that even this is not worth the effort at this point), but I 
think it would probably be a good idea to do so.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From pch-b6B5344D9@u-1.phicoh.com  Thu May 12 06:11: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 47DCDE0796 for ; Thu, 12 May 2011 06:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 kgYvwmdn5gds for ; Thu, 12 May 2011 06:11: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 94139E0798 for ; Thu, 12 May 2011 06:11:22 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QKVfl-0001iYC; Thu, 12 May 2011 15:11:21 +0200
Message-Id: 
To: Mark Andrews 
From: Philip Homburg 
Sender: pch-b6B5344D9@u-1.phicoh.com
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>  <20110512115921.C19F9EB1365@drugs.dv.isc.org> 
In-reply-to: Your message of "Thu, 12 May 2011 21:59:21 +1000 ." <20110512115921.C19F9EB1365@drugs.dv.isc.org> 
Date: Thu, 12 May 2011 15:11:06 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 13:11:31 -0000

In your letter dated Thu, 12 May 2011 21:59:21 +1000 you wrote:
>
>In message , Philip Homburg writes:
>> In your letter dated Thu, 12 May 2011 17:33:53 +1000 you wrote:
>> >Take 2 networks.  1 with IPv6, one without IPv6.  You have a machine
>> >that is moving between the two networks.  You don't want the machine
>> >to use 6to4 on the first.  You do want it to use 6to4 on the second.
>> >Expecting the user to remember to enable and disable 6to4 everytime
>> >the machine moves is 1. unrealistic and 2. error prone.   Having
>> >network 1 tell the machine to not use 6to4 as part of the process of
>> >connecting to the network prevents the error condition.
>> 
>> So, write a script that hooks to the dhcp client and enables 6to4 only if 
>> the IPv4 address is in a certain range. Problem solved.
>
>Which doesn't work in the general case.  

This is just a user interface issue. If it happens a lot you may want a 
widget on the desktop to inform you about the status of 6to4. No big deal.
It is not that different from connecting to a wifi network.

>It also doesn't help when
>ISP's start putting clients behind CGN's which wern't before.

It works perfectly for that case. Instead of a global address you now get an
RFC-1918 address and 6to4 stays disabled.

>Address don't indicate properties of networks.  

No, but (non-1918) addresses tend to correlate very well with location. And
if you want to enable 6to4 only in a specific location, then doing pattern 
matching on the IP address works very well.

>It also doesn't
>help when the ISP gives you different addresses each day.

Then don't put a single address there but match on a pattern. 



From lorenzo@google.com  Thu May 12 07:35: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 D097BE06B9 for ; Thu, 12 May 2011 07:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 KYDssO+WKEkA for ; Thu, 12 May 2011 07:35: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 CA6E4E06BE for ; Thu, 12 May 2011 07:35:38 -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 p4CEZWt7029957 for ; Thu, 12 May 2011 07:35:33 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305210938; bh=ym90KFimH6Q88LicgKcGDXAk1Yc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=aGKXz+v3SyJUibfHtarc2f6Nl9DXRFoFRU0QwpMx/CDJCnjTvvA5n9NW7kHeHe5xT pHyaXFCu/m9AYazAZddqQ==
Received: from gyf3 (gyf3.prod.google.com [10.243.50.67]) by kpbe12.cbf.corp.google.com with ESMTP id p4CEZBIK015914 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 12 May 2011 07:35:31 -0700
Received: by gyf3 with SMTP id 3so675801gyf.31 for ; Thu, 12 May 2011 07:35:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xKHGNIV/44tcTO1WNeah7573clB97eB+fQIdX65yLZI=; b=HBlVXcWfOTyBahxrLCARgCkwGePwk4B7E86BysGZF5nHsvVzSFwDZxjcgXe1zDQpl0 dL17XzydHhNVVY6s4rjw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fy25CnC4CIl0BfhuS1BoB6me3ELFj6X2QssIUlpXRb7ImmCy1SR7z0RhTOIYQcWLiG y0tst0U98WvWSOvSoldg==
MIME-Version: 1.0
Received: by 10.151.77.31 with SMTP id e31mr340062ybl.435.1305210931334; Thu, 12 May 2011 07:35:31 -0700 (PDT)
Received: by 10.151.101.5 with HTTP; Thu, 12 May 2011 07:35:31 -0700 (PDT)
Received: by 10.151.101.5 with HTTP; Thu, 12 May 2011 07:35:31 -0700 (PDT)
In-Reply-To: <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>
Date: Thu, 12 May 2011 07:35:31 -0700
Message-ID: 
From: Lorenzo Colitti 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=000e0cd63100eb4d1e04a3151971
X-System-Of-Record: true
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 14:35:39 -0000

--000e0cd63100eb4d1e04a3151971
Content-Type: text/plain; charset=ISO-8859-1

On May 12, 2011 12:34 AM, "Mark Andrews"  wrote:
> Take 2 networks.  1 with IPv6, one without IPv6.  You have a machine
> that is moving between the two networks.  You don't want the machine
> to use 6to4 on the first.  You do want it to use 6to4 on the second.

No, you don't. If you are an operator, you *never* want to use 6to4 -
because it's not reliable. You may be able to control for firewalls in your
network and install relays 0ms away from every client, but there is still
the major problem that the reverse path is completely unknown and may be
going through random third-party relays that could on a whim decide to drop
or rate-limit your traffic. And there's nothing you can do about it because
it depends on which BGP announcement the other side happened to choose. This
is worse than native traffic because at least there you have some control in
the form of prepending and so on.

Giving your users connectivity you can't control is assuming responsibility
for bad service without being able to fix it, and this is something that
operators tend to avoid like the plague because they don't like support
costs.

--000e0cd63100eb4d1e04a3151971
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On May 12, 2011 12:34 AM, "Mark Andrews" <marka@isc.org> wrote:

> Take 2 networks. =A01 with IPv6, one without IPv6. =A0You have a machi=
ne

> that is moving between the two networks. =A0You don't want the mac=
hine

> to use 6to4 on the first. =A0You do want it to use 6to4 on the second.=



No, you don't. If you are an operator, you *never* want to use 6to4 =
- because it's not reliable. You may be able to control for firewalls i=
n your network and install relays 0ms away from every client, but there is =
still the major problem that the reverse path is completely unknown and may=
 be going through random third-party relays that could on a whim decide to =
drop or rate-limit your traffic. And there's nothing you can do about i=
t because it depends on which BGP announcement the other side happened to c=
hoose. This is worse than native traffic because at least there you have so=
me control in the form of prepending and so on.



Giving your users connectivity you can't control is assuming respons=
ibility for bad service without being able to fix it, and this is something=
 that operators tend to avoid like the plague because they don't like s=
upport costs.



--000e0cd63100eb4d1e04a3151971--

From jhw@apple.com  Thu May 12 08:07: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 3C325E079C for ; Thu, 12 May 2011 08:07:02 -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 X0-o+1iwiogr for ; Thu, 12 May 2011 08:07:01 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id BD833E0758 for ; Thu, 12 May 2011 08:07:01 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LL300MQ98GSPCB1@mail-out.apple.com> for v6ops@ietf.org; Thu, 12 May 2011 08:07:01 -0700 (PDT)
X-AuditID: 11807137-b7cd4ae000003108-c4-4dcbf7943525
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 relay16.apple.com (Apple SCV relay) with SMTP id AE.17.12552.497FBCD4; Thu, 12 May 2011 08:07:01 -0700 (PDT)
Received: from [172.16.1.2] (adit.conjury.org [75.101.54.88]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LL3001IT8NOIH90@koseret.apple.com> for v6ops@ietf.org; Thu, 12 May 2011 08:07:00 -0700 (PDT)
From: james woodyatt 
In-reply-to: 
Date: Thu, 12 May 2011 08:07:00 -0700
Message-id: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> 
To: "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.1226)
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 15:07:02 -0000

On May 12, 2011, at 7:35 AM, Lorenzo Colitti wrote:
> 
>  If you are an operator, you *never* want to use 6to4 - because it's not reliable.

This isn't strictly true.  If you're an IPv4-only operator of a public access network, then you probably want to make 6to4 available for users who are willing to put up with the unreliability or who have specific destinations in mind, like their home networks, that are known to have a reverse path relay.

I assume this is why we don't feel inclined to publish a phase-out plan for 6to4.


--
james woodyatt 
member of technical staff, core os networking




From cb.list6@gmail.com  Thu May 12 08:43: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 7B068E06E2 for ; Thu, 12 May 2011 08:43:27 -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 ZJBfkDx1qAsN for ; Thu, 12 May 2011 08:43:25 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83E64E067A for ; Thu, 12 May 2011 08:43:24 -0700 (PDT)
Received: by eye13 with SMTP id 13so594381eye.31 for ; Thu, 12 May 2011 08:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pXv8foDuGXNlZGh7pDipEnpfqPTgCJqFXsRihsFC9d8=; b=Nphy+5UTKF0Mu1QJGUQAtWms9lBK6JHOPQBhLxDuaRVax24Pk1pyoCyNR7kThDjnPm G/Mu0sTi6qs/QZKdpgvqHZHKl2KgutiYJGU13fiW38MXBjpePMXRe/u3c45h/VPGt6Ri S1p128AIJ3PEZwNTYSlZEr3oP5YqwiRa6O2fk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UNoPUcK32SGom4w2GM95Es2KZBGd+3CZvP1jr52SPQhPZYCx5wL9cakN9Bz/EKnW2/ 2GrRSU9CWLhZeTdjn2XsFAtCg49DY7naoHasly2e1f7DzPO7eyfKhRMKHsNj32Cwjp+u NNfENW3NgKL7xF0M9T3PwcLcoeKzfWBrgfswI=
MIME-Version: 1.0
Received: by 10.14.27.140 with SMTP id e12mr180054eea.185.1305215003586; Thu, 12 May 2011 08:43:23 -0700 (PDT)
Received: by 10.14.37.143 with HTTP; Thu, 12 May 2011 08:43:23 -0700 (PDT)
Received: by 10.14.37.143 with HTTP; Thu, 12 May 2011 08:43:23 -0700 (PDT)
In-Reply-To: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>  
Date: Thu, 12 May 2011 08:43:23 -0700
Message-ID: 
From: Cameron Byrne 
To: james woodyatt 
Content-Type: multipart/alternative; boundary=bcaec52be9d1a4f02904a3160cd6
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 15:43:27 -0000

--bcaec52be9d1a4f02904a3160cd6
Content-Type: text/plain; charset=ISO-8859-1

On May 12, 2011 8:07 AM, "james woodyatt"  wrote:
>
> On May 12, 2011, at 7:35 AM, Lorenzo Colitti wrote:
> >
> >  If you are an operator, you *never* want to use 6to4 - because it's not
reliable.
>
> This isn't strictly true.  If you're an IPv4-only operator of a public
access network, then you probably want to make 6to4 available for users who
are willing to put up with the unreliability or who have specific
destinations in mind, like their home networks, that are known to have a
reverse path relay.
>
> I assume this is why we don't feel inclined to publish a phase-out plan
for 6to4.
>
>

James, are you speaking on behalf of an operator who cannot speak for
themselves?

There seems to be a misconception that consumers want or care about ipv6.
They don't. Yet, real ipv6 is needed to *replace* ipv4 for engineering
reasons.

IMHO, 6to4 is a techies trick. What Mark has published is not for the
benefit of the internet at large, it is a clever script that is more fit for
a FREEBSD users group.

I have yet to encounter anything beyond boutique network operators that
believe 6to4 is a supportable technology that has a place in the current and
going forward reality of this network of netkworks.

Cb

> --
> james woodyatt 
> member of technical staff, core os networking
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--bcaec52be9d1a4f02904a3160cd6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On May 12, 2011 8:07 AM, "james woodyatt" <jhw@apple.com> wrote:

>

> On May 12, 2011, at 7:35 AM, Lorenzo Colitti wrote:

> >

> > =A0If you are an operator, you *never* want to use 6to4 - because=
 it's not reliable.

>

> This isn't strictly true. =A0If you're an IPv4-only operator o=
f a public access network, then you probably want to make 6to4 available fo=
r users who are willing to put up with the unreliability or who have specif=
ic destinations in mind, like their home networks, that are known to have a=
 reverse path relay.


>

> I assume this is why we don't feel inclined to publish a phase-out=
 plan for 6to4.

>

>


James, are you speaking on behalf of an operator who cannot speak for th=
emselves? 


There seems to be a misconception that consumers want or care about ipv6=
. They don't. Yet, real ipv6 is needed to *replace* ipv4 for engineerin=
g reasons. 


IMHO, 6to4 is a techies trick. What Mark has published is not for the be=
nefit of the internet at large, it is a clever script that is more fit for =
a FREEBSD users group.


I have yet to encounter anything beyond boutique network operators that =
believe 6to4 is a supportable technology that has a place in the current an=
d going forward reality of this network of netkworks.


Cb


> --

> james woodyatt <jhw@apple.com&=
gt;

> member of technical staff, core os networking

>

>

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

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




--bcaec52be9d1a4f02904a3160cd6--

From jhw@apple.com  Thu May 12 08:53: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 24D26E077F for ; Thu, 12 May 2011 08:53:20 -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 QU4VO2e30xuV for ; Thu, 12 May 2011 08:53:19 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id B842FE0767 for ; Thu, 12 May 2011 08:53:19 -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 <0LL3005O1AQGMEE1@mail-out.apple.com> for v6ops@ietf.org; Thu, 12 May 2011 08:53:19 -0700 (PDT)
X-AuditID: 11807130-b7c15ae000005aca-ce-4dcc026f6940
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 D0.A3.23242.F620CCD4; Thu, 12 May 2011 08:53:19 -0700 (PDT)
Received: from 67-218-102-72.cust.layer42.net (67-218-102-72.cust.layer42.net [67.218.102.72]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LL30073JASTS570@cardamom.apple.com> for v6ops@ietf.org; Thu, 12 May 2011 08:53:19 -0700 (PDT)
From: james woodyatt 
In-reply-to: 
Date: Thu, 12 May 2011 08:53:16 -0700
Message-id: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>   
To: "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.1226)
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 15:53:20 -0000

On May 12, 2011, at 8:43 AM, Cameron Byrne wrote:

> James, are you speaking on behalf of an operator who cannot speak for themselves?

Yes.  Well, actually more like one that can't be bothered to speak for itself, but yes, the operator in question has deliberately made sure that 6to4 works while native IPv6 is not yet available, and they did this for the reason I mentioned in my previous message.  Is that *really* so hard to imagine?


--
james woodyatt 
member of technical staff, core os networking




From lorenzo@google.com  Thu May 12 08:59: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 B38EBE07A1 for ; Thu, 12 May 2011 08:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 XokBo+mQWYyZ for ; Thu, 12 May 2011 08:59:58 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 17992E079F for ; Thu, 12 May 2011 08:59:57 -0700 (PDT)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p4CFxvxt029264 for ; Thu, 12 May 2011 08:59:57 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305215997; bh=H7DFPwf91Xe/vH7vCSHviVKLILc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=syLk6e9UETlsul2m4k8GMYM6SiZ4w5gdq8NjCH0W2e2rIjzxnr0Vt8+LL+pVKUYn2 ydmJodtPyhE3p5yH1eSwA==
Received: from gxk10 (gxk10.prod.google.com [10.202.11.10]) by wpaz33.hot.corp.google.com with ESMTP id p4CFweXn023847 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 12 May 2011 08:59:56 -0700
Received: by gxk10 with SMTP id 10so794604gxk.11 for ; Thu, 12 May 2011 08:59:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6qBf0PX6w9KECH0nYPL0k9/labI6Qh7LHbIZ1GtyK5Q=; b=HyVR5viaN9FrfvBSF/Mh/MO8DwoPBI7w/xCI6dUeaeJARLy+snV0JfrYc+QPsCGfCl j4832qc6VAmNDu7halOg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=UU4FgsIJVy43uZF4CVddTX8wYX8DxnzSLqQKqEeTEt3th6J2OKBUM45B9CgmQeEn36 4QgzYjup62vqaXdyqEDA==
Received: by 10.151.77.31 with SMTP id e31mr426199ybl.435.1305215996134; Thu, 12 May 2011 08:59:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Thu, 12 May 2011 08:59:36 -0700 (PDT)
In-Reply-To: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>    
From: Lorenzo Colitti 
Date: Thu, 12 May 2011 08:59:36 -0700
Message-ID: 
To: james woodyatt 
Content-Type: multipart/alternative; boundary=000e0cd63100ce078c04a3164717
X-System-Of-Record: true
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 15:59:58 -0000

--000e0cd63100ce078c04a3164717
Content-Type: text/plain; charset=ISO-8859-1

On Thu, May 12, 2011 at 8:53 AM, james woodyatt  wrote:

> > James, are you speaking on behalf of an operator who cannot speak for
> themselves?
>
> Yes.  Well, actually more like one that can't be bothered to speak for
> itself, but yes, the operator in question has deliberately made sure that
> 6to4 works while native IPv6 is not yet available, and they did this for the
> reason I mentioned in my previous message.  Is that *really* so hard to
> imagine?


They can do this now to placate the tiny percentage of their customers that
asks for IPv6. But once content moves to IPv6 they will have to stop,
because their customers will complain that websites are slow and unreliable.

--000e0cd63100ce078c04a3164717
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, May 12, 2011 at 8:53 AM, james woodyatt =
<jhw@apple.com>=
; wrote:



> James, are you speaking on behalf of an operator who=
 cannot speak for themselves?




Yes. =A0Well, actually more like one that can't be bothered to sp=
eak for itself, but yes, the operator in question has deliberately made sur=
e that 6to4 works while native IPv6 is not yet available, and they did this=
 for the reason I mentioned in my previous message. =A0Is that *really* so =
hard to imagine?




They can do this now to placate the tiny percentage of =
their customers that asks for IPv6. But once content moves to IPv6 they wil=
l have to stop, because their customers will complain that websites are slo=
w and unreliable.





--000e0cd63100ce078c04a3164717--

From jhw@apple.com  Thu May 12 09: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 A448BE06B9 for ; Thu, 12 May 2011 09:08:57 -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 5MW2djMLQXaw for ; Thu, 12 May 2011 09:08:57 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3B487E06AF for ; Thu, 12 May 2011 09:08:57 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LL3004NABIS2BH1@mail-out.apple.com> for v6ops@ietf.org; Thu, 12 May 2011 09:08:56 -0700 (PDT)
X-AuditID: 11807136-b7c6bae000004a34-f7-4dcc06180425
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 relay15.apple.com (Apple SCV relay) with SMTP id 77.C8.18996.8160CCD4; Thu, 12 May 2011 09:08:56 -0700 (PDT)
Received: from 67-218-102-72.cust.layer42.net (67-218-102-72.cust.layer42.net [67.218.102.72]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LL30014PBITIHB0@koseret.apple.com> for v6ops@ietf.org; Thu, 12 May 2011 09:08:56 -0700 (PDT)
From: james woodyatt 
In-reply-to: 
Date: Thu, 12 May 2011 09:08:49 -0700
Message-id: <3E061335-58F5-4C3F-BCF4-3997DDB27C23@apple.com>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>     
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1226)
X-Brightmail-Tracker: AAAAAA==
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 16:08:57 -0000

On May 12, 2011, at 8:59 AM, Lorenzo Colitti wrote:

> But once content moves to IPv6 they will have to stop, because their customers will complain that websites are slow and unreliable.

Yes, but content won't be moving to general availability over IPv6 for a long, long time.

We can safely assume it will not happen before dual-stacked IPv6/IPv4 retail service is ubiquitous.  Every major content provider I've asked about this says they cannot foresee when they will be willing to make their content generally available over IPv6 without DNS whitelisting.

It therefore makes sense for IPv4-only operators to deploy 6to4 relays for those people who use actively use 6to4 in full knowledge of its unreliability for transporting general web content.  Deploying the 6to4 relays and making sure that protocol 41 works, as I-D.ietf-v6ops-6to4-advistory recommends, doesn't actively make anything worse for content providers, you know.


--
james woodyatt 
member of technical staff, core os networking




From behcetsarikaya@yahoo.com  Thu May 12 09: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 6009AE073D for ; Thu, 12 May 2011 09:37:13 -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 UDL9bbn0tM+Z for ; Thu, 12 May 2011 09:37:12 -0700 (PDT)
Received: from nm11-vm3.bullet.mail.ne1.yahoo.com (nm11-vm3.bullet.mail.ne1.yahoo.com [98.138.91.141]) by ietfa.amsl.com (Postfix) with SMTP id A7664E071C for ; Thu, 12 May 2011 09:37:12 -0700 (PDT)
Received: from [98.138.90.50] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 12 May 2011 16:37:11 -0000
Received: from [98.138.89.252] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 12 May 2011 16:37:11 -0000
Received: from [127.0.0.1] by omp1044.mail.ne1.yahoo.com with NNFMP; 12 May 2011 16:37:11 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 969638.11468.bm@omp1044.mail.ne1.yahoo.com
Received: (qmail 90477 invoked by uid 60001); 12 May 2011 16:37:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305218231; bh=s96FnOG22EduipeaEmBJJDML/Al+FKUdanvOnxEUnhs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=G0qjPUoEpDmj9iewSyU+12j2idnoLWUideqIkqt50ZfqJQfQGH0MSapZspnj4lKpWjwGX/Gg+uDPrw/ypM+hNamfGpLCfNeKVMonItTsXkJpAX4eKyKXA920wuVBHPFtQQoi/SElH5jledzQ158yNhSTjmW9cRLx3dw2NsEWD3U=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=P0a0UgH2/TlxYADsaA+/o1kaYaIpx5tdyM2WkuTu2KIHU0kB8DhA25unFvCZap0elo9AzgLRZ8RX+VNmi/0EMmIpZykG19EgOxSlU6c+ATYygVcHx+oFxyijwANO/6Em2AF1YFwt/nsWPCDAn87FBjWO6VEirVUfBzrCk1Ye+gI=;
Message-ID: <275236.40049.qm@web111402.mail.gq1.yahoo.com>
X-YMail-OSG: gL6QYpYVM1mHk6E6__bdH3LvNJhdT04NnAr_rN5cG.FffbI NXiKpIefDBLuvNBbuh0WfDLrZf4rGPSnNh.16LF.PNIi5UwX.2kdEc685CzS ViURNflYW1Jp.m9IpybsB6h5bz9yMsEn.Gk5qngDgjnQsXHsFrl1XLT_2swf F7PjPqiY8vi006.SDSejNa.Sz5RjspKv2zW9B8ikbrybF6j3ix5V3k4fmjcx 5oyRmxVPoV1bx5nnHFzvXgoxT0gip72JMs25LGM.pLUW_fjJ5CG0woczgq8m WNAaQdWiUr9QU9FDu_hS3ASd_QK7ZyvfNsUZqAKgi2Oat2ejkqNAefrl4tCT Db6wOZjh9criUXon5zAUMDUiUvq7Flrgcz68qsJFR_N8Pa0N2Ee0l8wDssOT QAecRMQnAxtBqbg--
Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Thu, 12 May 2011 09:37:11 PDT
X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.111.303096
References: <3CF3E905-E526-4847-A9AC-D6A28828B208@cisco.com> 
Date: Thu, 12 May 2011 09:37:11 -0700 (PDT)
From: Behcet Sarikaya 
To: Ole Troan , Ted Lemon , Suresh Krishnan 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: IPv6 Operations Working Group 
Subject: Re: [v6ops] draft-sarikaya-v6ops-prefix-delegation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 May 2011 16:37:13 -0000

Hi Ole,


> _is_ this best current practice?

Well, we would like it to be. The main message of the draft is that we should 
use DHCP PD to automate prefix management especially for the networks that have 
large number of UEs attaching to their networks because a unique prefix has to 
be assigned to each UE in some networks.

If it is not we can change it to Informational, whatever WG decides. 

> 
> does this conflict when DHCPv6 PD is  used between UE and AR?

The draft deals with UE address configuration when UE initially attaches the 
network.

After the address is configured, does UE need to do DHCPv6 PD? 
Maybe yes, but it is out of scope with my draft.

> I'm concerned about section 3.2, where the AR DHCPv6  relay should add an IA_PD 
>option to the DHCPv6 client - server exchange.
> has  that new protocol behaviour been reviewed in the DHC WG? 

Good point!

An earlier version was presented in DHC WG.
I copied this mail to Ted, expect he is going to chip in.

> in other scenarios that  functionality has been solved either with snooping or 
>the proposed RAAN  option.
> 

In version -01 we used Option 82. After Suresh, who is copied, commented, I 
changed it to IA_PD. Maybe he had asked, I don't know.

Would Option 82 which is already defined, work better?

Regards,

Behcet

> cheers,
> Ole
> 
> > The authors have asked me about 
> >  http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation
> >   "DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile  Networks",
> >  Behcet Sarikaya, Frank Xia, 19-Apr-11
> > 
> >  When we discussed this at IETF-79, a number of views were expressed, varying  
>from "let's adopt this as a working group draft and immediately publish as a  
>BCP" to "ignore and abandon this draft, if anything it belongs in some other SDO  
>or NOG", and all points in between. Several folks indicated that they would post  
>comments to the list, and the comments didn't materialize.
> > 
> >  Question for the assembled hordes: what needs to happen in this draft to 
>make it  useful/interesting for mobile network operators? What needs to happen 
>to make it  interesting to other operators?
> >  _______________________________________________
> > 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 cb.list6@gmail.com  Thu May 12 09:56: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 E228EE06C3 for ; Thu, 12 May 2011 09:56:40 -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=[AWL=0.001,  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 LiXUrjGiubcB for ; Thu, 12 May 2011 09:56:40 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED254E069E for ; Thu, 12 May 2011 09:56:39 -0700 (PDT)
Received: by ewy19 with SMTP id 19so615272ewy.31 for ; Thu, 12 May 2011 09:56:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xPzoStNhryPq7At+9YLQvd8YNAMtQChJhLws9WD+Kv4=; b=dK53TWDwGPnXumwScgisaOxM39yuIaXW9Preui2HiByuu6lIkFiq71AFlb7LMECcqj SGMhT1nKffV9WsAbv/l5FfAQPELRQ6i6k+TIpFr7ctfYUonSgSFKh1aRQtx9OuVxS6XW Tb3KcQs6NbFYM1nENVQ3c/v5EE0BuzukNHXHE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XfNf7OQzqfepY+6/Dhybc2BoBh9+FVysl97SBqk4UNe3QN/p9ENTNYzvuDWjFpIpJa svqqJeQJQoI+0ciRzMqRRd77R1c/rgs7lF/0Tl8tlgtXshabXZg4MT6fsTrSGS7zkUu+ KLXvQvl2ON7laYt2CHnqKIgs9NfJtbBo0cMJs=
MIME-Version: 1.0
Received: by 10.14.122.201 with SMTP id t49mr209334eeh.25.1305218635034; Thu, 12 May 2011 09:43:55 -0700 (PDT)
Received: by 10.14.37.143 with HTTP; Thu, 12 May 2011 09:43:54 -0700 (PDT)
In-Reply-To: <3E061335-58F5-4C3F-BCF4-3997DDB27C23@apple.com>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>      <3E061335-58F5-4C3F-BCF4-3997DDB27C23@apple.com>
Date: Thu, 12 May 2011 09:43:54 -0700
Message-ID: 
From: Cameron Byrne 
To: james woodyatt 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 16:56:41 -0000

On Thu, May 12, 2011 at 9:08 AM, james woodyatt  wrote:
> On May 12, 2011, at 8:59 AM, Lorenzo Colitti wrote:
>
>> But once content moves to IPv6 they will have to stop, because their cus=
tomers will complain that websites are slow and unreliable.
>
> Yes, but content won't be moving to general availability over IPv6 for a =
long, long time.
>

This is the chicken and egg problem that requires white-listing to
exist... and a self fulfilling prophecy.

I believe for networks that work for it, they will have a substantial
volume (<50% on  a per user basis in my mobile case) of IPv6 content
available within 12 months.  World IPv6 day should provide some
meaningful data.

Cameron




> We can safely assume it will not happen before dual-stacked IPv6/IPv4 ret=
ail service is ubiquitous. =A0Every major content provider I've asked about=
 this says they cannot foresee when they will be willing to make their cont=
ent generally available over IPv6 without DNS whitelisting.
>
> It therefore makes sense for IPv4-only operators to deploy 6to4 relays fo=
r those people who use actively use 6to4 in full knowledge of its unreliabi=
lity for transporting general web content. =A0Deploying the 6to4 relays and=
 making sure that protocol 41 works, as I-D.ietf-v6ops-6to4-advistory recom=
mends, doesn't actively make anything worse for content providers, you know=
.
>
>
> --
> james woodyatt 
> member of technical staff, core os networking
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

From Ted.Lemon@nominum.com  Thu May 12 10:07: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 11EFAE072E for ; Thu, 12 May 2011 10:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.279
X-Spam-Level: 
X-Spam-Status: No, score=-106.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 SANTh1YB3Wu9 for ; Thu, 12 May 2011 10:07:05 -0700 (PDT)
Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDBDE070A for ; Thu, 12 May 2011 10:07:04 -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 DSNKTcwTuF+17aATBrqWvPg+bMkVtidYkTvl@postini.com; Thu, 12 May 2011 10:07:05 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 66C5E1B861C for ; Thu, 12 May 2011 10:07:02 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 56256190052; Thu, 12 May 2011 10:07:02 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
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; Thu, 12 May 2011 10:07:01 -0700
MIME-Version: 1.0 (Apple Message framework v1222)
Content-Type: text/plain; charset="us-ascii"
From: Ted Lemon 
In-Reply-To: <275236.40049.qm@web111402.mail.gq1.yahoo.com>
Date: Thu, 12 May 2011 13:06:56 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <3CF3E905-E526-4847-A9AC-D6A28828B208@cisco.com>  <275236.40049.qm@web111402.mail.gq1.yahoo.com>
To: Behcet Sarikaya , Behcet Sarikaya 
X-Mailer: Apple Mail (2.1222)
Cc: IPv6 Operations Working Group 
Subject: Re: [v6ops] draft-sarikaya-v6ops-prefix-delegation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 12 May 2011 17:07:06 -0000

On May 12, 2011, at 12:37 PM, Behcet Sarikaya wrote:
>> I'm concerned about section 3.2, where the AR DHCPv6  relay should =
add an IA_PD=20
>> option to the DHCPv6 client - server exchange.
>> has  that new protocol behaviour been reviewed in the DHC WG?=20
>=20
> Good point!
>=20
> An earlier version was presented in DHC WG.
> I copied this mail to Ted, expect he is going to chip in.

Hm, I don't remember this.   I think it would probably be better to =
define a new option for the relay to use to indicate what prefix to =
delegate.   Otherwise you're needlessly overloading the meaning of that =
option.

> In version -01 we used Option 82. After Suresh, who is copied, =
commented, I=20
> changed it to IA_PD. Maybe he had asked, I don't know.
>=20
> Would Option 82 which is already defined, work better?

Option 82 doesn't exist in DHCPv6, so it probably wouldn't work very =
well... :)


From fred@cisco.com  Thu May 12 10:19: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 B48C6E0679 for ; Thu, 12 May 2011 10:19:24 -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 yjiy6cEOYMKl for ; Thu, 12 May 2011 10:19:24 -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 30607E0688 for ; Thu, 12 May 2011 10:19:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=795; q=dns/txt; s=iport; t=1305220764; x=1306430364; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=JEgZsxM0XSLZjYvIiQmR2R2uLJ0gpWb08EtoTYiKotw=; b=h6SK4796KvdnBkz+9Jiu7l4Zw4OzAUkb+dcJNHkB0lJm7GxedCqnyiIE lgONjgYW7OiaTgB3wxZW0gUkBiXF/JAY/KKptMkHSB0mfNVGxXR83li5U Rt49acqhac9I1Pc2x4AvBFzXUlaGj8rcjYS/yhAkOiBGc3pj8JbTBPtNK E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAMMVzE2rRDoJ/2dsb2JhbACleHepfp4nhhUEhkmJMoQoimE
X-IronPort-AV: E=Sophos;i="4.64,359,1301875200"; d="scan'208";a="446649916"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 12 May 2011 17:19:23 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4CHJITZ007231; Thu, 12 May 2011 17:19:23 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Thu, 12 May 2011 10:19:23 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Thu, 12 May 2011 10:19:23 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: <275236.40049.qm@web111402.mail.gq1.yahoo.com>
Date: Thu, 12 May 2011 10:19:07 -0700
Message-Id: <071E4CEA-7367-4D07-B4AC-2499277F7B1E@cisco.com>
References: <3CF3E905-E526-4847-A9AC-D6A28828B208@cisco.com>  <275236.40049.qm@web111402.mail.gq1.yahoo.com>
To: Behcet Sarikaya 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: IPv6 Operations Working Group 
Subject: Re: [v6ops] draft-sarikaya-v6ops-prefix-delegation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 12 May 2011 17:19:24 -0000

On May 12, 2011, at 9:37 AM, Behcet Sarikaya wrote:
> On May 11, 2011, at 12:25 AM, Ole Troan wrote:
>> _is_ this best current practice?
>=20
> Well, we would like it to be. The main message of the draft is that we =
should=20
> use DHCP PD to automate prefix management especially for the networks =
that have=20
> large number of UEs attaching to their networks because a unique =
prefix has to=20
> be assigned to each UE in some networks.
>=20
> If it is not we can change it to Informational, whatever WG decides.=20=


I don't think that's the question Ole was asking. He's not asking about =
the status of the draft; he's asking whether what the draft recommends =
is in fact the practice most operators use and arguably should use.

How do operators do this today?


From dcrocker@bbiw.net  Thu May 12 09:51: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 3DD2EE0682 for ; Thu, 12 May 2011 09:51:05 -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 RTqOLXbqsExm for ; Thu, 12 May 2011 09:51:04 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EF986E068E for ; Thu, 12 May 2011 09:51:03 -0700 (PDT)
Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4CGopbg014874 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 12 May 2011 09:50:56 -0700
Message-ID: <4DCC0FE5.9050503@bbiw.net>
Date: Thu, 12 May 2011 09:50:45 -0700
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "STARK, BARBARA H (ATTSI)" 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>  <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p>
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F1BEA6CF0@crexc50p>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 12 May 2011 09:50:57 -0700 (PDT)
X-Mailman-Approved-At: Thu, 12 May 2011 11:19:17 -0700
Cc: "Richard L. Barnes" , v6ops@ietf.org
Subject: Re: [v6ops] Review of:draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 12 May 2011 16:51:05 -0000

On 5/3/2011 7:17 AM, STARK, BARBARA H (ATTSI) wrote:
>> How about "IPv6 DNS Resolver Whitelisting"
>> or "IPv6 AAAA DNS Resolver Whitelisting"
>
> Well, I guess if we're going to discuss changing the name from what it
> had been (which I was fine with), then it should be to something that
> accurately reflects what is being discussed. The whitelisting is of DNS
> Resolvers that are using DNSv4 protocol, and not "IPv6 DNS" Resolvers or
> "IPv6 AAAA DNS" Resolvers. The purpose of the whitelisting is to
> determine which DNSv4 Resolvers are sent AAAA records in a response.
>
> So, maybe "DNSv4 Resolver Whitelisting" (short name) or "DNSv4 Resolver
> Whitelisting for Inclusion of AAAA Record in Response" (longer name)

For completeness:

I wound up doing a full review for the Apps Area -- you all should have seen it 
posted by now -- and included a bit more about naming issues/choices.  I think 
there is some 'internal' issues with the name, in addition to the 'external' 
confusion of conflicting with the established use by anti-abuse folk.

I'm a fan of choosing names that have some hope of being reasonable intuitive 
and precise.  It's rarely possible to be so intuitive that a new reader will 
guess the name, but it can be intuitive enough to be easy to remember and know 
what it means.




On 5/3/2011 8:26 AM, Erik Kline wrote:
 > IMHO, this document is not a real discussion of whitelisting mechanics
 > and motivations.  It is, rather, a harangue against its use, ...

I found the opinions of the draft sometimes difficult to discern.  I think that, 
in fact, it did not take clear enough positions for or against a number of 
issues in this topic.  Certainly I did not find anything either clear enough or 
strong enough to qualify as a harangue.

My second review noted this, especially with respect to "universal" adoption of 
the mechanism.

d/




-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From behcetsarikaya@yahoo.com  Thu May 12 11:28: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 4232DE06D5 for ; Thu, 12 May 2011 11:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level: 
X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.754,  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 sjrnEMQD4hDt for ; Thu, 12 May 2011 11:28:18 -0700 (PDT)
Received: from nm21-vm0.bullet.mail.sp2.yahoo.com (nm21-vm0.bullet.mail.sp2.yahoo.com [98.139.91.220]) by ietfa.amsl.com (Postfix) with SMTP id 55F76E06A1 for ; Thu, 12 May 2011 11:28:18 -0700 (PDT)
Received: from [98.139.91.66] by nm21.bullet.mail.sp2.yahoo.com with NNFMP; 12 May 2011 18:28:15 -0000
Received: from [98.139.91.59] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 12 May 2011 18:28:15 -0000
Received: from [127.0.0.1] by omp1059.mail.sp2.yahoo.com with NNFMP; 12 May 2011 18:28:15 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 323969.31291.bm@omp1059.mail.sp2.yahoo.com
Received: (qmail 54182 invoked by uid 60001); 12 May 2011 18:28:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305224894; bh=tLB9lKql9qpAGap26mqSR7N6QPUdTcf4VPRC2MzaEU8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ughKyW/THcSkAFZdxOdyKKCV2hUV8P+71NKsbpmQuVVNhdVjr0uV8qA26fcqNkp2PBsoHSPGZ9V8L3uWQuo9WM9eMBDlqAif5glMNmFJU6yI37Ekd4t806O2XkwEH4N3T9wFtxAk+7jT65/fnG+U1+FaROJOjkyvXVRJiXG8D1M=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=l79Za4c7FX+LSseFGr8eEl1gcmzlAompxGvlFWnctClrDTkuBeExo6oGuIM91oFYzG+sZ/E8Wf5VWHtcLSF1YrM6zntbOASMIEbXKdWhtWO2TiCQZZ7Of6c83rwePr6aFVsLaDPRVLEVc4eopkrjaw3otNhurQRjpquS2b1H6fI=;
Message-ID: <938159.38441.qm@web111403.mail.gq1.yahoo.com>
X-YMail-OSG: 3Kc4K38VM1mLz6niFVtCr2.itipOff0fJe2W_w3HvijJPEq .3o30kIPY98iSz8XJwkVnNE77Xb0gjp4rEQSV7Y0_YrTfQeiiL1msqtHUMkc PRF.sKLoSrD20rmM35H_e6kVMYQqClVymtinloYe7E.3giATP7VNPKvXFC9P sFt7B7c4Z9anNAvUhCnbza8ImqK8nirT8z9abtS6N53zVue7ATq4Yqu5f.A_ E4CIBTam2MiEsyEVvIVBGNXYVz87cf1sk1ciNiHC.W2iSPuoD9u9i9Lhz0IY 2fnEZBUHFrrzTNkYSAZKjyTEOruC62BMb2scSzFR6b2g36MdsU1qGTlnFXR4 UlOYWedZB6IreU4XY23HbJ.YnEYhPzjMK08c8klpf48hdFOO1rd24yweiIuo 5b.srOmamk8JwYw--
Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Thu, 12 May 2011 11:28:14 PDT
X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.111.303096
References: <3CF3E905-E526-4847-A9AC-D6A28828B208@cisco.com>  <275236.40049.qm@web111402.mail.gq1.yahoo.com> <071E4CEA-7367-4D07-B4AC-2499277F7B1E@cisco.com>
Date: Thu, 12 May 2011 11:28:14 -0700 (PDT)
From: Behcet Sarikaya 
To: Fred Baker , Behcet Sarikaya 
In-Reply-To: <071E4CEA-7367-4D07-B4AC-2499277F7B1E@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: IPv6 Operations Working Group 
Subject: Re: [v6ops] draft-sarikaya-v6ops-prefix-delegation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 May 2011 18:28:19 -0000

> 
> 
> On May 12, 2011, at 9:37 AM, Behcet Sarikaya wrote:
> > On May 11, 2011,  at 12:25 AM, Ole Troan wrote:
> >> _is_ this best current  practice?
> > 
> > Well, we would like it to be. The main message of the  draft is that we 
>should 
>
> > use DHCP PD to automate prefix management  especially for the networks that 
>have 
>
> > large number of UEs attaching to  their networks because a unique prefix has 
>to 
>
> > be assigned to each UE in  some networks.
> > 
> > If it is not we can change it to Informational,  whatever WG decides. 
> 
> I don't think that's the question Ole was asking.  He's not asking about the 
>status of the draft; he's asking whether what the  draft recommends is in fact 
>the practice most operators use and arguably should  use.
> 
> How do operators do this today?
> 


As IPv6 UEs are are rare, they are using prefix pool approach, I think. 
Many UEs can not connect on IPv6 because of chip set issue which was discussed 
on this list before.

From behcetsarikaya@yahoo.com  Thu May 12 12:18: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 70564E0718 for ; Thu, 12 May 2011 12:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.502,  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 a6F9w+cOakc6 for ; Thu, 12 May 2011 12:18:26 -0700 (PDT)
Received: from nm20.bullet.mail.sp2.yahoo.com (nm20.bullet.mail.sp2.yahoo.com [98.139.91.90]) by ietfa.amsl.com (Postfix) with SMTP id 097BDE0706 for ; Thu, 12 May 2011 12:18:26 -0700 (PDT)
Received: from [98.139.91.65] by nm20.bullet.mail.sp2.yahoo.com with NNFMP; 12 May 2011 19:18:23 -0000
Received: from [98.139.91.39] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 12 May 2011 19:18:23 -0000
Received: from [127.0.0.1] by omp1039.mail.sp2.yahoo.com with NNFMP; 12 May 2011 19:18:23 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 357741.71508.bm@omp1039.mail.sp2.yahoo.com
Received: (qmail 48563 invoked by uid 60001); 12 May 2011 19:18:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305227902; bh=KV2cwQzt/AZvBgEUBHHEs4coxkIDOXPVasIKNpmrt1c=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0muXk/KPJTHayHDxvW40bKKn6T2OQJAHMlPc8Rdumo58EMlQjtRUPM2ogItCAx2Y+fcql0neh+hjSYFLn0qSz8Ap8YHE4ieDiedgOZQqBeDJ929QHbp6vQIrVl+a+n9aAzuBsFqDYxdFx9pLZfyZZlfSZ40CsAaR9hMsds83sng=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1wEnG6EN6FN3eT5ZOpbju5kxJzY8nD6hSiwJbqIEFpUm8MPRj35Z5LRTkYp1/l9Cp8aO+uAAva6mANJ9LW61kLS+A2M82iX35OQ3dFBYq3mvLwrNrbMju6JUIhbyXKujrZ0tDcG12ctKdwcYzPqSBF5qHMXE8YqyaBziQrDJA40=;
Message-ID: <827183.46709.qm@web111414.mail.gq1.yahoo.com>
X-YMail-OSG: UmpTMS0VM1knqQrAepePExBaQh.xwJ5cpBRVhSarnYqCnqj 3Skk.5a_4sJRm9Tcjx0.hEOCUlE38uTuHDB4fb2M6_7nC2QpZLb40iiJTfYx xqbJ2W_C_cEO_6ZVfiRA9fsbGrndsuUAzphs6bGXv2Bz.EYGGV2UGbR_Dnhm B7_GvX2A9VLyiySXA232._UiMYmSpm4dYlQ9_.AC_4VGjBT3PQ9XIk6lz.tT NhTY7i9IUC9mHjQvVJ_yuMZoJvz_Oqyn1xCbZiBnkObiW1qUM3y8UiDR8WRy _1pDjCwIjN0Z6lqNe3wm4LQKzAHiaTF8kkQhir95N9RO5CvwnojYdM.Mn.OI dAeHK.iTXHHQCQJab9yuMgmLd7b2VaI3MPyL9dtLOkUKK7ujvJxLfj.qOUca 0enhctEqmklXJOg--
Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Thu, 12 May 2011 12:18:22 PDT
X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.111.303096
References: <3CF3E905-E526-4847-A9AC-D6A28828B208@cisco.com>  <275236.40049.qm@web111402.mail.gq1.yahoo.com> 
Date: Thu, 12 May 2011 12:18:22 -0700 (PDT)
From: Behcet Sarikaya 
To: Ted Lemon 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: IPv6 Operations Working Group 
Subject: Re: [v6ops] draft-sarikaya-v6ops-prefix-delegation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 May 2011 19:18:26 -0000

Hi Ted,
  It seems like Section 3.2 requires more work which we did not anticipate, 
because of this I am going to remove Section 3.2. It is not the main part in my 
draft.

Regards,

Behcet





> 
> On May 12, 2011, at 12:37 PM, Behcet Sarikaya wrote:
> >> I'm concerned  about section 3.2, where the AR DHCPv6  relay should add an 
>IA_PD 
>
> >> option to the DHCPv6 client - server exchange.
> >>  has  that new protocol behaviour been reviewed in the DHC WG? 
> > 
> > Good point!
> > 
> > An earlier version was presented in DHC  WG.
> > I copied this mail to Ted, expect he is going to chip in.
> 
> Hm,  I don't remember this.   I think it would probably be better to define a  
>new option for the relay to use to indicate what prefix to delegate.    
>Otherwise you're needlessly overloading the meaning of that option.
> 
> >  In version -01 we used Option 82. After Suresh, who is copied, commented, I 

> > changed it to IA_PD. Maybe he had asked, I don't know.
> > 
> >  Would Option 82 which is already defined, work better?
> 
> Option 82 doesn't  exist in DHCPv6, so it probably wouldn't work very well... 
>:)
> 
> 

From dr@cluenet.de  Thu May 12 14:30: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 CF4DCE0717 for ; Thu, 12 May 2011 14:30: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=[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 Q1FFoGDhOSoY for ; Thu, 12 May 2011 14:30:12 -0700 (PDT)
Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF5FE066E for ; Thu, 12 May 2011 14:30:11 -0700 (PDT)
Received: by mail1.cluenet.de (Postfix, from userid 500) id 4515C1080AA; Thu, 12 May 2011 23:30:09 +0200 (CEST)
Date: Thu, 12 May 2011 23:30:09 +0200
From: Daniel Roesen 
To: v6ops@ietf.org
Message-ID: <20110512213009.GA2709@srv03.cluenet.de>
Mail-Followup-To: v6ops@ietf.org
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.17 (2007-11-01)
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 21:30:12 -0000

On Tue, May 10, 2011 at 09:24:57AM +0200, Mohacsi Janos wrote:
> I completly agree with Lorenzo. Operators don't need 6to4 router option: if 
> they need it they can emulate better with 6rd.

+1

I fail to see the user base fully understanding the basic problems of
6to4 and happy to accept them conciously (as James described), yet
unable to just use "reliable" 6RD instead.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

From marka@isc.org  Thu May 12 16:33: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 C4AB5E067C for ; Thu, 12 May 2011 16:33:55 -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 7vHPcIDkywYh for ; Thu, 12 May 2011 16:33:55 -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 1E22DE066E for ; Thu, 12 May 2011 16:33:55 -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 CC6D6C94B6; Thu, 12 May 2011 23:33:44 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 66798216C1E; Thu, 12 May 2011 23:33:44 +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 35794EB4199; Fri, 13 May 2011 09:34:19 +1000 (EST)
To: james woodyatt 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>      <3E061335-58F5-4C3F-BCF4-3997DDB27C23@apple.com>
In-reply-to: Your message of "Thu, 12 May 2011 09:08:49 MST." <3E061335-58F5-4C3F-BCF4-3997DDB27C23@apple.com>
Date: Fri, 13 May 2011 09:34:19 +1000
Message-Id: <20110512233419.35794EB4199@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 12 May 2011 23:33:55 -0000

In message <3E061335-58F5-4C3F-BCF4-3997DDB27C23@apple.com>, james woodyatt wri
tes:
> On May 12, 2011, at 8:59 AM, Lorenzo Colitti wrote:
> 
> > But once content moves to IPv6 they will have to stop, because their custom
> ers will complain that websites are slow and unreliable.
> 
> Yes, but content won't be moving to general availability over IPv6 for a long
> , long time.
> 
> We can safely assume it will not happen before dual-stacked IPv6/IPv4 retail 
> service is ubiquitous.  Every major content provider I've asked about this sa
> ys they cannot foresee when they will be willing to make their content genera
> lly available over IPv6 without DNS whitelisting.
> 
> It therefore makes sense for IPv4-only operators to deploy 6to4 relays for th
> ose people who use actively use 6to4 in full knowledge of its unreliability f
> or transporting general web content.  Deploying the 6to4 relays and making su
> re that protocol 41 works, as I-D.ietf-v6ops-6to4-advistory recommends, doesn
> 't actively make anything worse for content providers, you know.

It also make sense for dual stack operators to deploy 6to4 reverse
relays for their customers that don't have the skills to self deploy.
If a operator has IPv6 only customers then those customers can't
self deploy a 6to4 reverse relay so the ISP should be doing it for
them.

You don't have to announce reverse relays.  You just need to put
them where they can see the IPv6 traffic that needs to be encapsulated.

> --
> james woodyatt 
> member of technical staff, core os networking
> 
> 
> 
> _______________________________________________
> 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 marka@isc.org  Thu May 12 20: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 49197E0780 for ; Thu, 12 May 2011 20:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.272
X-Spam-Level: 
X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 2ki2h06pjR+V for ; Thu, 12 May 2011 20:49:55 -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 A4846E06B1 for ; Thu, 12 May 2011 20:49:55 -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 878F35F9930 for ; Fri, 13 May 2011 03:49:33 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 F2148216C1E for ; Fri, 13 May 2011 03:49:31 +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 49BD0EB6146 for ; Fri, 13 May 2011 13:50:05 +1000 (EST)
To: v6ops@ietf.org
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>   <20110512213009.GA2709@srv03.cluenet.de>
Mail-Followup-To: v6ops@ietf.org
In-reply-to: Your message of "Thu, 12 May 2011 23:30:09 +0200." <20110512213009.GA2709@srv03.cluenet.de>
Date: Fri, 13 May 2011 13:50:05 +1000
Message-Id: <20110513035005.49BD0EB6146@drugs.dv.isc.org>
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 13 May 2011 03:49:56 -0000

In message <20110512213009.GA2709@srv03.cluenet.de>, Daniel Roesen writes:
> On Tue, May 10, 2011 at 09:24:57AM +0200, Mohacsi Janos wrote:
> > I completly agree with Lorenzo. Operators don't need 6to4 router option: if
>  
> > they need it they can emulate better with 6rd.
> 
> +1
> 
> I fail to see the user base fully understanding the basic problems of
> 6to4 and happy to accept them conciously (as James described), yet
> unable to just use "reliable" 6RD instead.

Because you can't get from 6to4 to 6rd without ISP support.  The
ISP needs to get themselves connected via IPv6.  They need to setup
6rd border routers (hard to come by).  They need to advertise them.
The customer also needs to get 6rd compatible equipement (hard to
come by).

> Best regards,
> Daniel
> 
> -- 
> CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
> _______________________________________________
> 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 rogerj@gmail.com  Thu May 12 22:55: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 4842FE06C0 for ; Thu, 12 May 2011 22:55:32 -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=[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 s4tbvOdDQ3yx for ; Thu, 12 May 2011 22:55:30 -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 9CE23E0674 for ; Thu, 12 May 2011 22:55:30 -0700 (PDT)
Received: by wwa36 with SMTP id 36so1708500wwa.13 for ; Thu, 12 May 2011 22:55:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=dbq6G9tQ5OMSUBgbHy9YK9/uc8gt29r6+vOxD437sKs=; b=lv4HTQnaVSsfwbjC9B3zLcOkCOqAr+7YzCxu9W+3om8nRwIOrm8wjLrxdRC71bbkvD ExxmnI+GZfJW9CS9CDt7tX2SkPBVlZ5bZUHxtNKITaldmH+Naw6lWQL5ESCOxVitgFAk 8wY17kqvba2fpSAQNqklma0V35+ZSUrqUv3P8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=LwKEHYLfEazBfMJx7nZucKoTokSMtn+cH9Q9ie1RmlMfu8GiH6NL2irrDBpfB+lLnu 4gvuje16tRj8vnhuzFAF524KAYh5EVx67n95MtO0IbCkGoc2mSGAh//zoTWI96JS4U7u uVJmhP1W9EDUdoz8E9tAFLRl1j0In2mK3H40E=
MIME-Version: 1.0
Received: by 10.227.11.146 with SMTP id t18mr1002764wbt.104.1305266129487; Thu, 12 May 2011 22:55:29 -0700 (PDT)
Received: by 10.227.143.211 with HTTP; Thu, 12 May 2011 22:55:28 -0700 (PDT)
In-Reply-To: <20110513035005.49BD0EB6146@drugs.dv.isc.org>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>   <20110512213009.GA2709@srv03.cluenet.de> <20110513035005.49BD0EB6146@drugs.dv.isc.org>
Date: Fri, 13 May 2011 07:55:28 +0200
Message-ID: 
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: v6ops@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 13 May 2011 05:55:32 -0000

On Fri, May 13, 2011 at 5:50 AM, Mark Andrews  wrote:
> In message <20110512213009.GA2709@srv03.cluenet.de>, Daniel Roesen writes=
:

>> I fail to see the user base fully understanding the basic problems of
>> 6to4 and happy to accept them conciously (as James described), yet
>> unable to just use "reliable" 6RD instead.
>
> Because you can't get from 6to4 to 6rd without ISP support. =A0The
> ISP needs to get themselves connected via IPv6. =A0They need to setup
> 6rd border routers (hard to come by). =A0They need to advertise them.
> The customer also needs to get 6rd compatible equipement (hard to
> come by).

That ISP don't have IPv6 would have worried me 10years ago, maybe even 5.
Right now, in the current time with IPv4 running out fast that should not b=
e
an issue. ISP has to move to IPv6 sooner or later and the faster customers
"force" them to do so the better it is.

Change or be gone really...




--=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  Thu May 12 23:36: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 C18ADE06ED for ; Thu, 12 May 2011 23:36:04 -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 yhBDMOixHxDR for ; Thu, 12 May 2011 23:36:04 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF25E06A7 for ; Thu, 12 May 2011 23:36:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=795; q=dns/txt; s=iport; t=1305268564; x=1306478164; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=EDJ+B+q5q4gPB0/jSL8KZTO5CXqkdCKkHT59GdtSkqY=; b=QHb+OmqxQDnpaPaWqdu8vDP2syJAj9OHRXCoTRtdd4Q78NLHwJzRgxG3 IrzLjk0kDJYD0a/yaTfEJyGrUCvguz6Nz8iwVYJTmreKXEWBI7R/eT97T XlpbcYFVxf1BNhW0w6ed3m6IbyvCl0nXN7y8JxjI2bwkl/xSLm0tpuX9o U=;
X-IronPort-AV: E=Sophos;i="4.64,362,1301875200"; d="scan'208";a="314745451"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 13 May 2011 06:36:04 +0000
Received: from Freds-Computer.local (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4D6ZxLS023114; Fri, 13 May 2011 06:36:03 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 12 May 2011 23:36:03 -0700
X-PGP-Universal: processed; by Freds-Computer.local on Thu, 12 May 2011 23:36:03 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D56A@PDAWM12B.ad.sprint.com>
Date: Thu, 12 May 2011 23:35:47 -0700
Message-Id: 
References: <5F8FA59F-A660-4EAD-8CFF-1D2BE442B37D@cisco.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D56A@PDAWM12B.ad.sprint.com>
To: Stig Venaas , Tim Chown 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: IPv6 Operations Working Group , Ron Bonica 
Subject: Re: [v6ops] draft-chown-v6ops-call-to-arms WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 13 May 2011 06:36:04 -0000

On May 2, 2011, at 11:38 AM, George, Wes E [NTK] wrote:

> Overall, I think that this document is quite good. My main concern is =
that even between now and June, it really should be a living
> document rather than the static document that an IETF draft that moves =
towards RFC becomes.=20

Question for Stig and Tim, and anyone else that wants to chime in. The =
authors will do another update to incorporate the few (but detailed) =
comments we have received during WGLC. =46rom my perspective, I don't =
see a problem with holding off until June to file it with Ron.

But - what would the objective be? It seems like the purpose of holding =
it off is either to add new things to test, or to report on the testing. =
Tim, Stig, others? What do you want to see happen here?=

From joelja@bogus.com  Thu May 12 23:48: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 5BA75E06A6 for ; Thu, 12 May 2011 23:48: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 5YbpYtxObTxo for ; Thu, 12 May 2011 23:48:40 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 844D5E0657 for ; Thu, 12 May 2011 23:48:40 -0700 (PDT)
Received: from 23173jjaeggli.local (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 p4D6m4tx009492 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 13 May 2011 06:48:05 GMT (envelope-from joelja@bogus.com)
Message-ID: <4DCCD421.9040700@bogus.com>
Date: Thu, 12 May 2011 23:48:01 -0700
From: Joel Jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Fred Baker 
References: <5F8FA59F-A660-4EAD-8CFF-1D2BE442B37D@cisco.com>	<54E900DC635DAB4DB7A6D799B3C4CD8E10C8D56A@PDAWM12B.ad.sprint.com> 
In-Reply-To: 
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 13 May 2011 06:48:05 +0000 (UTC)
Cc: Stig Venaas , Ron Bonica , IPv6 Operations Working Group 
Subject: Re: [v6ops] draft-chown-v6ops-call-to-arms WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 13 May 2011 06:48:41 -0000

On 5/12/11 11:35 PM, Fred Baker wrote:
> 
> On May 2, 2011, at 11:38 AM, George, Wes E [NTK] wrote:
> 
>> Overall, I think that this document is quite good. My main concern
>> is that even between now and June, it really should be a living 
>> document rather than the static document that an IETF draft that
>> moves towards RFC becomes.
> 
> Question for Stig and Tim, and anyone else that wants to chime in.
> The authors will do another update to incorporate the few (but
> detailed) comments we have received during WGLC. From my perspective,
> I don't see a problem with holding off until June to file it with
> Ron.
> 
> But - what would the objective be? It seems like the purpose of
> holding it off is either to add new things to test, or to report on
> the testing. Tim, Stig, others? What do you want to see happen here? 

putting it a different way, do we expect material improvement with age?

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


From v6ops@globis.net  Fri May 13 01: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 00DA7E0675 for ; Fri, 13 May 2011 01:25:56 -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 boirHmWH+xZ4 for ; Fri, 13 May 2011 01:25:55 -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 0B067E066A for ; Fri, 13 May 2011 01:25:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E56688700E5 for ; Fri, 13 May 2011 10:25: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 OmgXyfjsSvsP for ; Fri, 13 May 2011 10:25:37 +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 BDF998700DB for ; Fri, 13 May 2011 10:25:37 +0200 (CEST)
Message-ID: <4DCCEB01.7080805@globis.net>
Date: Fri, 13 May 2011 10:25:37 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: "v6ops@ietf.org WG" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [v6ops] Coexistence: Is there a need for an Informational RFC on Common Integration Pitfalls in a Dual Stack Environment
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 13 May 2011 08:25:56 -0000

I have a specific example of where a number of IPv4 and IPv6 components 
were performing correctly, but where the overall integrated system was 
failing.

As we move towards a dual stacked World in many environments, is there a 
need for an Informational RFC on Common Integration Pitfalls in a Dual 
Stack Environment and how to avoid them?

The specific example I have come across was a "minor annoyance" whilst 
testing an upgrade of some recent host software. I guess it could have 
been worse, and I haven't seen this class of problem mentioned anywhere, 
even though it might be "obvious" to everyone here, which is why I 
thought I'd post to the list.

The issue is that host to enterprise VPN clients traditionally have 
allowed network administrators to "control" access of home and traveling 
users to the Internet to either force traffic down the VPN link, or to 
prevent traffic passing directly to the Internet. These features are 
commonly known by various manufacturers as "split tunneling", "limited 
split tunneling", "forced tunneling", "inverse split tunneling", 
"reverse split tunneling" & "disabled split tunneling."

I won't go into the pros and cons of prevention of "split tunneling" or 
whether "forced tunneling" is desirable, suffice it to say that it is a 
requirement of a number of organizations' current security policies.

What was happening was that a new version of the VPN client had been 
requested from the manufacturer for use on a new version of well-known 
and popular desktop operating system to cover some upgrade and 
installation issues. The previous VPN client and concentrator were 
clearly IPv4 only, but the current version of the desktop operating 
system now ships with IPv6 enabled by default. The resulting code from 
the manufacturer was qualified by the manufacturer and passed to the VPN 
service supplier, before being sent to the desktop integrator, and was 
then sent for integration test and approval before being implemented in 
production. It failed at integration testing.

Enforcement of the "split tunneling" features in this particular product 
relies on the manipulation of the standard host IPv4 routing table. 
There are of course other ways to achieve this effect, so there is no 
direct read across to other manufacturer's products and solutions, and 
this may be just be a one off implementation issue.

Anyway, since this particular VPN client was completely unaware of the 
IPv6 routing table on the host, it did not manipulate the IPv6 part of 
the host routing table at all. So regardless of the settings on the 
central control console, the users on the VPN client hosts could access 
the Internet directly without passing through any enterprise managed 
systems, even though the centrally defined policy was set to prohibit 
this. No warning messages or other indications were given.

The manufacturer has stated that this system is "end of life" and will 
not be implementing any upgrade or fix.

Other manufacturers may of course already be aware of this issue and may 
have taken appropriate action in their products.

One reason that this turned out not to be more serious in this 
particular case was that the central VPN concentrator itself is very 
conservative about which packets it will accept over the IPSec VPN 
tunnel connection (limited to packets with an IPv4 source address of the 
endpoint of the IPSec VPN tunnel). Another reason is that the enterprise 
was prepared to consider alternative technical solutions for 
implementing certain requirements by deploying equipment from another 
manufacturer, and making amendments to their security policies for 
others. The potentially more serious general issue is that a network 
security manager may think that "split tunneling" is still controlled, 
even though it might not be, and that this may have slipped through 
their test and acceptance processes if they weren't as thorough as in 
the example.

I checked RFC 4942 and RFC 6169 and conducted a more general search but 
I could not locate any mention of older software manipulating the IPv4 
routing table, but failing to be aware of the IPv6 portion of the table. 
I could of course missed one or more important references in my 
admittedly rather cursory search.

Just thought that "forewarned is forearmed."

So should this sort of risk at the integration level be addressed by 
v6ops at all?

Are there more examples of these integration risks that "everyone knows 
about" but clearly some out there either don't know or don't communicate?

Is there a recommended test methodology equivalent of the "time travel" 
regression testing used in Millennium?

Is this something that the v6ops WG can act upon to produce an 
educational/ informational RFC of common pitfalls in transitioning to 
dual stack environments and how to avoid them?

Or is this just "operational noise", or "too vague," or is best kept off 
the list and discussed elsewhere, or taken on a case by case basis?

Your thoughts.....

Regards,
RayH

From tjc@ecs.soton.ac.uk  Fri May 13 03:46: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 13B47E075D for ; Fri, 13 May 2011 03:46:02 -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 1F-rBYTHqKtA for ; Fri, 13 May 2011 03:46:01 -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 9CADFE0744 for ; Fri, 13 May 2011 03:45:59 -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 p4DAjkZe013206; Fri, 13 May 2011 11:45:46 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p4DAjkZe013206
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1305283547; bh=jjt8/ib69JvV6G5jNElSE79c4hY=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=HeLIZhddHvlAaym64FCwwUDwR2xxA0LLgHqJNv7Hku1DMhs42outGCXxcQi7JsqjG 3kVi8UtNjDYY1KwKW/+reXaeVBpVlRRb+RWJdXuDh3svEBC3azyuf67SqgzbdNvypc cxvGozauMWOxH0T23MmHSdQvnEWCrUmEos1uOiqo=
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 n4CBjk0035615292hI ret-id none; Fri, 13 May 2011 11:45:47 +0100
Received: from dhcp-152-78-94-92.ecs.soton.ac.uk (dhcp-152-78-94-92.ecs.soton.ac.uk [152.78.94.92]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p4DAjfrK001678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 May 2011 11:45:41 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Tim Chown 
In-Reply-To: 
Date: Fri, 13 May 2011 11:45:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <5F8FA59F-A660-4EAD-8CFF-1D2BE442B37D@cisco.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D56A@PDAWM12B.ad.sprint.com>  
To: Fred Baker 
X-Mailer: Apple Mail (2.1084)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n4CBjk003561529200; tid=n4CBjk0035615292hI; client=relay,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: p4DAjkZe013206
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Cc: Stig Venaas , IPv6 Operations Working Group , Ron Bonica 
Subject: Re: [v6ops] draft-chown-v6ops-call-to-arms WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 13 May 2011 10:46:02 -0000

On 13 May 2011, at 07:35, Fred Baker wrote:

>=20
> On May 2, 2011, at 11:38 AM, George, Wes E [NTK] wrote:
>=20
>> Overall, I think that this document is quite good. My main concern is =
that even between now and June, it really should be a living
>> document rather than the static document that an IETF draft that =
moves towards RFC becomes.=20
>=20
> Question for Stig and Tim, and anyone else that wants to chime in. The =
authors will do another update to incorporate the few (but detailed) =
comments we have received during WGLC. =46rom my perspective, I don't =
see a problem with holding off until June to file it with Ron.
>=20
> But - what would the objective be? It seems like the purpose of =
holding it off is either to add new things to test, or to report on the =
testing. Tim, Stig, others? What do you want to see happen here?

I would be perfectly fine with it being a 'living document' for the =
foreseeable future.   =46rom discussion with Stig last week, I believe =
he shares the same view.  We also have a third author contributing =
material.

The idea was simply to have a place at which to point people - with a =
focus on administrators at end sites - to become more aware of some =
common connectivity issues they may see and some ways to measure the =
performance of clients attempting to reach their sites.   If that place =
is a draft not an RFC, it doesn't make the text any less useful, and as =
Wes suggests, we can make quick updates right up to the day if it's =
deemed useful/necessary.

It might be useful beyond June 8th if it becomes more the text that Ray =
is hinting at, for general connectivity gotchas for dual-stack sites.  =
For example we ran into another one recently during the IETF's test of =
its 'mirror' facilities. The duplicate IETF mail servers didn't have =
reverse IPv6 DNS, so our dual-stack mail servers rejected the mails, and =
after a few days I dropped off some lists.  The IETF ops people were =
really helpful in sorting it out, but the interesting thing was that the =
servers didn't - as far as I can determine - drop back to IPv4 =
transport; they kept retrying over IPv6.

Tim


From fred@cisco.com  Fri May 13 09: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 3BC3AE07DD for ; Fri, 13 May 2011 09:41:14 -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 zEqc9mvBILJr for ; Fri, 13 May 2011 09:41:13 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id B02C2E07DC for ; Fri, 13 May 2011 09:41:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2415; q=dns/txt; s=iport; t=1305304873; x=1306514473; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=qBCNqgAezAhQxj+3KuQa4x+3Q+F2qmSedxBGiE1dqs8=; b=ET0Sgxag7VltnQwx28TysIu8naa30IPsNk0ZGvG8pHYIxR8Yv6H7gQg7 qrshO1/431tPrBfnVK9Ij0KBydkMO/3rB3jU5Ki5oq8xNY1+8VPPMRDC4 CdeuYou2V0/hPwmBYxghcWnGLa/9fbh1R+fTJY1HZ8YzUoP0obwATHasj c=;
X-IronPort-AV: E=Sophos;i="4.64,365,1301875200"; d="scan'208";a="697067425"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-6.cisco.com with ESMTP; 13 May 2011 16:41:13 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4DGf2K1013086;  Fri, 13 May 2011 16:41:11 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Fri, 13 May 2011 09:41:12 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Fri, 13 May 2011 09:41:12 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: 
Date: Fri, 13 May 2011 09:40:35 -0700
Message-Id: <2D3C3BA1-D80B-43CF-A99B-9112C484FA21@cisco.com>
References: <5F8FA59F-A660-4EAD-8CFF-1D2BE442B37D@cisco.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8D56A@PDAWM12B.ad.sprint.com>   
To: Tim Chown 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: Stig Venaas , IPv6 Operations Working Group , Ron Bonica 
Subject: Re: [v6ops] draft-chown-v6ops-call-to-arms WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 13 May 2011 16:41:14 -0000

On May 13, 2011, at 3:45 AM, Tim Chown wrote:

>=20
> On 13 May 2011, at 07:35, Fred Baker wrote:
>=20
>>=20
>> On May 2, 2011, at 11:38 AM, George, Wes E [NTK] wrote:
>>=20
>>> Overall, I think that this document is quite good. My main concern =
is that even between now and June, it really should be a living
>>> document rather than the static document that an IETF draft that =
moves towards RFC becomes.=20
>>=20
>> Question for Stig and Tim, and anyone else that wants to chime in. =
The authors will do another update to incorporate the few (but detailed) =
comments we have received during WGLC. =46rom my perspective, I don't =
see a problem with holding off until June to file it with Ron.
>>=20
>> But - what would the objective be? It seems like the purpose of =
holding it off is either to add new things to test, or to report on the =
testing. Tim, Stig, others? What do you want to see happen here?
>=20
> I would be perfectly fine with it being a 'living document' for the =
foreseeable future.   =46rom discussion with Stig last week, I believe =
he shares the same view.  We also have a third author contributing =
material.

In that case, the WGLC was premature. Thanks, we'll just let it ride.

> The idea was simply to have a place at which to point people - with a =
focus on administrators at end sites - to become more aware of some =
common connectivity issues they may see and some ways to measure the =
performance of clients attempting to reach their sites.   If that place =
is a draft not an RFC, it doesn't make the text any less useful, and as =
Wes suggests, we can make quick updates right up to the day if it's =
deemed useful/necessary.
>=20
> It might be useful beyond June 8th if it becomes more the text that =
Ray is hinting at, for general connectivity gotchas for dual-stack =
sites.  For example we ran into another one recently during the IETF's =
test of its 'mirror' facilities. The duplicate IETF mail servers didn't =
have reverse IPv6 DNS, so our dual-stack mail servers rejected the =
mails, and after a few days I dropped off some lists.  The IETF ops =
people were really helpful in sorting it out, but the interesting thing =
was that the servers didn't - as far as I can determine - drop back to =
IPv4 transport; they kept retrying over IPv6.

Interesting. I presume you'll discuss that in the updated draft.=

From gert@space.net  Fri May 13 12:00: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 3D5C0E086E for ; Fri, 13 May 2011 12:00: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 iRaTI63BugA0 for ; Fri, 13 May 2011 12:00:00 -0700 (PDT)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C48DE0840 for ; Fri, 13 May 2011 11:59:58 -0700 (PDT)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id A2CEDF83FD for ; Fri, 13 May 2011 20:59:56 +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 8706DF841C for ; Fri, 13 May 2011 20:59:56 +0200 (CEST)
Received: (qmail 77005 invoked by uid 1007); 13 May 2011 20:59:56 +0200
Date: Fri, 13 May 2011 20:59:56 +0200
From: Gert Doering 
To: james woodyatt 
Message-ID: <20110513185956.GR52064@Space.Net>
References: <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org>      <3E061335-58F5-4C3F-BCF4-3997DDB27C23@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3E061335-58F5-4C3F-BCF4-3997DDB27C23@apple.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 13 May 2011 19:00:01 -0000

Hi,

On Thu, May 12, 2011 at 09:08:49AM -0700, james woodyatt wrote:
> Every major content provider I've asked about this says they cannot 
> foresee when they will be willing to make their content generally 
> available over IPv6 without DNS whitelisting.

So you haven't spoken to Tore recently?

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 dr@cluenet.de  Sat May 14 06:43: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 0C99EE06E9 for ; Sat, 14 May 2011 06:43:15 -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 gYhOIT4kuz99 for ; Sat, 14 May 2011 06:43:14 -0700 (PDT)
Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 62BD1E06E7 for ; Sat, 14 May 2011 06:43:13 -0700 (PDT)
Received: by mail1.cluenet.de (Postfix, from userid 500) id D64131080BC; Sat, 14 May 2011 15:43:11 +0200 (CEST)
Date: Sat, 14 May 2011 15:43:11 +0200
From: Daniel Roesen 
To: v6ops@ietf.org
Message-ID: <20110514134311.GA29095@srv03.cluenet.de>
Mail-Followup-To: v6ops@ietf.org
References: <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <4DCAC912.6080205@bogus.com> <20110511233945.63275EAD4F4@drugs.dv.isc.org>  <20110512011453.2A2AAEAE1E7@drugs.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110512011453.2A2AAEAE1E7@drugs.dv.isc.org>
User-Agent: Mutt/1.5.17 (2007-11-01)
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 14 May 2011 13:43:15 -0000

On Thu, May 12, 2011 at 11:14:53AM +1000, Mark Andrews wrote:
> It's minor configuration changes in many cases.  Real life configs.

In real life, most customers run on Windows based platforms, not using
ISC DHCP client.

Regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

From dr@cluenet.de  Sat May 14 06:52: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 CFAB5E06C1 for ; Sat, 14 May 2011 06:52:59 -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 EP3fEj62EV1o for ; Sat, 14 May 2011 06:52:59 -0700 (PDT)
Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 0860BE06B0 for ; Sat, 14 May 2011 06:52:59 -0700 (PDT)
Received: by mail1.cluenet.de (Postfix, from userid 500) id 1F5121080A2; Sat, 14 May 2011 15:52:58 +0200 (CEST)
Date: Sat, 14 May 2011 15:52:58 +0200
From: Daniel Roesen 
To: v6ops@ietf.org
Message-ID: <20110514135258.GB29095@srv03.cluenet.de>
Mail-Followup-To: v6ops@ietf.org
References: <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <4DCAC912.6080205@bogus.com> <20110511233945.63275EAD4F4@drugs.dv.isc.org>  <20110512011453.2A2AAEAE1E7@drugs.dv.isc.org> <20110514134311.GA29095@srv03.cluenet.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110514134311.GA29095@srv03.cluenet.de>
User-Agent: Mutt/1.5.17 (2007-11-01)
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 14 May 2011 13:52:59 -0000

On Sat, May 14, 2011 at 03:43:11PM +0200, Daniel Roesen wrote:
> On Thu, May 12, 2011 at 11:14:53AM +1000, Mark Andrews wrote:
> > It's minor configuration changes in many cases.  Real life configs.
> 
> In real life, most customers run on Windows based platforms, not using
> ISC DHCP client.

To add to myself, don't forget all the CPE implementations which never
see automatic updates.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

From jhw@apple.com  Sat May 14 10:08: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 05DAAE06ED for ; Sat, 14 May 2011 10:08:59 -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 I77de5ioPA4J for ; Sat, 14 May 2011 10:08:58 -0700 (PDT)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8D997E06AF for ; Sat, 14 May 2011 10:08:58 -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 <0LL7000ZN3M68S10@mail-out.apple.com> for v6ops@ietf.org; Sat, 14 May 2011 10:08:51 -0700 (PDT)
X-AuditID: 11807134-b7c00ae0000074fb-de-4dceb723d4c9
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 relay14.apple.com (Apple SCV relay) with SMTP id C8.E1.29947.327BECD4; Sat, 14 May 2011 10:08:51 -0700 (PDT)
Received: from [172.16.1.2] (adit.conjury.org [75.101.54.88]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LL70054Z3MQUD50@koseret.apple.com> for v6ops@ietf.org; Sat, 14 May 2011 10:08:51 -0700 (PDT)
From: james woodyatt 
In-reply-to: <20110514135258.GB29095@srv03.cluenet.de>
Date: Sat, 14 May 2011 10:08:51 -0700
Message-id: 
References: <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <4DCAC912.6080205@bogus.com> <20110511233945.63275EAD4F4@drugs.dv.isc.org>  <20110512011453.2A2AAEAE1E7@drugs.dv.isc.org> <20110514134311.GA29095@srv03.cluenet.de> <20110514135258.GB29095@srv03.cluenet.de>
To: Daniel Roesen 
X-Mailer: Apple Mail (2.1227)
X-Brightmail-Tracker: AAAAAA==
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-andrews-v6ops-6to4-router-option-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, 14 May 2011 17:08:59 -0000

On May 14, 2011, at 6:52 AM, Daniel Roesen wrote:
> 
> don't forget all the CPE implementations which never see automatic updates.

Or the ones that will never see any attention to 6to4 in their updates after complying with the recommendations in I-D.ietf-v6ops-6to4-to-historic.


--
james woodyatt 
member of technical staff, core os networking




From fred@cisco.com  Sun May 15 06:19: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 D8071E06B5 for ; Sun, 15 May 2011 06:19:55 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 dAthbYxliDDB for ; Sun, 15 May 2011 06:19:55 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 49D3CE06BA for ; Sun, 15 May 2011 06:19:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2192; q=dns/txt; s=iport; t=1305465595; x=1306675195; h=from:subject:date:message-id:cc:to:mime-version; bh=K4J/C66scQDsXCzfvhz7cm9knbHoqxj7SlnRBc7MhgM=; b=HGGUfmjlRDiIV+JRjX7/7nEIZR88QnTyLOZwg8xDWpPGB9mZN4yDR4Sf QKeOQNcR1Wuayg14ZB6Yd+XmkIsKP68shPYLlUkLJ+iVF8QIiUPpfhQRs BjY+I7sxNayfPuXIq4lSQpKIQOrcwe2hdYmFDn10nEFhD7K+sQIXm7GuS k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsYGAGHSz02rRDoG/2dsb2JhbACCY5UtjgV3q3+ceIYZBIZQiUGEL4pm
X-IronPort-AV: E=Sophos;i="4.64,369,1301875200";  d="scan'208,217";a="316038589"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 15 May 2011 13:04:38 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4FD4VAl012311; Sun, 15 May 2011 13:04:37 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Sun, 15 May 2011 06:04:38 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Sun, 15 May 2011 06:04:38 -0700
From: Fred Baker 
Date: Sun, 15 May 2011 06:04:14 -0700
Message-Id: <993AD341-6B37-4A86-B15F-918DB8CC5117@cisco.com>
To: v6ops@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-1-739940538
Cc: v6ops-chairs@tools.ietf.org, Ron Bonica 
Subject: [v6ops] draft-ietf-v6ops-3gpp-eps WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 15 May 2011 13:19:56 -0000

--Apple-Mail-1-739940538
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This is to initiate a two week working group last call of =
draft-ietf-v6ops-3gpp-eps. Please read it now. If you find nits =
(spelling errors, minor suggested wording changes, etc), comment to the =
authors; if you find greater issues, such as disagreeing with a =
statement or finding additional issues that need to be addressed, please =
post your comments to the list.

We are looking specifically for comments on the importance of the =
document as well as its content. If you have read the document and =
believe it to be of operational utility, that is also an important =
comment to make.=

--Apple-Mail-1-739940538
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

This is to initiate a two week working =
group last call of draft-ietf-v6ops-3gpp-eps. Please read it now. If you =
find nits (spelling errors, minor suggested wording changes, =
etc), comment to the authors; if you find greater issues, such as =
disagreeing with a statement or finding additional issues that need to =
be addressed, please post your comments to =
the list.

We are looking specifically for comments on the =
importance of the document as well as its content. If you have read the =
document and believe it to be of operational utility, that is also =
an important comment to make.
 =

--Apple-Mail-1-739940538--

From marka@isc.org  Sun May 15 16:16: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 13423E0701 for ; Sun, 15 May 2011 16:16:49 -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 0v3izFyNwNTf for ; Sun, 15 May 2011 16:16:48 -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 34203E06F7 for ; Sun, 15 May 2011 16:16:48 -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 141E6C9432; Sun, 15 May 2011 23:16:36 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 9B2FE216C31; Sun, 15 May 2011 23:16:35 +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 5DEB8EBE245; Mon, 16 May 2011 09:17:23 +1000 (EST)
To: Pekka Savola 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com> 
In-reply-to: Your message of "Thu, 12 May 2011 15:48:44 +0300." 
Date: Mon, 16 May 2011 09:17:23 +1000
Message-Id: <20110515231723.5DEB8EBE245@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 15 May 2011 23:16:49 -0000

In message , Pekka Savola write
s:
> On Thu, 12 May 2011, Tore Anderson wrote:
> > That said, I'd be more inclined to support a draft, or perhaps a new
> > section in the -advisory document, that instructed the hosts/CPEs to
> > probe the reliability of the outbound relay. For example by sending an
> > encapsulated ICMPv6 packet to 192.88.99.1 with IPv6 SRC=DST=[it's own
> > 6to4 address]. If it doesn't come back, then don't enable the 6to4
> > interface. This would, as far as I can tell, accomplish the same
> > smoother failure mode as your draft when in networks that don't support
> > 6to4, without requiring explicit support from the ISP (or the use of
> > DHCP for that matter).
> >
> > Furthermore, I understand that major vendors such as Apple and Microsoft
> > have implemented, or are about to implement, [something similar] to this
> > already.
> 
> Nit-pick:
> 
> The relay is not supposed to get address where both the source and 
> destination are from 2002::/16 prefix, so it could legitimately drop 
> it. (That's recommended in RFC3964.) I'm not sure if relays in general 
> do this or not.
> 
> But in any case, the test e.g. done by MS has at least 5-6 years of 
> deployment experience behind it and it accomplishes almost the same 
> thing -- also not requiring any support.
> 
> FWIW, I agree that recommending a connectivity test procedure is much 
> better than providing a DHCP option.  I'm not adamant on adding a 
> recommendation to do the test prodecure in -advisory (as I can see the 
> argument that even this is not worth the effort at this point), but I 
> think it would probably be a good idea to do so.

Test procedures are for temporary errors.  You withdraw the default
route and/or return network unreachable.  You continue to announce
the 6to4 prefixes.

The DHCP option is for permanent errors.  You tear down / never
establish the 6to4 interface and stop / don't start announcing 6to4
prefixes on the other interfaces.

> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From pekkas@netcore.fi  Sun May 15 22:44: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 D1D9EE0682 for ; Sun, 15 May 2011 22:44: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 J-o6UMsQL5iY for ; Sun, 15 May 2011 22:44:29 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4850E0679 for ; Sun, 15 May 2011 22:44:28 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p4G5iCHT020032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 May 2011 08:44:12 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p4G5iC4k020029; Mon, 16 May 2011 08:44:12 +0300
Date: Mon, 16 May 2011 08:44:12 +0300 (EEST)
From: Pekka Savola 
To: Mark Andrews 
In-Reply-To: <20110515231723.5DEB8EBE245@drugs.dv.isc.org>
Message-ID: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi
X-Virus-Status: Clean
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 16 May 2011 05:44:29 -0000

On Mon, 16 May 2011, Mark Andrews wrote:
> Test procedures are for temporary errors.  You withdraw the default
> route and/or return network unreachable.  You continue to announce
> the 6to4 prefixes.
>
> The DHCP option is for permanent errors.  You tear down / never
> establish the 6to4 interface and stop / don't start announcing 6to4
> prefixes on the other interfaces.

I fail to see the distinction.  While I can see it'd would be more 
optimal, if the test procedure was not run every 5 minutes or 24 hours 
(per host), it still achieves essentially the same thing.  Actually 
more -- with DHCP option, even if an IP address is provided, the 
implementation won't test that it actually works.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From marka@isc.org  Sun May 15 23:24: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 7B06BE0703 for ; Sun, 15 May 2011 23:24:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046,  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 irJ863BUIQJS for ; Sun, 15 May 2011 23:24:21 -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 E2FC1E069E for ; Sun, 15 May 2011 23:24: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.pao1.isc.org (Postfix) with ESMTPS id 60E67C94E6; Mon, 16 May 2011 06:24:10 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 EB6D8216C31; Mon, 16 May 2011 06:24:09 +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 94D4CEC26F2; Mon, 16 May 2011 16:24:59 +1000 (EST)
To: Pekka Savola 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org> 
In-reply-to: Your message of "Mon, 16 May 2011 08:44:12 +0300." 
Date: Mon, 16 May 2011 16:24:59 +1000
Message-Id: <20110516062459.94D4CEC26F2@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 16 May 2011 06:24:21 -0000

In message , Pekka Savola write
s:
> On Mon, 16 May 2011, Mark Andrews wrote:
> > Test procedures are for temporary errors.  You withdraw the default
> > route and/or return network unreachable.  You continue to announce
> > the 6to4 prefixes.
> >
> > The DHCP option is for permanent errors.  You tear down / never
> > establish the 6to4 interface and stop / don't start announcing 6to4
> > prefixes on the other interfaces.
> 
> I fail to see the distinction.  While I can see it'd would be more 
> optimal, if the test procedure was not run every 5 minutes or 24 hours 
> (per host), it still achieves essentially the same thing.  Actually 
> more -- with DHCP option, even if an IP address is provided, the 
> implementation won't test that it actually works.

If 6to4 was only a single host then there is little distinction but
6to4 is not a just single host.  It is a border router, RAs, PD and
a whole lot more.  6to4 gives you a /48 not a /128.  What you do to
a network is different to what you do to a single host.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From pch-b2B3A6689@u-1.phicoh.com  Mon May 16 02:39: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 7C375E0744 for ; Mon, 16 May 2011 02:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 WBf9JMu8PF+h for ; Mon, 16 May 2011 02:39:23 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 12D72E06A8 for ; Mon, 16 May 2011 02:39:22 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QLuGl-0001VGC; Mon, 16 May 2011 11:39:19 +0200
Message-Id: 
To: Mark Andrews 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org> 
In-reply-to: Your message of "Mon, 16 May 2011 16:24:59 +1000 ." <20110516062459.94D4CEC26F2@drugs.dv.isc.org> 
Date: Mon, 16 May 2011 11:38:54 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 16 May 2011 10:20:04 -0000

In your letter dated Mon, 16 May 2011 16:24:59 +1000 you wrote:
>If 6to4 was only a single host then there is little distinction but
>6to4 is not a just single host.  It is a border router, RAs, PD and
>a whole lot more.  6to4 gives you a /48 not a /128.  What you do to
>a network is different to what you do to a single host.

So what you should do (at least what I would do) is to not advertise anything
related to 6to4 until you have verified that the relay is reachable.

Similarly, I would stop advertising anything related to 6to4 as soon as the
connection to the relay is broken. If it is a transient error then there will
be just a bit of packet loss, if it is a longer lasting error then eventually
all addressen and routes will timeout and hosts will revert to IPv4.



From Fred.L.Templin@boeing.com  Mon May 16 08:50: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 99E1FE071C; Mon, 16 May 2011 08:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150,  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 A9j1vhsoZVVV; Mon, 16 May 2011 08:50:26 -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 13171E06CF; Mon, 16 May 2011 08:50:25 -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 p4GFoNn4024883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 May 2011 10:50:24 -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 p4GFoMqD014099; Mon, 16 May 2011 08:50:22 -0700 (PDT)
Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4GFoJKI013761 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 16 May 2011 08:50:19 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Mon, 16 May 2011 08:50:19 -0700
From: "Templin, Fred L" 
To: "v6ops@ietf.org" , "ipv6@ietf.org" 
Date: Mon, 16 May 2011 08:50:18 -0700
Thread-Topic: RFC3484, Section 6, Rule 7 and ISATAP
Thread-Index: AcwTst19svhVZRm1TjCUP8r7MCuobQAKi9Rg
Message-ID: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org><4DC8D717.3080402@redpill-linpro.com><2011 0510064904.B5081E9E11B@drugs.dv.isc.org><4DCA5121.9010809@redpill-linpro.co m><20110511121453.D438CEAA1A5@drugs.dv.isc.org><0F0C1186-50F6-4305-92E0-B83 3C0520127@employees.org><20110511144736.77E3AEAAEDA@drugs.dv.isc.org><4DCAC 64C.7030607@redpill-linpro.com><20110511232129.A5DFDEAD470@drugs.dv.isc.org ><4DCB7609.3020802@redpill-linpro.com><20110512073353.EB4CCEB0BC6@drugs.dv. isc.org><4DCBC1F1.7030600@redpill-linpro.com><20110515231723.5DEB8EBE245@drugs.dv.isc.org><20110516062459.94D4CEC26F2@drugs.dv.isc.org> 
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: [v6ops] RFC3484, Section 6, Rule 7 and ISATAP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 16 May 2011 15:50:26 -0000

Recently, there was discussion regarding how to discern
an ISATAP IPv6 address from a native IPv6 address, and an
implication that this may have some bearing on RFC3484
address selection. The correct answer is that an IPv6
address is an ISATAP address IFF it is assigned to an
ISATAP interface, i.e., a node can tell that its IPv6
source address is ISATAP by examining the interface to
which the address is assigned. Therefore, there is a way
for a node to prefer native IPv4 over ISATAP even though
an IPv6 address cannot be identified as ISATAP solely by
examining the prefix.

This policy is manifested in RFC3484, Section 6, Rule 7:

   "Rule 7:  Prefer native transport.
   If DA is reached via an encapsulating transition mechanism (e.g.,
   IPv6 in IPv4) and DB is not, then prefer DB.  Similarly, if DB
   is reached via encapsulation and DA is not, then prefer DA.

      Discussion:  6-over-4 [15], ISATAP [16], and configured tunnels
      [17] are examples of encapsulating transition mechanisms for which
      the destination address does not have a specific prefix and hence
      can not be assigned a lower precedence in the policy table.  An
      implementation MAY generalize this rule by using a concept of
      interface preference, and giving virtual interfaces (like the
      IPv6-in-IPv4 encapsulating interfaces) a lower preference than
      native interfaces (like ethernet interfaces)."

Although the Discussion shows a "MAY", the rule itself
asserts that the native transport is to be preferred over
an encapsulating transport. Hence, there is no particular
reason for an ISATAP host to avoid placing AAAA records in
the DNS for any of its SLAAC-derived ISATAP addresses.

Fred
fred.l.templin@boeing.com=

From Dmitry.Anipko@microsoft.com  Mon May 16 12:47: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 7ED75E07AA; Mon, 16 May 2011 12:47:53 -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 63UmTw-wL8Ov; Mon, 16 May 2011 12:47:52 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id DC2E6E07A7; Mon, 16 May 2011 12:47:52 -0700 (PDT)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 16 May 2011 12:47:52 -0700
Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 16 May 2011 12:47:52 -0700
Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Mon, 16 May 2011 12:47:52 -0700
From: Dmitry Anipko 
To: "Templin, Fred L" , "v6ops@ietf.org" , "ipv6@ietf.org" 
Date: Mon, 16 May 2011 12:47:51 -0700
Thread-Topic: RFC3484, Section 6, Rule 7 and ISATAP
Thread-Index: AcwTst19svhVZRm1TjCUP8r7MCuobQAKi9RgAAkUPbA=
Message-ID: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org><4DC8D717.3080402@redpill-linpro.com><2011 0510064904.B5081E9E11B@drugs.dv.isc.org><4DCA5121.9010809@redpill-linpro.co m><20110511121453.D438CEAA1A5@drugs.dv.isc.org><0F0C1186-50F6-4305-92E0-B83 3C0520127@employees.org><20110511144736.77E3AEAAEDA@drugs.dv.isc.org><4DCAC 64C.7030607@redpill-linpro.com><20110511232129.A5DFDEAD470@drugs.dv.isc.org ><4DCB7609.3020802@redpill-linpro.com><20110512073353.EB4CCEB0BC6@drugs.dv. isc.org><4DCBC1F1.7030600@redpill-linpro.com><20110515231723.5DEB8EBE245@drugs.dv.isc.org><20110516062459.94D4CEC26F2@drugs.dv.isc.org>  
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] RFC3484, Section 6, Rule 7 and ISATAP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 16 May 2011 19:47:53 -0000

Hello Fred,

Rule 7 does help to distinguish native IPv6 versus ISATAP.=20

However, rule 7 doesn't help to distinguish ISATAP from native IPv4: the ru=
le 7 is only considered after rule 6, and per rule 6 ISATAP is already prio=
ritized higher than IPv4 due to the default prefix policy table precedence =
values. As a result, rule 7 won't apply in that case, and ISATAP is preferr=
ed over IPv4.

I'm not weighing in on whether that is a problem or not, but trying to clar=
ify what I believe the raised concern was.

Thank you,
Dmitry

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Tem=
plin, Fred L
Sent: Monday, May 16, 2011 8:50 AM
To: v6ops@ietf.org; ipv6@ietf.org
Subject: RFC3484, Section 6, Rule 7 and ISATAP

Recently, there was discussion regarding how to discern
an ISATAP IPv6 address from a native IPv6 address, and an
implication that this may have some bearing on RFC3484
address selection. The correct answer is that an IPv6
address is an ISATAP address IFF it is assigned to an
ISATAP interface, i.e., a node can tell that its IPv6
source address is ISATAP by examining the interface to
which the address is assigned. Therefore, there is a way
for a node to prefer native IPv4 over ISATAP even though
an IPv6 address cannot be identified as ISATAP solely by
examining the prefix.

This policy is manifested in RFC3484, Section 6, Rule 7:

   "Rule 7:  Prefer native transport.
   If DA is reached via an encapsulating transition mechanism (e.g.,
   IPv6 in IPv4) and DB is not, then prefer DB.  Similarly, if DB
   is reached via encapsulation and DA is not, then prefer DA.

      Discussion:  6-over-4 [15], ISATAP [16], and configured tunnels
      [17] are examples of encapsulating transition mechanisms for which
      the destination address does not have a specific prefix and hence
      can not be assigned a lower precedence in the policy table.  An
      implementation MAY generalize this rule by using a concept of
      interface preference, and giving virtual interfaces (like the
      IPv6-in-IPv4 encapsulating interfaces) a lower preference than
      native interfaces (like ethernet interfaces)."

Although the Discussion shows a "MAY", the rule itself
asserts that the native transport is to be preferred over
an encapsulating transport. Hence, there is no particular
reason for an ISATAP host to avoid placing AAAA records in
the DNS for any of its SLAAC-derived ISATAP addresses.

Fred
fred.l.templin@boeing.com
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From joelja@bogus.com  Mon May 16 14:28: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 307F7E06A4; Mon, 16 May 2011 14:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.936
X-Spam-Level: 
X-Spam-Status: No, score=-101.936 tagged_above=-999 required=5 tests=[AWL=0.063, 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 DAMwrBJFDmY3; Mon, 16 May 2011 14:28:05 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE61E0681; Mon, 16 May 2011 14:28:04 -0700 (PDT)
Received: from 23173jjaeggli.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p4GLRx3L033501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 May 2011 21:28: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: <4DCB2909.3040506@isi.edu>
Date: Mon, 16 May 2011 14:27:53 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com>
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net> <4DC1E7C2.8010405@dougbarton.us> <4DCB2909.3040506@isi.edu>
To: Joe Touch 
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, 16 May 2011 21:28:01 +0000 (UTC)
Cc: v6ops@ietf.org, IETF Discussion 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 16 May 2011 21:28:06 -0000

On May 11, 2011, at 5:25 PM, Joe Touch wrote:

> Hi, all,
>=20
> Although this is a minor point, it's also easy to address:
>=20
> On 5/4/2011 4:56 PM, Doug Barton wrote:
> ...
>> Meanwhile, the discussion about whether or not to call this
>> "whitelisting" is pointless. The term is already well-established.
>=20
> That's true, but equally true that the terms for disk drives used to =
use terms "master" and "slave" - equally antiquated and potentially =
racially charged terms. FWIW, the Los Angeles County banned the terms in =
2003 when used for various purposes - including technology, preferring =
"primary" and "secondary", in specific. The terms don't even appear in =
the ATA spec after version 1.
>=20
> For the terms in this doc, alternatives that do not require =
explanation (and aren't potentially racially charged) include "permit =
list" and "deny list".

the blacklist originates with charles the 2nd. it has no racial =
connotations in that context.

see also the death of cromwell and the resortation.

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


From dhc2@dcrocker.net  Mon May 16 14: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 D011AE0733; Mon, 16 May 2011 14:37:26 -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 qb6Tu8gK1uKP; Mon, 16 May 2011 14:37:25 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DA25CE06A4; Mon, 16 May 2011 14:37:25 -0700 (PDT)
Received: from [172.20.2.149] (wsip-174-77-3-3.dc.dc.cox.net [174.77.3.3]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4GLbFLh019135 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 16 May 2011 14:37:22 -0700
Message-ID: <4DD19909.9060202@dcrocker.net>
Date: Mon, 16 May 2011 17:37:13 -0400
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Joel Jaeggli 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net>	<4DC1E7C2.8010405@dougbarton.us> <4DCB2909.3040506@isi.edu> <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com>
In-Reply-To: <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 16 May 2011 14:37:22 -0700 (PDT)
Cc: v6ops@ietf.org, IETF Discussion , Joe Touch 
Subject: Re: [v6ops] Review of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2011 21:37:26 -0000

On 5/16/2011 5:27 PM, Joel Jaeggli wrote:
>> For the terms in this doc, alternatives that do not require explanation
>> (and aren't potentially racially charged) include "permit list" and "deny
>> list".
>
> the blacklist originates with charles the 2nd. it has no racial connotations
> in that context.
>
> see also the death of cromwell and the resortation.


1. Changing times often call for changed vocabulary.

2. The "established" label is semantically wrong, since the construct of 
white/black for lists refers to priviledge or goodness.  Which is "good", v6 or 
v4?  The answer is completely arbitrary and, therefore, renders the term neither 
intuitive not really appropriate.

3. When the IETF processes work with a history, it often changes labels.

4. And let's not forget the name conflict with anti-spam DNS-based whitelists. 
(It's probably close enough to qualify as trademark infringement if this were a 
trademark case)

How much longer does this list need to be to justify choosing better labels for 
this v6 dual-stack transition hack?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From joelja@bogus.com  Mon May 16 15:08: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 44360E06D8; Mon, 16 May 2011 15:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.252
X-Spam-Level: 
X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[AWL=0.347, 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 eUdmGnVv9-is; Mon, 16 May 2011 15:08:38 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A586E06B5; Mon, 16 May 2011 15:08:38 -0700 (PDT)
Received: from 23173jjaeggli.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p4GM8T3R033697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 May 2011 22:08: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: <4DD19909.9060202@dcrocker.net>
Date: Mon, 16 May 2011 15:08:24 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net>	<4DC1E7C2.8010405@dougbarton.us> <4DCB2909.3040506@isi.edu> <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com> <4DD19909.9060202@dcrocker.net>
To: dcrocker@bbiw.net
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, 16 May 2011 22:08:31 +0000 (UTC)
Cc: v6ops@ietf.org, IETF Discussion , Joe Touch 
Subject: Re: [v6ops] Review of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 16 May 2011 22:08:39 -0000

On May 16, 2011, at 2:37 PM, Dave CROCKER wrote:

>=20
>=20
> On 5/16/2011 5:27 PM, Joel Jaeggli wrote:
>>> For the terms in this doc, alternatives that do not require =
explanation
>>> (and aren't potentially racially charged) include "permit list" and =
"deny
>>> list".
>>=20
>> the blacklist originates with charles the 2nd. it has no racial =
connotations
>> in that context.
>>=20
>> see also the death of cromwell and the resortation.
>=20
>=20
> 1. Changing times often call for changed vocabulary.

which is fine, the rational stated is false to fact.

> 2. The "established" label is semantically wrong, since the construct =
of white/black for lists refers to priviledge or goodness.  Which is =
"good", v6 or v4?  The answer is completely arbitrary and, therefore, =
renders the term neither intuitive not really appropriate.

> 3. When the IETF processes work with a history, it often changes =
labels.
>=20
> 4. And let's not forget the name conflict with anti-spam DNS-based =
whitelists. (It's probably close enough to qualify as trademark =
infringement if this were a trademark case)

Really? I can find numerous examples of whitelisting that don't involve =
spam.=20

> How much longer does this list need to be to justify choosing better =
labels for this v6 dual-stack transition hack?

returning different sets of resource records on the basis of the orgin =
of a query ala split horizon is not exactly new ground.

By my observation, what is being done, satisfactorily=20
meets the dictionary definition of a whitelist. the term was =
uncontroversial in the dicussion leading up to the wglc. If it's really =
inapropiate that's cool but I'm frankly not convinced.


> d/
>=20
> --=20
>=20
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
>=20


From jabley@hopcount.ca  Mon May 16 15:12: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 79A45E07AA; Mon, 16 May 2011 15:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Level: 
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, 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 GnMRUGi50np9; Mon, 16 May 2011 15:12:56 -0700 (PDT)
Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by ietfa.amsl.com (Postfix) with ESMTP id CFC95E069D; Mon, 16 May 2011 15:12:55 -0700 (PDT)
Received: from [2001:4900:1042:100:5a55:caff:feec:96bf] (helo=krill.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QM61m-000ABI-7t; Mon, 16 May 2011 22:12:39 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Joe Abley 
In-Reply-To: <4DCB2909.3040506@isi.edu>
Date: Mon, 16 May 2011 18:12:34 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net> <4DC1E7C2.8010405@dougbarton.us> <4DCB2909.3040506@isi.edu>
To: Joe Touch 
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 2001:4900:1042:100:5a55:caff:feec:96bf
X-SA-Exim-Mail-From: jabley@hopcount.ca
X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false
Cc: v6ops@ietf.org, IETF Discussion 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 16 May 2011 22:12:56 -0000

On 2011-05-11, at 20:25, Joe Touch wrote:

> FWIW, the Los Angeles County banned the terms in 2003 when used for =
various purposes - including technology, preferring "primary" and =
"secondary", in specific. The terms don't even appear in the ATA spec =
after version 1.

I believe that story may be apocryphal. e.g. =
 (one of the =
few references I could find in a hurry that actually quote anybody from =
the county):

>> "I do understand that this term has been an industry standard for =
years and years and this is nothing more than a plea to vendors to see =
what they can do," [Sandoval] said. "It appears that some folks have =
taken this a little too literally."
>>=20
>> Sandoval said that he had already rejected a suggestion that the =
county stop buying all equipment carrying the "master" and "slave" =
labels and had no intention of enforcing a ban on such terms with =
suppliers.

According to that article, Joe Sandoval was the division manager of =
purchasing and contract services at the time. Not that this is =
particularly on-topic for anything (and I'm no expert, and am very happy =
to concede that my amateur sleuthing has led me down the garden path).

For what it's worth, there is no shortage of examples of the use of =
"master" and "slave" in the DNS in Los Angeles county. In that =
particular context "primary" and "secondary" are particularly poor =
choices of terminology (in my opinion), since from the point of view of =
a DNS requestor master/primary and slave/secondary servers are simply =
instances of authoritative servers and no preference or priority ought =
to be inferred (masters are not prioritised above slaves or even =
identifiable as such; master/slave denotes the control plane =
distribution of zone data only).


Joe=

From dhc2@dcrocker.net  Mon May 16 15:21: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 B5FA4E0681; Mon, 16 May 2011 15:21:55 -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 u8T4lBPmR+G7; Mon, 16 May 2011 15:21:54 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D34E3E0686; Mon, 16 May 2011 15:21:54 -0700 (PDT)
Received: from [172.20.2.149] (wsip-174-77-3-3.dc.dc.cox.net [174.77.3.3]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4GMLlWt020102 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 16 May 2011 15:21:53 -0700
Message-ID: <4DD1A378.1050009@dcrocker.net>
Date: Mon, 16 May 2011 18:21:44 -0400
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Joel Jaeggli 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net>	<4DC1E7C2.8010405@dougbarton.us> <4DCB2909.3040506@isi.edu> <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com> <4DD19909.9060202@dcrocker.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 16 May 2011 15:21:54 -0700 (PDT)
Cc: v6ops@ietf.org, IETF Discussion , Joe Touch 
Subject: Re: [v6ops] Review of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2011 22:21:55 -0000

On 5/16/2011 6:08 PM, Joel Jaeggli wrote:
> On May 16, 2011, at 2:37 PM, Dave CROCKER wrote:
>> 1. Changing times often call for changed vocabulary.
>
> which is fine, the rational stated is false to fact.

But you do not seem to be refuting the point /I/ am making, which that the fact 
that the term has some established practice now does not automatically mean than 
it /must/ be retained.


>> 4. And let's not forget the name conflict with anti-spam DNS-based
>> whitelists. (It's probably close enough to qualify as trademark
>> infringement if this were a trademark case)
>
> Really? I can find numerous examples of whitelisting that don't involve
> spam.

This has been explored before.  Do a google on DNS whitelist.  Look for dominant 
use, not stray exceptions.


>> How much longer does this list need to be to justify choosing better labels
>> for this v6 dual-stack transition hack?
>
> returning different sets of resource records on the basis of the orgin of a
> query ala split horizon is not exactly new ground.

1. It is not previously standardized and I believe it is not documented in an RFC.

2. It is typically a split-DNS private/public mechanism.

The draft is quite clear about exploring this topic in order to pursue common 
behaviors.  That's standardization (eventually).


> By my observation, what is being done, satisfactorily meets the dictionary
> definition of a whitelist. the term was uncontroversial in the dicussion

Not this dictionary:

    

nor this one:

    

and neither of the main-stream examples cited here:

    


> leading up to the wglc.

The working group is what statistical research methodology calls a biased sample...

d/


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From jabley@hopcount.ca  Mon May 16 15:28: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 F363FE0686; Mon, 16 May 2011 15:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.563
X-Spam-Level: 
X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.038, 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 690W0orBlnuB; Mon, 16 May 2011 15:28:49 -0700 (PDT)
Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by ietfa.amsl.com (Postfix) with ESMTP id 54058E0651; Mon, 16 May 2011 15:28:49 -0700 (PDT)
Received: from [2001:4900:1042:100:5a55:caff:feec:96bf] (helo=krill.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QM6HH-000AgP-8j; Mon, 16 May 2011 22:28:40 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Joe Abley 
In-Reply-To: <4DD1A378.1050009@dcrocker.net>
Date: Mon, 16 May 2011 18:28:35 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net>	<4DC1E7C2.8010405@dougbarton.us> <4DCB2909.3040506@isi.edu> <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com> <4DD19909.9060202@dcrocker.net>  <4DD1A378.1050009@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 2001:4900:1042:100:5a55:caff:feec:96bf
X-SA-Exim-Mail-From: jabley@hopcount.ca
X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false
Cc: v6ops@ietf.org, IETF Discussion 
Subject: Re: [v6ops] Review of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 16 May 2011 22:28:50 -0000

Hi Dave,

I take no position on whether it's in good taste to use the word =
"whitelist" in this particular instance or in general, but

On 2011-05-16, at 18:21, Dave CROCKER wrote:

> 1. It is not previously standardized and I believe it is not =
documented in an RFC.

the term appears to have some precedent in the RFC series (see =
, =
which includes such contexts as DNS, mail, SDP, Atom, v4 and v6 network =
operations and SIP), and

> 2. It is typically a split-DNS private/public mechanism.

No.


Joe


From dhc2@dcrocker.net  Mon May 16 15: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 163F8E0681; Mon, 16 May 2011 15:34:00 -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 UDIXHwFgGUek; Mon, 16 May 2011 15:33:58 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B5872E0651; Mon, 16 May 2011 15:33:58 -0700 (PDT)
Received: from [172.20.2.149] (wsip-174-77-3-3.dc.dc.cox.net [174.77.3.3]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4GMXlfF020283 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 16 May 2011 15:33:54 -0700
Message-ID: <4DD1A649.4060508@dcrocker.net>
Date: Mon, 16 May 2011 18:33:45 -0400
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Joe Abley 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net>	<4DC1E7C2.8010405@dougbarton.us> <4DCB2909.3040506@isi.edu> <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com> <4DD19909.9060202@dcrocker.net>  <4DD1A378.1050009@dcrocker.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 16 May 2011 15:33:54 -0700 (PDT)
Cc: v6ops@ietf.org, dcrocker@bbiw.net, IETF Discussion 
Subject: Re: [v6ops] Review of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2011 22:34:00 -0000

On 5/16/2011 6:28 PM, Joe Abley wrote:
> Hi Dave,
>
> I take no position on whether it's in good taste to use the word "whitelist" in this particular instance or in general, but
>
> On 2011-05-16, at 18:21, Dave CROCKER wrote:
>
>> 1. It is not previously standardized and I believe it is not documented in an RFC.
>
> the term appears to have some precedent in the RFC series (see, which includes such contexts as DNS, mail, SDP, Atom, v4 and v6 network operations and SIP), and

silly me, to have forgotten John's effort to document long-establishedn 
anti-spam list publication through the DNS, that the IESG would not allow to 
have made a standard.

An ironic example, given the current thread.


>> 2. It is typically a split-DNS private/public mechanism.
>
> No.

No doubt you can point to IETF documentation or other related, formal 
documentation of this?

(By the way, I'm not saying it's not done, merely that it seems not to have been 
documented in the fashion the current draft is attempting.  Documentation 
history matters, for this sort of thread.)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From jabley@hopcount.ca  Mon May 16 15:37: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 6DC8FE06F0; Mon, 16 May 2011 15:37:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level: 
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, 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 hmpNE-04wijC; Mon, 16 May 2011 15:37:15 -0700 (PDT)
Received: from monster.hopcount.ca (monster.hopcount.ca [IPv6:2001:4900:1:392:213:20ff:fe1b:3bfe]) by ietfa.amsl.com (Postfix) with ESMTP id 07A8BE06B5; Mon, 16 May 2011 15:37:15 -0700 (PDT)
Received: from [2001:4900:1042:100:5a55:caff:feec:96bf] (helo=krill.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QM6PY-000Azm-C5; Mon, 16 May 2011 22:37:12 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Joe Abley 
In-Reply-To: <4DD1A649.4060508@dcrocker.net>
Date: Mon, 16 May 2011 18:37:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E9293B7-D4AC-41F9-9975-8D7ED13FA646@hopcount.ca>
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net>	<4DC1E7C2.8010405@dougbarton.us> <4DCB2909.3040506@isi.edu> <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com> <4DD19909.9060202@dcrocker.net>  <4DD1A378.1050009@dcrocker.net>  <4DD1A649.4060508@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1084)
X-SA-Exim-Connect-IP: 2001:4900:1042:100:5a55:caff:feec:96bf
X-SA-Exim-Mail-From: jabley@hopcount.ca
X-SA-Exim-Scanned: No (on monster.hopcount.ca); SAEximRunCond expanded to false
Cc: v6ops@ietf.org, IETF Discussion 
Subject: Re: [v6ops] Review of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 16 May 2011 22:37:15 -0000

On 2011-05-16, at 18:33, Dave CROCKER wrote:

>>> 2. It is typically a split-DNS private/public mechanism.
>>=20
>> No.
>=20
> No doubt you can point to IETF documentation or other related, formal =
documentation of this?

No, and I'm not sure why that's relevant. There's no shortage of =
examples of addresses encoded in the DNS which can be (and are) used as =
whitelists. By "typically" did you mean "theoretically"? :-)


Joe=

From joelja@bogus.com  Mon May 16 15:44: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 AB535E06AF; Mon, 16 May 2011 15:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.321
X-Spam-Level: 
X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=0.277, 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 vXoDsBVdByXS; Mon, 16 May 2011 15:44:37 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 99D86E06B5; Mon, 16 May 2011 15:44:36 -0700 (PDT)
Received: from 23173jjaeggli.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p4GMiSi2033933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 May 2011 22:44:29 GMT (envelope-from joelja@bogus.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-7-861148742
From: Joel Jaeggli 
In-Reply-To: <4DD1A378.1050009@dcrocker.net>
Date: Mon, 16 May 2011 15:44:23 -0700
Message-Id: 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net>	<4DC1E7C2.8010405@dougbarton.us> <4DCB2909.3040506@isi.edu> <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com> <4DD19909.9060202@dcrocker.net>  <4DD1A378.1050009@dcrocker.net>
To: dcrocker@bbiw.net
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, 16 May 2011 22:44:30 +0000 (UTC)
Cc: v6ops@ietf.org, IETF Discussion , Joe Touch 
Subject: Re: [v6ops] Review of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 16 May 2011 22:44:37 -0000

--Apple-Mail-7-861148742
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On May 16, 2011, at 3:21 PM, Dave CROCKER wrote:
>=20
> 1. It is not previously standardized and I believe it is not =
documented in an RFC.
>=20
> 2. It is typically a split-DNS private/public mechanism.
>=20
> The draft is quite clear about exploring this topic in order to pursue =
common behaviors.  That's standardization (eventually).

rfc 1919 didn't result in the standardization of split horizon dns =
either so I'm not sure what I'm supposed to conclude from that.

The criticicsm with the name of the draft  doesn't seem to have anything =
to do with criticism of documenting the practice.

>=20
>> By my observation, what is being done, satisfactorily meets the =
dictionary
>> definition of a whitelist. the term was uncontroversial in the =
dicussion
> The working group is what statistical research methodology calls a =
biased sample...

Will we be revising dkim rfc 4871 to explictly define whitelist as dns =
name based whitelist thereby replacing the existing two usages of the =
term (which involve explicitly allowing delivery on the basis of orign), =
or was the term appraise in 2009 but not now?

> d/
>=20
>=20
> --=20
>=20
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
>=20


--Apple-Mail-7-861148742
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



1. It is not =
previously standardized and I believe it is not documented in an =
RFC.

2. It is typically a split-DNS private/public =
mechanism.

The draft is quite clear about exploring this topic in =
order to pursue common behaviors.  That's standardization =
(eventually).

rfc 1919 didn't =
result in the standardization of split horizon dns either so I'm not =
sure what I'm supposed to conclude from =
that.

The criticicsm with the name of the draft =
 doesn't seem to have anything to do with criticism of documenting =
the practice.


By my observation, what is being done, satisfactorily =
meets the dictionary
definition =
of a whitelist. the term was uncontroversial in the =
dicussion
The working group is what statistical research =
methodology calls a biased =
sample...

Will we be revising =
dkim rfc 4871 to explictly define whitelist as dns name based whitelist =
thereby replacing the existing two usages of the term (which involve =
explicitly allowing delivery on the basis of orign), or was the term =
appraise in 2009 but not now?

d/


-- 

  Dave Crocker
 =
 Brandenburg InternetWorking
  bbiw.net


=
=

--Apple-Mail-7-861148742--

From dhc2@dcrocker.net  Mon May 16 15:49: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 565E2E06F1; Mon, 16 May 2011 15:49: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 MfydCwLSS+uG; Mon, 16 May 2011 15:49:51 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 66B37E06B5; Mon, 16 May 2011 15:49:51 -0700 (PDT)
Received: from [172.20.2.149] (wsip-174-77-3-3.dc.dc.cox.net [174.77.3.3]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4GMniBW020624 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 16 May 2011 15:49:50 -0700
Message-ID: <4DD1AA05.5060108@dcrocker.net>
Date: Mon, 16 May 2011 18:49:41 -0400
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Joel Jaeggli 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net>	<4DC1E7C2.8010405@dougbarton.us>	<4DCB2909.3040506@isi.edu>	<9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com>	<4DD19909.9060202@dcrocker.net>		<4DD1A378.1050009@dcrocker.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 16 May 2011 15:49:50 -0700 (PDT)
Cc: v6ops@ietf.org, IETF Discussion 
Subject: Re: [v6ops] Review	of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 May 2011 22:49:52 -0000

On 5/16/2011 6:44 PM, Joel Jaeggli wrote:
>>> By my observation, what is being done, satisfactorily meets the dictionary
>>> definition of a whitelist. the term was uncontroversial in the dicussion
>> The working group is what statistical research methodology calls a biased
>> sample...
>
> Will we be revising dkim rfc 4871 to explictly define whitelist as dns name
> based whitelist thereby replacing the existing two usages of the term (which
> involve explicitly allowing delivery on the basis of orign), or was the term
> appraise in 2009 but not now?


how is non-normative discussion text in rfc 4871 relevant?

Perhaps that also means that all RFC references to cron are required to define 
the term?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From sm@resistor.net  Mon May 16 17:48: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 66EFFE0696; Mon, 16 May 2011 17:48:35 -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 eHXZ5W6FovaW; Mon, 16 May 2011 17:48:33 -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 72C86E0684; Mon, 16 May 2011 17:48:32 -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 p4H0mM4n019901;  Mon, 16 May 2011 17:48:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1305593309; bh=YWJ8dgTdXdnpzgk6AyDQIL56kCQlTafDQJifMtSIaTw=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=PWATNwngkVTjRrju/ow+iCd18nJwhr5fnlpIchR48EOELxxnx27D+fVK+0KUbuc27 uSfsmuaeE8UC9HfYJzVsTLmYAcnOqIfQ64n8+DK8UgbduHWtWlnEw222W+Qjz+/rGd qCJuycrBG+HD3JaTLUjzRqBpJrCW2GHx9/3k2F3Q=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1305593309; bh=YWJ8dgTdXdnpzgk6AyDQIL56kCQlTafDQJifMtSIaTw=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=X8Ok0UieTzV//sIb1vt/i17PA6/7b5UfFvW5PxcK/AOnKdKACVDEQ+fDZ/+NOBXL/ EBm85/fMNbpb+XVuQlGIA6eKaeoIKfsOoFtDstQp/VhHWKV2Bd0+WBdVpaO27NaWRH +o6sOe7duHgjuoQCnCF5bn4HXHxQ5AjJVcEoAY2Y=
Message-Id: <6.2.5.6.2.20110516164344.03931248@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 16 May 2011 17:34:22 -0700
To: IETF Discussion 
From: SM 
In-Reply-To: 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>  <6.2.5.6.2.20110502215922.05513e20@resistor.net> <4DC1E7C2.8010405@dougbarton.us> <4DCB2909.3040506@isi.edu> <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com> <4DD19909.9060202@dcrocker.net>  <4DD1A378.1050009@dcrocker.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Review of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 00:48:35 -0000

At 15:44 16-05-2011, Joel Jaeggli wrote:
>Will we be revising dkim rfc 4871 to explictly define whitelist as 
>dns name based whitelist thereby replacing the existing two usages 
>of the term (which involve explicitly allowing delivery on the basis 
>of orign), or was the term appraise in 2009 but not now?

There is on-going work on RFC 4871.

Quoting the Abstract section of RFC 5782:

   "This memo documents the structure and usage of DNS-based blacklists
    and whitelists, and the protocol used to query them."

 From Abstract section of 
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03:

   "The objective of this document is to describe what the whitelisting
    of DNS AAAA resource records is, hereafter referred to as DNS
    whitelisting, as well as the implications of this emerging practice
    and what alternatives may exist."

Maybe this could be called "DNS Seal Team 6".

Regards,
-sm  


From marka@isc.org  Mon May 16 17:54: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 7FFFEE0696 for ; Mon, 16 May 2011 17:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.556
X-Spam-Level: 
X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=1.043,  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 mazznMHhJ3SB for ; Mon, 16 May 2011 17:54:10 -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 89457E0684 for ; Mon, 16 May 2011 17:54: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.pao1.isc.org (Postfix) with ESMTPS id B1638C94D1; Tue, 17 May 2011 00:54:00 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 45C66216C1E; Tue, 17 May 2011 00:54:00 +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 B45C3EC43F8; Tue, 17 May 2011 10:54:48 +1000 (EST)
To: Philip Homburg 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org> 
In-reply-to: Your message of "Mon, 16 May 2011 11:38:54 +0200." 
Date: Tue, 17 May 2011 10:54:48 +1000
Message-Id: <20110517005448.B45C3EC43F8@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 00:54:11 -0000

In message , Philip Homburg writes:
> In your letter dated Mon, 16 May 2011 16:24:59 +1000 you wrote:
> >If 6to4 was only a single host then there is little distinction but
> >6to4 is not a just single host.  It is a border router, RAs, PD and
> >a whole lot more.  6to4 gives you a /48 not a /128.  What you do to
> >a network is different to what you do to a single host.
> 
> So what you should do (at least what I would do) is to not advertise anything
> related to 6to4 until you have verified that the relay is reachable.
 
The option is design to be used on RENEW as well as initial requests.
It's designed for the operator of the network to tell the clients
of the network that 6to4 will no longer work and you should stop
running 6to4.

> Similarly, I would stop advertising anything related to 6to4 as soon as the
> connection to the relay is broken.

Define "broken".  I've had to work over IPv4 which dropped packet
but I didn't pull the IPv4 addresses off the machines just because
some packets got lost.

> If it is a transient error then there will
> be just a bit of packet loss, if it is a longer lasting error then eventually
> all addressen and routes will timeout and hosts will revert to IPv4.

So you would have host continuly renumbering themselves for temporary
errors.

This group has grossly over reacted to 6to4 and mixed up different
6to4 issues.

You have 6to4 failing due to being run in a environment where it
will not even start up.

You have machines moving from places where 6to4 works to places
where 6to4 cannot work.

You have machines moving from places where 6to4 works to places
where 6to4 still works but shouldn't be started for policy reasons.

You have networks that move from working 6to4 to non working 6to4
due to the introduction of things like CGN.

And you have potential load based issues which quite frankly are
completely solvable including return path issues.

Now from the http server operator perspective these are all the
same but from a engineering perspective (and we all claim to be
engineers here) they are very different problems which should be
addresses seperately.

Additionally none of the issues here are unique to 6to4.  With any
multi-homed service with multiple addresses you will have cases
where one address is reachable and one isn't.  This problem will
continue with IPv6 native though to a lesser degree as IPv4 and
IPv6 are treated seperately in the network so you will get failure
modes where one or other of these is unreachable and the other
isn't.  Applications don't have to behave badly when this occurs.

If the W3C was to certify browsers and part of that certification
required that the browser operated well in the presence of partially
unreachable multi-homed servers how long would you think it would
take the browser vendors to fix their products.

Removing this problem from most applications is not hard.  It just
requires someone to spend the time to do it.  Personally I thing
this would make a good project for Google's Summer of Code.  Have
a open source OS vendor manage someone to go through their package
collection and fixup the connection code with the idea to submit
the changes back upstream.  Once you have done it a couple of times
it doesn't take long to do the next one.

The OS vendor gets a better product fast as they can incorporate
the fixes directly into their package system and the fixes trickle
down to the rest of the community.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From fred@cisco.com  Mon May 16 20:45: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 89010E0713; Mon, 16 May 2011 20:45:59 -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 hiWaYZkFcgIE; Mon, 16 May 2011 20:45:58 -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 332B2E06B5; Mon, 16 May 2011 20:45:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2070; q=dns/txt; s=iport; t=1305603958; x=1306813558; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=AJM/8Nms+ph9IAsovyLrmxacVkjD6BUwyIDWF39wqf0=; b=RBbIZUSWxgGmzpRF+YlOIrm1Q5fSO+cCOyHegcpQFUwrhdb3gSygGZm8 hU+7kCRJ0LaH9PxTT7GOdDomUOHdUyiD++it/wm3BdiQ/29zIeffcCCdQ pL/GStpPSrp5QuygtWH+UmEQnC1no6xJCZs0nzo3daQ3yGcXdQZP0WsiH M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjAGANvu0U2Q/khRgWdsb2JhbACYC44MFAEBFiYliHCfZZ43hhkEkBGEL4pI
X-IronPort-AV: E=Sophos;i="4.65,223,1304294400"; d="scan'208";a="30549052"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 17 May 2011 03:45:56 +0000
Received: from [10.0.2.96] (dhcp-10-55-84-175.cisco.com [10.55.84.175]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4H3jtlp015428; Tue, 17 May 2011 03:45:55 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Fred Baker 
In-Reply-To: <4DD1AA05.5060108@dcrocker.net>
Date: Tue, 17 May 2011 05:45:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <985550C9-A8D8-40E0-9CD5-5DB432A6692A@cisco.com>
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net>	<4DC1E7C2.8010405@dougbarton.us>	<4DCB2909.3040506@isi.edu>	<9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com>	<4DD19909.9060202@dcrocker.net>		<4DD1A378.1050009@dcrocker.net>  <4DD1AA05.5060108@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org, IETF Discussion 
Subject: Re: [v6ops] Review	of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 03:45:59 -0000

On May 17, 2011, at 12:49 AM, Dave CROCKER wrote:

>=20
>=20
> On 5/16/2011 6:44 PM, Joel Jaeggli wrote:
>>>> By my observation, what is being done, satisfactorily meets the =
dictionary
>>>> definition of a whitelist. the term was uncontroversial in the =
dicussion
>>> The working group is what statistical research methodology calls a =
biased
>>> sample...
>>=20
>> Will we be revising dkim rfc 4871 to explictly define whitelist as =
dns name
>> based whitelist thereby replacing the existing two usages of the term =
(which
>> involve explicitly allowing delivery on the basis of orign), or was =
the term
>> appraise in 2009 but not now?
>=20
>=20
> how is non-normative discussion text in rfc 4871 relevant?
>=20
> Perhaps that also means that all RFC references to cron are required =
to define the term?

Speaking as and for myself...

I speak English. As a result, I understand that the word "run" has =
multiple meanings. If the speaker is looking at a stocking, I understand =
him or her to be talking about a "run" in a stocking; if we are at a =
baseball game, I automatically understand that "runs" compare with =
"hits" and "errors". In fact most words have multiple meanings and have =
to be understood in context.

In this case, the draft is talking about a particular variety of DNS =
service. One might call is "DNS Whitelisting" when the context isn't =
clear, but I think in this case the context is clearly not DKIM. The =
common thread it the phrase is that a whitelist identifies those deemed =
acceptable, as compared to a blacklist identifying those deemed =
unacceptable within the context.

Personally, I think this discussion is getting a little strange. It =
reminds me of a rabbi's discussion of what constitutes work and =
therefore may not be done on the sabbath.=20

> d/
> --=20
>=20
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


From sthaug@nethelp.no  Mon May 16 23:41: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 B200DE069E for ; Mon, 16 May 2011 23:41: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 TEsHObdLjyu1 for ; Mon, 16 May 2011 23:41:13 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 0C38FE0682 for ; Mon, 16 May 2011 23:41:12 -0700 (PDT)
Received: (qmail 34062 invoked from network); 17 May 2011 06:41:08 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 17 May 2011 06:41:08 -0000
Date: Tue, 17 May 2011 08:41:08 +0200 (CEST)
Message-Id: <20110517.084108.74718031.sthaug@nethelp.no>
To: joelja@bogus.com
From: sthaug@nethelp.no
In-Reply-To: 
References: <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com> <4DD19909.9060202@dcrocker.net> 
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org, touch@isi.edu, dcrocker@bbiw.net, ietf@ietf.org
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 06:41:13 -0000

> > How much longer does this list need to be to justify choosing better labels for this v6 dual-stack transition hack?
> 
> returning different sets of resource records on the basis of the orgin of a query ala split horizon is not exactly new ground.
> 
> By my observation, what is being done, satisfactorily 
> meets the dictionary definition of a whitelist. the term was uncontroversial in the dicussion leading up to the wglc. If it's really inapropiate that's cool but I'm frankly not convinced.

Agreed. I see no good reason to change the use of "whitelist". Let's
move on.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

From v6ops@globis.net  Mon May 16 23: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 C3009E07D5 for ; Mon, 16 May 2011 23:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level: 
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 IBPlfpuemT8j for ; Mon, 16 May 2011 23:55:03 -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 2D96EE07B4 for ; Mon, 16 May 2011 23:55:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3DBD88700E6; Tue, 17 May 2011 08:55:01 +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 r1R4NKevphR5; Tue, 17 May 2011 08:54:56 +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 3F26587007C; Tue, 17 May 2011 08:54:56 +0200 (CEST)
Message-ID: <4DD21BC0.3030502@globis.net>
Date: Tue, 17 May 2011 08:54:56 +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: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 06:55:03 -0000

The following is a half baked idea (by my own admission), but I submit 
it just in case it triggers anyone to improve on it.

A number of threads on the v6ops list seem to be debating whether A 
records should be preferred over AAAA records or vice versa, or whether 
IPv6 should be preferred over IPv4, or some other transport or 
transition protocol, or whether filtering DNS records is a way to 
achieve this effect of achieving good connectivity. An alternative 
solution that has been suggested is to try to set up many sessions in 
parallel.

All of the solutions proposed today seem to assume that the node 
initiating the connection, or the node answering the DNS query, has to 
"solve" the prioritization / preference selection on their own, without 
much knowledge of the communicating party. So they make assumptions and 
come to a local decision, try it, and then fall back to an alternative, 
potentially leading to unhappy eyeballs.

Here's a "what if" to think about.

What if there were a specific DNS record type available, where an 
individual node, (or indeed entire net block) could publish their 
preferred connectivity scenarios in advance? Similar to publishing 
telnet options in advance so they don't need to be renegotiated during 
session establishment?

So as well as fetching an address record, nodes may also fetch a 
connection policy record (which could of course be locally cached as it 
is part of DNS).

Would this information on the remote nodes' / networks' preferences be 
useful input into the various address selection mechanisms running on 
the local node?

best regards,
RayH

From pch-b2B3A6689@u-1.phicoh.com  Tue May 17 02:44: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 61019E0738 for ; Tue, 17 May 2011 02:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 UKmvmvoqeV7V for ; Tue, 17 May 2011 02:44: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 E19E5E065D for ; Tue, 17 May 2011 02:44:22 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QMGpA-0001j7C; Tue, 17 May 2011 11:44:20 +0200
Message-Id: 
To: Mark Andrews 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org> 
In-reply-to: Your message of "Tue, 17 May 2011 10:54:48 +1000 ." <20110517005448.B45C3EC43F8@drugs.dv.isc.org> 
Date: Tue, 17 May 2011 11:43:57 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 09:44:25 -0000

In your letter dated Tue, 17 May 2011 10:54:48 +1000 you wrote:
>In message , Philip Homburg writes:
>> In your letter dated Mon, 16 May 2011 16:24:59 +1000 you wrote:
>> >If 6to4 was only a single host then there is little distinction but
>> >6to4 is not a just single host.  It is a border router, RAs, PD and
>> >a whole lot more.  6to4 gives you a /48 not a /128.  What you do to
>> >a network is different to what you do to a single host.
>> 
>> So what you should do (at least what I would do) is to not advertise anythin
>g
>> related to 6to4 until you have verified that the relay is reachable.
> 
>The option is design to be used on RENEW as well as initial requests.
>It's designed for the operator of the network to tell the clients
>of the network that 6to4 will no longer work and you should stop
>running 6to4.

I understand that you are just trying to push your DHCP option, without
considering any other alternative, but this line of reasoning is unlikely
to get you anywhere.

So, take for a example the message you just replied to. I described how I
would use the reachability test to prevent 6to4 from being advertised and
how a lack of reachability would cause those advertisements to timeout.

So the only thing (in that scenario) a network operator has to do is block 
access to the 6to4 anycast address.

Now you may not like that mechanism, but is completely pointless to keep adding
all kinds of new features to your solution in the hope that you find a niche
where it might be used.

Get real, an operator who is going to dynamically (with RENEW) turn 6to4
support on and off?

>> Similarly, I would stop advertising anything related to 6to4 as soon as the
>> connection to the relay is broken.
>
>Define "broken".  I've had to work over IPv4 which dropped packet
>but I didn't pull the IPv4 addresses off the machines just because
>some packets got lost.

So, just read what I wrote in my previous message, reflect on how IPv6
neighbor discovery works, and you will see that this not what is going to
happen.

>> If it is a transient error then there will
>> be just a bit of packet loss, if it is a longer lasting error then eventuall
>y
>> all addressen and routes will timeout and hosts will revert to IPv4.
>
>So you would have host continuly renumbering themselves for temporary
>errors.

So of course not, because addresses are valid much longer than a short
transient error.

>This group has grossly over reacted to 6to4 and mixed up different
>6to4 issues.
>
>You have 6to4 failing due to being run in a environment where it
>will not even start up.

That is not failure from this group's perspective. 

>You have machines moving from places where 6to4 works to places
>where 6to4 cannot work.

So, do a reachbility check and you will be fine. Or, just enable 6to4
when the IPv4 address is in a specific range. That requires a small change
to the user interface, but allows the user to sepcify what he wants.

>You have machines moving from places where 6to4 works to places
>where 6to4 still works but shouldn't be started for policy reasons.

So, block access to the anycast address and you are back to the previous case.

>You have networks that move from working 6to4 to non working 6to4
>due to the introduction of things like CGN.

If it is done properly, then the RFC-1918 address will prevent 6to4 from 
starting anyhow. Otherwise, the reachability check will prevent 6to4 from
being used. Otherwise, the new IPv4 address will be outside the range for
which 6to4 is enabled (assuming the UI changes are in place).

>And you have potential load based issues which quite frankly are
>completely solvable including return path issues.

That's why this group wants to discourage the use of 6to4.



From ipng@69706e6720323030352d30312d31340a.nosense.org  Tue May 17 04:14: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 935E8E06DD for ; Tue, 17 May 2011 04:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[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 r2-w0sa78KNY for ; Tue, 17 May 2011 04:14:26 -0700 (PDT)
Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id EB69AE0689 for ; Tue, 17 May 2011 04:14:25 -0700 (PDT)
Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QMIEJ-0003uM-V9 for v6ops@ietf.org; Tue, 17 May 2011 20:44:23 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 98DC13B33B for ; Tue, 17 May 2011 20:44:23 +0930 (CST)
Date: Tue, 17 May 2011 20:44:23 +0930
From: Mark Smith 
To: v6ops@ietf.org
Message-ID: <20110517204423.2e2d2bc7@opy.nosense.org>
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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
Subject: [v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP Address Managment System?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 11:14:26 -0000

Hi,

It recently occurred to me that it could be useful to store IPv4 prefix
information in an IPv6 IP address management system, so that both IPv4
and IPv6 prefix information are kept in the same address
management database.

The only question I have about doing that is what IPv6 prefix to use
for these IPv4 prefix entries. The deprecated IPv4-Compatible IPv6
Address format would be convenient for this purpose as all bits
preceding the IPv4 prefix are zeros, making these entries very easy to
spot if you happen to be looking at the IPv6 form of them. Would that
be safe and reasonable to use the ::/96 prefix? Would it be worth me
writing up an ID proposing the recycing of this form of IPv6 address
for this purpose?

Thanks,
Mark.

From mohacsi@niif.hu  Tue May 17 04:33: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 9956FE0758 for ; Tue, 17 May 2011 04:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level: 
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[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 LcRqN9K+8yHG for ; Tue, 17 May 2011 04:33:06 -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 6600CE074E for ; Tue, 17 May 2011 04:33:06 -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 7D9E0874C6; Tue, 17 May 2011 13:33:03 +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 Kw1xLqt3w6Gl; Tue, 17 May 2011 13:32:40 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id B1F94874D0; Tue, 17 May 2011 13:32:40 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id AD661874C6; Tue, 17 May 2011 13:32:40 +0200 (CEST)
Date: Tue, 17 May 2011 13:32:40 +0200 (CEST)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Mark Smith 
In-Reply-To: <20110517204423.2e2d2bc7@opy.nosense.org>
Message-ID: 
References: <20110517204423.2e2d2bc7@opy.nosense.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
Subject: Re: [v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP Address Managment System?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 11:33:07 -0000

On Tue, 17 May 2011, Mark Smith wrote:

> Hi,
>
> It recently occurred to me that it could be useful to store IPv4 prefix
> information in an IPv6 IP address management system, so that both IPv4
> and IPv6 prefix information are kept in the same address
> management database.
>
> The only question I have about doing that is what IPv6 prefix to use
> for these IPv4 prefix entries. The deprecated IPv4-Compatible IPv6
> Address format would be convenient for this purpose as all bits
> preceding the IPv4 prefix are zeros, making these entries very easy to
> spot if you happen to be looking at the IPv6 form of them. Would that
> be safe and reasonable to use the ::/96 prefix? Would it be worth me
> writing up an ID proposing the recycing of this form of IPv6 address
> for this purpose?

I think it is only a representation, which can be specific for your 
application.  Parsing and implementing can be done  in the application as 
e.g.: ::192.168.0.1 or 192.168.0.1 or ::c0a8:1
Some application may decide to store IPv4 addresses in text, some in 
binary w.g in sockaddr_storage.

What is the motivation for standardise this?

Best Regards,
 	Janos Mohacsi

From pch-b2B3A6689@u-1.phicoh.com  Tue May 17 04:50: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 DA586E06EA for ; Tue, 17 May 2011 04:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 TdZyBWtPuez2 for ; Tue, 17 May 2011 04:50:03 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id EE1E1E0689 for ; Tue, 17 May 2011 04:50:01 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QMImc-0001i7C; Tue, 17 May 2011 13:49:50 +0200
Message-Id: 
To: Mark Smith 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
In-reply-to: Your message of "Tue, 17 May 2011 20:44:23 +0930 ." <20110517204423.2e2d2bc7@opy.nosense.org> 
Date: Tue, 17 May 2011 13:49:37 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP Address Managment System?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 11:50:04 -0000

In your letter dated Tue, 17 May 2011 20:44:23 +0930 you wrote:
>The only question I have about doing that is what IPv6 prefix to use
>for these IPv4 prefix entries. The deprecated IPv4-Compatible IPv6
>Address format would be convenient for this purpose as all bits
>preceding the IPv4 prefix are zeros, making these entries very easy to
>spot if you happen to be looking at the IPv6 form of them. Would that
>be safe and reasonable to use the ::/96 prefix? Would it be worth me
>writing up an ID proposing the recycing of this form of IPv6 address
>for this purpose?

I would use IPv4-mapped. [::ffff:] is also easy to grep, it is
already in use in a lot of places and it avoids confusion for
[::] and [::1]. That may not be an issue in your application, but it
probably more convenient to have one format that is used everywhere.



From ipng@69706e6720323030352d30312d31340a.nosense.org  Tue May 17 05:06: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 CE06EE0751 for ; Tue, 17 May 2011 05:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[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 Lr7EgC8kYun9 for ; Tue, 17 May 2011 05:06:50 -0700 (PDT)
Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id D8FF7E06AC for ; Tue, 17 May 2011 05:06:48 -0700 (PDT)
Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QMJ2z-00069W-N0; Tue, 17 May 2011 21:36:45 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 15B233B33B; Tue, 17 May 2011 21:36:45 +0930 (CST)
Date: Tue, 17 May 2011 21:36:44 +0930
From: Mark Smith 
To: Mohacsi Janos 
Message-ID: <20110517213644.64c78030@opy.nosense.org>
In-Reply-To: 
References: <20110517204423.2e2d2bc7@opy.nosense.org> 
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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
Subject: Re: [v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP Address Managment System?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 12:06:50 -0000

Hi Janos,

On Tue, 17 May 2011 13:32:40 +0200 (CEST)
Mohacsi Janos  wrote:

> 
> 
> 
> On Tue, 17 May 2011, Mark Smith wrote:
> 
> > Hi,
> >
> > It recently occurred to me that it could be useful to store IPv4 prefix
> > information in an IPv6 IP address management system, so that both IPv4
> > and IPv6 prefix information are kept in the same address
> > management database.
> >
> > The only question I have about doing that is what IPv6 prefix to use
> > for these IPv4 prefix entries. The deprecated IPv4-Compatible IPv6
> > Address format would be convenient for this purpose as all bits
> > preceding the IPv4 prefix are zeros, making these entries very easy to
> > spot if you happen to be looking at the IPv6 form of them. Would that
> > be safe and reasonable to use the ::/96 prefix? Would it be worth me
> > writing up an ID proposing the recycing of this form of IPv6 address
> > for this purpose?
> 
> I think it is only a representation, which can be specific for your 
> application.  Parsing and implementing can be done  in the application as 
> e.g.: ::192.168.0.1 or 192.168.0.1 or ::c0a8:1
> Some application may decide to store IPv4 addresses in text, some in 
> binary w.g in sockaddr_storage.
> 
> What is the motivation for standardise this?
> 

Similar to the motivation to have a specific documentation prefix. If
somebody wants to store an IPv4 address/prefix in an IPv6
variable/structure, there is a well known prefix defined for that
purpose. Certainly not necessary, but possibly quite useful.

The other alternative would be to use the IPv4-Mapped IPv6 Address
form. The description from RFC4291 seems to suit,

"A second type of IPv6 address that holds an embedded IPv4 address is
   defined.  This address type is used to represent the addresses of
   IPv4 nodes as IPv6 addresses."

although perhaps as this form is still in use for IPv6 applications to
receive IPv4 traffic, it might be better to have ::/96 as the
IPv4 address in IPv6 storage only well known prefix. ::/96 would be
easier and simpler for humans to deal with verses 0:0:0:0:0:ffff::/96
(as typing that in just demonstrated to me - I had to calculate the
number of ":0:"s and check them to make sure I had the right number).

Regards,
Mark.

From ipng@69706e6720323030352d30312d31340a.nosense.org  Tue May 17 05: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 F27CEE0743 for ; Tue, 17 May 2011 05:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.895
X-Spam-Level: 
X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[AWL=1.000,  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 rvUYsret7dS4 for ; Tue, 17 May 2011 05:19:29 -0700 (PDT)
Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 58CD8E0729 for ; Tue, 17 May 2011 05:19:29 -0700 (PDT)
Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QMJFF-0006ev-Lz; Tue, 17 May 2011 21:49:25 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 608DC3B33B; Tue, 17 May 2011 21:49:25 +0930 (CST)
Date: Tue, 17 May 2011 21:49:25 +0930
From: Mark Smith 
To: Philip Homburg 
Message-ID: <20110517214925.462f085d@opy.nosense.org>
In-Reply-To: 
References: <20110517204423.2e2d2bc7@opy.nosense.org> 
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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
Subject: Re: [v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP Address Managment System?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 12:19:30 -0000

Hi Philip,

On Tue, 17 May 2011 13:49:37 +0200
Philip Homburg  wrote:

> In your letter dated Tue, 17 May 2011 20:44:23 +0930 you wrote:
> >The only question I have about doing that is what IPv6 prefix to use
> >for these IPv4 prefix entries. The deprecated IPv4-Compatible IPv6
> >Address format would be convenient for this purpose as all bits
> >preceding the IPv4 prefix are zeros, making these entries very easy to
> >spot if you happen to be looking at the IPv6 form of them. Would that
> >be safe and reasonable to use the ::/96 prefix? Would it be worth me
> >writing up an ID proposing the recycing of this form of IPv6 address
> >for this purpose?
> 
> I would use IPv4-mapped. [::ffff:] is also easy to grep, it is
> already in use in a lot of places and it avoids confusion for
> [::] and [::1].

That is a very interesting point about [::1]. As an IPv6 addresses it
means something very different to the IPv4 value it would be when
interpreted using the IPv4-Compatible IPv6 Address format. Good thing
it is deprecated.

I think that suggests that ::ffff: is a better choice of
the existing IPv4 embedded in IPv6 address formats for this purpose.
That leaves the question of where there is any subtle traps with using
that IPv4 in IPv6 form for this storage purpose. 

>That may not be an issue in your application, but it
> probably more convenient to have one format that is used everywhere.
> 

Thanks,
Mark.

From marka@isc.org  Tue May 17 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 57585E073E for ; Tue, 17 May 2011 06:29:37 -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=1.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 jbZeWwYy1IUC for ; Tue, 17 May 2011 06:29: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 04B48E06B8 for ; Tue, 17 May 2011 06:29:35 -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 BFAC65F994D; Tue, 17 May 2011 13:29:11 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 4EC2B216C1E; Tue, 17 May 2011 13:29:09 +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 C5D3FECC630; Tue, 17 May 2011 23:30:06 +1000 (EST)
To: Philip Homburg 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org> 
In-reply-to: Your message of "Tue, 17 May 2011 11:43:57 +0200." 
Date: Tue, 17 May 2011 23:30:06 +1000
Message-Id: <20110517133006.C5D3FECC630@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 13:29:37 -0000

In message , Philip Homburg writes:
> In your letter dated Tue, 17 May 2011 10:54:48 +1000 you wrote:
> >In message , Philip Homburg writes:
> >> In your letter dated Mon, 16 May 2011 16:24:59 +1000 you wrote:
> >> >If 6to4 was only a single host then there is little distinction but
> >> >6to4 is not a just single host.  It is a border router, RAs, PD and
> >> >a whole lot more.  6to4 gives you a /48 not a /128.  What you do to
> >> >a network is different to what you do to a single host.
> >> 
> >> So what you should do (at least what I would do) is to not advertise anyth
> in
> >g
> >> related to 6to4 until you have verified that the relay is reachable.
> > 
> >The option is design to be used on RENEW as well as initial requests.
> >It's designed for the operator of the network to tell the clients
> >of the network that 6to4 will no longer work and you should stop
> >running 6to4.
> 
> I understand that you are just trying to push your DHCP option, without
> considering any other alternative, but this line of reasoning is unlikely
> to get you anywhere.

The other alteratives don't meet the operational needs.  Once you have
suceeded in getting 6to4 up and you have already advertised a prefix
you have cross a point which you really shouldn't go back across unless
you know that you won't recover.
 
> So, take for a example the message you just replied to. I described how I
> would use the reachability test to prevent 6to4 from being advertised and
> how a lack of reachability would cause those advertisements to timeout.

They are not mutually exclusive.
 
> So the only thing (in that scenario) a network operator has to do is block 
> access to the 6to4 anycast address.

Which is stupid.  Having to infer something is ALWAY going lead to wrong
results.

> Now you may not like that mechanism, but is completely pointless to keep addi
> ng
> all kinds of new features to your solution in the hope that you find a niche
> where it might be used.

I haven't added anything new.  0.0.0.0 for off has been there from the
begining.  What DHCP returns can and does change.
 
> Get real, an operator who is going to dynamically (with RENEW) turn 6to4
> support on and off?


 
> >> Similarly, I would stop advertising anything related to 6to4 as soon as th
> e
> >> connection to the relay is broken.
> >
> >Define "broken".  I've had to work over IPv4 which dropped packet
> >but I didn't pull the IPv4 addresses off the machines just because
> >some packets got lost.
> 
> So, just read what I wrote in my previous message, reflect on how IPv6
> neighbor discovery works, and you will see that this not what is going to
> happen.
> 
> >> If it is a transient error then there will
> >> be just a bit of packet loss, if it is a longer lasting error then eventua
> ll
> >y
> >> all addressen and routes will timeout and hosts will revert to IPv4.
> >
> >So you would have host continuly renumbering themselves for temporary
> >errors.
> 
> So of course not, because addresses are valid much longer than a short
> transient error.
> 
> >This group has grossly over reacted to 6to4 and mixed up different
> >6to4 issues.
> >
> >You have 6to4 failing due to being run in a environment where it
> >will not even start up.
> 
> That is not failure from this group's perspective. 
> 
> >You have machines moving from places where 6to4 works to places
> >where 6to4 cannot work.
> 
> So, do a reachbility check and you will be fine. Or, just enable 6to4
> when the IPv4 address is in a specific range. That requires a small change
> to the user interface, but allows the user to sepcify what he wants.

Which requires the use to know what address he his going to get and
if he know that he doesn't need dhcp.
 
> >You have machines moving from places where 6to4 works to places
> >where 6to4 still works but shouldn't be started for policy reasons.
> 
> So, block access to the anycast address and you are back to the previous case
> .

And you are back to guessing.
 
> >You have networks that move from working 6to4 to non working 6to4
> >due to the introduction of things like CGN.
> 
> If it is done properly, then the RFC-1918 address will prevent 6to4 from 
> starting anyhow. Otherwise, the reachability check will prevent 6to4 from
> being used. Otherwise, the new IPv4 address will be outside the range for
> which 6to4 is enabled (assuming the UI changes are in place).

Which is all supposition and guessing
 
> >And you have potential load based issues which quite frankly are
> >completely solvable including return path issues.
> 
> That's why this group wants to discourage the use of 6to4.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From pch-b2B3A6689@u-1.phicoh.com  Tue May 17 07:00: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 A6286E076D for ; Tue, 17 May 2011 07:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 DB65KXZZeA5c for ; Tue, 17 May 2011 07:00:00 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 70BFEE0773 for ; Tue, 17 May 2011 06:59: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 m1QMKoX-0001gNC; Tue, 17 May 2011 15:59:57 +0200
Message-Id: 
To: Mark Andrews 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org> 
In-reply-to: Your message of "Tue, 17 May 2011 23:30:06 +1000 ." <20110517133006.C5D3FECC630@drugs.dv.isc.org> 
Date: Tue, 17 May 2011 15:59:39 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 14:00:00 -0000

In your letter dated Tue, 17 May 2011 23:30:06 +1000 you wrote:
>> I understand that you are just trying to push your DHCP option, without
>> considering any other alternative, but this line of reasoning is unlikely
>> to get you anywhere.
>
>The other alteratives don't meet the operational needs.  Once you have
>suceeded in getting 6to4 up and you have already advertised a prefix
>you have cross a point which you really shouldn't go back across unless
>you know that you won't recover.

That is something you just pull out of thin air. If you fail to receive a
valid Router Advertisement for a long enough time, you have to expire your
addresses. 

If you fail to reach the DHCP(v4 or v6) server in time to renew your leases
you have the same problem.

But I also gave a solution for manual configuration. Which of course you
ignore.

>> So the only thing (in that scenario) a network operator has to do is block 
>> access to the 6to4 anycast address.
>
>Which is stupid.  Having to infer something is ALWAY going lead to wrong
>results.

Yes always. That's why duplicate address dectection is in the specs, that's
why we have neighbor unreachability detection. It is all going to fail.

>> So, do a reachbility check and you will be fine. Or, just enable 6to4
>> when the IPv4 address is in a specific range. That requires a small change
>> to the user interface, but allows the user to sepcify what he wants.
>
>Which requires the use to know what address he his going to get and
>if he know that he doesn't need dhcp.

You know, a long time ago somebody came up a notation for a range IP
addresses. Very cool.

>> >You have machines moving from places where 6to4 works to places
>> >where 6to4 still works but shouldn't be started for policy reasons.
>> 
>> So, block access to the anycast address and you are back to the previous cas
>e
>> .
>
>And you are back to guessing.

Guessing? If you get a reply from a 6to4 relay, then access to that relay is
not blocked by NAT or firewall. Doesn't sound like guessing to me.

>> >You have networks that move from working 6to4 to non working 6to4
>> >due to the introduction of things like CGN.
>> 
>> If it is done properly, then the RFC-1918 address will prevent 6to4 from 
>> starting anyhow. Otherwise, the reachability check will prevent 6to4 from
>> being used. Otherwise, the new IPv4 address will be outside the range for
>> which 6to4 is enabled (assuming the UI changes are in place).
>
>Which is all supposition and guessing

I'll just stop here.



From v6ops@globis.net  Tue May 17 07:09: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 3A5C5E0823 for ; Tue, 17 May 2011 07:09:20 -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, 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 jTPJHHUsvAUt for ; Tue, 17 May 2011 07:09:19 -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 C7329E0821 for ; Tue, 17 May 2011 07:09:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 65B69870083; Tue, 17 May 2011 16:09:17 +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 1VmeW3SaiTVr; Tue, 17 May 2011 16:09:11 +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 4D19C870023; Tue, 17 May 2011 16:09:11 +0200 (CEST)
Message-ID: <4DD28187.6000806@globis.net>
Date: Tue, 17 May 2011 16:09:11 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Mark Smith ,  "v6ops@ietf.org WG" 
Content-Type: multipart/alternative; boundary="------------090707090908010005000306"
Subject: [v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP Address Managment System?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 14:09:20 -0000

This is a multi-part message in MIME format.
--------------090707090908010005000306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I recently coded a system where I handled the IPv4 addresses as IPv4 
mapped IPv6 addresses = ::ffff:a.b.c.d addresses in a single table for 
all prefixes for an application. It was convenient in the end, but it 
took quite a lot of code to handle the special human readable forms 
properly.

I can let you have the PERL library if you want.

I would certainly avoid use of deprecated addresses ::0000:a.b.c.d. 
There is some overlap e.g. ::1 & ::0

I also found some problems with libraries handling things like ::ffff:10.0

Another equally valid approach is to use completely separate tables for 
IPv4 and IPv6, depending on your application.

How, for example, in a firewall rules system, would you distinguish a 
match rule for an IPv4 mapped IPv6 address being carried over a native 
IPv6 packet, versus a normal native IPv4 encapsulated packet? You'd 
anyway need to keep track of the encapsulation on the wire.

http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02

Sometimes it's just better to treat IPv4 and IPv6 as completely separate 
address families.

best regards,
RayH

> Subject:
> [v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP 
> Address Managment System?
> From:
> Mark Smith 
> Date:
> Tue, 17 May 2011 20:44:23 +0930
>
> To:
> v6ops@ietf.org
>
> Content-Transfer-Encoding:
> 7bit
> Precedence:
> list
> MIME-Version:
> 1.0
> Message-ID:
> <20110517204423.2e2d2bc7@opy.nosense.org>
> Content-Type:
> text/plain; charset=US-ASCII
> Message:
> 4
>
>
> Hi,
>
> It recently occurred to me that it could be useful to store IPv4 prefix
> information in an IPv6 IP address management system, so that both IPv4
> and IPv6 prefix information are kept in the same address
> management database.
>
> The only question I have about doing that is what IPv6 prefix to use
> for these IPv4 prefix entries. The deprecated IPv4-Compatible IPv6
> Address format would be convenient for this purpose as all bits
> preceding the IPv4 prefix are zeros, making these entries very easy to
> spot if you happen to be looking at the IPv6 form of them. Would that
> be safe and reasonable to use the ::/96 prefix? Would it be worth me
> writing up an ID proposing the recycing of this form of IPv6 address
> for this purpose?
>
> Thanks,
> Mark.
>
>    

--------------090707090908010005000306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit








I recently coded a system where I handled the IPv4 addresses as IPv4
mapped IPv6 addresses = ::ffff:a.b.c.d addresses in a single table for
all prefixes for an application. It was convenient in the end, but it
took quite a lot of code to handle the special human readable forms
properly.



I can let you have the PERL library if you want.



I would certainly avoid use of deprecated addresses ::0000:a.b.c.d.
There is some overlap e.g. ::1 & ::0



I also found some problems with libraries handling things like
::ffff:10.0



Another equally valid approach is to use completely separate tables for
IPv4 and IPv6, depending on your application.



How, for example, in a firewall rules system, would you distinguish a
match rule for an IPv4 mapped IPv6 address being carried over a native
IPv6 packet, versus a normal native IPv4 encapsulated packet? You'd
anyway need to keep track of the encapsulation on the wire.



http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02



Sometimes it's just better to treat IPv4 and IPv6 as completely
separate address families.



best regards,

RayH





  

    
      

        
        
Subject:
        

[v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP Address
Managment System?		
      

      

        
        
From: 

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>		
      

      

        
        
Date: 

Tue, 17 May 2011 20:44:23 +0930		
      

    
  

  

    
      

        
        
To: 

v6ops@ietf.org		
      

    
  

  

    
      

        
        
Content-Transfer-Encoding:
        

7bit		
      

      

        
        
Precedence:
        

list		
      

      

        
        
MIME-Version:
        

1.0		
      

      

        
        
Message-ID:
        

<20110517204423.2e2d2bc7@opy.nosense.org>		
      

      

        
        
Content-Type:
        

text/plain; charset=US-ASCII		
      

      

        
        
Message:
        

4		
      

    
  

  

  

  
Hi,

It recently occurred to me that it could be useful to store IPv4 prefix
information in an IPv6 IP address management system, so that both IPv4
and IPv6 prefix information are kept in the same address
management database.

The only question I have about doing that is what IPv6 prefix to use
for these IPv4 prefix entries. The deprecated IPv4-Compatible IPv6
Address format would be convenient for this purpose as all bits
preceding the IPv4 prefix are zeros, making these entries very easy to
spot if you happen to be looking at the IPv6 form of them. Would that
be safe and reasonable to use the ::/96 prefix? Would it be worth me
writing up an ID proposing the recycing of this form of IPv6 address
for this purpose?

Thanks,
Mark.

  

  






--------------090707090908010005000306--

From cb.list6@gmail.com  Tue May 17 08:27: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 EA17FE06C6; Tue, 17 May 2011 08:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.098
X-Spam-Level: 
X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 2xS4RfnWFFO4; Tue, 17 May 2011 08:27:13 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB9EBE0665; Tue, 17 May 2011 08:27:12 -0700 (PDT)
Received: by eye13 with SMTP id 13so248911eye.31 for ; Tue, 17 May 2011 08:27:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ypl+/64yv6Qsuw6U6iSBP/kGJd1b/BNkvdgW/+Eq3Ak=; b=vn03mcuwapuGoYalpK8VGobQwahPs95iVbmihAZXRv32cZWn7YCktHKG/V5KsUc/Bt TT5h+0lW209Xnmgx+H35MG+e9opRchnyScxxgqGU2oKYVNI14tFBMfrFEWXEjE/FdIQr ZaxgGb5csVoVZfUUJmPBoZEIc7pneJc7vruEI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xPgm6NWoQkMAEgHfAWJQAyrMv9ixHJhrghdGm+TAbFma/0Us0aF5VdQVawBOgYj74g uQU8atmFteMvKJ+AY1EBFob93HstQf0LtyPndDq5XKo6jFcsYa+wk6fWsIHT8G55bq3r imIwwXj+V79FGx/a0aKQ51ZezjKyDMq9yms/w=
MIME-Version: 1.0
Received: by 10.14.38.14 with SMTP id z14mr260783eea.169.1305646032040; Tue, 17 May 2011 08:27:12 -0700 (PDT)
Received: by 10.14.47.10 with HTTP; Tue, 17 May 2011 08:27:08 -0700 (PDT)
Received: by 10.14.47.10 with HTTP; Tue, 17 May 2011 08:27:08 -0700 (PDT)
In-Reply-To: <20110517.084108.74718031.sthaug@nethelp.no>
References: <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com> <4DD19909.9060202@dcrocker.net>  <20110517.084108.74718031.sthaug@nethelp.no>
Date: Tue, 17 May 2011 08:27:08 -0700
Message-ID: 
From: Cameron Byrne 
To: sthaug@nethelp.no
Content-Type: multipart/alternative; boundary=0015174c44b0f134b204a37a67b1
Cc: v6ops@ietf.org, ietf@ietf.org, dcrocker@bbiw.net, touch@isi.edu
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 15:27:14 -0000

--0015174c44b0f134b204a37a67b1
Content-Type: text/plain; charset=ISO-8859-1

On May 16, 2011 11:41 PM,  wrote:
>
> > > How much longer does this list need to be to justify choosing better
labels for this v6 dual-stack transition hack?
> >
> > returning different sets of resource records on the basis of the orgin
of a query ala split horizon is not exactly new ground.
> >
> > By my observation, what is being done, satisfactorily
> > meets the dictionary definition of a whitelist. the term was
uncontroversial in the dicussion leading up to the wglc. If it's really
inapropiate that's cool but I'm frankly not convinced.
>
> Agreed. I see no good reason to change the use of "whitelist". Let's
> move on.
>

+1 for moving on

Cb
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--0015174c44b0f134b204a37a67b1
Content-Type: text/html; charset=ISO-8859-1




On May 16, 2011 11:41 PM, <sthaug@nethelp.no> wrote:

>

> > > How much longer does this list need to be to justify choosing better labels for this v6 dual-stack transition hack?

> >

> > returning different sets of resource records on the basis of the orgin of a query ala split horizon is not exactly new ground.

> >

> > By my observation, what is being done, satisfactorily

> > meets the dictionary definition of a whitelist. the term was uncontroversial in the dicussion leading up to the wglc. If it's really inapropiate that's cool but I'm frankly not convinced.

>

> Agreed. I see no good reason to change the use of "whitelist". Let's

> move on.

>


+1 for moving on


Cb

> Steinar Haug, Nethelp consulting, sthaug@nethelp.no

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

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




--0015174c44b0f134b204a37a67b1--

From fanf2@hermes.cam.ac.uk  Tue May 17 02:04: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 6BB39E0755; Tue, 17 May 2011 02:04:33 -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 mfzfT6JGsSoy; Tue, 17 May 2011 02:04:32 -0700 (PDT)
Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3127BE071E; Tue, 17 May 2011 02:04:31 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44265) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1QMGCY-0005BP-Pw (Exim 4.72) (return-path ); Tue, 17 May 2011 10:04:26 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QMGCY-0005X2-0q (Exim 4.67) (return-path ); Tue, 17 May 2011 10:04:26 +0100
Date: Tue, 17 May 2011 10:04:26 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Fred Baker , jason_livingood@cable.comcast.com
In-Reply-To: <985550C9-A8D8-40E0-9CD5-5DB432A6692A@cisco.com>
Message-ID: 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>  <6.2.5.6.2.20110502215922.05513e20@resistor.net> <4DC1E7C2.8010405@dougbarton.us> <4DCB2909.3040506@isi.edu> <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com> <4DD19909.9060202@dcrocker.net>  <4DD1A378.1050009@dcrocker.net>  <4DD1AA05.5060108@dcrocker.net> <985550C9-A8D8-40E0-9CD5-5DB432A6692A@cisco.com>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
X-Mailman-Approved-At: Tue, 17 May 2011 08:32:20 -0700
Cc: v6ops@ietf.org, dcrocker@bbiw.net, IETF Discussion 
Subject: Re: [v6ops] Review of draft-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 09:04:33 -0000

Fred Baker  wrote:
>
> In this case, the draft is talking about a particular variety of DNS
> service. One might call is "DNS Whitelisting" when the context isn't
> clear, but I think in this case the context is clearly not DKIM.

The problem is that the specific phrase "DNS whitelist" is already used in
the anti-spam world, so it would be helpful if IPv6 resolver whitelists
used a different descriptive phrase.

The anti-spam blacklist/whitelist terminology is often quite poor. I think
it is clearer to talk about what is listed (as in URIBL) rather than how
the list is published (DNSBL) since the latter doesn't immediately explain
how the list is supposed to be used. See for example the cautionary note
at http://www.spamhaus.org/dbl/

In the case at hand, the list does not contain AAAA RRs as the abstract
suggests, it contains IPv6-capable resolvers. The whitelist isn't
published in the DNS, so it doesn't match the existing use of the phrase
"DNS whitelist".

So I suggest retitling the document "IPv6 DNS resolver whitelisting" and
revising the terminology throughout to match. e.g.

   This document describes the emerging practice of whitelisting of IPv6
   capable DNS resolvers, to determine which resolvers may be sent AAAA
   resrource records. This technique is referred to as IPv6 whitelisting.
   The document explores the implications of this emerging practice are
   and what alternatives may exist.

   The practice of IPv6 whitelisting appears to have first been used by
   major web content sites [...]

   As a result of this impairment affecting end users of a given domain,
   a few major domains have either implemented IPv6 whitelisting or are
   considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].
   When implemented, IPv6 whitelisting in practice means that a domain's
   authoritative DNS will return a AAAA resource record to DNS recursive
   resolvers [RFC1035] on the whitelist, while returning no AAAA
   resource records to DNS resolvers which are not on the whitelist.  It
   is important to note that these major domains are motivated by a
   desire to maintain a high-quality user experience for all of their
   users.  By engaging in IPv6 whitelisting, they are attempting to
   shield users with impaired access from the symptoms of those
   impairments.

etc.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.

From touch@isi.edu  Tue May 17 09:26: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 B6544E077A; Tue, 17 May 2011 09:26:56 -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 Qudrsvl22l-d; Tue, 17 May 2011 09:26:56 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id F1775E0746; Tue, 17 May 2011 09:26:55 -0700 (PDT)
Received: from [136.242.248.185] (host-248-185.cua.edu [136.242.248.185]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id p4HGQJ00014214 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 17 May 2011 09:26:29 -0700 (PDT)
Message-ID: <4DD2A1AB.9040409@isi.edu>
Date: Tue, 17 May 2011 09:26:19 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Cameron Byrne 
References: <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com>	<4DD19909.9060202@dcrocker.net>		<20110517.084108.74718031.sthaug@nethelp.no> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: v6ops@ietf.org, dcrocker@bbiw.net, ietf@ietf.org
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 16:26:56 -0000

On 5/17/2011 8:27 AM, Cameron Byrne wrote:
>
> On May 16, 2011 11:41 PM, >
> wrote:
>  >
>  > > > How much longer does this list need to be to justify choosing
> better labels for this v6 dual-stack transition hack?
>  > >
>  > > returning different sets of resource records on the basis of the
> orgin of a query ala split horizon is not exactly new ground.
>  > >
>  > > By my observation, what is being done, satisfactorily
>  > > meets the dictionary definition of a whitelist. the term was
> uncontroversial in the dicussion leading up to the wglc. If it's really
> inapropiate that's cool but I'm frankly not convinced.

I'm OK if there's consensus not to change it, but the wider scope of 
IETF LC and cross-area review is exactly to catch things that the WG didn't.

Joe

From hsantos@isdg.net  Tue May 17 09:46: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 D5C12E06AD for ; Tue, 17 May 2011 09:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.411
X-Spam-Level: 
X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=-0.812, 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 Cw92BWlSyQuh for ; Tue, 17 May 2011 09:46:17 -0700 (PDT)
Received: from groups.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DC2D5E071C for ; Tue, 17 May 2011 09:46:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=isdg.net; s=tms1; l=949; t=1305650772; h=Message-ID:Date:From:Organization:To: Subject; bh=N+VMUqUc/nStP3X4xnDBxglpKAI=; b=SjV3n1eE2SKXgQElmLDU V7LtNINMjjILsjB7MyB2+ICoy10Aj3zJXeiTVR5R1li8ABHC1eX4ge3eKS19WD8Y +wQQ5/31yKRAPSFQYkHEPeyBTxr7Y7kvFTfWgBAjTV9KQaSWKI61XU/7t3OdPc6p pogxSl0UFcPhSmEYmN8FKG0=
Received: by winserver.com (Wildcat! SMTP Router v6.3.453.5) for v6ops@ietf.org; Tue, 17 May 2011 12:46:12 -0400
Received: from opensite.winserver.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v6.3.453.5) with ESMTP id 2696265699.8564.2960; Tue, 17 May 2011 12:46:08 -0400
Received: by beta.winserver.com (Wildcat! SMTP Router v6.3.453.2) for v6ops@ietf.org; Tue, 17 May 2011 12:43:40 -0400
Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.3.453.2) with ESMTP id 3667592282; Tue, 17 May 2011 12:43:38 -0400
Message-ID: <4DD2A682.9070300@isdg.net>
Date: Tue, 17 May 2011 12:46:58 -0400
From: Hector Santos 
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Joe Touch 
References: <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com>	<4DD19909.9060202@dcrocker.net>		<20110517.084108.74718031.sthaug@nethelp.no>	 <4DD2A1AB.9040409@isi.edu>
In-Reply-To: <4DD2A1AB.9040409@isi.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 17 May 2011 10:08:58 -0700
Cc: ietf@ietf.org, v6ops@ietf.org, dcrocker@bbiw.net
Subject: Re: [v6ops] Review of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 16:46:17 -0000

Joe Touch wrote:
> 
> 
> On 5/17/2011 8:27 AM, Cameron Byrne wrote:
>>
>> On May 16, 2011 11:41 PM, >
>> wrote:
>>  >
>>  > > > How much longer does this list need to be to justify choosing
>> better labels for this v6 dual-stack transition hack?
>>  > >
>>  > > returning different sets of resource records on the basis of the
>> orgin of a query ala split horizon is not exactly new ground.
>>  > >
>>  > > By my observation, what is being done, satisfactorily
>>  > > meets the dictionary definition of a whitelist. the term was
>> uncontroversial in the dicussion leading up to the wglc. If it's really
>> inapropiate that's cool but I'm frankly not convinced.
> 
> I'm OK if there's consensus not to change it, but the wider scope of 
> IETF LC and cross-area review is exactly to catch things that the WG 
> didn't.

+1

-- 
Hector Santos, CTO
http://www.santronics.com




From hsantos@isdg.net  Tue May 17 09:51: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 3877DE0720 for ; Tue, 17 May 2011 09:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.393
X-Spam-Level: 
X-Spam-Status: No, score=-3.393 tagged_above=-999 required=5 tests=[AWL=-0.794, 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 sQWGurlmf6gf for ; Tue, 17 May 2011 09:51:12 -0700 (PDT)
Received: from listserv.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EACCDE071C for ; Tue, 17 May 2011 09:51:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=isdg.net; s=tms1; l=1385; t=1305651068; h=Message-ID:Date:From:Organization:To: Subject; bh=sN22Tv2lUoW5+zZv2WlOKA5c8Ao=; b=e94QLw99tlgPre21MTEm J8GsAQAIKw7x79WG4IBxg/rI+nsstNNC83C5ms7bnIRCF6fJ8snailpdaRUkJoJQ yd+20BkRr0Hg6Yq5iC2FI2fY/eqvE2qsh3s8IoOmuG4tsXb+Dv23Q7WzP1yq/86/ SX1SVJOjWQAEStI4YYx9U/A=
Received: by winserver.com (Wildcat! SMTP Router v6.3.453.5) for v6ops@ietf.org; Tue, 17 May 2011 12:51:08 -0400
Received: from beta.winserver.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v6.3.453.5) with ESMTP id 2696563130.8586.5412; Tue, 17 May 2011 12:51:05 -0400
Received: by beta.winserver.com (Wildcat! SMTP Router v6.3.453.2) for v6ops@ietf.org; Tue, 17 May 2011 12:48:39 -0400
Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.3.453.2) with ESMTP id 3667890985; Tue, 17 May 2011 12:48:37 -0400
Message-ID: <4DD2A7AE.4020502@isdg.net>
Date: Tue, 17 May 2011 12:51:58 -0400
From: Hector Santos 
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>		<6.2.5.6.2.20110502215922.05513e20@resistor.net>	<4DC1E7C2.8010405@dougbarton.us>	<4DCB2909.3040506@isi.edu>	<9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com>	<4DD19909.9060202@dcrocker.net>		<4DD1A378.1050009@dcrocker.net>	 <4DD1AA05.5060108@dcrocker.net>
In-Reply-To: <4DD1AA05.5060108@dcrocker.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 17 May 2011 10:08:58 -0700
Cc: v6ops@ietf.org, IETF Discussion 
Subject: Re: [v6ops] Review	of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 16:51:13 -0000

Dave CROCKER wrote:
> 
> 
> On 5/16/2011 6:44 PM, Joel Jaeggli wrote:

>> Will we be revising dkim rfc 4871 to explictly define whitelist as dns 
>> name based whitelist thereby replacing the existing two usages of the term 
>> (which involve explicitly allowing delivery on the basis of orign), or was 
>> the term appraise in 2009 but not now?
> 
> how is non-normative discussion text in rfc 4871 relevant?
> 
> Perhaps that also means that all RFC references to cron are required to 
> define the term?

The beauty of RFCs is its merger of functional and technical writing 
for a multi-discipline audience environment.

Ideally, the writer should find a term that is *universally" 
understood.  On the other hand, at times "Being Specific Is Terrific." 
In this case with DKIM, the "cron" usage in MLM I-D (IMO) was 
inconsistently applied; may be helpful for one audience group, but not 
others.

For "DNS Whitelisting," IMV, it is more universal, although it might 
be come with different perspectives and motivations.  For example, the 
irony (as I read the documents) is that it is based on faults 
occurring of the network - using expected failure as a form to 
filtering out the incompatibilities - the "bad". In that vain, we have 
a form of "whitelisting."

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com



From joelja@bogus.com  Tue May 17 14:40: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 3C668E068E for ; Tue, 17 May 2011 14:40:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.068
X-Spam-Level: 
X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 mXQIdSr+TOvw for ; Tue, 17 May 2011 14:40:22 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8E01EE0674 for ; Tue, 17 May 2011 14:40:22 -0700 (PDT)
Received: from 23173jjaeggli.corp.zynga.com ([12.184.108.202]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p4HLe9rZ041604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 May 2011 21:40:12 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: <20110517204423.2e2d2bc7@opy.nosense.org>
Date: Tue, 17 May 2011 14:40:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20110517204423.2e2d2bc7@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]); Tue, 17 May 2011 21:40:12 +0000 (UTC)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP Address Managment System?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 21:40:23 -0000

I would think that the appropriate  method would be to have an ipam =
system which supports both ipv4 and ipv6 addresses within it's data =
structures... if you store the v4 addresses in the v6 representation =
your engineers will eat a bullet every time the have to convert hex to =
decimal.

current versions of racktables or the U of O's netdot are capable of =
handling this.


On May 17, 2011, at 4:14 AM, Mark Smith wrote:

> Hi,
>=20
> It recently occurred to me that it could be useful to store IPv4 =
prefix
> information in an IPv6 IP address management system, so that both IPv4
> and IPv6 prefix information are kept in the same address
> management database.
>=20
> The only question I have about doing that is what IPv6 prefix to use
> for these IPv4 prefix entries. The deprecated IPv4-Compatible IPv6
> Address format would be convenient for this purpose as all bits
> preceding the IPv4 prefix are zeros, making these entries very easy to
> spot if you happen to be looking at the IPv6 form of them. Would that
> be safe and reasonable to use the ::/96 prefix? Would it be worth me
> writing up an ID proposing the recycing of this form of IPv6 address
> for this purpose?
>=20
> Thanks,
> Mark.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20


From ipng@69706e6720323030352d30312d31340a.nosense.org  Tue May 17 14:54: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 59D73E068E for ; Tue, 17 May 2011 14:54:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.038
X-Spam-Level: 
X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 04P5EbBlfOwN for ; Tue, 17 May 2011 14:54:11 -0700 (PDT)
Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA8BE0674 for ; Tue, 17 May 2011 14:54:11 -0700 (PDT)
Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QMSDQ-0006nb-7Y; Wed, 18 May 2011 07:24:08 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id E2DB03B338; Wed, 18 May 2011 07:24:07 +0930 (CST)
Date: Wed, 18 May 2011 07:24:07 +0930
From: Mark Smith 
To: Joel Jaeggli 
Message-ID: <20110518072407.7220ce14@opy.nosense.org>
In-Reply-To: 
References: <20110517204423.2e2d2bc7@opy.nosense.org> 
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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
Subject: Re: [v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP Address Managment System?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 21:54:12 -0000

Hi Joel,

On Tue, 17 May 2011 14:40:03 -0700
Joel Jaeggli  wrote:

> I would think that the appropriate  method would be to have an ipam system which supports both ipv4 and ipv6 addresses within it's data structures... if you store the v4 addresses in the v6 representation your engineers will eat a bullet every time the have to convert hex to decimal.
> 

That's the thing. If there is a well known IPv6 prefix for this, then
the routines that displays addresses or accepts them as input can
easily recognise IPv4 prefixes embedded in IPv6 prefixes and
convert them backwards and forwards for storage in the IPv6 fields. The
rest of the IPAM internals are IPv6 only.

I'm not strongly disagreeing with handling IPv4 and IPv6 separately in
an IPAM. It's just that it occurred to me that handling IPv4 as a
special case subset of IPv6, with the few differences being limited to
displaying, input conversion, and prefix length handling, that it might
be a bit less development effort than handling the protocols as
separate and unrelated cases throughout the IPAM.


Thanks,
Mark.

From marka@isc.org  Tue May 17 15: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 AB41AE06E1; Tue, 17 May 2011 15:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.326
X-Spam-Level: 
X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=-0.327, 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 dtXSIXKzpIPm; Tue, 17 May 2011 15:27: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 36B5FE0674; Tue, 17 May 2011 15:27:03 -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 8A1535F98EA; Tue, 17 May 2011 22:26:37 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 4281F216C40; Tue, 17 May 2011 22:26:35 +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 DF9C3ECDD7E; Wed, 18 May 2011 08:27:35 +1000 (EST)
To: Tony Finch 
From: Mark Andrews 
References: <3C9FA63D-F1C0-4E35-91A9-DA9E49BF4B68@bbn.com>  <6.2.5.6.2.20110502215922.05513e20@resistor.net> <4DC1E7C2.8010405@dougbarton.us> <4DCB2909.3040506@isi.edu> <9E8B2DA9-D968-407E-9C81-D14B8AF879D2@bogus.com> <4DD19909.9060202@dcrocker.net>  <4DD1A378.1050009@dcrocker.net>  <4DD1AA05.5060108@dcrocker.net> <985550C9-A8D8-40E0-9CD5-5DB432A6692A@cisco.com> 
In-reply-to: Your message of "Tue, 17 May 2011 10:04:26 +0100." 
Date: Wed, 18 May 2011 08:27:35 +1000
Message-Id: <20110517222735.DF9C3ECDD7E@drugs.dv.isc.org>
Cc: IETF Discussion , v6ops@ietf.org, dcrocker@bbiw.net
Subject: Re: [v6ops] Review of draft-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 22:27:04 -0000

In message , Tony F
inch writes:
> Fred Baker  wrote:
> >
> > In this case, the draft is talking about a particular variety of DNS
> > service. One might call is "DNS Whitelisting" when the context isn't
> > clear, but I think in this case the context is clearly not DKIM.
> 
> The problem is that the specific phrase "DNS whitelist" is already used in
> the anti-spam world, so it would be helpful if IPv6 resolver whitelists
> used a different descriptive phrase.
> 
> The anti-spam blacklist/whitelist terminology is often quite poor. I think
> it is clearer to talk about what is listed (as in URIBL) rather than how
> the list is published (DNSBL) since the latter doesn't immediately explain
> how the list is supposed to be used. See for example the cautionary note
> at http://www.spamhaus.org/dbl/
> 
> In the case at hand, the list does not contain AAAA RRs as the abstract
> suggests, it contains IPv6-capable resolvers. The whitelist isn't
> published in the DNS, so it doesn't match the existing use of the phrase
> "DNS whitelist".

No.  It contains just resolvers.  All the resolvers in the world
should be capable of resolving AAAA records if they followed RFC
1034.  It was clear enough that unknown == opaque blob in terms of
actually resolving data.  What wasn't clear was how to load and
display the data in the opaque blobs but once the data was in the
system moving it around shouldn't have been a problem.

A IPv6 capable resolver uses IPv6 as a transport.  A IPv6 capable
resolver may do its own AAAA lookups.  A IPv6 capable nameserver
may *not* even be able to decode AAAA presentation format.  It may
just be being handed blobs of data.  AAAA doesn't require any special
handling in a nameserver.

> So I suggest retitling the document "IPv6 DNS resolver whitelisting" and
> revising the terminology throughout to match. e.g.

"DNS resolver whitelisting for AAAA resolution" describes what is being
talked about.
 
>    This document describes the emerging practice of whitelisting of IPv6
>    capable DNS resolvers, to determine which resolvers may be sent AAAA
>    resrource records. This technique is referred to as IPv6 whitelisting.
>    The document explores the implications of this emerging practice are
>    and what alternatives may exist.
> 
>    The practice of IPv6 whitelisting appears to have first been used by
>    major web content sites [...]
> 
>    As a result of this impairment affecting end users of a given domain,
>    a few major domains have either implemented IPv6 whitelisting or are
>    considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].
>    When implemented, IPv6 whitelisting in practice means that a domain's
>    authoritative DNS will return a AAAA resource record to DNS recursive
>    resolvers [RFC1035] on the whitelist, while returning no AAAA
>    resource records to DNS resolvers which are not on the whitelist.  It
>    is important to note that these major domains are motivated by a
>    desire to maintain a high-quality user experience for all of their
>    users.  By engaging in IPv6 whitelisting, they are attempting to
>    shield users with impaired access from the symptoms of those
>    impairments.
> 
> etc.
> 
> Tony.
> -- 
> f.anthony.n.finch    http://dotat.at/
> Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
> Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
> or 6 later. Rough or very rough. Occasional rain. Moderate or good,
> occasionally poor.
> _______________________________________________
> 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 ipng@69706e6720323030352d30312d31340a.nosense.org  Tue May 17 15: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 3D5D9E06D8 for ; Tue, 17 May 2011 15:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=-0.125,  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 YQ7ivygX6KPJ for ; Tue, 17 May 2011 15:52:55 -0700 (PDT)
Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDD4E068E for ; Tue, 17 May 2011 15:52:55 -0700 (PDT)
Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QMT8H-0000Ts-Dt; Wed, 18 May 2011 08:22:53 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id C45C63B338; Wed, 18 May 2011 08:22:52 +0930 (CST)
Date: Wed, 18 May 2011 08:22:52 +0930
From: Mark Smith 
To: Ray Hunter 
Message-ID: <20110518082252.7a7addc5@opy.nosense.org>
In-Reply-To: <4DD28187.6000806@globis.net>
References: <4DD28187.6000806@globis.net>
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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 WG" 
Subject: Re: [v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP Address Managment System?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 May 2011 22:52:56 -0000

Hi Ray,

On Tue, 17 May 2011 16:09:11 +0200
Ray Hunter  wrote:

> I recently coded a system where I handled the IPv4 addresses as IPv4 
> mapped IPv6 addresses = ::ffff:a.b.c.d addresses in a single table for 
> all prefixes for an application. It was convenient in the end, but it 
> took quite a lot of code to handle the special human readable forms 
> properly.
> 
> I can let you have the PERL library if you want.
> 

Thanks for the offer. For me it is mostly a theoretical question,
although I know somebody who because of time constraints is having to
quickly write an IPv6 only IPAM. It was when I thought about some
of the IPv4 IPAM issues they have that it occurred to me that an IPv6
IPAM could hold IPv4 prefixes with an appropriate representation.

Is your PERL library on cpan?

(You may be interested in a PERL module that decodes IPv6 DHCPv6 DUIDs
that a college of mine wrote -  Net::DHCPv6::DUID::Parser)


> I would certainly avoid use of deprecated addresses ::0000:a.b.c.d. 
> There is some overlap e.g. ::1 & ::0
> 
> I also found some problems with libraries handling things like ::ffff:10.0
> 
> Another equally valid approach is to use completely separate tables for 
> IPv4 and IPv6, depending on your application.
> 
> How, for example, in a firewall rules system, would you distinguish a 
> match rule for an IPv4 mapped IPv6 address being carried over a native 
> IPv6 packet, versus a normal native IPv4 encapsulated packet? You'd 
> anyway need to keep track of the encapsulation on the wire.
> 
> http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02
> 
> Sometimes it's just better to treat IPv4 and IPv6 as completely separate 
> address families.
> 
> best regards,
> RayH
> 
> > Subject:
> > [v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP 
> > Address Managment System?
> > From:
> > Mark Smith 
> > Date:
> > Tue, 17 May 2011 20:44:23 +0930
> >
> > To:
> > v6ops@ietf.org
> >
> > Content-Transfer-Encoding:
> > 7bit
> > Precedence:
> > list
> > MIME-Version:
> > 1.0
> > Message-ID:
> > <20110517204423.2e2d2bc7@opy.nosense.org>
> > Content-Type:
> > text/plain; charset=US-ASCII
> > Message:
> > 4
> >
> >
> > Hi,
> >
> > It recently occurred to me that it could be useful to store IPv4 prefix
> > information in an IPv6 IP address management system, so that both IPv4
> > and IPv6 prefix information are kept in the same address
> > management database.
> >
> > The only question I have about doing that is what IPv6 prefix to use
> > for these IPv4 prefix entries. The deprecated IPv4-Compatible IPv6
> > Address format would be convenient for this purpose as all bits
> > preceding the IPv4 prefix are zeros, making these entries very easy to
> > spot if you happen to be looking at the IPv6 form of them. Would that
> > be safe and reasonable to use the ::/96 prefix? Would it be worth me
> > writing up an ID proposing the recycing of this form of IPv6 address
> > for this purpose?
> >
> > Thanks,
> > Mark.
> >
> >    

From marka@isc.org  Tue May 17 20:28: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 E5603E0733 for ; Tue, 17 May 2011 20:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.605
X-Spam-Level: 
X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 zqBD0dQrUaw9 for ; Tue, 17 May 2011 20:28:07 -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 E24BAE0681 for ; Tue, 17 May 2011 20:28:06 -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 C98385F991D; Wed, 18 May 2011 03:27:42 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 0A5CA216C1E; Wed, 18 May 2011 03:27:41 +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 4DAC5ED0D25; Wed, 18 May 2011 13:28:42 +1000 (EST)
To: Philip Homburg 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org> 
In-reply-to: Your message of "Tue, 17 May 2011 15:59:39 +0200." 
Date: Wed, 18 May 2011 13:28:42 +1000
Message-Id: <20110518032842.4DAC5ED0D25@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 03:28:08 -0000

For those that like the test procedures please define a standard
test procedure which will work with any 6to4 relay.  Asking CPE
vendor to test without describing how to do the test really isn't
up to snuff.  You also find that some of the "obvious" test methods
don't work.

ICMPv6 echo requests don't work as the relays are often configured
to not respond to them.  HE's don't respond which are the only ones
I can test against.

Constructing a encapsulated packets from yourself(ipv6) to
yourself(ipv6) and sending them to the relay results in them to be
dropped by anti-spoof ingress filters which FreeBSD turns on by
default in the virtual interface driver (stf).  You can see them
if you use a packet filter but that really doesn't test that they
will make it past the host firewall which is one of the things
people are complaining about.  Adding exceptions also doesn't test
the general case.  I'm also slightly suprised that the relay accepted
encapsultate IPv6 packets to 2002::/16 as they should be able to
be delivered directly.  That being said it provides about the only
test path.

You can forge a IPv6 packet from somewhere not inside your network
but what IPv6 source address should you use?  ULA, should be being
filtered.  I did try the relay's address (2002:c058:6301::) which
worked but I'm really suprised that it did as it means that there
wasn't a anti-spoof ingress filter installed for 2002:c058:6301::/48.

For testing I was encapsulating icmp6 echo reply packets using
socket(AF_INET, SOCK_RAW, IPPROTO_IPV6) and making sure they were
delivered to a icmp6 socket, i.e. socket(AF_INET6, SOCK_RAW,
IPPROTO_ICMPV6).  UDP packets would have also worked but I wanted
a IPv6 packet that would not generate a IPv6 error.

Note 6rd will have these issues as well as it doesn't have well
defined BR reachability detection.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From lorenzo@google.com  Tue May 17 20:57: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 6E9C8E079D for ; Tue, 17 May 2011 20:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 rDWrRBSia5fy for ; Tue, 17 May 2011 20:57:11 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id C736DE0795 for ; Tue, 17 May 2011 20:57:10 -0700 (PDT)
Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p4I3v7wD024111 for ; Tue, 17 May 2011 20:57:08 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305691029; bh=gvogjoEirfa39ZJ776H0uodxTFY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=jGHaKkpBku0BWonj9lsynSdLUKAw8BWccDYus0daqvb/vVFC54VY5DQoNXfJoSOUs dbCH1NTedenWk1j2yV7/w==
Received: from yib19 (yib19.prod.google.com [10.243.65.83]) by hpaq6.eem.corp.google.com with ESMTP id p4I3tXHO026135 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 May 2011 20:57:06 -0700
Received: by yib19 with SMTP id 19so596933yib.18 for ; Tue, 17 May 2011 20:57:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bbnfQ94wA1gin8E8jl7uPop5D28uwSZ4xrvoG33MuaY=; b=j89ePkmdMsbb/tpRHaX80y0X256fGYEjdTNvbC7Dny62YMhZTcxwLUabLTVEbjLm7+ MI3Lc62pn61uY8TsWo9A==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=u6X9emUFJgLF9DRHnWTdWuMoFhUtvYdKG+0SWQzIdpJ1VkCEymyJ1vcgAiygSpzG6Z xW6v6HQ2mWFMQLur8zIQ==
Received: by 10.150.7.15 with SMTP id 15mr1017349ybg.378.1305691026107; Tue, 17 May 2011 20:57:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Tue, 17 May 2011 20:56:46 -0700 (PDT)
In-Reply-To: <20110518032842.4DAC5ED0D25@drugs.dv.isc.org>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <20110518032842.4DAC5ED0D25@drugs.dv.isc.org>
From: Lorenzo Colitti 
Date: Tue, 17 May 2011 20:56:46 -0700
Message-ID: 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=000e0cd28788cc2fcd04a384e16e
X-System-Of-Record: true
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 03:57:11 -0000

--000e0cd28788cc2fcd04a384e16e
Content-Type: text/plain; charset=ISO-8859-1

On Tue, May 17, 2011 at 8:28 PM, Mark Andrews  wrote:

> For those that like the test procedures please define a standard
> test procedure which will work with any 6to4 relay.


Send a TTL=1 packet to one of those IPv6-only sites whose existence you cite
as a reason to keep 6to4 around, and see if you get an unreachable back. Or
send a TTL=1 DNS query to the root servers.

Given the average quality of the relays out there, something like that it
going to be a hell of a lot more reliable than actually using the 6to4 relay
itself for two-way connectivity.

Not that trying to fix 6to4 makes any sense anyway, IMO. I'm just providing
some token opposition every now and then in order to ensure that silence is
not taken as agreement. :-)

--000e0cd28788cc2fcd04a384e16e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, May 17, 2011 at 8:28 PM, Mark Andrews <mark=
a@isc.org> wrote:



For those that like the test procedures please define a standard

test procedure which will work with any 6to4 relay.

Send a TTL=3D1 packet to one of those IPv6-only sites whose existe=
nce you cite as a reason to keep 6to4 around, and see if you get an unreach=
able back.=A0Or send a TTL=3D1 DNS query to the root servers.=A0




Given the average quality of the relays out there, some=
thing like that it going to be a hell of a lot more reliable than actually =
using the 6to4 relay itself for two-way connectivity.




Not that trying to fix 6to4 makes any sense anyway, IMO. I'm just =
providing some token opposition every now and then in order to ensure that =
silence is not taken as agreement. :-)


--000e0cd28788cc2fcd04a384e16e--

From marka@isc.org  Tue May 17 21:12: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 B165FE0713 for ; Tue, 17 May 2011 21:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.605
X-Spam-Level: 
X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 t6OEB3gZEfp9 for ; Tue, 17 May 2011 21:12:04 -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 F2E60E0701 for ; Tue, 17 May 2011 21:12:03 -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 36AF3C94D4; Wed, 18 May 2011 04:11:55 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 C32BC216C1E; Wed, 18 May 2011 04:11:54 +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 720A3ED0FF9; Wed, 18 May 2011 14:12:56 +1000 (EST)
To: Lorenzo Colitti 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <201105 18032842.4DAC5ED0D25@drugs.dv.isc.org> 
In-reply-to: Your message of "Tue, 17 May 2011 20:56:46 MST." 
Date: Wed, 18 May 2011 14:12:56 +1000
Message-Id: <20110518041256.720A3ED0FF9@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 04:12:04 -0000

In message , Lorenzo Colitt
i writes:
> On Tue, May 17, 2011 at 8:28 PM, Mark Andrews  wrote:
> 
> > For those that like the test procedures please define a standard
> > test procedure which will work with any 6to4 relay.
> 
> Send a TTL=1 packet to one of those IPv6-only sites whose existence you cite
> as a reason to keep 6to4 around, and see if you get an unreachable back. Or
> send a TTL=1 DNS query to the root servers.

Which is subject to ICMPv6 rate limiting.  i.e. it won't work if all the
6to4 sites using the relay do this.

> Given the average quality of the relays out there, something like that it
> going to be a hell of a lot more reliable than actually using the 6to4 relay
> itself for two-way connectivity.

> Not that trying to fix 6to4 makes any sense anyway, IMO. I'm just providing
> some token opposition every now and then in order to ensure that silence is
> not taken as agreement. :-)
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From john.mann@monash.edu  Tue May 17 21:39: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 E6792E07C8 for ; Tue, 17 May 2011 21:39:19 -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 iTsget6zAHta for ; Tue, 17 May 2011 21:39:19 -0700 (PDT)
Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id A58DAE07C2 for ; Tue, 17 May 2011 21:39:18 -0700 (PDT)
Received: from mail-vx0-f172.google.com ([209.85.220.172]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKTdNNdVVgzXlMGrPiUhVm94Vr+6GGLCSM@postini.com; Tue, 17 May 2011 21:39:18 PDT
Received: by mail-vx0-f172.google.com with SMTP id 33so1399033vxg.17 for ; Tue, 17 May 2011 21:39:17 -0700 (PDT)
Received: by 10.52.99.7 with SMTP id em7mr2058032vdb.131.1305693557142; Tue, 17 May 2011 21:39:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.164.132 with HTTP; Tue, 17 May 2011 21:38:57 -0700 (PDT)
In-Reply-To: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <20110518032842.4DAC5ED0D25@drugs.dv.isc.org> 
From: "John Mann (ITS)" 
Date: Wed, 18 May 2011 14:38:57 +1000
Message-ID: 
To: Lorenzo Colitti 
Content-Type: multipart/alternative; boundary=20cf307f3704a8b4aa04a3857828
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 04:39:20 -0000

--20cf307f3704a8b4aa04a3857828
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On 18 May 2011 13:56, Lorenzo Colitti  wrote:

> On Tue, May 17, 2011 at 8:28 PM, Mark Andrews  wrote:
>
>> For those that like the test procedures please define a standard
>> test procedure which will work with any 6to4 relay.
>
>
> Send a TTL=1 packet to one of those IPv6-only sites whose existence you
> cite as a reason to keep 6to4 around, and see if you get an unreachable
> back. Or send a TTL=1 DNS query to the root servers.
>
> Given the average quality of the relays out there, something like that it
> going to be a hell of a lot more reliable than actually using the 6to4 relay
> itself for two-way connectivity.
>
> Not that trying to fix 6to4 makes any sense anyway, IMO. I'm just providing
> some token opposition every now and then in order to ensure that silence is
> not taken as agreement. :-)
>

I would like to see a standard set of tests that could be used to work out
if 6to4 gateways and relays are working.
[ And try to avoid the debates about DHCP options, -historic, 100%
reliability of tests etc etc. ]
- Where is the 6to4 gateway or relay?
- Is it up?
- Is it passing packets?
- Is the network working but the remote end is down?

The test definition would include packet dumps,
a tool that performs the test - ping, *traceroute*,  hping3, sendip, C or
Perl program, ...
whatever command line or binary blob input is required, and
what output is expected for success and failure.

Test taxonomy may be something like:

For normal 6to4:
   client <-> gateway1 <-> gateway2 <-> server
client and server are in 2002::/16

T1: client -> gateway1
T2: client -> gateway2
T3: client -> server
[ tests from server are same as tests from client ]
[ client may be same as gateway1, server may be same as gateway2 ]

For Anycast 6to4:
    client -> gateway1 -> relay1 -> server -> relay2 -> gateway1 -> client
client is in 2002::/16, server is in normal 2000::/3
[ client may be same as gateway1 ]

T11: client -> gateway1
T12: client -> relay1
T13: client -> server
T14: server -> relay2
T15: server -> gateway1
T16: server -> client

===
Has someone made such a list of tests before?
Defined any of these tests?

Thanks,
    John

--20cf307f3704a8b4aa04a3857828
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

On 18 May 2011 13:56, Lorenzo Colitti=
 <lorenzo@google=
.com> wrote:



On Tue, May 17, 2011 at 8:28 P=
M, Mark Andrews <marka@isc.org> wrote:





For those that like the test procedures please define a standard

test procedure which will work with any 6to4 relay.

Send a TTL=3D1 packet to one of those IPv6-only sites whose =
existence you cite as a reason to keep 6to4 around, and see if you get an u=
nreachable back.=A0Or send a TTL=3D1 DNS query to the root servers.=A0





Given the average quality of the relays out there, some=
thing like that it going to be a hell of a lot more reliable than actually =
using the 6to4 relay itself for two-way connectivity.






Not that trying to fix 6to4 makes any sense anyway, IMO. I'm just =
providing some token opposition every now and then in order to ensure that =
silence is not taken as agreement. :-)



I would like to see a standard set of test=
s that could be used to work out if 6to4 gateways and relays are working.
[ And try to avoid the debates about DHCP options, -historic, 100%=
 reliability of tests etc etc. ]



- Where is the 6to4 gateway or relay?
- Is it up?
=
- Is it passing packets?
- Is the network working but the remote =
end is down?

The test definition would include pac=
ket dumps,



a tool that performs the test -=A0ping, *traceroute*, =A0hping3, sendi=
p, C or Perl program, ...
whatever command line or binary blob in=
put is required, and
what output is expected for success and fail=
ure.




Test taxonomy=A0may be something like:

For normal 6to4:
=A0 =A0client <-> gateway1 <-&=
gt; gateway2 <-> server
client and server are in 2002::/16<=
/div>



T1: client -> gateway1
T2: client -> ga=
teway2
T3: client -> server
[ tests from server are =
same as tests from client ]
[ client may be same as gateway1, ser=
ver may be same as gateway2 ]




For Anycast 6to4:=A0
=A0 =A0 client -> gat=
eway1 -> relay1 -> server -> relay2 -> gateway1 -> client
client is in 2002::/16, server is in normal 2000::/3=A0
[=
 client=A0may be same as gateway1 ]




T11: client -> gateway1
T12: client -> =
relay1
T13: client -> server
T14: server -> relay=
2
T15: server -> gateway1
T16: server -> client



=3D=3D=3D
Has someone made such a list of tes=
ts before?
Defined any of these tests?

T=
hanks,
=A0 =A0 John


--20cf307f3704a8b4aa04a3857828--

From marka@isc.org  Tue May 17 22:06: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 9358DE07CF for ; Tue, 17 May 2011 22:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.605
X-Spam-Level: 
X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 I2WrHeGg7tuz for ; Tue, 17 May 2011 22:06: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 9A59BE07A5 for ; Tue, 17 May 2011 22:06: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 10FC85F98BC; Wed, 18 May 2011 05:06:07 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 3C113216C1E; Wed, 18 May 2011 05:06:05 +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 73DE8ED35E7; Wed, 18 May 2011 15:07:06 +1000 (EST)
To: "John Mann (ITS)" 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <201105 18032842.4DAC5ED0D25@drugs.dv.isc.org>  
In-reply-to: Your message of "Wed, 18 May 2011 14:38:57 +1000." 
Date: Wed, 18 May 2011 15:07:06 +1000
Message-Id: <20110518050706.73DE8ED35E7@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 05:06:27 -0000

In message , "John Mann (IT
S)" writes:
> Hi,
> 
> On 18 May 2011 13:56, Lorenzo Colitti  wrote:
> 
> > On Tue, May 17, 2011 at 8:28 PM, Mark Andrews  wrote:
> >
> >> For those that like the test procedures please define a standard
> >> test procedure which will work with any 6to4 relay.
> >
> >
> > Send a TTL=1 packet to one of those IPv6-only sites whose existence you
> > cite as a reason to keep 6to4 around, and see if you get an unreachable
> > back. Or send a TTL=1 DNS query to the root servers.
> >
> > Given the average quality of the relays out there, something like that it
> > going to be a hell of a lot more reliable than actually using the 6to4 rela
> y
> > itself for two-way connectivity.
> >
> > Not that trying to fix 6to4 makes any sense anyway, IMO. I'm just providing
> > some token opposition every now and then in order to ensure that silence is
> > not taken as agreement. :-)
> >
> 
> I would like to see a standard set of tests that could be used to work out
> if 6to4 gateways and relays are working.
> [ And try to avoid the debates about DHCP options, -historic, 100%
> reliability of tests etc etc. ]
> - Where is the 6to4 gateway or relay?
> - Is it up?
> - Is it passing packets?
> - Is the network working but the remote end is down?
> 
> The test definition would include packet dumps,
> a tool that performs the test - ping, *traceroute*,  hping3, sendip, C or
> Perl program, ...
> whatever command line or binary blob input is required, and
> what output is expected for success and failure.
> 
> Test taxonomy may be something like:
> 
> For normal 6to4:
>    client <-> gateway1 <-> gateway2 <-> server
> client and server are in 2002::/16
> 
> T1: client -> gateway1
> T2: client -> gateway2
> T3: client -> server
> [ tests from server are same as tests from client ]
> [ client may be same as gateway1, server may be same as gateway2 ]
> 
> For Anycast 6to4:
>     client -> gateway1 -> relay1 -> server -> relay2 -> gateway1 -> client
> client is in 2002::/16, server is in normal 2000::/3
> [ client may be same as gateway1 ]
> 
> T11: client -> gateway1
> T12: client -> relay1
> T13: client -> server
> T14: server -> relay2
> T15: server -> gateway1
> T16: server -> client
> 
> ===
> Has someone made such a list of tests before?
> Defined any of these tests?
> 
> Thanks,
>     John

If the client is not the gateway you are limited to standard IPv6
test tools.  If the client is the gateways then you can add IPv4
test tools.

It wouldn't be to hard to do a 6to4 traceroute which send a IPv6
hlim=1 packet with changing IPv4 ttls until you get a ICMPv6 time
exceeded message and then start counting that up.  You would need
the ability to set the IPv6 hop limit independent of the IPv4 ttl
to get around a relay that isn't sending back ttl exceeded.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From lorenzo@google.com  Tue May 17 22:46: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 AC853E0681 for ; Tue, 17 May 2011 22:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 iDJ1FLevZZpB for ; Tue, 17 May 2011 22:46:02 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id DB5A6E06B2 for ; Tue, 17 May 2011 22:46:01 -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 p4I5jwiR009920 for ; Tue, 17 May 2011 22:45:59 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305697560; bh=W1Ac4WRrflOfeDUvjv0cZ9Mkxtg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=fInUFv3nVixPX2uR0DpoMiZHjVNnD7I8v7hFBDh8TYz3SR5hfIH0VXCSB9HeJazQi RnCCeHXJJ8zZ37nhiOeAA==
Received: from ywf7 (ywf7.prod.google.com [10.192.6.7]) by wpaz17.hot.corp.google.com with ESMTP id p4I5jvKu027990 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 May 2011 22:45:57 -0700
Received: by ywf7 with SMTP id 7so684172ywf.27 for ; Tue, 17 May 2011 22:45:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2FbRpy8agVT6l3VK32JLpvaVK689TScFFojX9zrCzME=; b=GtvFalmxMWEbUPVaUzqd1v0BwutVVMGTrUM4crdl5QQA+VZIy9oq/GxA6YRP2i8ivp NH458888F55dNms9r5UA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=rqK2jJ2iQqpb0sulkYHsDPYpo1tP0fRbZfws4I93n2gq4AAkn2Aqu3VkfILC1odrY0 XoQ2Vicxh6lpL8o6lSlg==
Received: by 10.150.183.3 with SMTP id g3mr1074370ybf.264.1305697557078; Tue, 17 May 2011 22:45:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Tue, 17 May 2011 22:45:37 -0700 (PDT)
In-Reply-To: <20110518041256.720A3ED0FF9@drugs.dv.isc.org>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>   <20110518041256.720A3ED0FF9@drugs.dv.isc.org>
From: Lorenzo Colitti 
Date: Tue, 17 May 2011 22:45:37 -0700
Message-ID: 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=000e0cd6ecd812e4e704a3866732
X-System-Of-Record: true
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 05:46:02 -0000

--000e0cd6ecd812e4e704a3866732
Content-Type: text/plain; charset=ISO-8859-1

On Tue, May 17, 2011 at 9:12 PM, Mark Andrews  wrote:

> > Send a TTL=1 packet to one of those IPv6-only sites whose existence you
> cite
> > as a reason to keep 6to4 around, and see if you get an unreachable back.
> Or
> > send a TTL=1 DNS query to the root servers.
>
> Which is subject to ICMPv6 rate limiting.  i.e. it won't work if all the
> 6to4 sites using the relay do this.
>

So no worse than the return 6to4 relay, which could be subject to rate
limiting of all packets. Real story, real outage.

--000e0cd6ecd812e4e704a3866732
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, May 17, 2011 at 9:12 PM, Mark Andrews <marka@isc.org><=
/span> wrote:



> Send a TTL=3D1 packet to one of those IPv6-only site=
s whose existence you cite

> as a reason to keep 6to4 around, and see if you get an unreachable bac=
k. Or

> send a TTL=3D1 DNS query to the root servers.




Which is subject to ICMPv6 rate limiting. =A0i.e. it won't work i=
f all the

6to4 sites using the relay do this.

So =
no worse than the return 6to4 relay, which could be subject to rate limitin=
g of all packets. Real story, real outage.


--000e0cd6ecd812e4e704a3866732--

From ichiroumakino@gmail.com  Tue May 17 23: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 0A584E06E5 for ; Tue, 17 May 2011 23:00:16 -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 H44P+kz-qmsF for ; Tue, 17 May 2011 23:00:15 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27EBDE069D for ; Tue, 17 May 2011 23:00:15 -0700 (PDT)
Received: by ewy19 with SMTP id 19so473478ewy.31 for ; Tue, 17 May 2011 23:00:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=t8RpqJ+AbXCc1iXsu+AOei6nArfOAixql2fTiuZsxwM=; b=LgyjloZjFwtOSkji0bAOgm+q4//LPy+b78ANB6qhpezz+3AksjZCz9/LQi1GZvwDZK TB+P/PGdwMUp6Y23HAZdocu7ouSbcivTVCTV4raULjF+Bv+KVaXy0Yht/EV0iyrN50r6 yfM0d/xLAdphFsRc/bkDAKjHtzjsWFpaoWUuo=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=OyN+aeFE51vwfOANiYVVnKshv7/YzD01Sl29w5nizJQcr1VF2CEVT5zo2UNk0RKdWr ddCC/mzInd2BadN7WezIbo1XYXrjrrpe4sQ6z2tQZsCw8lG0BFGw0I1FDWKjmxJbJPrb hKc15vwF2SnALj3VjbynVvEXgnGepSOo6LheY=
Received: by 10.14.11.28 with SMTP id 28mr502192eew.86.1305698414211; Tue, 17 May 2011 23:00:14 -0700 (PDT)
Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id r12sm884979eeb.18.2011.05.17.23.00.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2011 23:00:13 -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: <20110518032842.4DAC5ED0D25@drugs.dv.isc.org>
Date: Wed, 18 May 2011 08:00:11 +0200
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <201105 18032842.4DAC5ED0D25@drugs.dv.isc.org>
To: Mark Andrews 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 06:00:16 -0000

Mark,

> Note 6rd will have these issues as well as it doesn't have well
> defined BR reachability detection.

section 8 of RFC5969.

Ole



From marka@isc.org  Tue May 17 23: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 E5551E06F2 for ; Tue, 17 May 2011 23:52:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.604
X-Spam-Level: 
X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 oimY+Ff9Uj+i for ; Tue, 17 May 2011 23:52:37 -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 35920E067C for ; Tue, 17 May 2011 23:52:37 -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 35D0E5F99AE; Wed, 18 May 2011 06:52:24 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 625B4216C1E; Wed, 18 May 2011 06:52:22 +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 78413ED391E; Wed, 18 May 2011 16:53:22 +1000 (EST)
To: Lorenzo Colitti 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>   <20110518041256.720A3ED0FF9@drugs.dv.isc.org> 
In-reply-to: Your message of "Tue, 17 May 2011 22:45:37 MST." 
Date: Wed, 18 May 2011 16:53:22 +1000
Message-Id: <20110518065322.78413ED391E@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 06:52:38 -0000

In message , Lorenzo Colitt
i writes:
> --000e0cd6ecd812e4e704a3866732
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Tue, May 17, 2011 at 9:12 PM, Mark Andrews  wrote:
> 
> > > Send a TTL=1 packet to one of those IPv6-only sites whose existence you
> > cite
> > > as a reason to keep 6to4 around, and see if you get an unreachable back.
> > Or
> > > send a TTL=1 DNS query to the root servers.
> >
> > Which is subject to ICMPv6 rate limiting.  i.e. it won't work if all the
> > 6to4 sites using the relay do this.
> 
> So no worse than the return 6to4 relay, which could be subject to rate
> limiting of all packets. Real story, real outage.

And how many relays rate limit encapsulation vs rate limit icmp?
1 vs almost all.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From marka@isc.org  Wed May 18 00:07: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 AAE55E07A8 for ; Wed, 18 May 2011 00:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.604
X-Spam-Level: 
X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 UqqE6TIzcLso for ; Wed, 18 May 2011 00:07:38 -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 F2DC7E06F5 for ; Wed, 18 May 2011 00:07:37 -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 BACFCC94CD; Wed, 18 May 2011 07:07:26 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 51B80216C31; Wed, 18 May 2011 07:07:26 +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 CDE38ED39F6; Wed, 18 May 2011 17:08:27 +1000 (EST)
To: Ole Troan 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <201105 18032842.4DAC5ED0D25@drugs.dv.isc.org> 
In-reply-to: Your message of "Wed, 18 May 2011 08:00:11 +0200." 
Date: Wed, 18 May 2011 17:08:27 +1000
Message-Id: <20110518070827.CDE38ED39F6@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 07:07:38 -0000

In message , Ole Troan writ
es:
> Mark,
> 
> > Note 6rd will have these issues as well as it doesn't have well
> > defined BR reachability detection.
> 
> section 8 of RFC5969.

And I tried the described technique with 6to4.  It runs into problems
with standard anti-spoofing filters.  The packet gets delivered,
de-encapsultated then dropped.  I don't expect 6rd to not have
anti-spoofing ingress filtering.

"Constructing a encapsulated packets from yourself(ipv6) to
yourself(ipv6) and sending them to the relay results in them to be
dropped by anti-spoof ingress filters which FreeBSD turns on by
default in the virtual interface driver (stf).  You can see them
if you use a packet filter but that really doesn't test that they
will make it past the host firewall which is one of the things
people are complaining about.  Adding exceptions also doesn't test
the general case.  I'm also slightly suprised that the relay accepted
encapsultate IPv6 packets to 2002::/16 as they should be able to
be delivered directly.  That being said it provides about the only
test path."

Mark

> Ole
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From lorenzo@google.com  Wed May 18 00: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 5D8C5E07CE for ; Wed, 18 May 2011 00:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 h0Jle0ffVI3d for ; Wed, 18 May 2011 00: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 C424DE06E5 for ; Wed, 18 May 2011 00:08:34 -0700 (PDT)
Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p4I78W3e025437 for ; Wed, 18 May 2011 00:08:32 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305702514; bh=6P7um8ttkgbmqCbUNmfPqnkgW4w=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dWYa8DdGDe26ZGHujVA+ZL0idQKQ9tO005p1Ui+yinAKZt0/XpkZISjBHCZLQcoAk ca7bV3NXzO5txr7sb5mUA==
Received: from gya6 (gya6.prod.google.com [10.243.49.6]) by kpbe18.cbf.corp.google.com with ESMTP id p4I78VYS007380 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 May 2011 00:08:31 -0700
Received: by gya6 with SMTP id 6so596118gya.21 for ; Wed, 18 May 2011 00:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Qr7JQ6q695hcpnWB+2JW/VGNuWb8b+T5LDlKRmIw0c4=; b=WQs24XIhS+akIXBG8wvcXuXR07p5KwCpHKJ+SZg0GiZfFpONiX7sqBV3Dxpsn1sq1O eONpW+YBTH4BnQU0tHBA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=fP83t1weZFg9OpMagfldqlBCtkVaLIHNSh/oQF13geoj2JONe/hRJnCpOLSX/2YgJ5 yKkzRPuugAVS4defRUGQ==
Received: by 10.150.195.18 with SMTP id s18mr1065134ybf.207.1305702511099; Wed, 18 May 2011 00:08:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Wed, 18 May 2011 00:08:11 -0700 (PDT)
In-Reply-To: <20110518065322.78413ED391E@drugs.dv.isc.org>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <20110518041256.720A3ED0FF9@drugs.dv.isc.org>  <20110518065322.78413ED391E@drugs.dv.isc.org>
From: Lorenzo Colitti 
Date: Wed, 18 May 2011 00:08:11 -0700
Message-ID: 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=000e0cd4d83c5b3eab04a3878e02
X-System-Of-Record: true
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 07:08:35 -0000

--000e0cd4d83c5b3eab04a3878e02
Content-Type: text/plain; charset=ISO-8859-1

On Tue, May 17, 2011 at 11:53 PM, Mark Andrews  wrote:

> > So no worse than the return 6to4 relay, which could be subject to rate
> > limiting of all packets. Real story, real outage.
>
> And how many relays rate limit encapsulation vs rate limit icmp?
> 1 vs almost all.


I see no data on either side of that assertion.

--000e0cd4d83c5b3eab04a3878e02
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, May 17, 2011 at 11:53 PM, Mark Andrews <=
span dir=3D"ltr"><marka@isc.org>=
 wrote:



> So no worse than the return 6to4 relay, which c=
ould be subject to rate

> limiting of all packets. Real story, real outage.




And how many relays rate limit encapsulation vs rate limit icmp=
?

1 vs almost all.

I see no data on either si=
de of that assertion.


--000e0cd4d83c5b3eab04a3878e02--

From pekkas@netcore.fi  Wed May 18 00:39: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 B90FCE0694 for ; Wed, 18 May 2011 00:39:42 -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 pSpXzJPRPzQH for ; Wed, 18 May 2011 00:39:42 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id 881E1E06C0 for ; Wed, 18 May 2011 00:39:41 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p4I7dNxR016553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 May 2011 10:39:23 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p4I7dLR7016550; Wed, 18 May 2011 10:39:21 +0300
Date: Wed, 18 May 2011 10:39:21 +0300 (EEST)
From: Pekka Savola 
To: Mark Andrews 
In-Reply-To: <20110518065322.78413ED391E@drugs.dv.isc.org>
Message-ID: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>   <20110518041256.720A3ED0FF9@drugs.dv.isc.org>  <20110518065322.78413ED391E@drugs.dv.isc.org>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi
X-Virus-Status: Clean
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 07:39:42 -0000

On Wed, 18 May 2011, Mark Andrews wrote:
>>>> Send a TTL=1 packet to one of those IPv6-only sites whose existence you
>>> cite
>>>> as a reason to keep 6to4 around, and see if you get an unreachable back.
>>> Or
>>>> send a TTL=1 DNS query to the root servers.
>>>
>>> Which is subject to ICMPv6 rate limiting.  i.e. it won't work if all the
>>> 6to4 sites using the relay do this.
>>
>> So no worse than the return 6to4 relay, which could be subject to rate
>> limiting of all packets. Real story, real outage.
>
> And how many relays rate limit encapsulation vs rate limit icmp?
> 1 vs almost all.

The fact that if you run a 6to4 relay, you may need to increase ICMPv6 
rate limits is well known.  On some systems, this is by default 
100pps.  On some others, it is by default 1000pps.  1000pps is the 
minimum that works.  When running a public relay, I think I used 
5000pps myself.

Dozens of millions Windows boxes have been sending ICMPv6 Echo 
Requests with Hop Count=1 for 5+ years.  This creates a lot of traffic 
on the relays.  This is already an established procedure.

All in all, this works just fine.

(FWIW, Windows implementations are supposed to send only one probe per 
24 hours and additional ones when you change network settings. There 
have been observations of more frequent probes.  But the amount is 
still manageable.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From marka@isc.org  Wed May 18 01:28: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 D0194E07D7 for ; Wed, 18 May 2011 01:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.604
X-Spam-Level: 
X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 vCMpPDprJAoU for ; Wed, 18 May 2011 01:28:42 -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 85D97E07DB for ; Wed, 18 May 2011 01:28:42 -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 572845F9920; Wed, 18 May 2011 08:28:27 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (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 7F0A5216C31; Wed, 18 May 2011 08:28:25 +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 30F5AED41C9; Wed, 18 May 2011 18:29:25 +1000 (EST)
To: Pekka Savola 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>   <20110518041256.720A3ED0FF9@drugs.dv.isc.org>  <20110518065322.78413ED391E@drugs.dv.isc.org> 
In-reply-to: Your message of "Wed, 18 May 2011 10:39:21 +0300." 
Date: Wed, 18 May 2011 18:29:25 +1000
Message-Id: <20110518082925.30F5AED41C9@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 08:28:43 -0000

In message , Pekka Savola write
s:
> On Wed, 18 May 2011, Mark Andrews wrote:
> >>>> Send a TTL=1 packet to one of those IPv6-only sites whose existence you
> >>> cite
> >>>> as a reason to keep 6to4 around, and see if you get an unreachable back.
> >>> Or
> >>>> send a TTL=1 DNS query to the root servers.
> >>>
> >>> Which is subject to ICMPv6 rate limiting.  i.e. it won't work if all the
> >>> 6to4 sites using the relay do this.
> >>
> >> So no worse than the return 6to4 relay, which could be subject to rate
> >> limiting of all packets. Real story, real outage.
> >
> > And how many relays rate limit encapsulation vs rate limit icmp?
> > 1 vs almost all.
> 
> The fact that if you run a 6to4 relay, you may need to increase ICMPv6 
> rate limits is well known.  On some systems, this is by default 
> 100pps.  On some others, it is by default 1000pps.  1000pps is the 
> minimum that works.  When running a public relay, I think I used 
> 5000pps myself.
> 
> Dozens of millions Windows boxes have been sending ICMPv6 Echo 
> Requests with Hop Count=1 for 5+ years.  This creates a lot of traffic 
> on the relays.  This is already an established procedure.

And this is documented where? 

http://go6.net/ipv6-6bone/v6ops/minutes/IETF-59-Seoul/6to4-stats.pdf
Mentions it in "Weird Things Seen on the Wire".

> All in all, this works just fine.
> 
> (FWIW, Windows implementations are supposed to send only one probe per 
> 24 hours and additional ones when you change network settings. There 
> have been observations of more frequent probes.  But the amount is 
> still manageable.)
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From ichiroumakino@gmail.com  Wed May 18 02:50: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 30A0CE07A8 for ; Wed, 18 May 2011 02:50:18 -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 Cjc8WQ86Rjuk for ; Wed, 18 May 2011 02:50:17 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75C80E07EF for ; Wed, 18 May 2011 02:50:17 -0700 (PDT)
Received: by eye13 with SMTP id 13so543161eye.31 for ; Wed, 18 May 2011 02:50:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=iYzJpWaBvHDuHHCoxGXOHcmhSYlMJclJJUrbLxfMJLI=; b=rQATHn2aRRpJh9OGhg/sXjW64B7+VYLLMfxgHy/JUyOpW/SUjYmEvL7aSga9kVIETT xWNLsfcYq92QGUZ5OdWQpkD9Cacoy3kG5U946yne+sljDrvF0/M48bgioBhT4A16KeHw BraBEKhhuBHCD5rkDD6He7BYhuTlYogn34PtA=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=nFWWP3fUAWMDz5kSCZe6lcMNTD3/m9uJvhWBng6laH/45QY6aXPfX00lGIu1Q98yRS oM1h4kjhmYtDRsKx0NVtTfqSRjlwxMH8AT8u594JSu9ATeH4+Md7bnCuK5VboTrv/+pz cm9MMnIS76exolgL/A3jzFrsfUKImm/qpMRS8=
Received: by 10.14.4.35 with SMTP id 35mr601842eei.100.1305712216334; Wed, 18 May 2011 02:50:16 -0700 (PDT)
Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id y3sm1023083eeh.23.2011.05.18.02.50.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 02:50:15 -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: <20110518070827.CDE38ED39F6@drugs.dv.isc.org>
Date: Wed, 18 May 2011 11:50:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <73CD3A11-9C25-4718-9C2B-CB84657BF8CE@employees.org>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <201105 18032842.4DAC5ED0D25@drugs.dv.isc.org>  <20110518070827.CDE38ED39F6@drugs.dv.isc.org>
To: Mark Andrews 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 09:50:18 -0000

Mark,

>>> Note 6rd will have these issues as well as it doesn't have well
>>> defined BR reachability detection.
>>=20
>> section 8 of RFC5969.
>=20
> And I tried the described technique with 6to4.  It runs into problems
> with standard anti-spoofing filters.  The packet gets delivered,
> de-encapsultated then dropped.  I don't expect 6rd to not have
> anti-spoofing ingress filtering.

section 9.2, RFC5969

we are going off topic now. you stated that "6rd will have these issues =
as well...".
I claim that it will not, as connectivity tests are described in the =
protocol specification.

cheers,
Ole=

From pekkas@netcore.fi  Wed May 18 03:25: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 DC862E066C for ; Wed, 18 May 2011 03:25:45 -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 cUCQqC7U7sbu for ; Wed, 18 May 2011 03:25:45 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8558E065D for ; Wed, 18 May 2011 03:25:44 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p4IAPWZ9020048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 May 2011 13:25:32 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p4IAPTCJ020045; Wed, 18 May 2011 13:25:29 +0300
Date: Wed, 18 May 2011 13:25:29 +0300 (EEST)
From: Pekka Savola 
To: Mark Andrews 
In-Reply-To: <20110518082925.30F5AED41C9@drugs.dv.isc.org>
Message-ID: 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>   <20110518041256.720A3ED0FF9@drugs.dv.isc.org>  <20110518065322.78413ED391E@drugs.dv.isc.org>  <20110518082925.30F5AED41C9@drugs.dv.isc.org>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi
X-Virus-Status: Clean
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 10:25:46 -0000

On Wed, 18 May 2011, Mark Andrews wrote:
>> The fact that if you run a 6to4 relay, you may need to increase ICMPv6
>> rate limits is well known.  On some systems, this is by default
>> 100pps.  On some others, it is by default 1000pps.  1000pps is the
>> minimum that works.  When running a public relay, I think I used
>> 5000pps myself.
>>
>> Dozens of millions Windows boxes have been sending ICMPv6 Echo
>> Requests with Hop Count=1 for 5+ years.  This creates a lot of traffic
>> on the relays.  This is already an established procedure.
>
> And this is documented where?
>
> http://go6.net/ipv6-6bone/v6ops/minutes/IETF-59-Seoul/6to4-stats.pdf
> Mentions it in "Weird Things Seen on the Wire".

Which part? The procedure is described in my "Observations of IPv6 
Traffic on a 6to4 Relay" paper that can be found easily from Google. 
AFAIK, there no official description of this from Microsoft.

ICMP rate-limiting issues have been discussed e.g. here:

http://lists.cluenet.de/pipermail/ipv6-ops/2008-February/001708.html
http://www.gossamer-threads.com/lists/nanog/users/129609
draft-ietf-v6ops-6to4-advisory-01 Section 4.4 point 6

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From marka@isc.org  Wed May 18 04:11: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 B70A4E070F for ; Wed, 18 May 2011 04:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.812
X-Spam-Level: 
X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=-0.212, 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 Sr7mKGEMPtoH for ; Wed, 18 May 2011 04:11:44 -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 C375FE06A8 for ; Wed, 18 May 2011 04:11:42 -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 EBE305F99BE; Wed, 18 May 2011 11:11:23 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 C1F83216C44; Wed, 18 May 2011 11:11:21 +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 3B5C3ED4722; Wed, 18 May 2011 21:12:23 +1000 (EST)
To: Ole Troan 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <201105 18032842.4DAC5ED0D25@drugs.dv.isc.org>  <20110518070827.CDE38ED39F6@drugs.dv.isc.org> <73CD3A11-9C25-4718-9C2B-CB84657BF8CE@employees.org>
In-reply-to: Your message of "Wed, 18 May 2011 11:50:13 +0200." <73CD3A11-9C25-4718-9C2B-CB84657BF8CE@employees.org>
Date: Wed, 18 May 2011 21:12:23 +1000
Message-Id: <20110518111223.3B5C3ED4722@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 11:11:44 -0000

In message <73CD3A11-9C25-4718-9C2B-CB84657BF8CE@employees.org>, Ole Troan writ
es:
> Mark,
> 
> >>> Note 6rd will have these issues as well as it doesn't have well
> >>> defined BR reachability detection.
> >>=20
> >> section 8 of RFC5969.
> >=20
> > And I tried the described technique with 6to4.  It runs into problems
> > with standard anti-spoofing filters.  The packet gets delivered,
> > de-encapsultated then dropped.  I don't expect 6rd to not have
> > anti-spoofing ingress filtering.
> 
> section 9.2, RFC5969
> 
> we are going off topic now. you stated that "6rd will have these issues =
> as well...".
> I claim that it will not, as connectivity tests are described in the =
> protocol specification.
> 
> cheers,
> Ole=

Machines other than the BR in the 6rd domain can't spoof as the
ipv4/ipv6 source address must match.  The BR however can be a source
of spoofed traffic as there are no restrictions placed on the ipv6
source addresses recieved from the BR.  Any sane implemation wouldn't
be depending in the ISP having done ingress filtering and would do
its own ingress filtering.

Mark

9.2.  Receiving Rules

   In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE
   MUST validate the embedded IPv4 source address of the encapsulated
   IPv6 packet with the IPv4 source address it is encapsulated by
   according to the configured parameters of the 6rd domain.  If the two
   source addresses do not match, the packet MUST be dropped and a
   counter incremented to indicate that a potential spoofing attack may
   be underway.  Additionally, a CE MUST allow forwarding of packets
   sourced by the configured BR IPv4 address.

   By default, the CE router MUST drop packets received on the 6rd
   virtual interface (i.e., after decapsulation of IPv4) for IPv6
   destinations not within its own 6rd delegated prefix.



-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From ichiroumakino@gmail.com  Wed May 18 04:58: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 5306DE0670 for ; Wed, 18 May 2011 04:58:18 -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 p3BGUXAQuc4v for ; Wed, 18 May 2011 04:58: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 8490EE0657 for ; Wed, 18 May 2011 04:58:17 -0700 (PDT)
Received: by wwa36 with SMTP id 36so1109709wwa.13 for ; Wed, 18 May 2011 04:58:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=mcggGMhqm4OM/lnC1/soQYMCnKGYWt6NLiuZBL2vOQI=; b=Ex8vAASjokExXT1ZGFiWlg/z5sJwuzMsfdZnE3PB798DnS9O9vH+LhNBdYwOd68f0f Wutv6bVh56MnFkLPTgRQCFkN9sw2eSrj0B2jkerZZFNJyihel3ChypnO6yiBoS2dR/m6 BGI8aRma1js3EY0j+KB5+2l3FJw40Wx7amoyA=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=kWXKnxrYLHqHArFye/XAtnk/o/q0ac6O3tBHV8wSWp5rfp3wtFp4ugBFh9S9tjaZIv uNiPj2eFCGD7Qv4qh2SpWfFeT9OwUec+DF5tLqP/E/aNwU2suGhRw1TkytIcteWH9Sqo 57sdqwq+A3nYTp7Vm/4BdvWRiIn8X3HNGkk6c=
Received: by 10.227.165.69 with SMTP id h5mr1741353wby.78.1305719896233; Wed, 18 May 2011 04:58:16 -0700 (PDT)
Received: from dhcp-10-55-93-60.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id s20sm932436wbh.6.2011.05.18.04.58.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 04:58:15 -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: <20110518111223.3B5C3ED4722@drugs.dv.isc.org>
Date: Wed, 18 May 2011 13:58:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F96309D-3BE4-4603-A56D-BE4FDC7E96D2@employees.org>
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <201105 18032842.4DAC5ED0D25@drugs.dv.isc.org>  <20110518070827.CDE38ED39F6@drugs.dv.isc.org> <73CD3A11-9C25-4718-9C2B-CB84657BF8CE@employees.org> <20110518111223.3B5C3ED4722@drugs.dv.isc.org>
To: Mark Andrews 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 11:58:18 -0000

Mark,

[...]

> Machines other than the BR in the 6rd domain can't spoof as the
> ipv4/ipv6 source address must match.  The BR however can be a source
> of spoofed traffic as there are no restrictions placed on the ipv6
> source addresses recieved from the BR.  Any sane implemation wouldn't
> be depending in the ISP having done ingress filtering and would do
> its own ingress filtering.

I don't get your point. there is no source address spoofing in the =
mechanism described in rfc5969.

cheers,
Ole


From marka@isc.org  Wed May 18 06:50: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 BB826E071F for ; Wed, 18 May 2011 06:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.769
X-Spam-Level: 
X-Spam-Status: No, score=-2.769 tagged_above=-999 required=5 tests=[AWL=-0.170, 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 vUzr4PnkppTI for ; Wed, 18 May 2011 06:50:54 -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 1A4E9E071A for ; Wed, 18 May 2011 06:50:53 -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 19E5E5F9976; Wed, 18 May 2011 13:50:33 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 02307216C1E; Wed, 18 May 2011 13:50:32 +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 2228EED558A; Wed, 18 May 2011 23:51:35 +1000 (EST)
To: Ole Troan 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <201105 18032842.4DAC5ED0D25@drugs.dv.isc.org>  <20110518070827.CDE38ED39F6@drugs.dv.isc.org> <73CD3A11-9C25-4718-9C2B-CB84657BF8CE@employees.org> <20110518111223.3B5C3ED4722@drugs.dv.isc.org> <1F96309D-3BE4-4603-A56D-BE4FDC7E96D2@employees.org>
In-reply-to: Your message of "Wed, 18 May 2011 13:58:11 +0200." <1F96309D-3BE4-4603-A56D-BE4FDC7E96D2@employees.org>
Date: Wed, 18 May 2011 23:51:35 +1000
Message-Id: <20110518135135.2228EED558A@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 13:50:54 -0000

In message <1F96309D-3BE4-4603-A56D-BE4FDC7E96D2@employees.org>, Ole Troan writ
es:
> Mark,
> 
> [...]
> 
> > Machines other than the BR in the 6rd domain can't spoof as the
> > ipv4/ipv6 source address must match.  The BR however can be a source
> > of spoofed traffic as there are no restrictions placed on the ipv6
> > source addresses recieved from the BR.  Any sane implemation wouldn't
> > be depending in the ISP having done ingress filtering and would do
> > its own ingress filtering.
> 
> I don't get your point. there is no source address spoofing in the =
> mechanism described in rfc5969.
> 
> cheers,
> Ole

There is nothing in RFC5969 to prevent someone outside of the 6rd
domain spoofing machines inside the 6rd domain.

You send a packet from <6rd-prefix> to
<6rd-prefix>.  The ISP may or may not be
filtering this.  The BR isn't required to filter it.  The CE is not
instructed to filter it.


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From pch-b2B3A6689@u-1.phicoh.com  Wed May 18 07:19: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 13C40E067F for ; Wed, 18 May 2011 07:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 vd5RXi08r7C9 for ; Wed, 18 May 2011 07:19:55 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id C241BE0688 for ; Wed, 18 May 2011 07:19:53 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QMhbE-0001gNC; Wed, 18 May 2011 16:19:44 +0200
Message-Id: 
To: Mark Andrews 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <201105 18032842.4DAC5ED0D25@drugs.dv.isc.org>  <20110518070827.CDE38ED39F6@drugs.dv.isc.org> <73CD3A11-9C25-4718-9C2B-CB84657BF8CE@employees.org> <20110518111223.3B5C3ED4722@drugs.dv.isc.org> <1F96309D-3BE4-4603-A56D-BE4FDC7E96D2@employees.org> <20110518135135.2228EED558A@drugs.dv.isc.org> 
In-reply-to: Your message of "Wed, 18 May 2011 23:51:35 +1000 ." <20110518135135.2228EED558A@drugs.dv.isc.org> 
Date: Wed, 18 May 2011 16:19:22 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 14:19:56 -0000

In your letter dated Wed, 18 May 2011 23:51:35 +1000 you wrote:
>There is nothing in RFC5969 to prevent someone outside of the 6rd
>domain spoofing machines inside the 6rd domain.
>
>You send a packet from <6rd-prefix> to
><6rd-prefix>.  The ISP may or may not be
>filtering this.  The BR isn't required to filter it.  The CE is not
>instructed to filter it.

I guess everybody knows that is not smart to rely on IP addresses for
authentication. But apart from that, it makes sense for the CE to filter out
its own prefix (just like you would do for native). It also makes sense for
an ISP to deploy ingress filtering everywhere (including traffic handled
by the 6rd relay). Otherwise, customers can make a mess of your network.



From marka@isc.org  Wed May 18 07:25: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 0ACEFE067F for ; Wed, 18 May 2011 07:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.741
X-Spam-Level: 
X-Spam-Status: No, score=-3.741 tagged_above=-999 required=5 tests=[AWL=0.858,  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 4KzqW+RaYQ7X for ; Wed, 18 May 2011 07:25:35 -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 D152BE0669 for ; Wed, 18 May 2011 07:25:34 -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 741C05F99CD; Wed, 18 May 2011 14:25:14 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 80E68216C31; Wed, 18 May 2011 14:25: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 564E6ED5CD2; Thu, 19 May 2011 00:26:16 +1000 (EST)
To: Philip Homburg 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <201105 18032842.4DAC5ED0D25@drugs.dv.isc.org>  <20110518070827.CDE38ED39F6@drugs.dv.isc.org> <73CD3A11-9C25-4718-9C2B-CB84657BF8CE@employees.org> <20110518111223.3B5C3ED4722@drugs.dv.isc.org> <1F96309D-3BE4-4603-A56D-BE4FDC7E96D2@employees.org> <20110518135135.2228EED558A@drugs.dv.isc.org> 
In-reply-to: Your message of "Wed, 18 May 2011 16:19:22 +0200." 
Date: Thu, 19 May 2011 00:26:16 +1000
Message-Id: <20110518142616.564E6ED5CD2@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 14:25:36 -0000

In message , Philip Homburg writes:
> In your letter dated Wed, 18 May 2011 23:51:35 +1000 you wrote:
> >There is nothing in RFC5969 to prevent someone outside of the 6rd
> >domain spoofing machines inside the 6rd domain.
> >
> >You send a packet from <6rd-prefix> to
> ><6rd-prefix>.  The ISP may or may not be
> >filtering this.  The BR isn't required to filter it.  The CE is not
> >instructed to filter it.
> 
> I guess everybody knows that is not smart to rely on IP addresses for
> authentication. But apart from that, it makes sense for the CE to filter out
> its own prefix (just like you would do for native). It also makes sense for
> an ISP to deploy ingress filtering everywhere (including traffic handled
> by the 6rd relay). Otherwise, customers can make a mess of your network.

Indeed.  The problem is that when you do that sort of filtering you
also block the test traffic to determine if the BR is running.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From pch-b2B3A6689@u-1.phicoh.com  Wed May 18 07:36: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 AF05EE0703 for ; Wed, 18 May 2011 07:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 8x9yD3OEgzza for ; Wed, 18 May 2011 07:36:25 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id C439EE0669 for ; Wed, 18 May 2011 07:36:23 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QMhrF-0001hIC; Wed, 18 May 2011 16:36:17 +0200
Message-Id: 
To: Mark Andrews 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <201105 18032842.4DAC5ED0D25@drugs.dv.isc.org>  <20110518070827.CDE38ED39F6@drugs.dv.isc.org> <73CD3A11-9C25-4718-9C2B-CB84657BF8CE@employees.org> <20110518111223.3B5C3ED4722@drugs.dv.isc.org> <1F96309D-3BE4-4603-A56D-BE4FDC7E96D2@employees.org> <20110518135135.2228EED558A@drugs.dv.isc.org>  <20110518142616.564E6ED5CD2@drugs.dv.isc.org> 
In-reply-to: Your message of "Thu, 19 May 2011 00:26:16 +1000 ." <20110518142616.564E6ED5CD2@drugs.dv.isc.org> 
Date: Wed, 18 May 2011 16:36:16 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 14:36:26 -0000

In your letter dated Thu, 19 May 2011 00:26:16 +1000 you wrote:
>In message , Philip Homburg writes:
>> In your letter dated Wed, 18 May 2011 23:51:35 +1000 you wrote:
>> >There is nothing in RFC5969 to prevent someone outside of the 6rd
>> >domain spoofing machines inside the 6rd domain.
>> >
>> >You send a packet from <6rd-prefix> to
>> ><6rd-prefix>.  The ISP may or may not be
>> >filtering this.  The BR isn't required to filter it.  The CE is not
>> >instructed to filter it.
>> 
>> I guess everybody knows that is not smart to rely on IP addresses for
>> authentication. But apart from that, it makes sense for the CE to filter out
>> its own prefix (just like you would do for native). It also makes sense for
>> an ISP to deploy ingress filtering everywhere (including traffic handled
>> by the 6rd relay). Otherwise, customers can make a mess of your network.
>
>Indeed.  The problem is that when you do that sort of filtering you
>also block the test traffic to determine if the BR is running.

I don't see any problem for the BR: it receives a packet from the IPv4 address
assigned to the CE and the IPv6 packet also has a source address in the
customer's prefix.

It is true that for the CE, you have to capture the packet from BR before
ingress filtering rules drop it. But that is something you already see in
the lab when you first turn the device on. Doesn't strike me as a big problem.



From marka@isc.org  Wed May 18 08:14: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 C1947E06B8 for ; Wed, 18 May 2011 08:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.863
X-Spam-Level: 
X-Spam-Status: No, score=-3.863 tagged_above=-999 required=5 tests=[AWL=0.736,  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 aHD5HShztBJL for ; Wed, 18 May 2011 08:14:07 -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 D74F7E06FB for ; Wed, 18 May 2011 08:14: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 394E15F99DB; Wed, 18 May 2011 15:13:27 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (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 BD253216C40; Wed, 18 May 2011 15:13:24 +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 8EA8AED6315; Thu, 19 May 2011 01:14:28 +1000 (EST)
To: Philip Homburg 
From: Mark Andrews 
References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org>  <4DC8D717.3080402@redpill-linpro.com> <20110510064904.B5081E9E11B@drugs.dv.isc.org> <4DCA5121.9010809@redpill-linpro.com> <20110511121453.D438CEAA1A5@drugs.dv.isc.org> <0F0C1186-50F6-4305-92E0-B833C0520127@employees.org> <20110511144736.77E3AEAAEDA@drugs.dv.isc.org> <4DCAC64C.7030607@redpill-linpro.com> <20110511232129.A5DFDEAD470@drugs.dv.isc.org> <4DCB7609.3020802@redpill-linpro.com> <20110512073353.EB4CCEB0BC6@drugs.dv.isc.org> <4DCBC1F1.7030600@redpill-linpro.com>  <20110515231723.5DEB8EBE245@drugs.dv.isc.org>  <20110516062459.94D4CEC26F2@drugs.dv.isc.org>  <20110517005448.B45C3EC43F8@drugs.dv.isc.org>  <20110517133006.C5D3FECC630@drugs.dv.isc.org>  <201105 18032842.4DAC5ED0D25@drugs.dv.isc.org>  <20110518070827.CDE38ED39F6@drugs.dv.isc.org> <73CD3A11-9C25-4718-9C2B-CB84657BF8CE@employees.org> <20110518111223.3B5C3ED4722@drugs.dv.isc.org> <1F96309D-3BE4-4603-A56D-BE4FDC7E96D2@employees.org> <20110518135135.2228EED558A@drugs.dv.isc.org>  <20110518142616.564E6ED5CD2@drugs.dv.isc.org> 
In-reply-to: Your message of "Wed, 18 May 2011 16:36:16 +0200." 
Date: Thu, 19 May 2011 01:14:28 +1000
Message-Id: <20110518151428.8EA8AED6315@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6to4 connectivity test procedures
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 15:14:07 -0000

In message , Philip Homburg writes:
> In your letter dated Thu, 19 May 2011 00:26:16 +1000 you wrote:
> >In message , Philip Homburg writes:
> >> In your letter dated Wed, 18 May 2011 23:51:35 +1000 you wrote:
> >> >There is nothing in RFC5969 to prevent someone outside of the 6rd
> >> >domain spoofing machines inside the 6rd domain.
> >> >
> >> >You send a packet from <6rd-prefix> to
> >> ><6rd-prefix>.  The ISP may or may not be
> >> >filtering this.  The BR isn't required to filter it.  The CE is not
> >> >instructed to filter it.
> >> 
> >> I guess everybody knows that is not smart to rely on IP addresses for
> >> authentication. But apart from that, it makes sense for the CE to filter o
> ut
> >> its own prefix (just like you would do for native). It also makes sense fo
> r
> >> an ISP to deploy ingress filtering everywhere (including traffic handled
> >> by the 6rd relay). Otherwise, customers can make a mess of your network.
> >
> >Indeed.  The problem is that when you do that sort of filtering you
> >also block the test traffic to determine if the BR is running.
> 
> I don't see any problem for the BR: it receives a packet from the IPv4 addres
> s
> assigned to the CE and the IPv6 packet also has a source address in the
> customer's prefix.
> 
> It is true that for the CE, you have to capture the packet from BR before
> ingress filtering rules drop it. But that is something you already see in
> the lab when you first turn the device on. Doesn't strike me as a big problem
> .

Then you havn't understood part of the firewall issues with 6to4
are equally applicable to 6rd and that adding exceptions for BR
tests doesn't help.  It's quite easy to not allow anything except
the BR tests through be accident when you start adding exections.

Mark
-- 
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 May 18 15:54: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 D6EF4E07F3 for ; Wed, 18 May 2011 15:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.111
X-Spam-Level: 
X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=-0.112, 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 3imSBD8+8cwH for ; Wed, 18 May 2011 15:54:08 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC8C0E0784 for ; Wed, 18 May 2011 15:54:07 -0700 (PDT)
Received: by ewy19 with SMTP id 19so817660ewy.31 for ; Wed, 18 May 2011 15:54:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uPsTIsk0TzcZ4P+q7RhKCfTpQVP5m3/PwlzN87fpqdQ=; b=aa9U+rq2ccq2ytRT1vliMGwdd3PYlXFYC/is2Usvc6nimWKmRqZyoAhNpakWP7zU7H N3ILRQmkhZzfHc4SgYGy7SUeHGki9TlEmXi3CvwrdzMZmFMjcU8HdiCrTJ74xzT1T1n+ P0P+NyUV1fxYw3q+ZWVQc6tbd+1MNLI/lVew8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YjJTMtfCaMRH5oJFmv+NBcEUuMMlaffES1bGCkEb8eIDC/KrTtCoF0iaPtkgdKY+VD OchIbMhVM2YbLzv9nZuEdcfXSz9mtFhTwgILe50pdlURZG1PgY1e/VtSjk3CCn6O8JHY lClxVvPwIaNdRFlaVhxaIE0G8Pg7PzDgO/C58=
MIME-Version: 1.0
Received: by 10.14.52.65 with SMTP id d41mr909854eec.85.1305759245779; Wed, 18 May 2011 15:54:05 -0700 (PDT)
Received: by 10.14.47.67 with HTTP; Wed, 18 May 2011 15:54:05 -0700 (PDT)
In-Reply-To: <993AD341-6B37-4A86-B15F-918DB8CC5117@cisco.com>
References: <993AD341-6B37-4A86-B15F-918DB8CC5117@cisco.com>
Date: Wed, 18 May 2011 15:54:05 -0700
Message-ID: 
From: Cameron Byrne 
To: Fred Baker 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica 
Subject: Re: [v6ops] draft-ietf-v6ops-3gpp-eps WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 May 2011 22:54:08 -0000

This draft is important and should be published

minor suggestions:

"With the impending exhaustion of available IPv4 addresses
   from the registries there is an increased emphasis for operators to
   migrate to IPv6."

Change "impending" to "on going".  APNIC is already exhausted.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

"However, the support for IPv6
   in commercially deployed networks by the end of 2010 is nearly non-
   existent."

Verizon Wireless commercially supports IPv6 and i remain hopeful that
other LTE offerings will be IPv6 enabled as well.

Perhaps "...the support for IPv6
   in commercially deployed networks remains low"

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


"In addition to operating dual-
   stack networks during the transition from IPv4 to IPv6 phase, the two
   alternative categories for the transition are encapsulation and
   translation.  Most of the mechanisms available in the toolbox can be
   categorized into either translation or encapsulation approaches."

This last sentence is repetitive and  should be removed or revised.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

"Standard NAT44 functionality
       enables the communication between hosts that are assigned the
       same IPv4 address but belong to different zones, yet are part of
       the same operator domain."

I don't believe "standard NAT44" will do this.  If i am behind a NAT44
and want to make a SIP call to someone else behind NAT44 ... i will
need a B2BUE to proxy signalling and media.  You may want to revise
this to simply say that "NAT44 allows for communication from the
RFC1918 private address space to the Internet".

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Thanks,
Cameron


On Sun, May 15, 2011 at 6:04 AM, Fred Baker  wrote:
> This is to initiate a two week working group last call of
> draft-ietf-v6ops-3gpp-eps. Please read it now. If you find nits (spelling
> errors, minor suggested wording changes, etc),=A0comment to the authors; =
if
> you find greater issues, such as disagreeing with a statement or finding
> additional issues that need to be addressed, please post your comments to
> the=A0list.
> We are looking specifically for comments on the importance of the documen=
t
> as well as its content. If you have read the document and believe it to b=
e
> of operational utility, that is=A0also an important comment to make.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

From jouni.nospam@gmail.com  Thu May 19 02:28: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 EF91EE0780 for ; Thu, 19 May 2011 02:28:05 -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 kO6rCWW1Gxov for ; Thu, 19 May 2011 02:28:05 -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 F1AF9E0727 for ; Thu, 19 May 2011 02:28:04 -0700 (PDT)
Received: by yic13 with SMTP id 13so1023140yic.31 for ; Thu, 19 May 2011 02:28:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=IfyjOpFzO4yzTrv5zbLSIisSV9PxlsjncZwnf9VeEZ0=; b=Ll244s3TUE/A3pGClU1G+IpWgmytLw/HsYjw+USXSIxQZnzuDlQ35leESYEsLlcmlS s+L0q/oxj9eKRb5IvQ7aa7zsv2K+7pbbaD6R2HCEdMht2zwM+ogXOyFFBiT5J/rHkUM9 3DEoDxbFSbrZHoXdFrhQLdmupxP67DY3HUkco=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=TbxWmSkNafnV+z280kLMAkZc6HhGaowoiCVDCvYidumV/9JqDTIZatWuqXr/TyzFSX FAoluG8cIEIoOLtMiT+wIMKzNxeamgg+IYyDxEkWNXuj9OJ5H4lqekPaAI4SHt2rXtYX D0YjhNsZYSzVvrmDcuPjpiJhC6iRqF2n/6/Cw=
Received: by 10.236.109.18 with SMTP id r18mr3134151yhg.189.1305797284079; Thu, 19 May 2011 02:28:04 -0700 (PDT)
Received: from [10.255.142.39] ([192.100.123.77]) by mx.google.com with ESMTPS id q45sm1071027yhm.9.2011.05.19.02.28.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2011 02:28:03 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: 
Date: Thu, 19 May 2011 12:27:55 +0300
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <993AD341-6B37-4A86-B15F-918DB8CC5117@cisco.com> 
To: Cameron Byrne 
X-Mailer: Apple Mail (2.1082)
Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica 
Subject: Re: [v6ops] draft-ietf-v6ops-3gpp-eps WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 19 May 2011 09:28:06 -0000

Hi Cameron,

Thanks for the review. Appreciated. See my responses inline.


On May 19, 2011, at 1:54 AM, Cameron Byrne wrote:

> This draft is important and should be published
> 
> minor suggestions:
> 
> "With the impending exhaustion of available IPv4 addresses
>   from the registries there is an increased emphasis for operators to
>   migrate to IPv6."
> 
> Change "impending" to "on going".  APNIC is already exhausted.

Ack. Will change.

> 
> ================
> 
> "However, the support for IPv6
>   in commercially deployed networks by the end of 2010 is nearly non-
>   existent."
> 
> Verizon Wireless commercially supports IPv6 and i remain hopeful that
> other LTE offerings will be IPv6 enabled as well.
> 
> Perhaps "...the support for IPv6
>   in commercially deployed networks remains low"

Ack. Will change.

> 
> ============
> 
> 
> "In addition to operating dual-
>   stack networks during the transition from IPv4 to IPv6 phase, the two
>   alternative categories for the transition are encapsulation and
>   translation.  Most of the mechanisms available in the toolbox can be
>   categorized into either translation or encapsulation approaches."
> 
> This last sentence is repetitive and  should be removed or revised.

Ok to remove the last sentence.


> 
> ===============
> 
> "Standard NAT44 functionality
>       enables the communication between hosts that are assigned the
>       same IPv4 address but belong to different zones, yet are part of
>       the same operator domain."
> 
> I don't believe "standard NAT44" will do this.  If i am behind a NAT44
> and want to make a SIP call to someone else behind NAT44 ... i will
> need a B2BUE to proxy signalling and media.  You may want to revise
> this to simply say that "NAT44 allows for communication from the
> RFC1918 private address space to the Internet".

Right. How about:

   1.  Very large network deployments are partitioned, for example,
       based on a geographical areas.  This partitioning allows for
       overlapping IPv4 addresses ranges to be assigned to hosts that
       are in different areas.  Each area has its own pool of gateways
       that are dedicated for a certain overlapping IPv4 address range
       (referred here later as a zone).  Standard NAT44 functionality
       allows for communication from the RFC1918 private zone to the
       Internet. Communication between zones require special arrangement,
       such as using intermediate gateways (e.g. Back to Back User Agent
       (B2BUA) in case of SIP).

- Jouni



> 
> ===========
> 
> Thanks,
> Cameron
> 
> 
> On Sun, May 15, 2011 at 6:04 AM, Fred Baker  wrote:
>> This is to initiate a two week working group last call of
>> draft-ietf-v6ops-3gpp-eps. Please read it now. If you find nits (spelling
>> errors, minor suggested wording changes, etc), comment to the authors; if
>> you find greater issues, such as disagreeing with a statement or finding
>> additional issues that need to be addressed, please post your comments to
>> the list.
>> We are looking specifically for comments on the importance of the document
>> as well as its content. If you have read the document and believe it to be
>> of operational utility, that is also an important comment to make.
>> _______________________________________________
>> 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 behcetsarikaya@yahoo.com  Thu May 19 03:30: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 18A6FE07A5 for ; Thu, 19 May 2011 03:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.12
X-Spam-Level: 
X-Spam-Status: No, score=0.12 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_05=-1.11, 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 4UaVNPYqacpy for ; Thu, 19 May 2011 03:30:06 -0700 (PDT)
Received: from nm19-vm0.bullet.mail.sp2.yahoo.com (nm19-vm0.bullet.mail.sp2.yahoo.com [98.139.91.216]) by ietfa.amsl.com (Postfix) with SMTP id 83C57E0795 for ; Thu, 19 May 2011 03:30:06 -0700 (PDT)
Received: from [98.139.91.65] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 19 May 2011 10:30:06 -0000
Received: from [98.139.91.38] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 19 May 2011 10:30:06 -0000
Received: from [127.0.0.1] by omp1038.mail.sp2.yahoo.com with NNFMP; 19 May 2011 10:30:06 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 480867.98883.bm@omp1038.mail.sp2.yahoo.com
Received: (qmail 25507 invoked by uid 60001); 19 May 2011 10:30:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305801005; bh=HSsU2Ipyf2SXAbm+bBwZRKVYl06rM9bwEI9FOtYDbuQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=xvkEdxy+CMX6+wBiKbCw9nbh8yIiWBbBDRYrJ3adPJfP3rPvZYs8PI/YK4gcRF+syT+p0YP1nedVwPjMWZq+fVj47ZFP9qUTe4byn3n3RZ6MzXZ+jEZE+NQiVOSPGMSvdj3cYMIFVrCE840sOoJHuSYsdXSN/+1CkXk85k9yT5M=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=s6TbWLBR+27nnf7TOVziscIVv70Lx8MMD9PuiGGVq6TL1QYGLODZoVk1daI0afl95x5aedGk8DdEZibxeHPNaRo+08EFnwzF6cKqlhSJ5N4Usaz7E2UQH1gkjSksqRMarJTVgPxLSIRbu3OCLu9Nhq2aY5fg/Q6SbfUC2oEz5Ak=;
Message-ID: <189336.24979.qm@web111410.mail.gq1.yahoo.com>
X-YMail-OSG: C0Hd2MAVM1kOd00q.f68m_5rfZhnLshiD746UvzT694xLCu P7Aj.0Kz2jcVpIevXH0zO1NeBU74wVePZu6xnDsEW.Ds8e.OiNOEk9YSU1oU Fx5MZej9wzC_FV3bBxZpOgla7RUlBJkwG9Jhs8gZFJsGdUMGihrDB.1EieHc P.gZvN3lc9m5pDKXmluAh5yAxB8WDr2g8vJJrx5fsCqrNP1drd4MYiPC6XWr mO.b2gBPcoI8Tz1MM5lumEqo8WvixE2V2AluxgTkNiOHR6UhG5KExGzKxaTW is3zo_XGFKdRpoNB18.OiGIGOOABjgYOud0nDzADc3.H20foE9OP_hogiTQW KJ49prWNAsQkvwPXUY6BZ2ZUhQ4pbr3wuI1ifonB3w7wdrUCpAxQjlOUJyQn 8ke8v_LCl2OmjtA--
Received: from [217.110.189.170] by web111410.mail.gq1.yahoo.com via HTTP; Thu, 19 May 2011 03:30:04 PDT
X-Mailer: YahooMailRC/567 YahooMailWebService/0.8.111.303096
References: <3CF3E905-E526-4847-A9AC-D6A28828B208@cisco.com> 
Date: Thu, 19 May 2011 03:30:04 -0700 (PDT)
From: Behcet Sarikaya 
To: IPv6 Operations 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [v6ops] draft-sarikaya-v6ops-prefix-delegation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 May 2011 10:30:07 -0000

I submitted a revision based on the online and some offline comments received so 
far,
The new draft draft-sarikaya-v6ops-prefix-delegation-04.txt should be accessible
soon.

Regards,

Behcet




> _is_ this best current practice?
> 
> does this conflict when DHCPv6 PD is  used between UE and AR?
> I'm concerned about section 3.2, where the AR DHCPv6  relay should add an IA_PD 
>option to the DHCPv6 client - server exchange.
> has  that new protocol behaviour been reviewed in the DHC WG? in other 
>scenarios that  functionality has been solved either with snooping or the 
>proposed RAAN  option.
> 
> cheers,
> Ole
> 
> > The authors have asked me about 
> >  http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation
> >   "DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile  Networks",
> >  Behcet Sarikaya, Frank Xia, 19-Apr-11
> > 
> >  When we discussed this at IETF-79, a number of views were expressed, varying  
>from "let's adopt this as a working group draft and immediately publish as a  
>BCP" to "ignore and abandon this draft, if anything it belongs in some other SDO  
>or NOG", and all points in between. Several folks indicated that they would post  
>comments to the list, and the comments didn't materialize.
> > 
> >  Question for the assembled hordes: what needs to happen in this draft to 
>make it  useful/interesting for mobile network operators? What needs to happen 
>to make it  interesting to other operators?
> >  _______________________________________________
> > 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 cb.list6@gmail.com  Thu May 19 06:51: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 6F8ACE06D9 for ; Thu, 19 May 2011 06:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.098
X-Spam-Level: 
X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 GNKD0UEjEm2v for ; Thu, 19 May 2011 06:51:45 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 264A0E0745 for ; Thu, 19 May 2011 06:51:44 -0700 (PDT)
Received: by ewy19 with SMTP id 19so1062822ewy.31 for ; Thu, 19 May 2011 06:51:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OsGk1VGeJLW3hGhBOgq3FNW/WSmRECWc/pbaNHHb6AE=; b=hJ7V9i8O1fjjq5QviFkjluaNhLVNSnSPqMRoiSGOSgVoKSqOa+cy39rc6Y0pr4gAAc CiMOohEaevLDAriNJwsw3xTy6oVGRs/oTklCyWVpE53g/grjKQ5F5PYwncC2GdYGZVIA rzHC44augY3vj9uO79yN4VBjhsGD2ZQI2nvmM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tOFuIbNfxEBx2DAFmO1okjlepgacCB1b4SUHPc44B5ECErSVwvw7MT+dfVBRDsrIXM euXpVVkxffp76YHZg+ndRJf4qCGm2JxoJTDCpOoTAMmPWiHpcrW1zhUpdIOLbRBLRcQ1 LZNhC3OGeJEEndSGo/emL52bT15YDOkKtDf8c=
MIME-Version: 1.0
Received: by 10.14.43.218 with SMTP id l66mr1104312eeb.188.1305813102705; Thu, 19 May 2011 06:51:42 -0700 (PDT)
Received: by 10.14.48.14 with HTTP; Thu, 19 May 2011 06:51:42 -0700 (PDT)
Received: by 10.14.48.14 with HTTP; Thu, 19 May 2011 06:51:42 -0700 (PDT)
In-Reply-To: 
References: <993AD341-6B37-4A86-B15F-918DB8CC5117@cisco.com>  
Date: Thu, 19 May 2011 06:51:42 -0700
Message-ID: 
From: Cameron Byrne 
To: jouni korhonen 
Content-Type: multipart/alternative; boundary=0015175cd666213c1204a3a14e46
Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica 
Subject: Re: [v6ops] draft-ietf-v6ops-3gpp-eps WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 19 May 2011 13:51:46 -0000

--0015175cd666213c1204a3a14e46
Content-Type: text/plain; charset=ISO-8859-1

On May 19, 2011 2:28 AM, "jouni korhonen"  wrote:
>
> Hi Cameron,
>
> Thanks for the review. Appreciated. See my responses inline.
>
>
> On May 19, 2011, at 1:54 AM, Cameron Byrne wrote:
>
> > This draft is important and should be published
> >
> > minor suggestions:
> >
> > "With the impending exhaustion of available IPv4 addresses
> >   from the registries there is an increased emphasis for operators to
> >   migrate to IPv6."
> >
> > Change "impending" to "on going".  APNIC is already exhausted.
>
> Ack. Will change.
>
> >
> > ================
> >
> > "However, the support for IPv6
> >   in commercially deployed networks by the end of 2010 is nearly non-
> >   existent."
> >
> > Verizon Wireless commercially supports IPv6 and i remain hopeful that
> > other LTE offerings will be IPv6 enabled as well.
> >
> > Perhaps "...the support for IPv6
> >   in commercially deployed networks remains low"
>
> Ack. Will change.
>
> >
> > ============
> >
> >
> > "In addition to operating dual-
> >   stack networks during the transition from IPv4 to IPv6 phase, the two
> >   alternative categories for the transition are encapsulation and
> >   translation.  Most of the mechanisms available in the toolbox can be
> >   categorized into either translation or encapsulation approaches."
> >
> > This last sentence is repetitive and  should be removed or revised.
>
> Ok to remove the last sentence.
>
>
> >
> > ===============
> >
> > "Standard NAT44 functionality
> >       enables the communication between hosts that are assigned the
> >       same IPv4 address but belong to different zones, yet are part of
> >       the same operator domain."
> >
> > I don't believe "standard NAT44" will do this.  If i am behind a NAT44
> > and want to make a SIP call to someone else behind NAT44 ... i will
> > need a B2BUE to proxy signalling and media.  You may want to revise
> > this to simply say that "NAT44 allows for communication from the
> > RFC1918 private address space to the Internet".
>
> Right. How about:
>
>   1.  Very large network deployments are partitioned, for example,
>       based on a geographical areas.  This partitioning allows for
>       overlapping IPv4 addresses ranges to be assigned to hosts that
>       are in different areas.  Each area has its own pool of gateways
>       that are dedicated for a certain overlapping IPv4 address range
>       (referred here later as a zone).  Standard NAT44 functionality
>       allows for communication from the RFC1918 private zone to the
>       Internet. Communication between zones require special arrangement,
>       such as using intermediate gateways (e.g. Back to Back User Agent
>       (B2BUA) in case of SIP).
>
> - Jouni
>
>

Sounds good.

Thanks.

Cb
>
> >
> > ===========
> >
> > Thanks,
> > Cameron
> >
> >
> > On Sun, May 15, 2011 at 6:04 AM, Fred Baker  wrote:
> >> This is to initiate a two week working group last call of
> >> draft-ietf-v6ops-3gpp-eps. Please read it now. If you find nits
(spelling
> >> errors, minor suggested wording changes, etc), comment to the authors;
if
> >> you find greater issues, such as disagreeing with a statement or
finding
> >> additional issues that need to be addressed, please post your comments
to
> >> the list.
> >> We are looking specifically for comments on the importance of the
document
> >> as well as its content. If you have read the document and believe it to
be
> >> of operational utility, that is also an important comment to make.
> >> _______________________________________________
> >> 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
>

--0015175cd666213c1204a3a14e46
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On May 19, 2011 2:28 AM, "jouni korhonen" <jouni.nospam@gmail.com> wrote:

>

> Hi Cameron,

>

> Thanks for the review. Appreciated. See my responses inline.

>

>

> On May 19, 2011, at 1:54 AM, Cameron Byrne wrote:

>

> > This draft is important and should be published

> >

> > minor suggestions:

> >

> > "With the impending exhaustion of available IPv4 addresses
> > =A0 from the registries there is an increased emphasis for operat=
ors to

> > =A0 migrate to IPv6."

> >

> > Change "impending" to "on going". =A0APNIC is=
 already exhausted.

>

> Ack. Will change.

>

> >

> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> >

> > "However, the support for IPv6

> > =A0 in commercially deployed networks by the end of 2010 is nearl=
y non-

> > =A0 existent."

> >

> > Verizon Wireless commercially supports IPv6 and i remain hopeful =
that

> > other LTE offerings will be IPv6 enabled as well.

> >

> > Perhaps "...the support for IPv6

> > =A0 in commercially deployed networks remains low"

>

> Ack. Will change.

>

> >

> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> >

> >

> > "In addition to operating dual-

> > =A0 stack networks during the transition from IPv4 to IPv6 phase,=
 the two

> > =A0 alternative categories for the transition are encapsulation a=
nd

> > =A0 translation. =A0Most of the mechanisms available in the toolb=
ox can be

> > =A0 categorized into either translation or encapsulation approach=
es."

> >

> > This last sentence is repetitive and =A0should be removed or revi=
sed.

>

> Ok to remove the last sentence.

>

>

> >

> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> >

> > "Standard NAT44 functionality

> > =A0 =A0 =A0 enables the communication between hosts that are assi=
gned the

> > =A0 =A0 =A0 same IPv4 address but belong to different zones, yet =
are part of

> > =A0 =A0 =A0 the same operator domain."

> >

> > I don't believe "standard NAT44" will do this. =A0I=
f i am behind a NAT44

> > and want to make a SIP call to someone else behind NAT44 ... i wi=
ll

> > need a B2BUE to proxy signalling and media. =A0You may want to re=
vise

> > this to simply say that "NAT44 allows for communication from=
 the

> > RFC1918 private address space to the Internet".

>

> Right. How about:

>

> =A0 1. =A0Very large network deployments are partitioned, for example,=


> =A0 =A0 =A0 based on a geographical areas. =A0This partitioning allows=
 for

> =A0 =A0 =A0 overlapping IPv4 addresses ranges to be assigned to hosts =
that

> =A0 =A0 =A0 are in different areas. =A0Each area has its own pool of g=
ateways

> =A0 =A0 =A0 that are dedicated for a certain overlapping IPv4 address =
range

> =A0 =A0 =A0 (referred here later as a zone). =A0Standard NAT44 functio=
nality

> =A0 =A0 =A0 allows for communication from the RFC1918 private zone to =
the

> =A0 =A0 =A0 Internet. Communication between zones require special arra=
ngement,

> =A0 =A0 =A0 such as using intermediate gateways (e.g. Back to Back Use=
r Agent

> =A0 =A0 =A0 (B2BUA) in case of SIP).

>

> - Jouni

>

>


Sounds good.


Thanks.


Cb

>

> >

> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

> >

> > Thanks,

> > Cameron

> >

> >

> > On Sun, May 15, 2011 at 6:04 AM, Fred Baker <fred@cisco.com> wrote:

> >> This is to initiate a two week working group last call of

> >> draft-ietf-v6ops-3gpp-eps. Please read it now. If you find ni=
ts (spelling

> >> errors, minor suggested wording changes, etc), comment to the=
 authors; if

> >> you find greater issues, such as disagreeing with a statement=
 or finding

> >> additional issues that need to be addressed, please post your=
 comments to

> >> the list.

> >> We are looking specifically for comments on the importance of=
 the document

> >> as well as its content. If you have read the document and bel=
ieve it to be

> >> of operational utility, that is also an important comment to =
make.

> >> _______________________________________________

> >> v6ops mailing list

> >> v6ops@ietf.org

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

> >>

> >>

> > _______________________________________________

> > v6ops mailing list

> > v6ops@ietf.org

> > https://w=
ww.ietf.org/mailman/listinfo/v6ops

>




--0015175cd666213c1204a3a14e46--

From behcetsarikaya@yahoo.com  Thu May 19 03:00: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 E2221E07AA for ; Thu, 19 May 2011 03:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.625
X-Spam-Level: 
X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_20=-0.74, 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 23p6C4zcLAYP for ; Thu, 19 May 2011 03:00:32 -0700 (PDT)
Received: from nm17-vm0.bullet.mail.sp2.yahoo.com (nm17-vm0.bullet.mail.sp2.yahoo.com [98.139.91.212]) by ietfa.amsl.com (Postfix) with SMTP id 9210BE07A9 for ; Thu, 19 May 2011 03:00:32 -0700 (PDT)
Received: from [98.139.91.66] by nm17.bullet.mail.sp2.yahoo.com with NNFMP; 19 May 2011 10:00:29 -0000
Received: from [98.139.91.26] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 19 May 2011 10:00:29 -0000
Received: from [127.0.0.1] by omp1026.mail.sp2.yahoo.com with NNFMP; 19 May 2011 10:00:29 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 331662.28269.bm@omp1026.mail.sp2.yahoo.com
Received: (qmail 8123 invoked by uid 60001); 19 May 2011 10:00:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305799228; bh=mAvzKWDqfz0SnWgLSZdQHUbCpjJxwZMi4kLed1YcPMA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fdPd55RjCepGNdeJFABYiONK6pXmofo0pu9UirCNp4YY7c6S720+Yiq9R4Ivxm7NNBojZge6P3qvNSRPXkK7CDlfCM9OvERBrUYJesQvAcMHT1OurY4ARIoLYNPxNMQ0Ih7v17OYZ5+8I0m53ET82X0x7mgWX1S07jtdaTc1ngg=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=R2Bv/RtlxvCh8HVd1o3c1iYE7ezMRukaxZYiT0H9Nje7bUAF73tz9TjqtKwB9uNX+s7WXjQveNqjzFV/GbF3ckIHOTsuRWEDFQrEDmFaQkGO9xI/VS2RgF/5SUOtGNn3iypZy72/PZN2JB3aZPWE6V2NJgAQlR+uN67BlFc0H64=;
Message-ID: <826542.7269.qm@web111406.mail.gq1.yahoo.com>
X-YMail-OSG: jqau4gEVM1nlYvWBg2tW8DCDURmEOvHQlVrAadv1xv8VW7j CNdaPR91zwbKfsXoLiIfwNiykMYMv2lbTWXY9.og52T._WoPrBe1PFaRcdEq hjRcYNdwn3xhpGkjoXsAgP3iGAJXud_JzDjbOe72oyfsd45bjE96fYO4GTG. BQ52YmVmEWCqHSYqUmoao.FGoEfZeVn2zfisJAmu7ba356ghAkCznaomRvDX JJ5W5Re9.zGZ8j93Kyis6LMEyvIlLN3u7LqCDniHcIuaIBDynivdRzBjhPl3 MrnVlHU2xSTeJz0E1_YWNA.kqp8Jj0bRvLZO6oMbTek7QiyPR88oSCexDQCk Dv9UQvCaRP1LLXx2CNW5nVuwvc1FS7OdXtRicRY3onhCf0i2TdtNwWiFaUNF Rg90WANT_Mskc9g--
Received: from [217.110.189.170] by web111406.mail.gq1.yahoo.com via HTTP; Thu, 19 May 2011 03:00:28 PDT
X-Mailer: YahooMailWebService/0.8.111.303096
References: <3CF3E905-E526-4847-A9AC-D6A28828B208@cisco.com> 
Date: Thu, 19 May 2011 03:00:28 -0700 (PDT)
From: Behcet Sarikaya 
To: Ole Troan , Fred Baker 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 19 May 2011 08:09:44 -0700
Cc: IPv6 Operations Working Group 
Subject: Re: [v6ops] draft-sarikaya-v6ops-prefix-delegation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 May 2011 10:00:34 -0000

I submitted a revision based on the online and some offline comments receiv=
ed so far,=0AThe new draft draft-sarikaya-v6ops-prefix-delegation-04.txt sh=
ould be accessible=0Asoon.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A> =0A> _is_=
 this best current practice?=0A> =0A> does this conflict when DHCPv6 PD is =
used between UE and AR?=0A> I'm concerned about section 3.2, where the AR D=
HCPv6 relay should add an =0A> IA_PD option to the DHCPv6 client - server e=
xchange.=0A> has that new protocol behaviour been reviewed in the DHC WG? i=
n other scenarios =0A> that functionality has been solved either with snoop=
ing or the proposed RAAN =0A> option.=0A> =0A> cheers,=0A> Ole=0A> =0A>>  T=
he authors have asked me about =0A>>  http://tools.ietf.org/html/draft-sari=
kaya-v6ops-prefix-delegation=0A>> =A0 "DHCPv6 Prefix Delegation as IPv6 Mig=
ration Tool in Mobile =0A> Networks",=0A>> =A0 Behcet Sarikaya, Frank Xia, =
19-Apr-11=0A>> =0A>>  When we discussed this at IETF-79, a number of views =
were expressed, =0A> varying from "let's adopt this as a working group draf=
t and immediately =0A> publish as a BCP" to "ignore and abandon this draft,=
 if anything it =0A> belongs in some other SDO or NOG", and all points in b=
etween. Several folks =0A> indicated that they would post comments to the l=
ist, and the comments didn't =0A> materialize.=0A>> =0A>>  Question for the=
 assembled hordes: what needs to happen in this draft to =0A> make it usefu=
l/interesting for mobile network operators? What needs to happen to =0A> ma=
ke it interesting to other operators?=0A>>  _______________________________=
________________=0A>>  v6ops mailing list=0A>>  v6ops@ietf.org=0A>>  https:=
//www.ietf.org/mailman/listinfo/v6ops=0A> =0A> ____________________________=
___________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://w=
ww.ietf.org/mailman/listinfo/v6ops=0A>

From Fred.L.Templin@boeing.com  Thu May 19 10:52: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 22703E06BE for ; Thu, 19 May 2011 10:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.499
X-Spam-Level: 
X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100,  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 7zMgfwc4G9GC for ; Thu, 19 May 2011 10:52:49 -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 4CDFAE0814 for ; Thu, 19 May 2011 10:52:43 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4JHqdoK026488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 19 May 2011 12:52:40 -0500 (CDT)
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 p4JHASgs000785 for ; Thu, 19 May 2011 10:10:28 -0700 (PDT)
Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4JHARDL000773 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Thu, 19 May 2011 10:10:28 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Thu, 19 May 2011 10:52:38 -0700
From: "Templin, Fred L" 
To: "v6ops@ietf.org" 
Date: Thu, 19 May 2011 10:52:37 -0700
Thread-Topic: I-D Action: draft-templin-v6ops-isops-02.txt
Thread-Index: AcwWSn8iPi2gJV2wRcyc3ocS4NTUpwAAlgSg
Message-ID: 
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: I-D Action: draft-templin-v6ops-isops-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: Thu, 19 May 2011 17:52:50 -0000

FYI, a new version of this document is available. The most
notable change is the addition of a simplified ISATAP service
model that assigns a single IPv6 /64 prefix to an entire site.
This can be most readily seen in the new Section 7.1:

"7.1.  A Simple Example

   Consider a large, multinational enterprise network that wishes to
   enable IPv6 services without significant alterations to its long-
   established IPv4 network operations and policies.  The enterprise
   network has a mature IPv4 routing and addressing system; possibly
   including firewalling and filtering policies which divide the
   enterprise into multiple partitions.

   The enterprise network administrators obtain a single IPv6 prefix
   such as 2001:db8::/64 and arrange to advertise the prefix into the
   global IPv6 routing system.  The administrators further configure
   sufficient advertising ISATAP routers throughout the enterprise
   network so that there will be at least one advertising ISATAP router
   within close topological and/or geographic proximity with all
   potential ISATAP clients.  Each advertising ISATAP router is
   configured to advertise the IPv6 prefix 2001:db8::/64 on its
   advertising ISATAP interface.  Each advertising ISATAP router
   configures an IPv4 anycast address such as 192.0.2.1 (e.g., by
   assigning the address to a loopback interface) and advertises the
   address within the enterprise-interior IPv4 routing system.

   Finally, the administrators configure all prospective ISATAP clients
   to prefer IPv4 addresses over IPv6 addresses derived from the prefix
   2001:db8::/64 so that clients will continue to use IPv4 services for
   communications within the enterprise network as they have always
   done.  When the prospective clients have been configured with the
   correct address selection policies, the enterprise network
   administrators finally add the IPv4 anycast address 192.0.2.1 to the
   PRL for the enterprise, e.g., by adding the address to the resource
   records for the name "isatap" within the enterprise network name
   service.  This action automatically enables the ISATAP service for
   all prospective clients, which can then use SLAAC to configure an
   ISATAP address from the prefix 2001:db8::/64 and use the address to
   communicate with IPv6 correspondents outside of the enterprise
   network."

See below for the draft announcement, and send any comments
or suggestions to the list.

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: Thursday, May 19, 2011 10:30 AM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-templin-v6ops-isops-02.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-02.txt
	Pages           : 20
	Date            : 2011-05-19

   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.  It is also
   expected that more and more IPv6-only devices will be deployed within
   the site over time.  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-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-templin-v6ops-isops-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 internet-drafts@ietf.org  Thu May 19 14:05: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 699D0E076B; Thu, 19 May 2011 14:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.568
X-Spam-Level: 
X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 pHhUubZgxqXh; Thu, 19 May 2011 14:05:00 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEA1E06B1; Thu, 19 May 2011 14:05:00 -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.54
Message-ID: <20110519210500.14224.13029.idtracker@ietfa.amsl.com>
Date: Thu, 19 May 2011 14:05:00 -0700
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6-in-mobile-networks-05.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, 19 May 2011 21:05:01 -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           : Mobile Networks Considerations for IPv6 Deployment
	Author(s)       : Rajeev Koodli
	Filename        : draft-ietf-v6ops-v6-in-mobile-networks-05.txt
	Pages           : 19
	Date            : 2011-05-19

   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.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-in-mobile-networks-=
05.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-v6-in-mobile-networks-0=
5.txt

From v6ops@globis.net  Fri May 20 10:45: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 4468BE0700 for ; Fri, 20 May 2011 10:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  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 wVNWBNq-YZ8T for ; Fri, 20 May 2011 10:45:15 -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 B8DD3E0688 for ; Fri, 20 May 2011 10:45:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E0DF98700B4 for ; Fri, 20 May 2011 19:45:13 +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 g3iI7Jrv-5nH for ; Fri, 20 May 2011 19:45:09 +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 3309E870023 for ; Fri, 20 May 2011 19:45:09 +0200 (CEST)
Message-ID: <4DD6A8A5.5010204@globis.net>
Date: Fri, 20 May 2011 19:45:09 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: "v6ops@ietf.org WG" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [v6ops] draft-ietf-v6ops-3gpp-eps WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 20 May 2011 17:45:16 -0000

I read the document draft-ietf-v6ops-3gpp-eps and had no comments.

regards,
RayH


From iesg-secretary@ietf.org  Fri May 20 13: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 72A9BE0764; Fri, 20 May 2011 13:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level: 
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 bbkqfpDDbM5R; Fri, 20 May 2011 13:59:30 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089DAE07AE; Fri, 20 May 2011 13:59:30 -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.54
Message-ID: <20110520205930.2314.63463.idtracker@ietfa.amsl.com>
Date: Fri, 20 May 2011 13:59:30 -0700
Cc: v6ops mailing list , v6ops chair , RFC Editor 
Subject: [v6ops] Document Action: 'Mobile Networks Considerations for IPv6 Deployment'	to Informational RFC (draft-ietf-v6ops-v6-in-mobile-networks-05.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, 20 May 2011 20:59:31 -0000

The IESG has approved the following document:
- 'Mobile Networks Considerations for IPv6 Deployment'
  (draft-ietf-v6ops-v6-in-mobile-networks-05.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-v6-in-mobile-networks/




   Technical Summary 

  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.

   Working Group Summary 

The IPv6 Operations Working Group discussed this document at IETF-77 and IETF-78 
and in an email Working Group last Call. There were comments made, and the 
commentators stated that they were comfortable with the resolution in the final document.

   Document Quality 

We are starting to see operational mobile networks with the set of problems the document 
addresses and considering similar solutions. Comments from the working group suggested 
that the writeup was useful to them.


Personnel

  Fred Baker is shepherd.


From iesg-secretary@ietf.org  Fri May 20 16:37: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 C186BE0740; Fri, 20 May 2011 16:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.244
X-Spam-Level: 
X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=-0.245, 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 h+ye-YRW-OUQ; Fri, 20 May 2011 16:37:55 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E331E0772; Fri, 20 May 2011 16:37:55 -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.54
Message-ID: <20110520233755.12486.96637.idtracker@ietfa.amsl.com>
Date: Fri, 20 May 2011 16:37:55 -0700
Cc: v6ops mailing list , v6ops chair , RFC Editor 
Subject: [v6ops] Document Action: 'Routing Loop Attack using IPv6 Automatic Tunnels:	Problem Statement and Proposed Mitigations' to Informational	RFC (draft-ietf-v6ops-tunnel-loops-07.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, 20 May 2011 23:37:55 -0000

The IESG has approved the following document:
- 'Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement
   and Proposed Mitigations'
  (draft-ietf-v6ops-tunnel-loops-07.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-tunnel-loops/




Technical Summary

   This document is concerned with security vulnerabilities in IPv6-in-
   IPv4 automatic tunnels.  These vulnerabilities allow an attacker to
   take advantage of inconsistencies between the IPv4 routing state and
   the IPv6 routing state.  The attack forms a routing loop which can be
   abused as a vehicle for traffic amplification to facilitate DoS
   attacks.  The first aim of this document is to inform on this attack
   and its root causes.  The second aim is to present some possible
   mitigation measures.

Working Group Summary

   The initial version of the document was published 10/20/09.
   Subsequent to IETF 78 the document was accepted as a working group
   document. Last call was completed on 10/12/10.

Document Quality

   This work has benefited from discussions on the V6OPS, 6MAN and
   SECDIR mailing lists.  Remi Despres, Christian Huitema, Dmitry
   Anipko, Dave Thaler and Fernando Gont are acknowledged for their
   contributions.

Personnel

Joel Jaegli is documet sheperd.


From fred@cisco.com  Sun May 22 11:00: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 94C1EE06E7 for ; Sun, 22 May 2011 11:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.471
X-Spam-Level: 
X-Spam-Status: No, score=-109.471 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=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 X9PG-Xfdao01 for ; Sun, 22 May 2011 11:00:21 -0700 (PDT)
Received: from ams-iport-1.cisco.com (unknown [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id BB226E06CF for ; Sun, 22 May 2011 11:00:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1168; q=dns/txt; s=iport; t=1306087220; x=1307296820; h=from:subject:date:message-id:cc:to:mime-version; bh=MuGGeMnrWl9gu0/eeqNy2chbjBHen4mpBX16YyLk6/U=; b=iUpKRC9Kyst8Ze1zFlL2bbIHei1Qnx32uTtpy3YSqnSL72acAzj1SCS/ kUrd2MgB5GsjIzoWwfla4ydNYOkSZUkmbTeNlaG/VuB8dTsGfbUEBp7ph nBS8zyggnP4ZTJvqZVryxd0Y/gzwyjggCuMfQ013h4tdsR3RB2WRFbv4a I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtIDABBO2U2Q/khLgWdsb2JhbACCZqM5FAEBFiYmpnacOoYZBJARhC+KRw
X-IronPort-AV: E=Sophos;i="4.65,252,1304294400"; d="scan'208,217";a="90007594"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 22 May 2011 18:00:19 +0000
Received: from Freds-Computer.local (dhcp-10-55-95-37.cisco.com [10.55.95.37]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4MI0Ebo024447; Sun, 22 May 2011 18:00:19 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 22 May 2011 19:00:19 +0100
X-PGP-Universal: processed; by Freds-Computer.local on Sun, 22 May 2011 19:00:19 +0100
From: Fred Baker 
Date: Sun, 22 May 2011 19:00:04 +0100
Message-Id: <7B661D1F-F127-45A8-B3E1-DDA6ED10AD35@cisco.com>
To: IPv6 Operations Working Group 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-57--784993803
Cc: v6ops-chairs@tools.ietf.org, Ron Bonica 
Subject: [v6ops] Reminder: draft-ietf-v6ops-3gpp-eps WGLC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 May 2011 18:00:21 -0000

--Apple-Mail-57--784993803
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The working group last call for this draft announced last week continues =
for another week. Please feel free to comment on it.



--Apple-Mail-57--784993803
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


The working group last call for this draft announced last week continues for another week. Please feel free to comment on it.


 

--Apple-Mail-57--784993803--

From cancanhuang110@gmail.com  Mon May 23 05:29: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 A9140E078D for ; Mon, 23 May 2011 05:29:31 -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_53=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 Zvbp7TyRxAr7 for ; Mon, 23 May 2011 05:29:30 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B024E0787 for ; Mon, 23 May 2011 05:29:29 -0700 (PDT)
Received: by fxm15 with SMTP id 15so4382153fxm.31 for ; Mon, 23 May 2011 05:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=OTKJ7M3pqjVafpL2Rmj9oCq4hZZCxkpxUNkvrxgRJAE=; b=uTIrTM68/dWiK4ozwSp2IFy1eebWdawqvj98DC/MCDpeYxATuPJqdUwNezAws9rbR6 10URb5zyo95L0ASGaccRBBIJzWCH2RmZB2TTNvseqLUUaHJ14IJQyf/Oa2NcC5kMo8yC k7YHjMzkSBxRBOuv8+GV/Va+NcbBR/n/72NC4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=uE2/1B4DMbedze6S9A8wEexjp46ufWmsS5ISqFqpet17FU54eUSDEp5r4DimgeFbIY ekgyQTQRVqxC1jx7bcJPQK5hqXJuaUMpb4gZKlojw9CRH6dFFEAr3Y+mSn2tLTglZetL JQf68gzUNMHBJ6d1UhQxGNUrIV9blzCSGRbdg=
MIME-Version: 1.0
Received: by 10.223.13.207 with SMTP id d15mr2462667faa.38.1306153768942; Mon, 23 May 2011 05:29:28 -0700 (PDT)
Received: by 10.223.127.11 with HTTP; Mon, 23 May 2011 05:29:28 -0700 (PDT)
Date: Mon, 23 May 2011 20:29:28 +0800
Message-ID: 
From: huang cancan 
To: IPv6 Operations 
Content-Type: multipart/alternative; boundary=0015173fedc06b7c0d04a3f09ff3
Cc: =?UTF-8?B?5p2o5Zu96Imv?= , wuym@gsta.com
Subject: [v6ops]  new draft: draft-yang-v6ops-fast6-tools-selection-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, 23 May 2011 12:29:31 -0000

--0015173fedc06b7c0d04a3f09ff3
Content-Type: text/plain; charset=ISO-8859-1

Dear All,



We have just post a new ID of the analysis of tools selection for broadband
ISP. In the current stage,  NAT444, DS-LITE, 6RD and other transition
technologies have been well done, the ISP should select the most suitable
tool to meet the requirements of a typical broadband access network in the
real world regarding its network architecture, operation situation and
transition goals,etc. According to the mainstream broadband access network,
this draft focuses on analyzing the problems that may be encountered when
using various transitional technologies during the transition and finally
introduces a more systematic and operational proposal.


Please find it out from following url:
http://tools.ietf.org/html/draft-yang-v6ops-fast6-tools-selection-00


We'd like to have your kind review, and comments.


Best wishes

Cancan Huang

--0015173fedc06b7c0d04a3f09ff3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


<=
font size=3D"3">Dear All,


<=
font face=3D"Times New Roman" size=3D"3">=A0


<=
font size=3D"3">We=A0have just post=A0a new =
ID of the analysis of tools selection for broadband ISP. In the current sta=
ge,=A0 NAT444, DS-LITE, 6RD and other transition technologies have been wel=
l=A0done, the ISP should select the most suitable tool to meet the=A0requir=
ements of a typical broadband access network in the real world regarding it=
s network architecture, operation situation and transition goals,etc.=A0Acc=
ording to the mainstream broadband access network, this draft focuses on an=
alyzing the problems that may be encountered when using various transitiona=
l technologies during the transition and finally introduces a more systemat=
ic and operational proposal.


=A0


Please find it out from fo=
llowing url:


http://tools.ietf.or=
g/html/draft-yang-v6ops-fast6-tools-selection-00


=A0

<=
font size=3D"3">We'd like to have your k=
ind review, and comments.


<=
font face=3D"Times New Roman" size=3D"3">=A0


Best wishes


=A0


Cancan Huang


--0015173fedc06b7c0d04a3f09ff3--

From fred@cisco.com  Mon May 23 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 BD5F6E0783 for ; Mon, 23 May 2011 06:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.495
X-Spam-Level: 
X-Spam-Status: No, score=-108.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RCVD_IN_DNSWL_HI=-8, RDNS_NONE=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 P8-jMMIL6GD8 for ; Mon, 23 May 2011 06:55:01 -0700 (PDT)
Received: from sj-iport-3.cisco.com (unknown [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 89473E077F for ; Mon, 23 May 2011 06:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=140; q=dns/txt; s=iport; t=1306158901; x=1307368501; h=date:from:message-id:to:subject:cc; bh=AsqIh4V03PxVtJyIVVLYe/RIDThcs0DBMDGZzuGSq04=; b=mr3axfqYVCO46ktqPLZnGhTeNKOe1WJTRd8RRyRMpd6CaQk0TFJ7JdRD CM3bqD7Nqd+Ui2A/n17RF9ssQs0vogvdNYCIeeCIR2a5ZP2fz+mnWt18H W3PiEatS7lIua3TPnI2R7PN/4A24kL5qdLrci5WtElLwW4gDD9+Kim3g5 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiwHANZm2k2rRDoH/2dsb2JhbACYJAEBjX93pSGdDYYZBIZQmFY
X-IronPort-AV: E=Sophos;i="4.65,256,1304294400"; d="scan'208";a="321601418"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 23 May 2011 13:55:01 +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 p4NDt0an014507; Mon, 23 May 2011 13:55:00 GMT
Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p4NDt0E24750; Mon, 23 May 2011 06:55:00 -0700 (PDT)
Date: Mon, 23 May 2011 06:55:00 -0700 (PDT)
From: 
Message-Id: <201105231355.p4NDt0E24750@ftpeng-update.cisco.com>
To: v6ops@ietf.org
Cc: draft-yang-v6ops-fast6-tools-selection@tools.ietf.org
Subject: [v6ops] new draft: draft-yang-v6ops-fast6-tools-selection-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, 23 May 2011 13:55:02 -0000

A new draft has been posted, at http://tools.ietf.org/html/draft-yang-v6ops-fast6-tools-selection. Please take a look at it and comment.

From jhw@apple.com  Mon May 23 11:45: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 EE5C9E07E7 for ; Mon, 23 May 2011 11:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.449
X-Spam-Level: 
X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_PAIN=2.3, 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 41M1Bz3A+BfW for ; Mon, 23 May 2011 11:45:02 -0700 (PDT)
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id CFC5DE07DB for ; Mon, 23 May 2011 11:45:01 -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 <0LLN00CNEW2V6L71@mail-out.apple.com> for v6ops@ietf.org; Mon, 23 May 2011 11:45:00 -0700 (PDT)
X-AuditID: 11807134-b7c00ae0000074fb-7f-4ddaab2c2cd7
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 relay14.apple.com (Apple SCV relay) with SMTP id 0D.71.29947.C2BAADD4; Mon, 23 May 2011 11:45:00 -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 <0LLN00227W307210@cardamom.apple.com> for v6ops@ietf.org; Mon, 23 May 2011 11:45:00 -0700 (PDT)
From: james woodyatt 
In-reply-to: <7B661D1F-F127-45A8-B3E1-DDA6ED10AD35@cisco.com>
Date: Mon, 23 May 2011 11:45:00 -0700
Message-id: <9EFA85B3-43E6-441B-82B6-2C19084F5B39@apple.com>
References: <7B661D1F-F127-45A8-B3E1-DDA6ED10AD35@cisco.com>
To: "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.1231)
X-Brightmail-Tracker: AAAAAA==
Subject: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-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: Mon, 23 May 2011 18:45:03 -0000

On May 22, 2011, at 11:00 , Fred Baker wrote:
> 
> The working group last call for this draft announced last week continues for another week. Please feel free to comment on it.

I am in the target audience for this document, so my contributions will seem more critical than constructive and predominantly editorial in nature, mainly because I'm not confident that my knowledge of 3GPP protocols and technologies is complete.

Please do not interpret my criticisms as opposition to this draft.  I very much want to see a document with this information published in the RFC series.

----

p1. The abstract seems overly verbose.  Here is a proposed rewrite:

   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.

p2. This sentence needs updating:

   However, the support for IPv6
   in commercially deployed networks by the end of 2010 is nearly non-
   existent.

p3. In section 2.1, Terminology, I think it would help if the abbreviations were all collected into one table and expanded once in each glossary subsection entry and in each top level section where they are used.  The terms in the glossary subsection should be headed by expanded abbreviations, and they should be presented in alphabetical order.

p4. In section 2.1, Terminology, the definition of "Packet Data Network" introduces what seems to be a specialized term, 'packet domain network,' that goes undefined in this section.  Please clarify.

p5. In section 2.1, Terminology, the definition of "Policy and Charging Control (PCC) framework" explains that it's used for QoS policy, which I think I might understand, but also for 'charging control' which is never defined.  It also doesn't appear to be inferable from context in the draft.  The dependent clause "but needed if dynamic policy and charging control by means of PCC rules based on user and services are desired" is therefore really not much use.  Please clarify.

p6. In section 2.1, Terminology, the term "evolved packet core" is introduced and used in the document, but never defined.  Please clarify.

p7. I think section 2.2, The concept of APN, might more properly belong in section 3 [but I'm not sure].  If it really belongs in section 2, because it describes an architecture independent of the Internet Protocol, then perhaps this should be explicitly mentioned here.

p8. In section 3.1, figure 2, what does the abbreviation TE mean?  Also, I gather that PLMN stands for Public Land Mobile Network, but this term is not properly introduced.  The "i.e." parentheticals in the Gn/Gp table entry are no help to me.

p9. In section 5.3, Prefix Delegation, the second paragraph is mostly unintelligible to me.  The citation of RFC 3633, section 12.1, is confusing, because that document doesn't place any limitations on the delegating router, only the requesting router, which is contrary to what this draft states.  The sentences that follow in that paragraph therefore don't make sense to me.  Please clarify.

p10. In section 6, the abbreviation "DS" is used, presumably to stand for 'dual-stack,' but no proper introduction is given.  I think it would be better to eliminate some uses of it, particularly in figures 5, 6 and 7, and expand it fully everywhere else.

p11. In section 6.4, the abbreviation IPv4v6 is introduced and used several places thereafter.  I can infer that this signals a special type of 3GPP bearer that transports both IPv4 and IPv6 at the same time, but I don't like this abbreviation.  If it's official 3GPP terminology, then please cite it and add it to the Terminology section.  Otherwise, please come up with a more descriptive term, e.g. "dual-stack IP" should work in a pinch, and use that instead.

p12. Throughout, I think it would be better to use a hyphen when writing IPv4-only and IPv6-only.


--
james woodyatt 
member of technical staff, core os networking




From tena@huawei.com  Mon May 23 13: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 94066E0830 for ; Mon, 23 May 2011 13:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.073
X-Spam-Level: 
X-Spam-Status: No, score=-105.073 tagged_above=-999 required=5 tests=[AWL=-1.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_CHARSET_FARAWAY=2.45, 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 2Tx975N2RpV4 for ; Mon, 23 May 2011 13:36:43 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 87A7EE069C for ; Mon, 23 May 2011 13:36:43 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLO002XF19643@usaga04-in.huawei.com> for v6ops@ietf.org; Mon, 23 May 2011 15:36:42 -0500 (CDT)
Received: from TingZousc1 ([10.193.34.188]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLO00KZC190Y7@usaga04-in.huawei.com> for v6ops@ietf.org; Mon, 23 May 2011 15:36:41 -0500 (CDT)
Date: Mon, 23 May 2011 13:36:37 -0700
From: Tina Tsou 
In-reply-to: 
To: 'huang cancan' , 'IPv6 Operations' 
Message-id: <008b01cc1989$1dcd75c0$59686140$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_bJ20D0IgTOX+ww+QF24BZA)"
Content-language: en-us
Thread-index: AcwZRXQ1GS5HBX3EQyCkcoFoObGYZwAQ0kdA
References: 
Cc: =?gb2312?B?J9HuufrBvCc=?= , wuym@gsta.com
Subject: Re: [v6ops] new draft: draft-yang-v6ops-fast6-tools-selection-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, 23 May 2011 20:36:44 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_bJ20D0IgTOX+ww+QF24BZA)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable

Can-can, Guo-Liang, and YouMing,
It is very practical I-D.
One quick comment, the tern LSN has been changed back to CGN from WG =
behave,
which IETF will use.
You may want to correct it in next version of
http://tools.ietf.org/html/draft-yang-v6ops-fast6-pppoe-00
=20
We keep our promises with one another =A8C no matter what!
=20
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
=20
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of
huang cancan
Sent: Monday, May 23, 2011 5:29 AM
To: IPv6 Operations
Cc: =D1=EE=B9=FA=C1=BC; wuym@gsta.com
Subject: [v6ops] new draft: draft-yang-v6ops-fast6-tools-selection-00
=20
Dear All,
=20
We have just post a new ID of the analysis of tools selection for =
broadband
ISP. In the current stage,  NAT444, DS-LITE, 6RD and other transition
technologies have been well done, the ISP should select the most =
suitable
tool to meet the requirements of a typical broadband access network in =
the
real world regarding its network architecture, operation situation and
transition goals,etc. According to the mainstream broadband access =
network,
this draft focuses on analyzing the problems that may be encountered =
when
using various transitional technologies during the transition and =
finally
introduces a more systematic and operational proposal.

=20
Please find it out from following url:
http://tools.ietf.org/html/draft-yang-v6ops-fast6-tools-selection-00
=20
We'd like to have your kind review, and comments.
=20
Best wishes
=20
Cancan Huang

--Boundary_(ID_bJ20D0IgTOX+ww+QF24BZA)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable



Can-can, Guo-Liang, and =
YouMing,
It is very practical =
I-D.
One quick comment, the tern =
LSN has been changed back to CGN from WG behave, which IETF will =
use.
You may want =
to correct it in next version of
http:=
//tools.ietf.org/html/draft-yang-v6ops-fast6-pppoe-00
 
We keep our =
promises with one another =A8C no matter what!
 
Best =
Regards,
Tina =
TSOU
http://tinatsou.weebly.com/contact=
.html
 
From: v6ops-bounces@ietf.org =
[mailto:v6ops-bounces@ietf.org] On Behalf Of huang =
cancan
Sent: Monday, May 23, 2011 5:29 AM
To: IPv6 =
Operations
Cc: =D1=EE=B9=FA=C1=BC; wuym@gsta.com
Subject: [v6ops] =
new draft: =
draft-yang-v6ops-fast6-tools-selection-00
 
Dear =
All,
 
We have just post a new ID of the analysis =
of tools selection for broadband ISP. In the current stage,  =
NAT444, DS-LITE, 6RD and other transition technologies have been =
well done, the ISP should select the most suitable tool to meet =
the requirements of a typical broadband access network in the real =
world regarding its network architecture, operation situation and =
transition goals,etc. According to the mainstream broadband access =
network, this draft focuses on analyzing the problems that may be =
encountered when using various transitional technologies during the =
transition and finally introduces a more systematic and operational =
proposal.

 
Please =
find it out from following url:
 
We'd =
like to have your kind review, and comments.
 
Best =
wishes
 
Cancan Huang
=

--Boundary_(ID_bJ20D0IgTOX+ww+QF24BZA)--

From Fred.L.Templin@boeing.com  Mon May 23 14:16: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 A1DA5E0862 for ; Mon, 23 May 2011 14:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.572
X-Spam-Level: 
X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027,  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 PzMakO8hh-9I for ; Mon, 23 May 2011 14:16:48 -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 BCABBE069A for ; Mon, 23 May 2011 14:16:48 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4NLGh7w017240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 23 May 2011 16:16:46 -0500 (CDT)
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 p4NKSiIu019715 for ; Mon, 23 May 2011 13:28:44 -0700 (PDT)
Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4NKSfLc019611 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Mon, 23 May 2011 13:28:44 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Mon, 23 May 2011 14:16:41 -0700
From: "Templin, Fred L" 
To: "v6ops@ietf.org" 
Date: Mon, 23 May 2011 14:16:40 -0700
Thread-Topic: Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP
Thread-Index: AcwZg/pxdRJzbeAxSIyB4YcRb0RuxAACkeBQ
Message-ID: 
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] Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 May 2011 21:16:49 -0000

Folks,

I am done tweaking this document now. Would appreciate
input, especially from those who have expressed interest
in ISATAP over the past several weeks.

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

-----Original Message-----
From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] =
On Behalf Of internet-drafts@ietf.org
Sent: Monday, May 23, 2011 12:59 PM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-templin-v6ops-isops-05.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-05.txt
	Pages           : 26
	Date            : 2011-05-23

   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.  It is also
   expected that more and more IPv6-only devices will be deployed within
   the site over time.  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-05.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-05.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 tena@huawei.com  Mon May 23 17:02: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 53875E07AF for ; Mon, 23 May 2011 17:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.542
X-Spam-Level: 
X-Spam-Status: No, score=-104.542 tagged_above=-999 required=5 tests=[AWL=-1.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 5CizoRfC76Zs for ; Mon, 23 May 2011 17:02:45 -0700 (PDT)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 26456E06DB for ; Mon, 23 May 2011 17:02:45 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLO000BOASK1S@usaga02-in.huawei.com> for v6ops@ietf.org; Mon, 23 May 2011 17:02:44 -0700 (PDT)
Received: from TingZousc1 ([10.193.34.188]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLO0094HASIX0@usaga02-in.huawei.com> for v6ops@ietf.org; Mon, 23 May 2011 17:02:44 -0700 (PDT)
Date: Mon, 23 May 2011 17:02:43 -0700
From: Tina Tsou 
In-reply-to: <000601cc19a5$1faecf30$5f0c6d90$@com>
To: =?gb2312?B?J9HuufrBvCc=?= , 'huang cancan' , 'IPv6 Operations' 
Message-id: <013f01cc19a5$e8514440$b8f3ccc0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_lw238KofZi1pkv03f6igqQ)"
Content-language: en-us
Thread-index: AcwZRXQ1GS5HBX3EQyCkcoFoObGYZwAQ0kdAAAYrTBAAAQ9WcA==
References:  <008b01cc1989$1dcd75c0$59686140$@com> <000601cc19a5$1faecf30$5f0c6d90$@com>
Cc: wuym@gsta.com
Subject: Re: [v6ops] new draft: draft-yang-v6ops-fast6-tools-selection-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, 24 May 2011 00:02:46 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_lw238KofZi1pkv03f6igqQ)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable

Guo-Liang,
It is a positive way to replace NAT444 with FAST6 with a, b, and c), and
make the assumptions clear.
=20
We keep our promises with one another =A8C no matter what!
=20
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
=20
From: =D1=EE=B9=FA=C1=BC [mailto:yanggl@gsta.com]=20
Sent: Monday, May 23, 2011 4:57 PM
To: 'Tina Tsou'; 'huang cancan'; 'IPv6 Operations'
Cc: wuym@gsta.com
Subject: =B4=F0=B8=B4: [v6ops] new draft: =
draft-yang-v6ops-fast6-tools-selection-00
=20
Thank you very much, more comments are welcome. We hope to replace =
NAT444
with FAST6 in our transition solution, because NAT444 has its =
limitation. I
think you can help us.^_^
=20
    =B4=CB=D6=C2
=BE=B4=C0=F1=A3=A1
=20
=D1=EE=B9=FA=C1=BC
Tel: 020-38639615
Mobile: 13316090336
MSN: yanggl@live.com =20
QQ: yanggl@189.cn
=20
=B7=A2=BC=FE=C8=CB: Tina Tsou [mailto:tena@huawei.com]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C224=C8=D5 4:37
=CA=D5=BC=FE=C8=CB: 'huang cancan'; 'IPv6 Operations'
=B3=AD=CB=CD: '=D1=EE=B9=FA=C1=BC'; wuym@gsta.com
=D6=F7=CC=E2: RE: [v6ops] new draft: =
draft-yang-v6ops-fast6-tools-selection-00
=20
Can-can, Guo-Liang, and YouMing,
It is very practical I-D.
One quick comment, the tern LSN has been changed back to CGN from WG =
behave,
which IETF will use.
You may want to correct it in next version of
http://tools.ietf.org/html/draft-yang-v6ops-fast6-pppoe-00
=20
We keep our promises with one another =A8C no matter what!
=20
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
=20
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of
huang cancan
Sent: Monday, May 23, 2011 5:29 AM
To: IPv6 Operations
Cc: =D1=EE=B9=FA=C1=BC; wuym@gsta.com
Subject: [v6ops] new draft: draft-yang-v6ops-fast6-tools-selection-00
=20
Dear All,
=20
We have just post a new ID of the analysis of tools selection for =
broadband
ISP. In the current stage,  NAT444, DS-LITE, 6RD and other transition
technologies have been well done, the ISP should select the most =
suitable
tool to meet the requirements of a typical broadband access network in =
the
real world regarding its network architecture, operation situation and
transition goals,etc. According to the mainstream broadband access =
network,
this draft focuses on analyzing the problems that may be encountered =
when
using various transitional technologies during the transition and =
finally
introduces a more systematic and operational proposal.

=20
Please find it out from following url:
http://tools.ietf.org/html/draft-yang-v6ops-fast6-tools-selection-00
=20
We'd like to have your kind review, and comments.
=20
Best wishes
=20
Cancan Huang

--Boundary_(ID_lw238KofZi1pkv03f6igqQ)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable


Guo-Liang,
It is a positive way to replace NAT444 with =
FAST6 with a, b, and c), and make the assumptions clear.
 
We keep our promises with one =
another =A8C no matter what!
 
Best =
Regards,
Tina TSOU
http://tinatsou.weebly.com/contact=
.html
 
From:=
 =
=D1=EE=B9=
=FA=C1=BC =
[mailto:yanggl@gsta.com] 
Sent: Monday, May 23, 2011 4:57 =
PM
To: 'Tina Tsou'; 'huang cancan'; 'IPv6 =
Operations'
Cc: wuym@gsta.com
Subject: =B4=F0=B8=
=B4: [v6ops] =
new draft: =
draft-yang-v6ops-fast6-tools-selection-00
 
Thank you very much, more comments are welcome. We hope to replace =
NAT444 with FAST6 in our transition solution, because NAT444 has its =
limitation. I think you can help us.^_^
 
 &nbs=
p;  =B4=CB=D6=C2
=BE=B4=C0=F1=
=A3=A1
 =
;
=D1=EE=B9=FA=
=C1=BC
Tel: =
020-38639615
Mobile: =
13316090336
MSN: yanggl@live.com
=

QQ: yanggl@189.cn
 
=B7=A2=BC=FE=C8=CB: Tina Tsou =
[mailto:tena@huawei.com] 
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C224=C8=D5 4:37
=CA=D5=BC=FE=C8=CB: 'huang cancan'; 'IPv6 =
Operations'
=B3=AD=CB=CD: '=D1=EE=B9=FA=C1=BC'; wuym@gsta.com
=D6=F7=CC=E2: RE: [v6ops] new draft: =
draft-yang-v6ops-fast6-tools-selection-00
 
Can-can, Guo-Liang, and YouMing,
It is very practical I-D.
One quick comment, the tern LSN has been changed back to CGN from WG =
behave, which IETF will use.
You may want to correct it in next version of
http:=
//tools.ietf.org/html/draft-yang-v6ops-fast6-pppoe-00
 
We keep our promises with one another =A8C no matter =
what!
 
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
huang cancan
Sent: Monday, May 23, 2011 5:29 =
AM
To: IPv6 Operations
Cc: =D1=EE=B9=FA=C1=BC; =
wuym@gsta.com
Subject: [v6ops] new draft: =
draft-yang-v6ops-fast6-tools-selection-00
 
Dear =
All,
 
We have just post a new ID of the analysis =
of tools selection for broadband ISP. In the current stage,  =
NAT444, DS-LITE, 6RD and other transition technologies have been =
well done, the ISP should select the most suitable tool to meet =
the requirements of a typical broadband access network in the real =
world regarding its network architecture, operation situation and =
transition goals,etc. According to the mainstream broadband access =
network, this draft focuses on analyzing the problems that may be =
encountered when using various transitional technologies during the =
transition and finally introduces a more systematic and operational =
proposal.

 
Please =
find it out from following url:
 
We'd =
like to have your kind review, and comments.
 
Best =
wishes
 
Cancan Huang
=

--Boundary_(ID_lw238KofZi1pkv03f6igqQ)--

From jasonlin.gz@gmail.com  Mon May 23 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 47EA5E0682 for ; Mon, 23 May 2011 18:43:13 -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 6SCFRsnYa021 for ; Mon, 23 May 2011 18:43:12 -0700 (PDT)
Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7624AE067B for ; Mon, 23 May 2011 18:43:12 -0700 (PDT)
Received: by pxi2 with SMTP id 2so3716056pxi.38 for ; Mon, 23 May 2011 18:43:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=oPWK14h29/Za3tIQU14iCc9QhIXDjmxdboO6Z++InJQ=; b=Cp/3e2IbKHdZrAHN4kZDhAXsN2G++2zylIjsP/O8/g00Ea5Cf0FPs/jlXvXlrmH76W Y5CEaaTxwh3c7CnNHlt2XjqMCcZK/CIlkjw2N3Onsdp9ZTHPazpnJDICaryS+riXA0Zw +AFJYVXFsE4Tj3PdJVoNmkZ9o7oyvsD3oqK3k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mWq3faeoQJ7do+q6VqadIpG9KaTEIqq1xzVyOgWPolmd0Ad+FEdyErdSra6oMv0h1m 46HsBZcgHs+k0gK/cCv7bs9N6LpyIChvas8oaFR0fnqIkquTK7IcvCmddOptNaWq2LxJ U/NZoIurhYp0/r7B915rjmj3PzXrMTgbAPO+A=
MIME-Version: 1.0
Received: by 10.68.63.9 with SMTP id c9mr2252394pbs.71.1306201391141; Mon, 23 May 2011 18:43:11 -0700 (PDT)
Received: by 10.68.62.200 with HTTP; Mon, 23 May 2011 18:43:11 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 24 May 2011 09:43:11 +0800
Message-ID: 
From: Jason Lin 
To: IPv6 Operations 
Content-Type: multipart/alternative; boundary=bcaec5396758ec94ad04a3fbb5bc
Subject: [v6ops] new draft: draft-yang-v6ops-fast6-pppoe-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, 24 May 2011 01:43:13 -0000

--bcaec5396758ec94ad04a3fbb5bc
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

We have submitted a new I-D:
http://tools.ietf.org/html/draft-yang-v6ops-fast6-pppoe-00.

It specifies an architecture for a broadband ISP that are transitioning to
IPv6.

Thank you for Tina's comment, next version will change "LSN" by "CGN".

We'd like to have your kind review, and comments.

Best Regards,

Jinyan Lin
2011-5-24

<<<
Internet Engineering Task Force                                  G. Yang
Internet-Draft                                                    J. Lin
Intended status: Informational                                    J. Tan
Expires: November 24, 2011                                 China Telecom
                                                            May 23, 2011


Fundamental Architecture of Services Provider's network Transitioning to
                  IPv6 (FAST6)-PPPoE Broadband Access
                    draft-yang-v6ops-fast6-pppoe-00

Abstract

   Although there have already been many transition solutions and
   technologies, it is still lack of a complete solution for large scale
   broadband ISPs based on the network architecture in the real world,
   with considering service providers' requirements and constraints.
   This document proposes a transitioning architecture, the FAST6, a
   fundamental architecture of service provider's broadband network with
   PPPoE access method that is transitioning to IPv6.  It is based on
   common broadband network architecture and providing transitioning
   solutions going through the whole transition period.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Terminologies  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Brief Description of ISP's Broadband Network . . . . . . . . .  5
     3.1.  Broadband Architecture . . . . . . . . . . . . . . . . . .  5
     3.2.  Network scale and model  . . . . . . . . . . . . . . . . .  6
     3.3.  ISP Requirements For IPv6 Transition . . . . . . . . . . .  7
     3.4.  Weaknesses of current transition technology  . . . . . . .  7
   4.  The FAST6 Architecture with L2 Access Network  . . . . . . . .  7
     4.1.  Distributed LSN (DLSN) Architecture  . . . . . . . . . . .  8
       4.1.1.  Architecture Description . . . . . . . . . . . . . . .  8
       4.1.2.  Scenario 1: Subscribers Access Legacy IPv4 BRAS  . . . 10
       4.1.3.  Scenario 2: Subscribers Access Updated or New
               Dual-Stack BRAS  . . . . . . . . . . . . . . . . . . . 11
       4.1.4.  Sharing Address between DLSNs  . . . . . . . . . . . . 12
     4.2.  Centralized LSN (CLSN) Architecture  . . . . . . . . . . . 12
       4.2.1.  Architecture Description . . . . . . . . . . . . . . . 12
       4.2.2.  Scenario 1: Subscribers Access Legacy IPv4 BRAS  . . . 14
       4.2.3.  Scenario 2: Subscribers Access Updated or New
               Dual-Stack BRAS  . . . . . . . . . . . . . . . . . . . 15
       4.2.4.  BRAS-to-CLSN Tunnel for private IPv4 traffic . . . . . 15
     4.3.  Recommendations for PPPoE Access Broadband ISP . . . . . . 16
   5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 17
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
>>>


-------------------------------------------

Jinyan Lin

China Telecom

Email: jasonlin.gz@gmail.com 

--bcaec5396758ec94ad04a3fbb5bc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi all,

<=
/font>




It specifies an architecture for a =
broadband ISP that are transitioning to IPv6.



Thank you for Tina's comment, n=
ext version will change "LSN" by "CGN".



We'd like =
to have your kind
review, and comments.

Best Regards,<=
/div>

Jinyan Lin
2011-5-24

<<<
Internet Engineering Task Force =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0G. Yang



Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0J. Lin
Intended s=
tatus: Informational =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0J. Tan
Expires: November 24, 2011 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 China Telecom



=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0May 23, 2011
=


Fundamental Architecture of Services Provider=
's network Transitioning to
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0IPv6 (FAST6)-PPPoE Broadband Access



=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-yang-v6ops-fast6-pppoe=
-00

Abstract

=A0=A0 Altho=
ugh there have already been many transition solutions and
=A0=A0 =
technologies, it is still lack of a complete solution for large scale



=A0=A0 broadband ISPs based on the network architecture in the real wo=
rld,
=A0=A0 with considering service providers' requirements =
and constraints.
=A0=A0 This document proposes a transitioning ar=
chitecture, the FAST6, a



=A0=A0 fundamental architecture of service provider's broadband ne=
twork with
=A0=A0 PPPoE access method that is transitioning to IP=
v6. =A0It is based on
=A0=A0 common broadband network architectur=
e and providing transitioning



=A0=A0 solutions going through the whole transition period.
=


Table of Contents

=
=A0=A0 1. =A0Introduction . . . . . . . . . . . . . . . . . . . . . . . . .=
 =A03



=A0=A0 =A0 1.1. =A0Requirements Language =A0. . . . . . . . . . . . . =
. . . . . =A03
=A0=A0 2. =A0Terminologies =A0. . . . . . . . . . =
. . . . . . . . . . . . . . =A03
=A0=A0 3. =A0Brief Description o=
f ISP's Broadband Network . . . . . . . . . =A05



=A0=A0 =A0 3.1. =A0Broadband Architecture . . . . . . . . . . . . . . =
. . . . =A05
=A0=A0 =A0 3.2. =A0Network scale and model =A0. . . =
. . . . . . . . . . . . . . =A06
=A0=A0 =A0 3.3. =A0ISP Requireme=
nts For IPv6 Transition . . . . . . . . . . . =A07



=A0=A0 =A0 3.4. =A0Weaknesses of current transition technology =A0. . =
. . . . . =A07
=A0=A0 4. =A0The FAST6 Architecture with L2 Access=
 Network =A0. . . . . . . . =A07
=A0=A0 =A0 4.1. =A0Distributed L=
SN (DLSN) Architecture =A0. . . . . . . . . . . =A08



=A0=A0 =A0 =A0 4.1.1. =A0Architecture Description . . . . . . . . . . =
. . . . . =A08
=A0=A0 =A0 =A0 4.1.2. =A0Scenario 1: Subscribers A=
ccess Legacy IPv4 BRAS =A0. . . 10
=A0=A0 =A0 =A0 4.1.3. =A0Scena=
rio 2: Subscribers Access Updated or New



=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 Dual-Stack BRAS =A0. . . . . . . . . . =
. . . . . . . . . 11
=A0=A0 =A0 =A0 4.1.4. =A0Sharing Address bet=
ween DLSNs =A0. . . . . . . . . . . . 12
=A0=A0 =A0 4.2. =A0Centr=
alized LSN (CLSN) Architecture =A0. . . . . . . . . . . 12



=A0=A0 =A0 =A0 4.2.1. =A0Architecture Description . . . . . . . . . . =
. . . . . 12
=A0=A0 =A0 =A0 4.2.2. =A0Scenario 1: Subscribers Acc=
ess Legacy IPv4 BRAS =A0. . . 14
=A0=A0 =A0 =A0 4.2.3. =A0Scenari=
o 2: Subscribers Access Updated or New



=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 Dual-Stack BRAS =A0. . . . . . . . . . =
. . . . . . . . . 15
=A0=A0 =A0 =A0 4.2.4. =A0BRAS-to-CLSN Tunnel=
 for private IPv4 traffic . . . . . 15
=A0=A0 =A0 4.3. =A0Recomme=
ndations for PPPoE Access Broadband ISP . . . . . . 16



=A0=A0 5. =A0Conclusions =A0. . . . . . . . . . . . . . . . . . . . . =
. . . . 17
=A0=A0 6. =A0Acknowledgements . . . . . . . . . . . . =
. . . . . . . . . . . 17
=A0=A0 7. =A0IANA Considerations =A0. . =
. . . . . . . . . . . . . . . . . . . 17



=A0=A0 8. =A0Security Considerations =A0. . . . . . . . . . . . . . . =
. . . . 17
=A0=A0 9. =A0References . . . . . . . . . . . . . . . =
. . . . . . . . . . . 17
=A0=A0 =A0 9.1. =A0Normative References =
. . . . . . . . . . . . . . . . . . . 17



=A0=A0 =A0 9.2. =A0Informative References . . . . . . . . . . . . . . =
. . . . 17
=A0=A0 Authors' Addresses . . . . . . . . . . . . =
. . . . . . . . . . . . 19
>>>

=




-------------------------------------------



Jinyan Lin



China Telecom



Email: jasonlin.gz@gmail.com






--bcaec5396758ec94ad04a3fbb5bc--

From internet-drafts@ietf.org  Tue May 24 00:56: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 A49AAE06FA; Tue, 24 May 2011 00:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.573
X-Spam-Level: 
X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 0h7RANI9I629; Tue, 24 May 2011 00:56:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1532AE06F5; Tue, 24 May 2011 00:56:32 -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.54
Message-ID: <20110524075632.3521.23377.idtracker@ietfa.amsl.com>
Date: Tue, 24 May 2011 00:56:32 -0700
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-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, 24 May 2011 07:56:32 -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           : Request to move Connection of IPv6 Domains via IPv4 Clou=
ds (6to4) to Historic status
	Author(s)       : Ole Troan
	Filename        : draft-ietf-v6ops-6to4-to-historic-03.txt
	Pages           : 7
	Date            : 2011-05-24

   Experience with the "Connection of IPv6 Domains via IPv4 Clouds
   (6to4)" IPv6 transitioning mechanism has shown that the mechanism is
   unsuitable for widespread deployment and use in the Internet.  This
   document requests that RFC3056 and the companion document "An Anyca=
st
   Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-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-6to4-to-historic-03.txt

From iamyanggl@gmail.com  Mon May 23 18:37: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 86107E07EB for ; Mon, 23 May 2011 18:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.297
X-Spam-Level: ****
X-Spam-Status: No, score=4.297 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ0gbCTR34uy for ; Mon, 23 May 2011 18:37:32 -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 8698CE06DF for ; Mon, 23 May 2011 18:37:32 -0700 (PDT)
Received: by pvh18 with SMTP id 18so3795979pvh.31 for ; Mon, 23 May 2011 18:37:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=YxDyfnidNnMihQfZ+KJt76UlyqgyUAesH4UoazveE4I=; b=VDBswRXOmu148tOhthUP9a2ad2HI14rn/HhFrYxDahzPLOzjtd9F6xvAd3HH6II/dh Gez2TFMHu5+wrIGxg4EHJB/475UA2WVxujHUVeGPG5Za5XRSwMAwr11mBILSK3yW4Yjk hDL2KZiNtCR92VO/kVpeGuKo00Enb3TsfuduI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=m7x4E+R0rBkbtNLo3GEOVAgXkWGiq9OH15GMyiCnMKikhJIalFxA0WaCxTOl3zS3+R e7syzNbaSafhNEWWH5XqVUHQk6COQcAlnNQ+dOSalgYZsfdtzYpwCWTfqLesfaMmFC5/ ZykkTm/WuMKuFUMzFGx+nMuGmVEknOr6m3lY4=
Received: by 10.68.55.5 with SMTP id n5mr2413545pbp.426.1306201052179; Mon, 23 May 2011 18:37:32 -0700 (PDT)
Received: from LocalHost ([182.144.28.121]) by mx.google.com with ESMTPS id m10sm4684842pbf.8.2011.05.23.18.36.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2011 18:37:29 -0700 (PDT)
From: "Yang Guoliang" 
To: "'Tina Tsou'" , "'huang cancan'" , "'IPv6 Operations'" 
References:  <008b01cc1989$1dcd75c0$59686140$@com> <000601cc19a5$1faecf30$5f0c6d90$@com> <013f01cc19a5$e8514440$b8f3ccc0$@com>
In-Reply-To: <013f01cc19a5$e8514440$b8f3ccc0$@com>
Date: Tue, 24 May 2011 09:36:54 +0800
Message-ID: <003d01cc19b3$18e6efd0$4ab4cf70$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01CC19F6.270A2FD0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcwZRXQ1GS5HBX3EQyCkcoFoObGYZwAQ0kdAAAYrTBAAAQ9WcAADUgeg
Content-language: zh-cn
X-Mailman-Approved-At: Tue, 24 May 2011 03:59:29 -0700
Cc: wuym@gsta.com
Subject: [v6ops] =?gb2312?b?tPC4tDogICBuZXcgZHJhZnQ6IGRyYWZ0LXlhbmctdjZv?= =?gb2312?b?cHMtZmFzdDYtdG9vbHMtc2VsZWN0aW9uLTAw?=
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 May 2011 01:37:33 -0000

ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£

------=_NextPart_000_003E_01CC19F6.270A2FD0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

Thanks, next version is coming soon.

=20

Best regards.

=20

Yang Guoliang

Tel: 86-20-38639615

Mobile: 86-13316090336

MSN: yanggl@live.com =20

=20

=B7=A2=BC=FE=C8=CB: Tina Tsou [mailto:tena@huawei.com]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C224=C8=D5 8:03
=CA=D5=BC=FE=C8=CB: '=D1=EE=B9=FA=C1=BC'; 'huang cancan'; 'IPv6 =
Operations'
=B3=AD=CB=CD: wuym@gsta.com
=D6=F7=CC=E2: RE: [v6ops] new draft: =
draft-yang-v6ops-fast6-tools-selection-00

=20

Guo-Liang,

It is a positive way to replace NAT444 with FAST6 with a, b, and c), and
make the assumptions clear.

=20

We keep our promises with one another =A8C no matter what!

=20

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

=20

From: =D1=EE=B9=FA=C1=BC [mailto:yanggl@gsta.com]=20
Sent: Monday, May 23, 2011 4:57 PM
To: 'Tina Tsou'; 'huang cancan'; 'IPv6 Operations'
Cc: wuym@gsta.com
Subject: =B4=F0=B8=B4: [v6ops] new draft: =
draft-yang-v6ops-fast6-tools-selection-00

=20

Thank you very much, more comments are welcome. We hope to replace =
NAT444
with FAST6 in our transition solution, because NAT444 has its =
limitation. I
think you can help us.^_^

=20

    =B4=CB=D6=C2

=BE=B4=C0=F1=A3=A1

=20

=D1=EE=B9=FA=C1=BC

Tel: 020-38639615

Mobile: 13316090336

MSN: yanggl@live.com =20

QQ: yanggl@189.cn

=20

=B7=A2=BC=FE=C8=CB: Tina Tsou [mailto:tena@huawei.com]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA5=D4=C224=C8=D5 4:37
=CA=D5=BC=FE=C8=CB: 'huang cancan'; 'IPv6 Operations'
=B3=AD=CB=CD: '=D1=EE=B9=FA=C1=BC'; wuym@gsta.com
=D6=F7=CC=E2: RE: [v6ops] new draft: =
draft-yang-v6ops-fast6-tools-selection-00

=20

Can-can, Guo-Liang, and YouMing,

It is very practical I-D.

One quick comment, the tern LSN has been changed back to CGN from WG =
behave,
which IETF will use.

You may want to correct it in next version of

http://tools.ietf.org/html/draft-yang-v6ops-fast6-pppoe-00

=20

We keep our promises with one another =A8C no matter what!

=20

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of
huang cancan
Sent: Monday, May 23, 2011 5:29 AM
To: IPv6 Operations
Cc: =D1=EE=B9=FA=C1=BC; wuym@gsta.com
Subject: [v6ops] new draft: draft-yang-v6ops-fast6-tools-selection-00

=20

Dear All,

=20

We have just post a new ID of the analysis of tools selection for =
broadband
ISP. In the current stage,  NAT444, DS-LITE, 6RD and other transition
technologies have been well done, the ISP should select the most =
suitable
tool to meet the requirements of a typical broadband access network in =
the
real world regarding its network architecture, operation situation and
transition goals,etc. According to the mainstream broadband access =
network,
this draft focuses on analyzing the problems that may be encountered =
when
using various transitional technologies during the transition and =
finally
introduces a more systematic and operational proposal.

=20

Please find it out from following url:

http://tools.ietf.org/html/draft-yang-v6ops-fast6-tools-selection-00

=20

We'd like to have your kind review, and comments.

=20

Best wishes

=20

Cancan Huang


------=_NextPart_000_003E_01CC19F6.270A2FD0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable
















Thanks, next version is coming =
soon.



 






Best =
regards.



 



Yang =
Guoliang



Tel: =
86-20-38639615



Mobile: =
86-13316090336



MSN: yanggl@live.com






 









=B7=A2=BC=FE=C8=CB: Tina Tsou [mailto:tena@huawei.com] 

=B7=A2=CB=CD=CA=B1=BC=
=E4: =
2011=C4=EA5=D4=C224=C8=D5 8:03

=CA=D5=BC=FE=C8=CB: '=D1=EE=B9=FA=C1=BC'; 'huang cancan'; 'IPv6 Operations'

=B3=AD=CB=CD: =
wuym@gsta.com

=D6=F7=CC=E2: =
RE: [v6ops] new
draft: =
draft-yang-v6ops-fast6-tools-selection-00









 



Guo-Liang,



It is a positive way to replace NAT444 with FAST6 with a, b, and c), and make the assumptions =
clear.






 



We keep our promises with one another =A8C no matter =
what!



 



Best Regards,



Tina TSOU



http://tinatsou.weebly.com/contact.html<=
/p>





 









From: =D1=EE=B9=FA=C1=BC [mailto:yanggl@gsta.com] 

Sent: Monday, May 23, 2011 4:57 PM

To: 'Tina Tsou'; 'huang cancan'; 'IPv6 Operations'

Cc: wuym@gsta.com

Subject: =B4=F0=B8=B4: [v6ops]
new draft: =
draft-yang-v6ops-fast6-tools-selection-00









 



Thank you very much, more comments are welcome. We hope =
to
replace NAT444 with FAST6 in our transition solution, because NAT444 has =
its
limitation. I think you can help us.^_^



 












 &nbs=
p; 
=B4=CB=D6=C2=




=BE=B4=C0=F1=
=A3=A1



 =
;



=D1=EE=B9=FA=
=C1=BC



Tel: =
020-38639615



Mobile: =
13316090336



MSN: yanggl@live.com
=



QQ: =
yanggl@189.cn












 









=B7=A2=BC=FE=C8=CB: Tina Tsou [mailto:tena@huawei.com] 

=B7=A2=CB=CD=CA=B1=BC=
=E4: =
2011=C4=EA5=D4=C224=C8=D5 4:37

=CA=D5=BC=FE=C8=CB: 'huang cancan';
'IPv6 Operations'

=B3=AD=CB=CD: =
'=D1=EE=B9=FA=C1=BC'; wuym@gsta.com

=D6=F7=CC=E2: =
RE: [v6ops] new
draft: =
draft-yang-v6ops-fast6-tools-selection-00









 



Can-can, Guo-Liang, and YouMing,



It is very practical I-D.



One quick comment, the tern LSN has been changed back to =
CGN
from WG behave, which IETF will use.



You may want to correct it in next version =
of



http:=
//tools.ietf.org/html/draft-yang-v6ops-fast6-pppoe-00



 



We keep our promises with one another =A8C no matter =
what!



 



Best Regards,



Tina TSOU



http://tinatsou.weebly.com/contact.html<=
/p>


 






From: v6ops-bounces@ietf.org
[mailto:v6ops-bounces@ietf.org] On Behalf Of huang cancan

Sent: Monday, May 23, 2011 5:29 AM

To: IPv6 Operations

Cc: =D1=EE=B9=FA=C1=BC;
wuym@gsta.com

Subject: [v6ops] new draft: =
draft-yang-v6ops-fast6-tools-selection-00






 



Dear All,



 



We have just post a =
new ID of the
analysis of tools selection for broadband ISP. In the current =
stage, 
NAT444, DS-LITE, 6RD and other transition technologies have been
well done, the ISP should select the most suitable tool to meet
the requirements of a typical broadband access network in the real =
world
regarding its network architecture, operation situation and transition
goals,etc. According to the mainstream broadband access network, =
this
draft focuses on analyzing the problems that may be encountered when =
using
various transitional technologies during the transition and finally =
introduces
a more systematic and operational proposal.



 






Please find it out from =
following url:











 






We'd like to have your kind =
review, and
comments.



 






Best =
wishes









 









Cancan =
Huang












------=_NextPart_000_003E_01CC19F6.270A2FD0--


From marc.lampo@eurid.eu  Tue May 24 04:24: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 C2863E071E for ; Tue, 24 May 2011 04:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.854
X-Spam-Level: 
X-Spam-Status: No, score=-7.854 tagged_above=-999 required=5 tests=[AWL=0.004,  BAYES_00=-2.599, MISSING_HEADERS=1.292, MSGID_MULTIPLE_AT=1.449, 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 CIcd0ZX1crsA for ; Tue, 24 May 2011 04:24:13 -0700 (PDT)
Received: from barra.eurid.eu (mx.eurid.eu [212.190.206.103]) by ietfa.amsl.com (Postfix) with ESMTP id C7C0EE0711 for ; Tue, 24 May 2011 04:24:12 -0700 (PDT)
X-ASG-Debug-ID: 1306236251-03694916395d0f0001-b2NLKh
Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id RMumKXwVTxt8BS68 for ; Tue, 24 May 2011 13:24:11 +0200 (CEST)
X-Barracuda-Envelope-From: marc.lampo@eurid.eu
X-ASG-Whitelist: Client
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 84D2FE407A for ; Tue, 24 May 2011 13:15:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at techmail.eurid.eu
Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYBs7wrKW+6M for ; Tue, 24 May 2011 13:15:46 +0200 (CEST)
Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 73768E4056 for ; Tue, 24 May 2011 13:15:46 +0200 (CEST)
From: "Marc Lampo" 
Cc: 
References: <20110524075632.3521.23377.idtracker@ietfa.amsl.com>
In-Reply-To: <20110524075632.3521.23377.idtracker@ietfa.amsl.com>
Date: Tue, 24 May 2011 13:15:46 +0200 (CEST)
X-ASG-Orig-Subj: RE: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-03.txt
Message-ID: <010201cc1a05$1a95b800$4fc12800$@lampo@eurid.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraConnectorForOutlook/5.0.3064.18)
Thread-Index: AcwZ6Bhvkf9lKTUsS8y9QlkKwqhzUwAHC+ag
Content-Language: en-za
X-Originating-IP: [172.20.1.130]
X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121]
X-Barracuda-Start-Time: 1306236251
X-Barracuda-URL: http://172.20.1.190:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at eurid.eu
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-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, 24 May 2011 11:24:14 -0000

The document claims :
"There would appear to be no evidence of any substantial deployment of
   the variant of 6to4 described in [RFC3056]."
(first sentence of the Introduction)

If my Windows 7 based workstation finds a public IP address on one of its 
interfaces, it automatically assigns a 6to4 IPv6 address to that interface.
Forgive my ignorance, with Windows, but if the behaviour I see is default on 
Windows 7,
I daresay there must be quite a bit potential users of 6to4 tunneling, out 
there.

I did hear Brian Carpenters excellent talk on 6to4 defects, in Prague,
and there is certainly room for improvement.

Kind regards,

Marc Lampo


-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: 24 May 2011 09:57 AM
To: i-d-announce@ietf.org
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-03.txt

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           : Request to move Connection of IPv6 Domains via IPv4 
Clouds (6to4) to Historic status
	Author(s)       : Ole Troan
	Filename        : draft-ietf-v6ops-6to4-to-historic-03.txt
	Pages           : 7
	Date            : 2011-05-24

   Experience with the "Connection of IPv6 Domains via IPv4 Clouds
   (6to4)" IPv6 transitioning mechanism has shown that the mechanism is
   unsuitable for widespread deployment and use in the Internet.  This
   document requests that RFC3056 and the companion document "An 
Anycast
   Prefix for 6to4 Relay Routers" RFC3068 are moved to historic status.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-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-6to4-to-historic-03.txt


From nick@inex.ie  Tue May 24 05:20: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 C6903E068D for ; Tue, 24 May 2011 05:20: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 I1yEsFAZIyGE for ; Tue, 24 May 2011 05:20:27 -0700 (PDT)
Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3C250E067C for ; Tue, 24 May 2011 05:20:25 -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 p4OCJm9B002721 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 May 2011 13:19:49 +0100 (IST) (envelope-from nick@inex.ie)
Message-ID: <4DDBA264.80908@inex.ie>
Date: Tue, 24 May 2011 13:19:48 +0100
From: Nick Hilliard 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b13pre) Gecko/20110314 Thunderbird/3.3a3
MIME-Version: 1.0
To: Marc Lampo 
References: <20110524075632.3521.23377.idtracker@ietfa.amsl.com> <010201cc1a05$1a95b800$4fc12800$@lampo@eurid.eu>
In-Reply-To: <010201cc1a05$1a95b800$4fc12800$@lampo@eurid.eu>
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; format=flowed
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-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, 24 May 2011 12:20:27 -0000

On 24/05/2011 12:15, Marc Lampo wrote:
> The document claims :
> "There would appear to be no evidence of any substantial deployment of
>     the variant of 6to4 described in [RFC3056]."
> (first sentence of the Introduction)
>
> If my Windows 7 based workstation finds a public IP address on one of its
> interfaces, it automatically assigns a 6to4 IPv6 address to that interface.
> Forgive my ignorance, with Windows, but if the behaviour I see is default on
> Windows 7,

http://www.ietf.org/mail-archive/web/v6ops/current/msg08580.html

Nick


From ichiroumakino@gmail.com  Tue May 24 05:20: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 13985E073E for ; Tue, 24 May 2011 05:20: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=[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 dYKFV8O+VIhA for ; Tue, 24 May 2011 05:20:53 -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 4F312E073C for ; Tue, 24 May 2011 05:20:53 -0700 (PDT)
Received: by bwz13 with SMTP id 13so6452225bwz.31 for ; Tue, 24 May 2011 05:20:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Ud6kM5NLFOwEHm3VHd+M+usjvtr8KhBlz/vhg7YUUAU=; b=kuWcfWt6CItAxZMdx9wIqRQhV11yCOwGWkdZqDzXdL3OQLc1ZFFi48AjMx9BnGIZ/6 5z26wihTHZ5kSKP6I/X1i89Tpy0pMRpR0MIo47OIbxMyrAbHPGf7CWNaC01GWJVY88es hYSBy0WSWc6cmd2ON7os7n8R+wGj/52RErMvY=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=u83UeasDBFw0R877qTlB9Rkmgjvigr4ZNWsjQaLCZhwwju3q+SiA3haT6RbIKWKFSq 68B+vH8+uHJq1ca1TjLw8+8b1lqZ6SCm45BnOa87f97lUN0DTYAfcfv/HT5UXNC2oAf6 lkY0HDlZ5q8uG9L9Q46YVq6C6B4AKYOPFWwDg=
Received: by 10.204.80.28 with SMTP id r28mr3220264bkk.46.1306239652017; Tue, 24 May 2011 05:20:52 -0700 (PDT)
Received: from [10.61.97.210] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id x6sm4525570bkv.0.2011.05.24.05.20.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2011 05:20:51 -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: <010201cc1a05$1a95b800$4fc12800$@lampo@eurid.eu>
Date: Tue, 24 May 2011 14:20:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7135D776-0581-4F04-84CC-EDC31369C02F@employees.org>
References: <20110524075632.3521.23377.idtracker@ietfa.amsl.com> <010201cc1a05$1a95b800$4fc12800$@lampo@eurid.eu>
To: Marc Lampo 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-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, 24 May 2011 12:20:54 -0000

Marc,

> The document claims :
> "There would appear to be no evidence of any substantial deployment of
>   the variant of 6to4 described in [RFC3056]."
> (first sentence of the Introduction)
>=20
> If my Windows 7 based workstation finds a public IP address on one of =
its=20
> interfaces, it automatically assigns a 6to4 IPv6 address to that =
interface.
> Forgive my ignorance, with Windows, but if the behaviour I see is =
default on=20
> Windows 7,
> I daresay there must be quite a bit potential users of 6to4 tunneling, =
out=20
> there.

I could ask you to check the archives as this has already been =
discussed.
to save you trawling through a few hundred messages; what you see is =
3068 deployment not the managed deployment model described in 3056.

cheers,
Ole=

From fred@cisco.com  Tue May 24 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 69A04E06AF for ; Tue, 24 May 2011 06:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.547
X-Spam-Level: 
X-Spam-Status: No, score=-109.547 tagged_above=-999 required=5 tests=[AWL=1.052, 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 2K1J3Qnl-3e1 for ; Tue, 24 May 2011 06:55:01 -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 99F19E068D for ; Tue, 24 May 2011 06:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=130; q=dns/txt; s=iport; t=1306245301; x=1307454901; h=date:from:message-id:to:subject:cc; bh=ULC6ZAxWwEUgG+jxRRuTb4oCiWOxh7yhyeogNNuIh1c=; b=TnOghOa3Ofoos4qKKPrPtNz3RJ4Z7PtuM/AxBnKq80UAHJiaSgpeNKi1 JLfTb+mnLrlg5vDqeeDGkGj9/Mbs0in/4fBrdZuc4YKehWiyPJQ7RqmnJ I5t5MYd+Nin0BH/dAepUN6eL4vY3pNP6Id83zybQYHNYg/wZbmB+EtLvr I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvAHAGu4202rRDoJ/2dsb2JhbACYJAEBjgR3qzudeoYbBIZWmGo
X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="453310498"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 24 May 2011 13:55:00 +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 p4ODt08r012975; Tue, 24 May 2011 13:55:00 GMT
Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id p4ODt0j23372; Tue, 24 May 2011 06:55:00 -0700 (PDT)
Date: Tue, 24 May 2011 06:55:00 -0700 (PDT)
From: 
Message-Id: <201105241355.p4ODt0j23372@ftpeng-update.cisco.com>
To: v6ops@ietf.org
Cc: draft-yang-v6ops-fast6-pppoe@tools.ietf.org
Subject: [v6ops] new draft: draft-yang-v6ops-fast6-pppoe-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, 24 May 2011 13:55:02 -0000

A new draft has been posted, at http://tools.ietf.org/html/draft-yang-v6ops-fast6-pppoe. Please take a look at it and comment.

From prondou@gmail.com  Tue May 24 08:47: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 96FC2E0752; Tue, 24 May 2011 08:47:02 -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 7FEvUsPEB-8g; Tue, 24 May 2011 08:47:02 -0700 (PDT)
Received: from mailrelay011.isp.belgacom.be (mailrelay011.isp.belgacom.be [195.238.6.178]) by ietfa.amsl.com (Postfix) with ESMTP id 81637E0755; Tue, 24 May 2011 08:47:01 -0700 (PDT)
X-Belgacom-Dynamic: yes
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIBAEDR201R95HQ/2dsb2JhbAAMhFGrNK9GPIcdN4hngSuDaYEHBJAfjwM
Received: from 208.145-247-81.adsl-dyn.isp.belgacom.be (HELO [192.168.1.40]) ([81.247.145.208]) by relay.skynet.be with ESMTP; 24 May 2011 17:46:56 +0200
Message-ID: <4DDBD2F1.3020704@gmail.com>
Date: Tue, 24 May 2011 17:46:57 +0200
From: Pierre Rondou 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: Eric Dumazet 
References: <4DC1FACC.4080204@gmail.com> <1306248975.3026.47.camel@edumazet-laptop>
In-Reply-To: <1306248975.3026.47.camel@edumazet-laptop>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: v6ops@ietf.org, behave@ietf.org, Cyril Soldani , netfilter-devel@vger.kernel.org, guy.leduc@ulg.ac.be
Subject: Re: [v6ops] Netfilter Module for NAT IVI available
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 May 2011 15:47:02 -0000

Le 24/05/11 16:56, Eric Dumazet a écrit :
> Le jeudi 05 mai 2011 à 03:18 +0200, Pierre Rondou a écrit :
>    
>> Hello everybody,
>>
>> I'm currently a student at the University of Liège. As part of my master
>> thesis, I have to develop a Linux kernel module for IVI (
>> http://datatracker.ietf.org/doc/rfc6219/ ).
>>
>> I now consider my module as finished (i.e, all functionalities are
>> implemented) and publish it.
>>
>> It is available on sourceforge:
>>
>> http://sourceforge.net/projects/nativi/
>>
>> Feel free to test it and report to me any bug, bad implementation,
>> error, ...
>>
>> If you believe that this module can be included is the Linux Kernel or
>> in the Xtables-addons framework, I'll be glad and will help you in this
>> task.
>>
>>
>> I have tested my module inside the Xtables-addons framework (version
>> 1.32) on a debian squeeze (6.0.1) linux with a 2.6.32-5  kernel (i686).
>>
>> Because of the lack of "EXPORT_SYMBOL" in the kernel, I had to
>> copy-paste several functions from the kernel into the
>> nativi_kernel_code.c file in order to use some features already
>> available in the kernel (ip_finish_output, ip6_output, icmp_send).
>>
>> Documentation is provided in the source code, if you have any question
>> don't hesitate to ask me.
>>
>>      
> Hi Pierre
>
> 1) Are you sure netfilter is the right place for this IVI feature ?
>     (fact that you had to copy/paste ~1300 lines of code from kernel
> might show that this would be better to use a module hooked into
> forwarding stack ?)
>    
I used Xtables to produce my module, fact is that I was (and still am) a 
kernel nooby, Xtables seemed to a be good way to produce this code.
I'm not sure to what you're refering about, are you suggesting I should 
have developed the module directly into the kernel?

> 2) How this can integrate a {conntrack enabled} firewall ?
>
>    

I can't ... It's a drawback of the module. The fact is that I only have 
found a very little documentation about conntrack code, so I dropped the 
idea of dealing with it.
But it shouldn't be difficult to update the conntrack for a kernel pro I 
guess ;-)

Regards,

Pierre

From john.mann@monash.edu  Tue May 24 14:12: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 9975BE0792 for ; Tue, 24 May 2011 14:12:32 -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, 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 iBSmJOdEPJul for ; Tue, 24 May 2011 14:12:31 -0700 (PDT)
Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 68A6FE0786 for ; Tue, 24 May 2011 14:12:31 -0700 (PDT)
Received: from mail-vw0-f54.google.com ([209.85.212.54]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTdwfPp3v4RMaweDXXpW5tEwEkY8Lxecf@postini.com; Tue, 24 May 2011 14:12:31 PDT
Received: by vws18 with SMTP id 18so7137660vws.41 for ; Tue, 24 May 2011 14:12:30 -0700 (PDT)
Received: by 10.52.178.98 with SMTP id cx2mr4203855vdc.91.1306271549089; Tue, 24 May 2011 14:12:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.164.132 with HTTP; Tue, 24 May 2011 14:12:09 -0700 (PDT)
In-Reply-To: 
References: 
From: "John Mann (ITS)" 
Date: Wed, 25 May 2011 07:12:09 +1000
Message-ID: 
To: "Templin, Fred L" 
Content-Type: multipart/alternative; boundary=20cf3071cd0ca9e96004a40c0b1e
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 May 2011 21:12:32 -0000

--20cf3071cd0ca9e96004a40c0b1e
Content-Type: text/plain; charset=ISO-8859-1

Fred,

I like ISATAP and your draft.

But I'm not sure about
---
9. Alternative Approaches
*
*
...
IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320]
are a tribute to those in all walks of life who serve with dignity
and honor for the benefit of others.
---

a) it seems out of place in that it doesn't discuss the method used or
service provided by these protocols.
b) is it a round-about way of praising yourself in that you are the author
of those protocols, and of this draft?

======
Also in http://tools.ietf.org/html/draft-templin-v6ops-isops-05#section-9
the text "[RFC4554]" doesn't web-link to  http://tools.ietf.org/html/rfc4554
But I can't tell if this is a original markup problem, or draft->html
converter problem.

Thanks,
    John

On 24 May 2011 07:16, Templin, Fred L  wrote:

> Folks,
>
> I am done tweaking this document now. Would appreciate
> input, especially from those who have expressed interest
> in ISATAP over the past several weeks.
>
> 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: Monday, May 23, 2011 12:59 PM
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-templin-v6ops-isops-05.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>        Title           : Operational Guidance for IPv6 Deployment in IPv4
> Sites using ISATAP
>        Author(s)       : Fred L. Templin
>        Filename        : draft-templin-v6ops-isops-05.txt
>        Pages           : 26
>        Date            : 2011-05-23
>
>   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.  It is also
>   expected that more and more IPv6-only devices will be deployed within
>   the site over time.  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-05.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-05.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
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--20cf3071cd0ca9e96004a40c0b1e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Fred,

I like ISATAP and your draft.

=

But I'm not sure about
---
9.  Alternative Appro=
aches



=

...
IRON [RFC6179], RANGER [RFC5720], VET [RFC5=
558] and SEAL [RFC5320]


are a tribute to those in all walks of life who serve with dignity
   an=
d honor for the benefit of others.
---

a) =
it seems out of place in that it doesn't discuss the method used or ser=
vice provided by these protocols.



b) is it a round-about way of praising yourself in that you are the au=
thor of those protocols, and of this draft?

=3D=3D=
=3D=3D=3D=3D


the text "[RFC4554]" doesn't web-link to =A0http://tools.ietf.org/html/rfc455=
4



But I can't tell if this is a original markup problem, or draft-&g=
t;html converter problem.

Thanks,
=A0 =
=A0 John



On 24 May 2011 07:16, Templin, Fred L <Fred.L.Templin@boeing.com> wrot=
e:


Folks,



I am done tweaking this document now. Would appreciate

input, especially from those who have expressed interest

in ISATAP over the past several weeks.



Thanks - Fred

fred.l.templin@boeing.com<=
br>


-----Original Message-----

From: i-d-announce-bounces=
@ietf.org [mailto:i-d-=
announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org



Sent: Monday, May 23, 2011 12:59 PM

To: i-d-announce@ietf.org

Subject: I-D Action: draft-templin-v6ops-isops-05.txt



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



 =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Operational Guidance for IPv6 D=
eployment in IPv4 Sites using ISATAP

 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Fred L. Templin

 =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-templin-v6ops-isops-05.txt<=
br>
 =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 26

 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-05-23



 =A0 Many end user sites in the Internet today still have predominantly

 =A0 IPv4 internal infrastructures. =A0These sites range in size from small=


 =A0 home/office networks to large corporate enterprise networks, but

 =A0 share the commonality that IPv4 continues to provide satisfactory

 =A0 internal routing and addressing services for most applications. =A0As<=
br>
 =A0 more and more IPv6-only services are deployed in the Internet,

 =A0 however, end user devices within such sites will increasingly require<=
br>
 =A0 at least basic IPv6 functionality for external access. =A0It is also
 =A0 expected that more and more IPv6-only devices will be deployed within<=
br>
 =A0 the site over time. =A0This document therefore provides operational
 =A0 guidance for deployment of IPv6 within predominantly IPv4 sites using<=
br>
 =A0 the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).





A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-templin-v=
6ops-isops-05.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-v6o=
ps-isops-05.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

_______________________________________________

v6ops mailing list

v6ops@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/v6ops





--20cf3071cd0ca9e96004a40c0b1e--

From Fred.L.Templin@boeing.com  Tue May 24 15:07: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 0435CE07C4 for ; Tue, 24 May 2011 15:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.212
X-Spam-Level: 
X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 DuAnwzzPC0WD for ; Tue, 24 May 2011 15:07:07 -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 01ACFE07A7 for ; Tue, 24 May 2011 15:07:06 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4OM74QU005528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 May 2011 17:07:04 -0500 (CDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4OM73SD004972; Tue, 24 May 2011 17:07:03 -0500 (CDT)
Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4OM72wa004937 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 24 May 2011 17:07:03 -0500 (CDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 24 May 2011 15:07:02 -0700
From: "Templin, Fred L" 
To: "John Mann (ITS)" 
Date: Tue, 24 May 2011 15:07:00 -0700
Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment in IPv4 Sitesusing ISATAP
Thread-Index: AcwaV0yNvktUcb7/Rnax1zqxY2DNSQABryzg
Message-ID: 
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_E1829B60731D1740BB7A0626B4FAF0A65C6A6C96A3XCHNW01Vnwnos_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in IPv4 Sitesusing ISATAP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 May 2011 22:07:08 -0000

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

Hi John,

Please believe me when I say that it is not a round-about way of praising
myself - quite to the contrary, I was trying to be respectful of others. Th=
ese
technologies are however alternative approaches that could be used in the
same use cases as ISATAP, and I have also co-authored a RANGER
Scenarios document [RFC6139] that shows how this is true.

Perhaps it would be acceptable to just list the technologies under Alternat=
ive
Approaches, but delete the non-technical phrasing that caught your attentio=
n?

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

________________________________
From: John Mann (ITS) [mailto:john.mann@monash.edu]
Sent: Tuesday, May 24, 2011 2:12 PM
To: Templin, Fred L
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in IPv4 Sites=
using ISATAP

Fred,

I like ISATAP and your draft.

But I'm not sure about
---
9. Alternative Approaches

...
IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320]
are a tribute to those in all walks of life who serve with dignity
and honor for the benefit of others.
---

a) it seems out of place in that it doesn't discuss the method used or serv=
ice provided by these protocols.
b) is it a round-about way of praising yourself in that you are the author =
of those protocols, and of this draft?

=3D=3D=3D=3D=3D=3D
Also in http://tools.ietf.org/html/draft-templin-v6ops-isops-05#section-9
the text "[RFC4554]" doesn't web-link to  http://tools.ietf.org/html/rfc455=
4
But I can't tell if this is a original markup problem, or draft->html conve=
rter problem.

Thanks,
    John

On 24 May 2011 07:16, Templin, Fred L > wrote:
Folks,

I am done tweaking this document now. Would appreciate
input, especially from those who have expressed interest
in ISATAP over the past several weeks.

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: Monday, May 23, 2011 12:59 PM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-templin-v6ops-isops-05.txt

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

       Title           : Operational Guidance for IPv6 Deployment in IPv4 S=
ites using ISATAP
       Author(s)       : Fred L. Templin
       Filename        : draft-templin-v6ops-isops-05.txt
       Pages           : 26
       Date            : 2011-05-23

  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.  It is also
  expected that more and more IPv6-only devices will be deployed within
  the site over time.  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-05.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-05.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
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


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







Hi John,


 


Please believe me when I say that it is not a roun=
d-about=20
way of praising


myself - quite to the contrary, I was trying to be=
=20
respectful of others. These


technologies are however alternative approaches th=
at=20
could be used in the


same use cases as ISATAP, and I have also=20
co-authored a RANGER 


Scenarios document [RFC6139] that shows how =
this is=20
true.


 


Perhaps it would be acceptable to just list the=20
technologies under Alternative


Approaches, but delete the non-technical phrasing =
that=20
caught your attention?


 


Thanks - Fred


fred.l.templin@boeing.com




  

  

  From: John Mann (ITS)=20
  [mailto:john.mann@monash.edu] 
Sent: Tuesday, May 24, 2011 2:12=
=20
  PM
To: Templin, Fred L
Cc:=20
  v6ops@ietf.org
Subject: Re: [v6ops] Operational Guidance for IP=
v6=20
  Deployment in IPv4 Sitesusing ISATAP


  
Fred,
  


  
I like ISATAP and your draft.

  


  
But I'm not sure about

  
---

  
9. Alternative Approaches

...
  
IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320]are=20
  a tribute to those in all walks of life who serve with dignity
and hon=
or=20
  for the benefit of others.

  
---

  


  
a) it seems out of place in that it doesn't discuss the method used =
or=20
  service provided by these protocols.

  
b) is it a round-about way of praising yourself in that you are the=
=20
  author of those protocols, and of this draft?

  


  
=3D=3D=3D=3D=3D=3D

  
Also in http://tools.ietf.org/html/draft-templin-v6ops-isops-05#section-9
  
the text "[RFC4554]" doesn't web-link=
 to=20
   http://tools.ietf.org/html/rf=
c4554

  
But I can't tell if this is a original markup problem, or draft->=
html=20
  converter problem.

  


  
Thanks,

  
    John

  


  

  
On 24 May 2011 07:16, Templin, Fred L <Fred.L.Templin@boeing.com&g=
t;=20
  wrote:

  
Folks,

I=20
    am done tweaking this document now. Would appreciate
input, especial=
ly=20
    from those who have expressed interest
in ISATAP over the past sever=
al=20
    weeks.

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


-----Original=20
    Message-----
From: i-d-announce-bounces@ietf=
.org=20
    [mailto:i-d-announce-bounces@ietf=
.org]=20
    On Behalf Of internet-drafts@ietf.orgSent:=20
    Monday, May 23, 2011 12:59 PM
To: i-d-announce@ietf.org
Subj=
ect:=20
    I-D Action: draft-templin-v6ops-isops-05.txt

A New Internet-Draf=
t is=20
    available from the on-line Internet-Drafts directories.

  &=
nbsp;=20
       Title           : Operational Gui=
dance=20
    for IPv6 Deployment in IPv4 Sites using ISATAP
     =
=20
     Author(s)       : Fred L. Templin
   =
=20
       Filename        :=20
    draft-templin-v6ops-isops-05.txt
       Pages &n=
bsp;=20
            : 26
       Date &nb=
sp;=20
             : 2011-05-23

  Many end u=
ser=20
    sites in the Internet today still have predominantly
  IPv4 int=
ernal=20
    infrastructures.  These sites range in size from small
 =20
    home/office networks to large corporate enterprise networks, but
&nb=
sp;=20
    share the commonality that IPv4 continues to provide satisfactory
&n=
bsp;=20
    internal routing and addressing services for most applications.=20
     As
  more and more IPv6-only services are deployed in the=
=20
    Internet,
  however, end user devices within such sites will=20
    increasingly require
  at least basic IPv6 functionality for=20
    external access.  It is also
  expected that more and more=
=20
    IPv6-only devices will be deployed within
  the site over time.=
=20
     This document therefore provides operational
  guidance f=
or=20
    deployment of IPv6 within predominantly IPv4 sites using
  the=
=20
    Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).


A =
URL=20
    for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-templin-v6ops=
-isops-05.txt

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

This=20
    Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-templin-v6ops-=
isops-05.txt
_______________________________________________
I-D-=
Announce=20
    mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
I=
nternet-Draft=20
    directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
______=
_________________________________________
v6ops=20
    mailing list
v6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops



--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A6C96A3XCHNW01Vnwnos_--

From joelja@bogus.com  Tue May 24 15:11: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 A20E4E07CE for ; Tue, 24 May 2011 15:11: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 GY3NFDlLPJsf for ; Tue, 24 May 2011 15:11:03 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E2BDAE07A7 for ; Tue, 24 May 2011 15:11:02 -0700 (PDT)
Received: from [10.186.55.163] (227.sub-166-250-38.myvzw.com [166.250.38.227]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p4OMAJ91097997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 May 2011 22:10:24 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: <010201cc1a05$1a95b800$4fc12800$@lampo@eurid.eu>
Date: Tue, 24 May 2011 15:10:13 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <66F79D14-12C9-4836-AFFC-F965C9B8A410@bogus.com>
References: <20110524075632.3521.23377.idtracker@ietfa.amsl.com> <010201cc1a05$1a95b800$4fc12800$@lampo@eurid.eu>
To: Marc Lampo 
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, 24 May 2011 22:10:25 +0000 (UTC)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-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, 24 May 2011 22:11:03 -0000

On May 24, 2011, at 4:15 AM, Marc Lampo wrote:

> The document claims :
> "There would appear to be no evidence of any substantial deployment of
>   the variant of 6to4 described in [RFC3056]."
> (first sentence of the Introduction)
>=20
> If my Windows 7 based workstation finds a public IP address on one of =
its=20
> interfaces, it automatically assigns a 6to4 IPv6 address to that =
interface.
> Forgive my ignorance, with Windows, but if the behaviour I see is =
default on=20
> Windows 7,
> I daresay there must be quite a bit potential users of 6to4 tunneling, =
out=20
> there.

the experience you've had on that system is leveraging rfc 3068.

> I did hear Brian Carpenters excellent talk on 6to4 defects, in Prague,
> and there is certainly room for improvement.
>=20
> Kind regards,
>=20
> Marc Lampo
>=20
>=20
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: 24 May 2011 09:57 AM
> To: i-d-announce@ietf.org
> Cc: v6ops@ietf.org
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-03.txt
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts=20
> directories. This draft is a work item of the IPv6 Operations Working =
Group=20
> of the IETF.
>=20
> 	Title           : Request to move Connection of IPv6 Domains via =
IPv4=20
> Clouds (6to4) to Historic status
> 	Author(s)       : Ole Troan
> 	Filename        : draft-ietf-v6ops-6to4-to-historic-03.txt
> 	Pages           : 7
> 	Date            : 2011-05-24
>=20
>   Experience with the "Connection of IPv6 Domains via IPv4 Clouds
>   (6to4)" IPv6 transitioning mechanism has shown that the =
mechanism is
>   unsuitable for widespread deployment and use in the Internet.  This
>   document requests that RFC3056 and the companion document "An=20=

> Anycast
>   Prefix for 6to4 Relay Routers" RFC3068 are moved to historic =
status.
>=20
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-03.t=
xt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> =
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-to-historic-03.tx=
t
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20


From john.mann@monash.edu  Tue May 24 16: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 177BCE06AC for ; Tue, 24 May 2011 16:45:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.576
X-Spam-Level: 
X-Spam-Status: No, score=-5.576 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 kn3kVP9IiLRP for ; Tue, 24 May 2011 16:45:23 -0700 (PDT)
Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id 905E1E064E for ; Tue, 24 May 2011 16:45:22 -0700 (PDT)
Received: from mail-vx0-f181.google.com ([209.85.220.181]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKTdxDEgQ8Vjl5KwD9W82s4NE3yQQPpQ0O@postini.com; Tue, 24 May 2011 16:45:22 PDT
Received: by vxb39 with SMTP id 39so6620192vxb.40 for ; Tue, 24 May 2011 16:45:21 -0700 (PDT)
Received: by 10.52.176.98 with SMTP id ch2mr6157616vdc.51.1306280721236; Tue, 24 May 2011 16:45:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.164.132 with HTTP; Tue, 24 May 2011 16:45:01 -0700 (PDT)
In-Reply-To: 
References:   
From: "John Mann (ITS)" 
Date: Wed, 25 May 2011 09:45:01 +1000
Message-ID: 
To: "Templin, Fred L" 
Content-Type: multipart/alternative; boundary=20cf3071cecc5dc40804a40e2ef3
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in IPv4 Sitesusing ISATAP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 May 2011 23:45:24 -0000

--20cf3071cecc5dc40804a40e2ef3
Content-Type: text/plain; charset=ISO-8859-1

Fred,

OK, if I have this right, something like ...

IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320]
are dual-protocol IPv4 and IPv6 overlay technologies that could be used
instead of ISATAP to
enable IPv6 services.

or ... protocol agnostic overlay technologies ...

Thanks,
    John


On 25 May 2011 08:07, Templin, Fred L  wrote:

>  Hi John,
>
> Please believe me when I say that it is not a round-about way of praising
> myself - quite to the contrary, I was trying to be respectful of others.
> These
> technologies are however alternative approaches that could be used in the
> same use cases as ISATAP, and I have also co-authored a RANGER
> Scenarios document [RFC6139] that shows how this is true.
>
> Perhaps it would be acceptable to just list the technologies under
> Alternative
> Approaches, but delete the non-technical phrasing that caught your
> attention?
>
> Thanks - Fred
> fred.l.templin@boeing.com
>
>  ------------------------------
> *From:* John Mann (ITS) [mailto:john.mann@monash.edu]
> *Sent:* Tuesday, May 24, 2011 2:12 PM
> *To:* Templin, Fred L
> *Cc:* v6ops@ietf.org
> *Subject:* Re: [v6ops] Operational Guidance for IPv6 Deployment in IPv4
> Sitesusing ISATAP
>
> Fred,
>
> I like ISATAP and your draft.
>
> But I'm not sure about
> ---
> 9. Alternative Approaches
> *
> *
> ...
> IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320]
> are a tribute to those in all walks of life who serve with dignity
> and honor for the benefit of others.
> ---
>
> a) it seems out of place in that it doesn't discuss the method used or
> service provided by these protocols.
> b) is it a round-about way of praising yourself in that you are the author
> of those protocols, and of this draft?
>
> ======
> Also in http://tools.ietf.org/html/draft-templin-v6ops-isops-05#section-9
> the text "[RFC4554]" doesn't web-link to
> http://tools.ietf.org/html/rfc4554
> But I can't tell if this is a original markup problem, or draft->html
> converter problem.
>
> Thanks,
>     John
>
>  On 24 May 2011 07:16, Templin, Fred L  wrote:
>
>> Folks,
>>
>> I am done tweaking this document now. Would appreciate
>> input, especially from those who have expressed interest
>> in ISATAP over the past several weeks.
>>
>> 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: Monday, May 23, 2011 12:59 PM
>> To: i-d-announce@ietf.org
>> Subject: I-D Action: draft-templin-v6ops-isops-05.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>        Title           : Operational Guidance for IPv6 Deployment in IPv4
>> Sites using ISATAP
>>        Author(s)       : Fred L. Templin
>>        Filename        : draft-templin-v6ops-isops-05.txt
>>        Pages           : 26
>>        Date            : 2011-05-23
>>
>>   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.  It is also
>>   expected that more and more IPv6-only devices will be deployed within
>>   the site over time.  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-05.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-05.txt
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draftdirectories:
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>

--20cf3071cecc5dc40804a40e2ef3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Fred,

OK, if I have this right, something like ...
=


IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL =
[RFC5320]



are dual-protocol IPv4 and IPv6 overlay technologies that could be use=
d instead of ISATAP to
enable IPv6 services.

=

or ... protocol agnostic overlay=A0technologies ...



Thanks,
=A0 =A0 John



On 25 May 2011 08:07, Templin, Fred L <Fred.L.Templin@boeing.com> wrot=
e:









Hi John,


=A0


Please believe me when I say that it is not a round-about=20
way of praising


myself - quite to the contrary, I was trying to be=20
respectful of others. These


technologies are however alternative approaches that=20
could=
 be used in the


same use cases as ISATAP, and I have also=20
co-au=
thored a=A0RANGER 


Scenarios document [RFC6139] that shows how this is=20
true.


=A0


Perhaps it would be acceptable to just list the=20
technologies under Alternative


Approaches, but delete the non-technical phrasing that=20
caugh=
t your attention?


=A0


Thanks - Fred





  

  

  From: John Mann (ITS)=20
  [mailto:john.ma=
nn@monash.edu] 
Sent: Tuesday, May 24, 2011 2:12=20
  PM
To: Templin, Fred L
Cc:=20
  v6ops@ietf.orgSubject: Re: [v6ops] Operational Guidance for IPv6=20
  Deployment in IPv4 Sitesusing ISATAP

=


  
Fred,
  


  
I like ISATAP and your draft.

  


  
But I'm not sure about

  
---

  
9. Alternative Approaches

=

...
  
IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320]are=20
  a tribute to those in all walks of life who serve with dignity
and hon=
or=20
  for the benefit of others.

  
---

  


  
a) it seems out of place in that it doesn't discuss the method u=
sed or=20
  service provided by these protocols.

  
b) is it a round-about way of praising yourself in that you are the=
=20
  author of those protocols, and of this draft?

  


  
=3D=3D=3D=3D=3D=3D

  
  
the text "[RFC4554]=
" doesn't web-link to=20
  =A0http:=
//tools.ietf.org/html/rfc4554

  
But I can't tell if this is a original markup problem, or draft-=
>html=20
  converter problem.

  


  
Thanks,

  
=A0 =A0 John

  


  

  
On 24 May 2011 07:16, Templin, Fred L <Fred.L.Templin@boeing.com>=20
  wrote:

  
Folks,

I=20
    am done tweaking this document now. Would appreciate
input, especial=
ly=20
    from those who have expressed interest
in ISATAP over the past sever=
al=20
    weeks.

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

-----Original=
=20
    Message-----
From: i-d-announce-bounces@ietf.org=20
    [mailto:i-d-announce-bounces@ietf.org]=20
    On Behalf Of internet-drafts@ietf.org
Sent:=20
    Monday, May 23, 2011 12:59 PM
To: i-d-announce@ietf.org
Subject:=20
    I-D Action: draft-templin-v6ops-isops-05.txt

A New Internet-Draf=
t is=20
    available from the on-line Internet-Drafts directories.

=A0 =A0=
=20
    =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Operational Guidance=20
    for IPv6 Deployment in IPv4 Sites using ISATAP
=A0 =A0 =A0=20
    =A0Author(s) =A0 =A0 =A0 : Fred L. Templin
=A0 =A0=20
    =A0 =A0Filename =A0 =A0 =A0 =A0:=20
    draft-templin-v6ops-isops-05.txt
=A0 =A0 =A0 =A0Pages =A0=20
    =A0 =A0 =A0 =A0 : 26
=A0 =A0 =A0 =A0Date =A0=20
    =A0 =A0 =A0 =A0 =A0: 2011-05-23

=A0 Many end user=20
    sites in the Internet today still have predominantly
=A0 IPv4 intern=
al=20
    infrastructures. =A0These sites range in size from small
=A0=20
    home/office networks to large corporate enterprise networks, but
=A0=
=20
    share the commonality that IPv4 continues to provide satisfactory
=
=A0=20
    internal routing and addressing services for most applications.=20
    =A0As
=A0 more and more IPv6-only services are deployed in the=20
    Internet,
=A0 however, end user devices within such sites will=20
    increasingly require
=A0 at least basic IPv6 functionality for=20
    external access. =A0It is also
=A0 expected that more and more=20
    IPv6-only devices will be deployed within
=A0 the site over time.=20
    =A0This document therefore provides operational
=A0 guidance for=20
    deployment of IPv6 within predominantly IPv4 sites using
=A0 the=20
    Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).


A =
URL=20
    for this Internet-Draft is:
http://www.ietf.=
org/internet-drafts/draft-templin-v6ops-isops-05.txt

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

This=20
    Internet-Draft can be retrieved at:
ftp://ftp=
.ietf.org/internet-drafts/draft-templin-v6ops-isops-05.txt
_________=
______________________________________


I-D-Announce=20
    mailing list
I-D-Announce@ietf.org
https://www.ietf.org/m=
ailman/listinfo/i-d-announce


Internet-Draft=20
    directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-=
sites.txt


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




--20cf3071cecc5dc40804a40e2ef3--

From internet-drafts@ietf.org  Tue May 24 17:23: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 4A1A2E076C; Tue, 24 May 2011 17:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.573
X-Spam-Level: 
X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 dbqLjE2Swf98; Tue, 24 May 2011 17:23:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0683E073C; Tue, 24 May 2011 17:23:13 -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: <20110525002313.14940.82695.idtracker@ietfa.amsl.com>
Date: Tue, 24 May 2011 17:23:13 -0700
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-happy-eyeballs-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: Wed, 25 May 2011 00:23:14 -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           : Happy Eyeballs: Trending Towards Success with Dual-Stack=
 Hosts
	Author(s)       : Dan Wing
                          Andrew Yourtchenko
	Filename        : draft-ietf-v6ops-happy-eyeballs-02.txt
	Pages           : 19
	Date            : 2011-05-24

   This document describes an algorithm for a dual-stack client to
   quickly determine the functioning address family to a dual-stack
   server, and trend towards using that same address family for
   subsequent connections.  This improves the dual-stack user experience
   during IPv6 or IPv4 server or network outages.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-happy-eyeballs-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-happy-eyeballs-02.txt

From dwing@cisco.com  Tue May 24 17:25: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 B70CAE0791 for ; Tue, 24 May 2011 17:25:41 -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 QkSwTwfdcM4y for ; Tue, 24 May 2011 17:25:41 -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 23C6AE078B for ; Tue, 24 May 2011 17:25:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2433; q=dns/txt; s=iport; t=1306283141; x=1307492741; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=G9kKeuj5yyIs1U4/8CWQlDicnrzeWNp4hZaQJ2RjC5w=; b=CR8g31ar2sKF7rO+AO4bbtZfjpPeVEnoRTNUM3SI0Oc9Kau/F76w2iMh wSC3v3MuyOCcNXOhVLvHclotm5giosbhe2d6H9H1nUJpc/Ap6ZqbLx70x SG2E/2TiRhMshj/fyIl7D65gnNXl+2s14Qw6iYZ+Z5erI2xgqp3aW7z/O I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: At4GAARM3E2rRDoJ/2dsb2JhbACYJYEkjGB3qGGBHZ1whhsEhlaYag
X-IronPort-AV: E=Sophos;i="4.65,264,1304294400"; d="scan'208";a="453699970"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 25 May 2011 00:25:40 +0000
Received: from dwingWS (dhcp-128-107-104-227.cisco.com [128.107.104.227]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4P0PeSx001951 for ; Wed, 25 May 2011 00:25:40 GMT
From: "Dan Wing" 
To: 
Date: Tue, 24 May 2011 17:25:40 -0700
Message-ID: <06d801cc1a72$4735e4d0$d5a1ae70$@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: AcwackcCP0amXN93T9qruR7SdLeQUg==
Content-Language: en-us
Subject: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 00:25:41 -0000

This has been a long time coming -- sorry about that.

This new version incorporates almost all of the feedback we received from
the working group -- support for per-prefix "P", IPv6 head start, fully
describing "Smoothed P".  This also added complexity.  There are some ideas
Andrew is kicking around to reduce the complexity, but we wanted people to
take a look at this document and see how it feels.  There is a tradeoff in
complexity with being gentle to the network -- which is desirable if only
certain servers or certain IPv6 prefixes are failing (but others are
working), and we don't want to abuse the network by attempting IPv4
connections whenever IPv6 has a small hiccup.

Reading this update will require a holistic view, so please fill your coffee
mug before diving into the document.

new version:
  http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-02	
side-by-side differences:
  http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-happy-eyeballs-02.txt

Changes are in Appendix A.1, and are also copied below for reference.

-Dan and Andrew

-----

   o  Now honors host's address preference (RFC3484 and friends)

   o  No longer requires thread-safe DNS library.  It uses getaddrinfo()

   o  No longer describes threading.

   o  IPv6 is given a 200ms head start (Initial Headstart variable).

   o  If the IPv6 and IPv4 connection attempts were made at nearly the
      same time, wait Tolerance Interval milliseconds for both to
      complete before deciding which one wins. 

   o  Renamed "global P" to "Smoothed P", and better described how it is
      calculated.

   o  introduced the exception cache.  This contains the set of networks
      that only work with IPv4 (or only with IPv6), so that subsequent
      connection attempts use that address family without them causing
      serious affect to Smoothed P.

   o  encourages that every 10 minutes the exception cache and Smoothed
      P be reset.  This allows IPv6 to be attempted again, so we don't
      get 'stuck' on IPv4.

   o  If we didn't get both A and AAAA, abandon all Happy Eyeballs
      processing (thanks to Simon Perreault).

   o  added discussion of Same Origin Policy

   o  Removed discussion of NAT-PT and address learning; those are only
      used with IPv6-only hosts whereas this document is about dual-
      stack hosts contacting dual-stack servers.



From sunseawq@huawei.com  Tue May 24 18:35: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 7068DE0764 for ; Tue, 24 May 2011 18:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.133
X-Spam-Level: 
X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.466,  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 t5UD0gYaWfxz for ; Tue, 24 May 2011 18:35:31 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A746DE0753 for ; Tue, 24 May 2011 18:35:31 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ00AWN9R6A4@szxga03-in.huawei.com> for v6ops@ietf.org; Wed, 25 May 2011 09:35:30 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ00IHB9R6ZA@szxga03-in.huawei.com> for v6ops@ietf.org; Wed, 25 May 2011 09:35:30 +0800 (CST)
Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLQ008869R6TW@szxml04-in.huawei.com> for v6ops@ietf.org; Wed, 25 May 2011 09:35:30 +0800 (CST)
Date: Wed, 25 May 2011 09:39:37 +0800
From: Qin Wu 
To: v6ops@ietf.org
Message-id: <019301cc1a7c$9c3a8710$46298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: multipart/mixed; boundary="Boundary_(ID_XtA25nyxMog7EZOb9wIUFw)"
X-Priority: 3
X-MSMail-priority: Normal
Subject: [v6ops] Review of the new version draft-sarikaya-v6ops-prefix-delegation-04
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 01:35:32 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_XtA25nyxMog7EZOb9wIUFw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi, 
I was asked to review this new version of draft-sarikaya-v6ops-prefix-delegation.

This version looks better, but I am still not sure it clealy clarify how prefix management 
issue is addressed in the AR or homegateway for per-MN interface prefix model, in particular:

Section 1,  it seems to me the figure 1 is combination of WiMAX archteicture and 
3GPP architecutre. I am not sure I understand
the difference between access GW and access router. To my mind,  PDN-GW
 is edge router rather than access router. If I am wrong, please correct me.

Section 3.1, This draft is referencing to TS23.401, I am wondering what is missing in TS23.401
for stateless address autoconfiguration. As described in section 5.3.1.2.2 of TS23.401,
IPv6 can be allocated from external PDN,e.g., DHCP server to PDN GW and then PDN GW 
will allocate IPv6 address to UE through Router Soliciation/Router Advertisement exhange. 
Also Prefix can be released during release of the PDN connection. So I am wondering whether 
prefix mangement is a real a issue in the PDN-GW for stateless address autocofigureation case? 
What is the special issue for per-MN interface prefix model?
So it is better it clarify how it gets alignment with TS23.401, what is missing in 
TS23.401, How it overcomes the problem unsolved in TS23.401.

Section 3.2, As regarding to stateful address configuation, I don't know why TS23.401 does not cover this
case and specify something. In this draft, it assumes one specific case, i.e., DHCP client is 
collocated with DHCP server in the AR. It is okay. 
Otherwise, AR will not be responsible for prefix management. Instead, DHCP server will do. 
However is there too much value for this case, since we can not mandate DHCP 
server should be always sitting in the AR. there are other depoyment scenarios.
So it is better to explain why stateful address allocation is useful in such case.

Regards!
-Qin
----- Original Message ----- 
From: 
To: 
Sent: Thursday, May 19, 2011 6:00 PM
Subject: I-D Action:draft-sarikaya-v6ops-prefix-delegation-04.txt


>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> Title           : DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks
> Author(s)       : B. Sarikaya, et al.
> Filename        : draft-sarikaya-v6ops-prefix-delegation-04.txt
> Pages           : 14
> Date            : 2011-05-19
> 
> As interest on IPv6 deployment is increasing in cellular networks
> several migration issues are being raised and IPv6 prefix management
> is the one addressed in this document.  Based on the idea that DHCPv6
> servers can manage prefixes, we address prefix management issues such
> as the access router offloading delegation and release tasks of the
> prefixes to a DHCPv6 server using DHCPv6 PD.  The access router first
> requests a prefix for an incoming mobile node from the DHCPv6 server.
> The access router may next stateless or stateful address allocation
> to the mobile node, e.g. with a Router Advertisement or using DHCP.
> We also describe prefix management using Authentication Authorization
> and Accounting servers.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-sarikaya-v6ops-prefix-delegation-04.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.
>


--------------------------------------------------------------------------------


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

--Boundary_(ID_XtA25nyxMog7EZOb9wIUFw)
Content-type: text/plain; name=draft-sarikaya-v6ops-prefix-delegation-04.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment;
 filename=draft-sarikaya-v6ops-prefix-delegation-04.txt

Content-Type: text/plain
Content-ID: <2011-05-19025537.I-D@ietf.org>


--Boundary_(ID_XtA25nyxMog7EZOb9wIUFw)--

From jonne.soininen@renesasmobile.com  Tue May 24 22: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 BDE8513000A for ; Tue, 24 May 2011 22:40:43 -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, MANGLED_PAIN=2.3, 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 DZlD2Xtf4iK3 for ; Tue, 24 May 2011 22:40:43 -0700 (PDT)
Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with ESMTP id A70E9E06EF for ; Tue, 24 May 2011 22:40:42 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: jonne.soininen@renesasmobile.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1306302040!7834181!1
X-StarScan-Version: 6.2.17; banners=-,-,-
X-Originating-IP: [213.174.82.10]
Received: (qmail 14453 invoked from network); 25 May 2011 05:40:40 -0000
Received: from renexfe01.roe2.renesasmobile.com (HELO renexfe01.roe2.renesasmobile.com) (213.174.82.10) by server-3.tower-182.messagelabs.com with AES128-SHA encrypted SMTP; 25 May 2011 05:40:40 -0000
Received: from RENEXMB01.roe2.renesasmobile.com ([fe80::e58a:2b9f:54fe:ff5]) by renexfe01.roe2.renesasmobile.com ([fe80::ec94:bbb3:68e:a94a%18]) with mapi id 14.01.0255.000; Wed, 25 May 2011 08:40:40 +0300
From: 
To: , 
Thread-Topic: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-01
Thread-Index: AQHMGp5HkfLdKLlOHEW07tWdJr+Y2A==
Date: Wed, 25 May 2011 05:40:39 +0000
Message-ID: 
In-Reply-To: <9EFA85B3-43E6-441B-82B6-2C19084F5B39@apple.com>
Accept-Language: en-US, da-DK
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.22.233]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-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, 25 May 2011 05:40:43 -0000

Hi James,


On 5/23/11 9:45 PM, "james woodyatt"  wrote:

>On May 22, 2011, at 11:00 , Fred Baker wrote:
>>=20
>> The working group last call for this draft announced last week
>>continues for another week. Please feel free to comment on it.
>
>I am in the target audience for this document, so my contributions will
>seem more critical than constructive and predominantly editorial in
>nature, mainly because I'm not confident that my knowledge of 3GPP
>protocols and technologies is complete.
>
>Please do not interpret my criticisms as opposition to this draft.  I
>very much want to see a document with this information published in the
>RFC series.
>
>----
>
>p1. The abstract seems overly verbose.  Here is a proposed rewrite:
>
>   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.
>
>p2. This sentence needs updating:
>
>   However, the support for IPv6
>   in commercially deployed networks by the end of 2010 is nearly non-
>   existent.
>
>p3. In section 2.1, Terminology, I think it would help if the
>abbreviations were all collected into one table and expanded once in each
>glossary subsection entry and in each top level section where they are
>used.  The terms in the glossary subsection should be headed by expanded
>abbreviations, and they should be presented in alphabetical order.
>
>p4. In section 2.1, Terminology, the definition of "Packet Data Network"
>introduces what seems to be a specialized term, 'packet domain network,'
>that goes undefined in this section.  Please clarify.
>
>p5. In section 2.1, Terminology, the definition of "Policy and Charging
>Control (PCC) framework" explains that it's used for QoS policy, which I
>think I might understand, but also for 'charging control' which is never
>defined.  It also doesn't appear to be inferable from context in the
>draft.  The dependent clause "but needed if dynamic policy and charging
>control by means of PCC rules based on user and services are desired" is
>therefore really not much use.  Please clarify.
>
>p6. In section 2.1, Terminology, the term "evolved packet core" is
>introduced and used in the document, but never defined.  Please clarify.
>
>p7. I think section 2.2, The concept of APN, might more properly belong
>in section 3 [but I'm not sure].  If it really belongs in section 2,
>because it describes an architecture independent of the Internet
>Protocol, then perhaps this should be explicitly mentioned here.
>
>p8. In section 3.1, figure 2, what does the abbreviation TE mean?  Also,
>I gather that PLMN stands for Public Land Mobile Network, but this term
>is not properly introduced.  The "i.e." parentheticals in the Gn/Gp table
>entry are no help to me.
>
>p9. In section 5.3, Prefix Delegation, the second paragraph is mostly
>unintelligible to me.  The citation of RFC 3633, section 12.1, is
>confusing, because that document doesn't place any limitations on the
>delegating router, only the requesting router, which is contrary to what
>this draft states.  The sentences that follow in that paragraph therefore
>don't make sense to me.  Please clarify.
>
>p10. In section 6, the abbreviation "DS" is used, presumably to stand for
>'dual-stack,' but no proper introduction is given.  I think it would be
>better to eliminate some uses of it, particularly in figures 5, 6 and 7,
>and expand it fully everywhere else.
>
>p11. In section 6.4, the abbreviation IPv4v6 is introduced and used
>several places thereafter.  I can infer that this signals a special type
>of 3GPP bearer that transports both IPv4 and IPv6 at the same time, but I
>don't like this abbreviation.  If it's official 3GPP terminology, then
>please cite it and add it to the Terminology section.  Otherwise, please
>come up with a more descriptive term, e.g. "dual-stack IP" should work in
>a pinch, and use that instead.
>
>p12. Throughout, I think it would be better to use a hyphen when writing
>IPv4-only and IPv6-only.
>
>
>--
>james woodyatt 
>member of technical staff, core os networking
>
>
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops


From jonne.soininen@renesasmobile.com  Tue May 24 23:18: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 CD99813000D for ; Tue, 24 May 2011 23:18:27 -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, MANGLED_PAIN=2.3, 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 6aYStyuHn52e for ; Tue, 24 May 2011 23:18:27 -0700 (PDT)
Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECE413000C for ; Tue, 24 May 2011 23:18:26 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: jonne.soininen@renesasmobile.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1306304304!20930557!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [213.174.82.10]
Received: (qmail 1433 invoked from network); 25 May 2011 06:18:25 -0000
Received: from renexfe01.roe2.renesasmobile.com (HELO renexfe01.roe2.renesasmobile.com) (213.174.82.10) by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 25 May 2011 06:18:25 -0000
Received: from RENEXMB01.roe2.renesasmobile.com ([fe80::e58a:2b9f:54fe:ff5]) by renexfe01.roe2.renesasmobile.com ([fe80::ec94:bbb3:68e:a94a%18]) with mapi id 14.01.0255.000; Wed, 25 May 2011 09:18:24 +0300
From: 
To: , 
Thread-Topic: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-01
Thread-Index: AQHMGqONkfLdKLlOHEW07tWdJr+Y2A==
Date: Wed, 25 May 2011 06:18:24 +0000
Message-ID: 
In-Reply-To: <9EFA85B3-43E6-441B-82B6-2C19084F5B39@apple.com>
Accept-Language: en-US, da-DK
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.22.233]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-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, 25 May 2011 06:18:27 -0000

Hi,

(the last mail escaped a bit early). Sorry! Well, now trying again...


On 5/23/11 9:45 PM, "james woodyatt"  wrote:

>On May 22, 2011, at 11:00 , Fred Baker wrote:
>>=20
>> The working group last call for this draft announced last week
>>continues for another week. Please feel free to comment on it.
>
>I am in the target audience for this document, so my contributions will
>seem more critical than constructive and predominantly editorial in
>nature, mainly because I'm not confident that my knowledge of 3GPP
>protocols and technologies is complete.
>
>Please do not interpret my criticisms as opposition to this draft.  I
>very much want to see a document with this information published in the
>RFC series.

Good comments and good review is never bad! Thank you very much for your
comments. We'll try to update the draft accordingly. After working for
over ten years on these things, some of the terms and issues become a
second nature, and we might not have explained everything, which we
actually should.

Thanks for the review, James!

Cheers,

Jonne.

>
>----
>
>p1. The abstract seems overly verbose.  Here is a proposed rewrite:
>
>   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.
>
>p2. This sentence needs updating:
>
>   However, the support for IPv6
>   in commercially deployed networks by the end of 2010 is nearly non-
>   existent.
>
>p3. In section 2.1, Terminology, I think it would help if the
>abbreviations were all collected into one table and expanded once in each
>glossary subsection entry and in each top level section where they are
>used.  The terms in the glossary subsection should be headed by expanded
>abbreviations, and they should be presented in alphabetical order.
>
>p4. In section 2.1, Terminology, the definition of "Packet Data Network"
>introduces what seems to be a specialized term, 'packet domain network,'
>that goes undefined in this section.  Please clarify.
>
>p5. In section 2.1, Terminology, the definition of "Policy and Charging
>Control (PCC) framework" explains that it's used for QoS policy, which I
>think I might understand, but also for 'charging control' which is never
>defined.  It also doesn't appear to be inferable from context in the
>draft.  The dependent clause "but needed if dynamic policy and charging
>control by means of PCC rules based on user and services are desired" is
>therefore really not much use.  Please clarify.
>
>p6. In section 2.1, Terminology, the term "evolved packet core" is
>introduced and used in the document, but never defined.  Please clarify.
>
>p7. I think section 2.2, The concept of APN, might more properly belong
>in section 3 [but I'm not sure].  If it really belongs in section 2,
>because it describes an architecture independent of the Internet
>Protocol, then perhaps this should be explicitly mentioned here.
>
>p8. In section 3.1, figure 2, what does the abbreviation TE mean?  Also,
>I gather that PLMN stands for Public Land Mobile Network, but this term
>is not properly introduced.  The "i.e." parentheticals in the Gn/Gp table
>entry are no help to me.
>
>p9. In section 5.3, Prefix Delegation, the second paragraph is mostly
>unintelligible to me.  The citation of RFC 3633, section 12.1, is
>confusing, because that document doesn't place any limitations on the
>delegating router, only the requesting router, which is contrary to what
>this draft states.  The sentences that follow in that paragraph therefore
>don't make sense to me.  Please clarify.
>
>p10. In section 6, the abbreviation "DS" is used, presumably to stand for
>'dual-stack,' but no proper introduction is given.  I think it would be
>better to eliminate some uses of it, particularly in figures 5, 6 and 7,
>and expand it fully everywhere else.
>
>p11. In section 6.4, the abbreviation IPv4v6 is introduced and used
>several places thereafter.  I can infer that this signals a special type
>of 3GPP bearer that transports both IPv4 and IPv6 at the same time, but I
>don't like this abbreviation.  If it's official 3GPP terminology, then
>please cite it and add it to the Terminology section.  Otherwise, please
>come up with a more descriptive term, e.g. "dual-stack IP" should work in
>a pinch, and use that instead.
>
>p12. Throughout, I think it would be better to use a hyphen when writing
>IPv4-only and IPv6-only.
>
>
>--
>james woodyatt 
>member of technical staff, core os networking
>
>
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops


From jouni.nospam@gmail.com  Wed May 25 01:43: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 835C2E0692 for ; Wed, 25 May 2011 01:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_PAIN=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 5phClwRhxMIV for ; Wed, 25 May 2011 01:43:32 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41E1DE06BE for ; Wed, 25 May 2011 01:43:32 -0700 (PDT)
Received: by eye13 with SMTP id 13so3320758eye.31 for ; Wed, 25 May 2011 01:43:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=7h6eIXeyH/KmIVJ6fmFZw7roE8w12tjlHmQzmHyuXSU=; b=bOmOtxSRnvKtr5nOf9kHupjdHvzjEleNJxeaeUCUtPFuiiRC3dsGQBLUZtN6ShH9NF B9Gj+BlIVWTIjIcvDnIB/+VsRLX1/mX+eammcBZw9pizlgeGNVoIftgTNUlC+ifHOJBE XYcnkDH2cezqBea/AlVXVaArJFeJHqRCL1bIQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=m+ZK8VjIXYxfeQMPGhUrxl/Io1w1HkteRfLIlm6KMbnEM79rYm4G0R+Fgtl5pn+z/P nZb4M608HpDJdP6HVYlng04oIGrukPZ7wJsLXPWRQ8jqQz61Iy3YhvZiV3MthLox6StH mHvp0BizcFJc0VvLsnO88m7/H4Us+4Q/xdG9M=
Received: by 10.14.9.215 with SMTP id 63mr417945eet.144.1306313010821; Wed, 25 May 2011 01:43:30 -0700 (PDT)
Received: from pc-a82035.wlan.inet.fi (pc-a82035.wlan.inet.fi [194.111.82.35]) by mx.google.com with ESMTPS id y2sm5925746eeh.11.2011.05.25.01.43.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2011 01:43:29 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <9EFA85B3-43E6-441B-82B6-2C19084F5B39@apple.com>
Date: Wed, 25 May 2011 11:43:27 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CF04D93-43FC-4D44-B3AD-D16E7F480593@gmail.com>
References: <7B661D1F-F127-45A8-B3E1-DDA6ED10AD35@cisco.com> <9EFA85B3-43E6-441B-82B6-2C19084F5B39@apple.com>
To: james woodyatt 
X-Mailer: Apple Mail (2.1082)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-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, 25 May 2011 08:43:33 -0000

James,

Thanks for the review. Really appreciated! See my initial comments =
inline.

On May 23, 2011, at 9:45 PM, james woodyatt wrote:

> On May 22, 2011, at 11:00 , Fred Baker wrote:
>>=20
>> The working group last call for this draft announced last week =
continues for another week. Please feel free to comment on it.
>=20
> I am in the target audience for this document, so my contributions =
will seem more critical than constructive and predominantly editorial in =
nature, mainly because I'm not confident that my knowledge of 3GPP =
protocols and technologies is complete.
>=20
> Please do not interpret my criticisms as opposition to this draft.  I =
very much want to see a document with this information published in the =
RFC series.
>=20
> ----
>=20
> p1. The abstract seems overly verbose.  Here is a proposed rewrite:
>=20
>   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.

Looks OK to me.


>=20
> p2. This sentence needs updating:
>=20
>   However, the support for IPv6
>   in commercially deployed networks by the end of 2010 is nearly non-
>   existent.

Yes. Cameron also pointed this out.


>=20
> p3. In section 2.1, Terminology, I think it would help if the =
abbreviations were all collected into one table and expanded once in =
each glossary subsection entry and in each top level section where they =
are used.  The terms in the glossary subsection should be headed by =
expanded abbreviations, and they should be presented in alphabetical =
order.

Hmm.. OK to collect all abbreviations. Do you mean that each of these =
current entries in the terminology section would become a subsection of =
their own?

>=20
> p4. In section 2.1, Terminology, the definition of "Packet Data =
Network" introduces what seems to be a specialized term, 'packet domain =
network,' that goes undefined in this section.  Please clarify.

s/domain/core

Good catch. Packet core network means the operator internal network.


>=20
> p5. In section 2.1, Terminology, the definition of "Policy and =
Charging Control (PCC) framework" explains that it's used for QoS =
policy, which I think I might understand, but also for 'charging =
control' which is never defined.  It also doesn't appear to be inferable =
from context in the draft.  The dependent clause "but needed if dynamic =
policy and charging control by means of PCC rules based on user and =
services are desired" is therefore really not much use.  Please clarify.

Ok. But I do not want to go into too much details.. PCC is a beast of =
its own.. brrr..

>=20
> p6. In section 2.1, Terminology, the term "evolved packet core" is =
introduced and used in the document, but never defined.  Please clarify.

Oops :) Will add it.

>=20
> p7. I think section 2.2, The concept of APN, might more properly =
belong in section 3 [but I'm not sure].  If it really belongs in section =
2, because it describes an architecture independent of the Internet =
Protocol, then perhaps this should be explicitly mentioned here.

I have no strong opinion here. Section 2.2 could fit nicely between =
current Sections 3.1 and 3.2.

>=20
> p8. In section 3.1, figure 2, what does the abbreviation TE mean?  =
Also, I gather that PLMN stands for Public Land Mobile Network, but this =
term is not properly introduced.  The "i.e." parentheticals in the Gn/Gp =
table entry are no help to me.
>=20

More stuff to terminology section.. TE is Terminal Equipment e.g. your =
laptop. MT would then be your modem.


> p9. In section 5.3, Prefix Delegation, the second paragraph is mostly =
unintelligible to me.  The citation of RFC 3633, section 12.1, is =
confusing, because that document doesn't place any limitations on the =
delegating router, only the requesting router, which is contrary to what =
this draft states.  The sentences that follow in that paragraph =
therefore don't make sense to me.  Please clarify.

There was a long discussion on this in DHC WG. The restriction applies =
also to delegating router. When you delegate a prefix to a requesting =
router, then the delegating router must not advertise (in RAs) any of =
these prefixes on its downstream link towards requesting router.. which =
would be the case in 3GPP architecture. Thus all this prefix delegation =
work and description here.

>=20
> p10. In section 6, the abbreviation "DS" is used, presumably to stand =
for 'dual-stack,' but no proper introduction is given.  I think it would =
be better to eliminate some uses of it, particularly in figures 5, 6 and =
7, and expand it fully everywhere else.

Ok.

>=20
> p11. In section 6.4, the abbreviation IPv4v6 is introduced and used =
several places thereafter.  I can infer that this signals a special type =
of 3GPP bearer that transports both IPv4 and IPv6 at the same time, but =
I don't like this abbreviation.  If it's official 3GPP terminology, then =
please cite it and add it to the Terminology section.  Otherwise, please =
come up with a more descriptive term, e.g. "dual-stack IP" should work =
in a pinch, and use that instead.
>=20

Right, will add IPv4v6 to terminology section as it is formal 3GPP =
jargon.


> p12. Throughout, I think it would be better to use a hyphen when =
writing IPv4-only and IPv6-only.

Ack.

Thanks for the thorough review.

- Jouni


>=20
>=20
> --
> james woodyatt 
> member of technical staff, core os networking
>=20
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From pch-b2B3A6689@u-1.phicoh.com  Wed May 25 04:49: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 CC042E0718 for ; Wed, 25 May 2011 04:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 aPmhGCRiv3uH for ; Wed, 25 May 2011 04:49:43 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 079C8E0618 for ; Wed, 25 May 2011 04:49:43 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QPCao-0001h6C; Wed, 25 May 2011 13:49:38 +0200
Message-Id: 
To: "Dan Wing" 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
In-reply-to: Your message of "Tue, 24 May 2011 17:25:40 -0700 ." <06d801cc1a72$4735e4d0$d5a1ae70$@com> 
Date: Wed, 25 May 2011 13:49:28 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 11:49:43 -0000

In your letter dated Tue, 24 May 2011 17:25:40 -0700 you wrote:
>This new version incorporates almost all of the feedback we received from
>the working group -- support for per-prefix "P", IPv6 head start, fully
>describing "Smoothed P".  

Two comments.

It looks like a naive implementation would take at least Tolerance Interval
(20ms) when both an A and AAAA are present. I wonder if that is really a
good idea. I would be prefer a connection to be available to the application
as soon as possible. Optionally without updating the SP value.

The draft is biased towards IPv6. I wonder if that is a good idea. In the past,
a bias towards IPv6 led to all kinds of problems. If IPv6 is better, let
that be shown in the connection setup times. Maybe for small values of P,
the algorithm should use the address in the order in which they were found
in the getaddrinfo results. 



From prondou@gmail.com  Wed May 25 05:59: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 D7695130017; Wed, 25 May 2011 05:59: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 qQSBnvES-0IO; Wed, 25 May 2011 05:59:49 -0700 (PDT)
Received: from mailrelay008.isp.belgacom.be (mailrelay008.isp.belgacom.be [195.238.6.174]) by ietfa.amsl.com (Postfix) with ESMTP id 041E0E067C; Wed, 25 May 2011 05:59:48 -0700 (PDT)
X-Belgacom-Dynamic: yes
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIBABb73E1R95HQ/2dsb2JhbAAMhFDXMzyHHzmIZ4Erg2qBBwSQLo8J
Received: from 208.145-247-81.adsl-dyn.isp.belgacom.be (HELO [192.168.1.40]) ([81.247.145.208]) by relay.skynet.be with ESMTP; 25 May 2011 14:59:47 +0200
Message-ID: <4DDCFD42.3010708@gmail.com>
Date: Wed, 25 May 2011 14:59:46 +0200
From: Pierre Rondou 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: Eric Dumazet 
References: <4DC1FACC.4080204@gmail.com>	 <1306248975.3026.47.camel@edumazet-laptop> <4DDBD2F1.3020704@gmail.com> <1306252554.3026.66.camel@edumazet-laptop>
In-Reply-To: <1306252554.3026.66.camel@edumazet-laptop>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: v6ops@ietf.org, behave@ietf.org, Cyril Soldani , netfilter-devel@vger.kernel.org, guy.leduc@ulg.ac.be
Subject: Re: [v6ops] Netfilter Module for NAT IVI available
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 12:59:50 -0000

Le 24/05/11 17:55, Eric Dumazet a écrit :
>
>>>>
>>>>          
>>> Hi Pierre
>>>
>>> 1) Are you sure netfilter is the right place for this IVI feature ?
>>>      (fact that you had to copy/paste ~1300 lines of code from kernel
>>> might show that this would be better to use a module hooked into
>>> forwarding stack ?)
>>>
>>>        
>> I used Xtables to produce my module, fact is that I was (and still am) a
>> kernel nooby, Xtables seemed to a be good way to produce this code.
>> I'm not sure to what you're refering about, are you suggesting I should
>> have developed the module directly into the kernel?
>>
>>      
> We all were kernel newbie at very beginning ;)
>    

Sure, unfortunately there is no real book to teach new coders on what 
they should do.

>    
>>> 2) How this can integrate a {conntrack enabled} firewall ?
>>>
>>>
>>>        
>> I can't ... It's a drawback of the module. The fact is that I only have
>> found a very little documentation about conntrack code, so I dropped the
>> idea of dealing with it.
>> But it shouldn't be difficult to update the conntrack for a kernel pro I
>> guess ;-)
>>      
> This has to be discussed before even coding ;)
>
> One packet going through this gateway has one IPv6 side and one ipv4
> side. This can be a problem to firewalling (either its ipv4, either its
> ipv6) and conntracking.
>
>
>    

It is a problem that's sure.
But as stated before, I didn't any suitable conntrack doc :(
My main thesis goal is to provide a working module, conntrack support 
would be a bonus, but for now, I cannot do it on my own because of a 
lack of conntrack knowledge.

From Olaf.Bonness@telekom.de  Wed May 25 07:23: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 1AC2013003E for ; Wed, 25 May 2011 07:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.649
X-Spam-Level: 
X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, 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 m4j5caJPGwO1 for ; Wed, 25 May 2011 07:23:30 -0700 (PDT)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 469FE13002F for ; Wed, 25 May 2011 07:23:30 -0700 (PDT)
Received: from he101251.emea1.cds.t-internal.com ([10.125.92.154]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 25 May 2011 16:23:08 +0200
Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.241]) by HE101251.emea1.cds.t-internal.com ([fe80::e428:2144:dcc5:bcce%15]) with mapi; Wed, 25 May 2011 16:23:07 +0200
From: 
To: , 
Date: Wed, 25 May 2011 16:23:06 +0200
Thread-Topic: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
Thread-Index: Acwa0ezf/s4fwdISQgO8f9pPYruL6AAFBGLw
Message-ID: 
References: Your message of "Tue, 24 May 2011 17:25:40 -0700 ." <06d801cc1a72$4735e4d0$d5a1ae70$@com> 
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 14:23:31 -0000

I disagree with Philips opinion.

I think we have to prefer IPv6 since we simply want to push back IPv4 in th=
e case that IPv4 and IPv6 connectivity are equal in quality. Otherwise we w=
ould never get rid of IPv4 since nobody will switch of IPv4 servers when he=
 sees incoming IPv4 connections.
That's why I also like the 200 ms head start for IPv6 since this seems to c=
ome close to an (IPv4) exit strategy I requested a few discussion cycles be=
fore.

Regards
        Olaf

> -----Urspr=FCngliche Nachricht-----
> Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]
> Im Auftrag von Philip Homburg
> Gesendet: Mittwoch, 25. Mai 2011 13:49
> An: Dan Wing
> Cc: v6ops@ietf.org
> Betreff: Re: [v6ops] Happy eyeballs update,
> draft-ietf-v6ops-happy-eyeballs-02
>
> In your letter dated Tue, 24 May 2011 17:25:40 -0700 you wrote:
> >This new version incorporates almost all of the feedback we
> received from
> >the working group -- support for per-prefix "P", IPv6 head
> start, fully
> >describing "Smoothed P".
>
> Two comments.
>
> It looks like a naive implementation would take at least
> Tolerance Interval
> (20ms) when both an A and AAAA are present. I wonder if that
> is really a
> good idea. I would be prefer a connection to be available to
> the application
> as soon as possible. Optionally without updating the SP value.
>
> The draft is biased towards IPv6. I wonder if that is a good
> idea. In the past,
> a bias towards IPv6 led to all kinds of problems. If IPv6 is
> better, let
> that be shown in the connection setup times. Maybe for small
> values of P,
> the algorithm should use the address in the order in which
> they were found
> in the getaddrinfo results.
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

From tjc@ecs.soton.ac.uk  Wed May 25 07:49: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 6F333130065 for ; Wed, 25 May 2011 07:49:25 -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 BhcgGefY44j0 for ; Wed, 25 May 2011 07:49: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 6AEE5130061 for ; Wed, 25 May 2011 07:49:24 -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 p4PEnHpb031328 for ; Wed, 25 May 2011 15:49:17 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p4PEnHpb031328
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1306334957; bh=KcK3W8DYlwznUOQdS5PTztqEYYM=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=cRIW+KBv1IcwnO48svPiBElx6UxAf5uiyPsQEdcVdV7Kn0N5aocZTx1OoovHl7bAo oAanXcz9eC9OrNzVWW5hBDonU3/7V9EE94seMWzSdgyxHhYCHj4Kh0Eqbp6OWNrO44 VXVAxK6bEsFfTtt9l2Clh5QsrqT0kwZn1zXRxXRQ=
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 n4OFnH0035634633Ry ret-id none; Wed, 25 May 2011 15:49:17 +0100
Received: from [IPv6:2001:630:d0:f105:226:8ff:fee4:215b] ([IPv6:2001:630:d0:f105:226:8ff:fee4:215b]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p4PEnAA3001840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 25 May 2011 15:49:10 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Tim Chown 
In-Reply-To: 
Date: Wed, 25 May 2011 15:49:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: Your message of "Tue, 24 May 2011 17:25:40 -0700 ." <06d801cc1a72$4735e4d0$d5a1ae70$@com>   
To: IPv6 Operations Working Group 
X-Mailer: Apple Mail (2.1084)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n4OFnH003563463300; tid=n4OFnH0035634633Ry; 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: p4PEnHpb031328
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 14:49:25 -0000

On 25 May 2011, at 15:23,  wrote:

> I disagree with Philips opinion.
>=20
> I think we have to prefer IPv6 since we simply want to push back IPv4 =
in the case that IPv4 and IPv6 connectivity are equal in quality. =
Otherwise we would never get rid of IPv4 since nobody will switch of =
IPv4 servers when he sees incoming IPv4 connections.
> That's why I also like the 200 ms head start for IPv6 since this seems =
to come close to an (IPv4) exit strategy I requested a few discussion =
cycles before.

I agree.

I notice the latest Chrome now has IPv4 fallback code in it, which gives =
IPv6 a 300ms head start.  Not a pure Happy Eyeballs implementation, but =
a very nice start, and much better than a 21 second fallback.

See =
http://googlechromereleases.blogspot.com/2011/05/stable-channel-update_24.=
html
and more specifically the tail of =
http://code.google.com/p/chromium/issues/detail?id=3D81686

Kudos to Lorenzo and those involved to get this out in time for IPv6 =
Day; if you have issues on the 8th just get Chrome :)

Also worth noting that in some cases you can predict the page fetch so =
the content is coming in before the user hits their enter key or clicks =
somewhere.

Tim


From behcetsarikaya@yahoo.com  Wed May 25 08:36: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 75FC4130054 for ; Wed, 25 May 2011 08:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.681
X-Spam-Level: 
X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_PAIN=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 zJsCbsWqHMEN for ; Wed, 25 May 2011 08:36:13 -0700 (PDT)
Received: from nm17.bullet.mail.sp2.yahoo.com (nm17.bullet.mail.sp2.yahoo.com [98.139.91.87]) by ietfa.amsl.com (Postfix) with SMTP id C39BD130035 for ; Wed, 25 May 2011 08:36:13 -0700 (PDT)
Received: from [98.139.91.69] by nm17.bullet.mail.sp2.yahoo.com with NNFMP; 25 May 2011 15:36:09 -0000
Received: from [98.139.91.26] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 25 May 2011 15:36:09 -0000
Received: from [127.0.0.1] by omp1026.mail.sp2.yahoo.com with NNFMP; 25 May 2011 15:36:09 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 241500.30494.bm@omp1026.mail.sp2.yahoo.com
Received: (qmail 11258 invoked by uid 60001); 25 May 2011 15:36:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306337768; bh=0mOrfqaGUZDvnoo7FSwKtu2b2ACLnHumYv093XkrbRs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AAgaoIrLv+XJRs6f6uHK8HV02mMC+eNMAVcgExh33qNiA2Guv50LWFU+FmYn6p6HyZL/5xobnj2aIEF63+ARVlJGBHaLCKsP8fXEBk9OnM/rqCGDDLmnGP0A2w3hNW2pdFn4DAWc9kIRzXIQNeGqgh/Z8SO6uyBVAsaCfOoC3os=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sMIlPtg+ulDu8Gr5nzwvedGw9o1MXAm0Ird6RqflgiouPXs3P0uhzGTD72ACmNZMr7elGRE7nbHT8oVM3LUSy+sOqrAe22ANgQl4hFuGX6BxlTTX2gPnc65xeaYJOHtS53Te6RfLUB3jc2rPEEl8/WOcDQLI35Wl3EkDIhSgmTo=;
Message-ID: <699302.4860.qm@web111415.mail.gq1.yahoo.com>
X-YMail-OSG: f6ICzQkVM1ll0AYwsQGNA6bSGVCEJf08f.qu5.T_.CjRu76 rXerBmA.Zm7WndanOzrcAAdnwES8qsLFhuCPjqHwQMDz5K6MS.kMmTo5DSQ2 d8QFnky98q6Apd5v9s1jxNhzSsnAU4YgDsByLk2PdOILwgzVBZvLp4p70uSB d_ZJwyLusmue5ApcgDtCcFLUjGXgyKBU2.Xs5GKYdKEVVHLw9T2FoDMpQEKb brIpXPZUkWHSnuHexjlIytndXZEH65iGorI75G4nAGuuvTtbdAa_jjtfOn5Z vJ9E67_mkMZ1yCpGlCTf8FA1Da8AibpWxDviHrzENTkk00h.kEE.uuRKLcPo wx_OrJDwl7h22R_Ze2XMuSoG56TGqAApH5Uo6iF9lF7L._80qtYooDjKHeFh f2yncOKncBF4Z4Q--
Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Wed, 25 May 2011 08:36:08 PDT
X-Mailer: YahooMailRC/567 YahooMailWebService/0.8.111.303096
References: <7B661D1F-F127-45A8-B3E1-DDA6ED10AD35@cisco.com> <9EFA85B3-43E6-441B-82B6-2C19084F5B39@apple.com> <4CF04D93-43FC-4D44-B3AD-D16E7F480593@gmail.com>
Date: Wed, 25 May 2011 08:36:08 -0700 (PDT)
From: Behcet Sarikaya 
To: jouni korhonen , james woodyatt 
In-Reply-To: <4CF04D93-43FC-4D44-B3AD-D16E7F480593@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "v6ops@ietf.orgWG" 
Subject: Re: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-01
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 May 2011 15:36:14 -0000

Jouni, James,

Please take a look at RFC 3316,
http://tools.ietf.org/html/rfc3316

it already defined so many of the terms and you can copy its structure.
Do not reinvent the wheel  :-).
Regards,

Behcet

> James,

> 
> Thanks for the review. Really appreciated! See my initial comments  inline.
> 
> On May 23, 2011, at 9:45 PM, james woodyatt wrote:
> 
> > On  May 22, 2011, at 11:00 , Fred Baker wrote:
> >> 
> >> The working  group last call for this draft announced last week continues 
>for another week.  Please feel free to comment on it.
> > 
> > I am in the target audience  for this document, so my contributions will seem 
>more critical than constructive  and predominantly editorial in nature, mainly 
>because I'm not confident that my  knowledge of 3GPP protocols and technologies 
>is complete.
> > 
> >  Please do not interpret my criticisms as opposition to this draft.  I very  
>much want to see a document with this information published in the RFC  series.
> > 
> > ----
> > 
> > p1. The abstract seems overly  verbose.  Here is a proposed rewrite:
> > 
> >   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.
> 
> Looks OK to me.
> 
> 
> > 
> > p2. This sentence needs updating:
> > 
> >   However, the  support for IPv6
> >   in commercially deployed networks by the end of  2010 is nearly non-
> >   existent.
> 
> Yes. Cameron also pointed  this out.
> 
> 
> > 
> > p3. In section 2.1, Terminology, I think it  would help if the abbreviations 
>were all collected into one table and expanded  once in each glossary subsection 
>entry and in each top level section where they  are used.  The terms in the 
>glossary subsection should be headed by  expanded abbreviations, and they should 
>be presented in alphabetical  order.
> 
> Hmm.. OK to collect all abbreviations. Do you mean that each of  these current 
>entries in the terminology section would become a subsection of  their own?
> 
> > 
> > p4. In section 2.1, Terminology, the definition  of "Packet Data Network" 
>introduces what seems to be a specialized term, 'packet  domain network,' that 
>goes undefined in this section.  Please  clarify.
> 
> s/domain/core
> 
> Good catch. Packet core network means the  operator internal network.
> 
> 
> > 
> > p5. In section 2.1,  Terminology, the definition of "Policy and Charging 
>Control (PCC) framework"  explains that it's used for QoS policy, which I think 
>I might understand, but  also for 'charging control' which is never defined.  It 
>also doesn't appear  to be inferable from context in the draft.  The dependent 
>clause "but  needed if dynamic policy and charging control by means of PCC rules 
>based on  user and services are desired" is therefore really not much use.  
>Please  clarify.
> 
> Ok. But I do not want to go into too much details.. PCC is a  beast of its 
>own.. brrr..
> 
> > 
> > p6. In section 2.1, Terminology,  the term "evolved packet core" is 
>introduced and used in the document, but never  defined.  Please clarify.
> 
> Oops :) Will add it.
> 
> > 
> >  p7. I think section 2.2, The concept of APN, might more properly belong in  
>section 3 [but I'm not sure].  If it really belongs in section 2, because  it 
>describes an architecture independent of the Internet Protocol, then perhaps  
>this should be explicitly mentioned here.
> 
> I have no strong opinion here.  Section 2.2 could fit nicely between current 
>Sections 3.1 and 3.2.
> 
> > 
> > p8. In section 3.1, figure 2, what does the abbreviation TE mean?   Also, I 
>gather that PLMN stands for Public Land Mobile Network, but this term is  not 
>properly introduced.  The "i.e." parentheticals in the Gn/Gp table  entry are no 
>help to me.
> > 
> 
> More stuff to terminology section.. TE  is Terminal Equipment e.g. your laptop. 
>MT would then be your  modem.
> 
> 
> > p9. In section 5.3, Prefix Delegation, the second  paragraph is mostly 
>unintelligible to me.  The citation of RFC 3633,  section 12.1, is confusing, 
>because that document doesn't place any limitations  on the delegating router, 
>only the requesting router, which is contrary to what  this draft states.  The 
>sentences that follow in that paragraph therefore  don't make sense to me.  
>Please clarify.
> 
> There was a long discussion  on this in DHC WG. The restriction applies also to 
>delegating router. When you  delegate a prefix to a requesting router, then the 
>delegating router must not  advertise (in RAs) any of these prefixes on its 
>downstream link towards  requesting router.. which would be the case in 3GPP 
>architecture. Thus all this  prefix delegation work and description here.
> 
> > 
> > p10. In  section 6, the abbreviation "DS" is used, presumably to stand for 
>'dual-stack,'  but no proper introduction is given.  I think it would be better 
>to  eliminate some uses of it, particularly in figures 5, 6 and 7, and expand it  
>fully everywhere else.
> 
> Ok.
> 
> > 
> > p11. In section 6.4, the  abbreviation IPv4v6 is introduced and used several 
>places thereafter.  I  can infer that this signals a special type of 3GPP bearer 
>that transports both  IPv4 and IPv6 at the same time, but I don't like this 
>abbreviation.  If  it's official 3GPP terminology, then please cite it and add 
>it to the  Terminology section.  Otherwise, please come up with a more 
>descriptive  term, e.g. "dual-stack IP" should work in a pinch, and use that 
>instead.
> > 
> 
> Right, will add IPv4v6 to terminology section as it is formal 3GPP  jargon.
> 
> 
> > p12. Throughout, I think it would be better to use a  hyphen when writing 
>IPv4-only and IPv6-only.
> 
> Ack.
> 
> Thanks for the  thorough review.
> 
> - Jouni
> 
> 
> > 
> > 
> > --
> >  james woodyatt 
> > member of technical  staff, core os networking
> > 
> > 
> > 
> >  _______________________________________________
> > 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 Fred.L.Templin@boeing.com  Wed May 25 08:46: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 0A6C4130060 for ; Wed, 25 May 2011 08:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.048
X-Spam-Level: 
X-Spam-Status: No, score=-6.048 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 6tXKj7PIfglV for ; Wed, 25 May 2011 08:46:06 -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 DC9A3130035 for ; Wed, 25 May 2011 08:46:05 -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 p4PFjvWm015998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2011 08:45:58 -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 p4PEtUdV024270; Wed, 25 May 2011 07:55:30 -0700 (PDT)
Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4PEtUEL024255 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 25 May 2011 07:55:30 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Wed, 25 May 2011 08:45:57 -0700
From: "Templin, Fred L" 
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "John Mann (ITS)" 
Date: Wed, 25 May 2011 08:45:55 -0700
Thread-Topic: [v6ops] Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP
Thread-Index: Acwa76D2voLkzNIFT9msE+YPCrXFvQAAnpow
Message-ID: 
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_E1829B60731D1740BB7A0626B4FAF0A65C6A6C97F2XCHNW01Vnwnos_"
MIME-Version: 1.0
Cc: v6ops v6ops WG 
Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 15:46:07 -0000

--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A6C97F2XCHNW01Vnwnos_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Remi and John,

Thanks for the input; I have made the necessary correction by removing the
non-technical text:

http://www.ietf.org/id/draft-templin-v6ops-isops-06.txt

John - I made the correction before seeing your proposed changes. I'll see =
if
it needs tweaking in the next version.

Remi - the 6rd citation is there but came earlier in the document. If you t=
hink
more is needed, please propose text.

Thanks - Fred

________________________________
From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr]
Sent: Wednesday, May 25, 2011 8:22 AM
To: John Mann (ITS); Templin, Fred L
Cc: v6ops v6ops WG
Subject: Re: [v6ops] Operational Guidance for IPv6 Deployment in IPv4 Sites=
 using ISATAP


Le 24 mai 2011 =E0 23:12, John Mann (ITS) a =E9crit :

Fred,

I like ISATAP and your draft.

I also believe this draft is useful.

But I'm not sure about
---
9. Alternative Approaches

...
IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320]
are a tribute to those in all walks of life who serve with dignity
and honor for the benefit of others.
---

a) it seems out of place

+1

in that it doesn't discuss the method used or service provided by these pro=
tocols.

Besides these protocols are experimental, whereas ISATAP is standard track.

b) is it a round-about way of praising yourself in that you are the author =
of those protocols, and of this draft?

Not also that:
- 6to4, which has a different purpose, is complementary to ISATAP (it isn't=
 an "alternative").
- If 6to4 would be nevertheless mentioned (at a time when it is known to be=
 problematic and some consider it historic), 6rd would have to be mentioned=
 too.

Suggestion: delete the section, and proceed with the remainder of the draft=
.

Regards,
RD





=3D=3D=3D=3D=3D=3D
Also in http://tools.ietf.org/html/draft-templin-v6ops-isops-05#section-9
the text "[RFC4554]" doesn't web-link to  http://tools.ietf.org/html/rfc455=
4
But I can't tell if this is a original markup problem, or draft->html conve=
rter problem.

Thanks,
    John

On 24 May 2011 07:16, Templin, Fred L > wrote:
Folks,

I am done tweaking this document now. Would appreciate
input, especially from those who have expressed interest
in ISATAP over the past several weeks.

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: Monday, May 23, 2011 12:59 PM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-templin-v6ops-isops-05.txt

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

       Title           : Operational Guidance for IPv6 Deployment in IPv4 S=
ites using ISATAP
       Author(s)       : Fred L. Templin
       Filename        : draft-templin-v6ops-isops-05.txt
       Pages           : 26
       Date            : 2011-05-23

  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.  It is also
  expected that more and more IPv6-only devices will be deployed within
  the site over time.  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-05.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-05.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
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

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


--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A6C97F2XCHNW01Vnwnos_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Hi Remi and John,


 


Thanks for the input; I have made the necessary co=
rrection=20
by removing the


non-technical text:


 


http://www=
.ietf.org/id/draft-templin-v6ops-isops-06.txt


 


John - I made the correction before seeing your pr=
oposed=20
changes. I'll see if


it needs tweaking in the next version.


 


Remi - the 6rd citation is there but came earlier =
in the=20
document. If you think


more is needed, please propose text.=



 


Thanks - Fred



  

  

  From: R=E9mi Despr=E9s=20
  [mailto:remi.despres@free.fr] 
Sent: Wednesday, May 25, 2011 8:=
22=20
  AM
To: John Mann (ITS); Templin, Fred L
Cc: v6ops v6o=
ps=20
  WG
Subject: Re: [v6ops] Operational Guidance for IPv6 Deploymen=
t in=20
  IPv4 Sites using ISATAP


  


  

  
Le 24 mai 2011 =E0 23:12, John Mann (ITS) a =E9crit :

  
Fred,
    


    
I like ISATAP and your draft.

  

I also believe this draft is useful.

  


  

  

    
But I'm not sure about

    
---

    
9. Alternative Approaches

<=
/DIV>...
    
IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL=20
    [RFC5320]
are a tribute to those in all walks of life who serve with=
=20
    dignity
and honor for the benefit of others.

    
---

    


    
a) it seems out of place

  

+1

  


  

    

    
in that it doesn't discuss the method used or service provided by =
these=20
    protocols.

  

Besides these protocols are experimental, whereas ISATAP i=
s=20
  standard track.

  


  

    

    
b) is it a round-about way of praising yourself in that you are th=
e=20
    author of those protocols, and of this draft?

  


  
Not also that:

  
- 6to4, which has a different purpose, is complementary to ISATAP (i=
t=20
  isn't an "alternative").

  
- If 6to4 would be nevertheless mentioned (at a time when it is know=
n to=20
  be problematic and some consider it historic), 6rd would have to be menti=
oned=20
  too.

  


  
Suggestion: delete the section, and proceed with the remainder of th=
e=20
  draft.

  


  
Regards,

  
RD

  


  


  


  


  

    

    


    
=3D=3D=3D=3D=3D=3D

    
Also in http://tools.ietf.org/html/draft-templin-v6ops-isops-05#section-9
    
the text "[RFC4554]" doesn't web-li=
nk to=20
     http://tools.ietf.org/html/=
rfc4554

    
But I can't tell if this is a original markup problem, or=20
    draft->html converter problem.

    


    
Thanks,

    
    John

    


    

    
On 24 May 2011 07:16, Templin, Fred L <Fred.L.Templin@boeing.com=
>=20
    wrote:

    
Folks,

I=20
      am done tweaking this document now. Would appreciate
input, especi=
ally=20
      from those who have expressed interest
in ISATAP over the past sev=
eral=20
      weeks.

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

-----Original=20
      Message-----
From: i-d-announce-bounces@ie=
tf.org=20
      [mailto:i-d-announce-bounces@ie=
tf.org]=20
      On Behalf Of internet-drafts@ietf.org=

Sent:=20
      Monday, May 23, 2011 12:59 PM
To: i-d-announce@ietf.org
Su=
bject:=20
      I-D Action: draft-templin-v6ops-isops-05.txt

A New Internet-Dr=
aft=20
      is available from the on-line Internet-Drafts directories.

&nb=
sp;=20
           Title           : Operat=
ional=20
      Guidance for IPv6 Deployment in IPv4 Sites using ISATAP
  &nb=
sp;=20
         Author(s)       : Fred L. Templin
&nbs=
p;=20
           Filename        :=20
      draft-templin-v6ops-isops-05.txt
       Pages=
=20
                : 26
       =
;Date=20
                 : 2011-05-23

  M=
any=20
      end user sites in the Internet today still have predominantly
&nbs=
p;=20
      IPv4 internal infrastructures.  These sites range in size from=20
      small
  home/office networks to large corporate enterprise=20
      networks, but
  share the commonality that IPv4 continues to=
=20
      provide satisfactory
  internal routing and addressing servic=
es=20
      for most applications.  As
  more and more IPv6-only ser=
vices=20
      are deployed in the Internet,
  however, end user devices wit=
hin=20
      such sites will increasingly require
  at least basic IPv6=20
      functionality for external access.  It is also
  expecte=
d=20
      that more and more IPv6-only devices will be deployed within
 =
; the=20
      site over time.  This document therefore provides=20
      operational
  guidance for deployment of IPv6 within predomin=
antly=20
      IPv4 sites using
  the Intra-Site Automatic Tunnel Addressing=
=20
      Protocol (ISATAP).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-templin-v6o=
ps-isops-05.txt

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

This=20
      Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-templin-v6op=
s-isops-05.txt
_______________________________________________
I-=
D-Announce=20
      mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft=20
      directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
____=
___________________________________________
v6ops=20
      mailing list
v6ops@ietf.org<=
BR>https://www.ietf.org/mailman/listinfo/v6ops

__________________________________________=
_____
v6ops=20
    mailing list
v6ops@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/v6ops



--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A6C97F2XCHNW01Vnwnos_--

From cb.list6@gmail.com  Wed May 25 09:01: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 ECD9EE071D for ; Wed, 25 May 2011 09:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.088
X-Spam-Level: 
X-Spam-Status: No, score=-3.088 tagged_above=-999 required=5 tests=[AWL=-0.090, 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 yJWBFxo+IMhH for ; Wed, 25 May 2011 09:01:45 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E4332E0718 for ; Wed, 25 May 2011 09:01:44 -0700 (PDT)
Received: by ewy19 with SMTP id 19so3224836ewy.31 for ; Wed, 25 May 2011 09:01:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/iy0v+Vce0PMKpTDrLezc24T6tsCblxUVSApdtmTous=; b=bBVXxLI8RypQFGrX9N9y0zkrrmdwDSe1Nky7OtFlGLPIhHDUXqiYKjaTlKveIhBRDh ZbKK9oJY5L8lJmljvUthgHizqwTk9EXHIlmWzZbDpoqwn5VWCBI6LKPb0FO5kks8mOMX DYWSQyH71eSxO7rq3w3hDEC2QT6wQQ+C1KGlI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IQUb2BpAaYkDalvgFRjCs/nZ32qtW9DCnMrUh5nnY8fB1LkuDV1fRIUZ15B5D1oOrt Wi13I2YDqWQgnWXzyzWuWQv8qzVeyC2bg7m6+5njjHPN22DzSJICD56yyLbx0NPbWfb1 t55w7EbflliM50kH+Mca8RyNY6+iywtuJbHIE=
MIME-Version: 1.0
Received: by 10.14.44.151 with SMTP id n23mr1730763eeb.124.1306339303997; Wed, 25 May 2011 09:01:43 -0700 (PDT)
Received: by 10.14.48.14 with HTTP; Wed, 25 May 2011 09:01:43 -0700 (PDT)
Received: by 10.14.48.14 with HTTP; Wed, 25 May 2011 09:01:43 -0700 (PDT)
In-Reply-To: 
References: <06d801cc1a72$4735e4d0$d5a1ae70$@com>    
Date: Wed, 25 May 2011 09:01:43 -0700
Message-ID: 
From: Cameron Byrne 
To: Tim Chown 
Content-Type: multipart/alternative; boundary=0015175cfd0a2bc34f04a41bd2fe
Cc: IPv6 Operations Working Group 
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 16:01:46 -0000

--0015175cfd0a2bc34f04a41bd2fe
Content-Type: text/plain; charset=ISO-8859-1

On May 25, 2011 7:49 AM, "Tim Chown"  wrote:
>
>
> On 25 May 2011, at 15:23,  wrote:
>
> > I disagree with Philips opinion.
> >
> > I think we have to prefer IPv6 since we simply want to push back IPv4 in
the case that IPv4 and IPv6 connectivity are equal in quality. Otherwise we
would never get rid of IPv4 since nobody will switch of IPv4 servers when he
sees incoming IPv4 connections.
> > That's why I also like the 200 ms head start for IPv6 since this seems
to come close to an (IPv4) exit strategy I requested a few discussion cycles
before.
>
> I agree.
>

+1 for v6 head start

Cb

> I notice the latest Chrome now has IPv4 fallback code in it, which gives
IPv6 a 300ms head start.  Not a pure Happy Eyeballs implementation, but a
very nice start, and much better than a 21 second fallback.
>
> See
http://googlechromereleases.blogspot.com/2011/05/stable-channel-update_24.html
> and more specifically the tail of
http://code.google.com/p/chromium/issues/detail?id=81686
>
> Kudos to Lorenzo and those involved to get this out in time for IPv6 Day;
if you have issues on the 8th just get Chrome :)
>
> Also worth noting that in some cases you can predict the page fetch so the
content is coming in before the user hits their enter key or clicks
somewhere.
>
> Tim
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--0015175cfd0a2bc34f04a41bd2fe
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On May 25, 2011 7:49 AM, "Tim Chown" <tjc@ecs.soton.ac.uk> wrote:

>

>

> On 25 May 2011, at 15:23, <Olaf.Bonness@telekom.de> wrote:

>

> > I disagree with Philips opinion.

> >

> > I think we have to prefer IPv6 since we simply want to push back =
IPv4 in the case that IPv4 and IPv6 connectivity are equal in quality. Othe=
rwise we would never get rid of IPv4 since nobody will switch of IPv4 serve=
rs when he sees incoming IPv4 connections.


> > That's why I also like the 200 ms head start for IPv6 since t=
his seems to come close to an (IPv4) exit strategy I requested a few discus=
sion cycles before.

>

> I agree.

>


+1 for v6 head start


Cb


> I notice the latest Chrome now has IPv4 fallback code in it, which =
gives IPv6 a 300ms head start. =A0Not a pure Happy Eyeballs implementation,=
 but a very nice start, and much better than a 21 second fallback.

>

> See http://googlechromereleases.blogspot.com/2011/05/s=
table-channel-update_24.html

> and more specifically the tail of http://code.google.com/p/chromium/issues=
/detail?id=3D81686

>

> Kudos to Lorenzo and those involved to get this out in time for IPv6 D=
ay; if you have issues on the 8th just get Chrome :)

>

> Also worth noting that in some cases you can predict the page fetch so=
 the content is coming in before the user hits their enter key or clicks so=
mewhere.

>

> Tim

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

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




--0015175cfd0a2bc34f04a41bd2fe--

From dwing@cisco.com  Wed May 25 09:14: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 0B723E080F for ; Wed, 25 May 2011 09:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.491
X-Spam-Level: 
X-Spam-Status: No, score=-111.491 tagged_above=-999 required=5 tests=[AWL=1.108, BAYES_00=-2.599, GB_I_LETTER=-2, 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 RuGrzkbvgguE for ; Wed, 25 May 2011 09:14:01 -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 5CAB8E080B for ; Wed, 25 May 2011 09:14:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2017; q=dns/txt; s=iport; t=1306340041; x=1307549641; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=YQfOrGHLJfVWYboUQ09YeFtcYg4Cn4IeI5fkEcTTXqs=; b=D5fw/zHokWfJu784pBWZUM1s0vHuBkomiXUiY3XdxHdkUYxG26HZG0aN XfuqjQ5dFJEGaIZzbjnyNyiyJfjJ1P9g+AYRGrFwIF1bkGXTfFpzSI+Hy qsXHFd6GTBTTfpqC3MG7GONlpG139yqOWtrvxwGG8ky1fL3j2/tlHsCwN 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhMBAHgp3U2rRDoH/2dsb2JhbACXZ4FkjGF4iHCea513hhwEhluYew
X-IronPort-AV: E=Sophos;i="4.65,268,1304294400"; d="scan'208";a="454151232"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 25 May 2011 16:13:55 +0000
Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4PGDtNQ022042; Wed, 25 May 2011 16:13:55 GMT
From: "Dan Wing" 
To: "'Philip Homburg'" 
References: Your message of "Tue, 24 May 2011 17:25:40 -0700 ." <06d801cc1a72$4735e4d0$d5a1ae70$@com> 
In-Reply-To: 
Date: Wed, 25 May 2011 09:13:55 -0700
Message-ID: <099201cc1af6$bf214f50$3d63edf0$@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: Acwa0dwYyDukdzdlSn2egxcf6t1ZYQAI5Qpw
Content-Language: en-us
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 16:14:02 -0000

> -----Original Message-----
> From: pch-b2B3A6689@u-1.phicoh.com [mailto:pch-b2B3A6689@u-
> 1.phicoh.com] On Behalf Of Philip Homburg
> Sent: Wednesday, May 25, 2011 4:49 AM
> To: Dan Wing
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-
> eyeballs-02
> 
> In your letter dated Tue, 24 May 2011 17:25:40 -0700 you wrote:
> >This new version incorporates almost all of the feedback we received
> from
> >the working group -- support for per-prefix "P", IPv6 head start,
> fully
> >describing "Smoothed P".
> 
> Two comments.
> 
> It looks like a naive implementation would take at least Tolerance
> Interval
> (20ms) when both an A and AAAA are present. I wonder if that is really
> a
> good idea. I would be prefer a connection to be available to the
> application
> as soon as possible. 

Then Tolerance Interval is set to 0ms.

> Optionally without updating the SP value.

If SP isn't adjusted, we'll blindly beat the network and server.  This
is certainly easiest to implement.  It also creates the most impact to
the network and the server.

> The draft is biased towards IPv6. I wonder if that is a good idea. In
> the past, a bias towards IPv6 led to all kinds of problems. 

> If IPv6 is better, let
> that be shown in the connection setup times. Maybe for small values of
> P, the algorithm should use the address in the order in which they were
> found in the getaddrinfo results.

Yes, there is a slight IPv6 bias when IPv4 and IPv6 are both connecting 
quickly.  

My own testing shows variance in IPv4 and IPv6 connection setup times
to the same hosts.  For that reason, using Tolerance Interval allows
improving upon a "first connection wins" algorithm.  I want to prefer
IPv6 because the IPv4 path is more likely to have NATs (home NAT or
carrier NAT) which will prevent deployment of new transports (e.g.,
SCTP), have designed or enforced port limits, and all the other
evils of IPv4 address sharing.

-d




From dougb@dougbarton.us  Wed May 25 10:26: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 37D8CE068C for ; Wed, 25 May 2011 10:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.824
X-Spam-Level: 
X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 t0j3-JtrQR8Q for ; Wed, 25 May 2011 10:25:59 -0700 (PDT)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 48B3CE0686 for ; Wed, 25 May 2011 10:25:59 -0700 (PDT)
Received: (qmail 20857 invoked by uid 399); 25 May 2011 17:25:55 -0000
Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 25 May 2011 17:25:55 -0000
X-Originating-IP: 65.241.43.5
X-Sender: dougb@dougbarton.us
Message-ID: <4DDD3BA3.7090701@dougbarton.us>
Date: Wed, 25 May 2011 10:25:55 -0700
From: Doug Barton 
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10
MIME-Version: 1.0
To: Olaf.Bonness@telekom.de
References: Your message of "Tue, 24 May 2011 17:25:40 -0700 ."	<06d801cc1a72$4735e4d0$d5a1ae70$@com>	 
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
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 17:26:00 -0000

On 05/25/2011 07:23, Olaf.Bonness@telekom.de wrote:
> I think we have to prefer IPv6 since we simply want to push back IPv4 in the case that IPv4 and IPv6 connectivity are equal in quality. Otherwise we would never get rid of IPv4 since nobody will switch of IPv4 servers when he sees incoming IPv4 connections.
> That's why I also like the 200 ms head start for IPv6 since this seems to come close to an (IPv4) exit strategy I requested a few discussion cycles before.

+1 on both purpose and reasoning.


-- 

	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 jhw@apple.com  Wed May 25 11:15: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 40C1AE0756 for ; Wed, 25 May 2011 11:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.216
X-Spam-Level: 
X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 ftx3iWkvm4r1 for ; Wed, 25 May 2011 11:15:14 -0700 (PDT)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id B615AE0717 for ; Wed, 25 May 2011 11:15:14 -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 <0LLR00I8IJUF2X70@mail-out.apple.com> for v6ops@ietf.org; Wed, 25 May 2011 11:15:14 -0700 (PDT)
X-AuditID: 1180711d-b7c70ae00000719a-b9-4ddd473173ba
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 98.09.29082.1374DDD4; Wed, 25 May 2011 11:15:14 -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 <0LLR00LH4K1D9P20@koseret.apple.com> for v6ops@ietf.org; Wed, 25 May 2011 11:15:13 -0700 (PDT)
From: james woodyatt 
In-reply-to: 
Date: Wed, 25 May 2011 11:15:13 -0700
Message-id: <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com>
References: 
To: "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.1232)
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 18:15:15 -0000

On May 25, 2011, at 04:49 , Philip Homburg wrote:
> 
> The draft is biased towards IPv6. I wonder if that is a good idea. In the past, a bias towards IPv6 led to all kinds of problems. If IPv6 is better, let that be shown in the connection setup times.

I have to break from the majority on this and concur with Mr. Homburg.  These little 200 milliseconds delays will add up quickly with repetition.

Picture in your mind a user interface for letting a human configure the bias between IPv4 and IPv6.  The proper way to present this would be a slider, where the middle position means without any bias between IPv4 and IPv6, and the distance from the middle position, in either direction, corresponds to the amount of time a user is willing to wait for a connection over a specific network layer protocol when the other one would give them service sooner.

Can anyone here imagine a reasonable situation where an ordinary user would want to position that slider anywhere other than the middle position?

I can imagine situations where a certain class of advanced user might want, for troubleshooting purposes, to disable one or the other network layer entirely, but I can't see why I should be required by standards action to set a default for that conceptual slider on the vast majority of ordinary users to anywhere but the exact middle.

Why, oh why, would we ever think it was smart to force these delays in a standards track document?


--
james woodyatt 
member of technical staff, core os networking




From jouni.nospam@gmail.com  Wed May 25 11:18: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 7F345E0756 for ; Wed, 25 May 2011 11:18:43 -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 6prkanf8bsCh for ; Wed, 25 May 2011 11:18:42 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE3F7E0717 for ; Wed, 25 May 2011 11:18:41 -0700 (PDT)
Received: by ewy19 with SMTP id 19so3277797ewy.31 for ; Wed, 25 May 2011 11:18:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=8zgA38ENIh7Xr8J997aAmRFA4+qJoxfyfFW7ONrmFD4=; b=omDnWgDAR7TSLc5dx76E7rvKFfbBRWmqF6g7Dj0LRwqGt6MJSmwl6DBg8fFBsmVdM2 myiDKM78Txy6uWr2xMUVkvG9/LgXC8RMmd4TskAlHIuFTXXaOhGGYaqE6rttoU5aM8cI jbUv6Cpxps+hH8ZzgvjNe3EOhtv7QwQOSl0SM=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=RhQzcZ1Liqohu+WmvTKCBMpGZHaKaY0ytcZZFcW5BOZ98kPbgqepArsunQQArqsT61 BRPT6fIEF4KgwxQ0V9rHG7XUnqf8PP02fwCQsY39JQV2WvCOzPYqMU27XJS8oZg1jYJQ 38qjZMAaOi4j9wNAITABV08+v0J8BIEz+PJfI=
Received: by 10.213.3.196 with SMTP id 4mr2035109ebo.50.1306347521012; Wed, 25 May 2011 11:18:41 -0700 (PDT)
Received: from a83-245-209-233.elisa-laajakaista.fi (a83-245-209-233.elisa-laajakaista.fi [83.245.209.233]) by mx.google.com with ESMTPS id y14sm3925994eeh.17.2011.05.25.11.18.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2011 11:18:40 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <826542.7269.qm@web111406.mail.gq1.yahoo.com>
Date: Wed, 25 May 2011 21:18:37 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <15B2EFC5-F724-43A0-B619-637744379BA1@gmail.com>
References: <3CF3E905-E526-4847-A9AC-D6A28828B208@cisco.com>  <826542.7269.qm@web111406.mail.gq1.yahoo.com>
To: Behcet Sarikaya 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations Working Group 
Subject: Re: [v6ops] draft-sarikaya-v6ops-prefix-delegation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 18:18:43 -0000

Hello,

I read the draft and have few issues with it. The draft attempts to give =
generic guidance about prefix delegation in mobile networks. However, =
except for mentioning "WiMAX" once in the introduction and making a =
reference to 802.16 link model RFC, the draft is mostly about 3GPP GPRS =
or EPC (or some mixture of those). Clear distinction should be made when =
the text applies to some specific architecture and when it does not..=20

Regarding the shared vs. p2p link model and DAD text I do not understand =
why those even needs to be discussed here.

The text should make it clear when the delegated prefix is /64 and when =
something else. E.g. in 3GPP architecture a PGW acting as a requesting =
router would only be asking for /64s.

In Section 3.1 it is assumed that the GGSN/PGW implements a relay, which =
is used by the client also residing in the same GGSN/PGW. I assume the =
attempt is to circumvent the fact that the client cannot unicast a =
solicitation to the server but a relay can. This is purely an =
implementation/deployment option and I do not see a reason to assume =
such collocated functionality.

One could also argue whether steps 2-5 in Figure 2 do happen before step =
6. In 3GPP networks they happen in a middle of current step 6 (which is =
referenced in this step).

The last paragraph in Section 3.1 is somehow misplaced. I would give it =
its own section. It also took me a while to figure out what was meant =
here.. The current text is rather confusing regarding which node has =
which role in each step. The text should be more explicit when the =
requesting router is the MN and when it is the AR, and also how these =
cases differ from the rest of the system point of view.

What mobile architecture Section 3.2 refers to? If it is a "generic" =
architecture, I am not sure why RFC2119 language is needed.

Section 3.4 talks about renumbering. It should be made clear whether the =
delegated prefix is used to number the MN itself or whether the MN was =
the requesting routing. In certain mobile architectures renumbering is =
not considered at all i.e. prefixes always have an infinite lifetime. If =
renumbering is needed that would mean tearing down the connection. Also =
in certain mobile architectures adding new prefixes is either possible =
or not depending which entity was the requesting router.

Why Section 3.5.1? If it needs to be there, a bit more text is needed to =
build to the context around FMIP6.

Section 3.5.2: s/IMNI/IMSI
Also I would not say MAC address corresponds to IMSI. IMEI could be a =
better choice.

Section 3.5.3: What is "broadcasting prefixes" ? For prefixes used for =
documentation purposes see RFC5156.


I have hard time to see the value of this document in its current form. =
The overall presentation should be far more focused and more specific on =
topics it covers. For the parts it documents existing systems those has =
to be as they are in respective SDO specs. For those parts that are =
generic recommendations, I would like to see more reasoning why given =
recommendations are considered good. Mixing existing architectures and =
generic architectures in the same context and figures make reading =
really hard.

- Jouni



On May 19, 2011, at 1:00 PM, Behcet Sarikaya wrote:

> I submitted a revision based on the online and some offline comments =
received so far,
> The new draft draft-sarikaya-v6ops-prefix-delegation-04.txt should be =
accessible
> soon.
>=20
> Regards,
>=20
> Behcet
>=20
>=20
>=20
>>=20
>> _is_ this best current practice?
>>=20
>> does this conflict when DHCPv6 PD is used between UE and AR?
>> I'm concerned about section 3.2, where the AR DHCPv6 relay should add =
an=20
>> IA_PD option to the DHCPv6 client - server exchange.
>> has that new protocol behaviour been reviewed in the DHC WG? in other =
scenarios=20
>> that functionality has been solved either with snooping or the =
proposed RAAN=20
>> option.
>>=20
>> cheers,
>> Ole
>>=20
>>> The authors have asked me about=20
>>> http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation
>>>   "DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile=20
>> Networks",
>>>   Behcet Sarikaya, Frank Xia, 19-Apr-11
>>>=20
>>> When we discussed this at IETF-79, a number of views were expressed,=20=

>> varying from "let's adopt this as a working group draft and =
immediately=20
>> publish as a BCP" to "ignore and abandon this draft, if anything it=20=

>> belongs in some other SDO or NOG", and all points in between. Several =
folks=20
>> indicated that they would post comments to the list, and the comments =
didn't=20
>> materialize.
>>>=20
>>> Question for the assembled hordes: what needs to happen in this =
draft to=20
>> make it useful/interesting for mobile network operators? What needs =
to happen to=20
>> make it interesting to other operators?
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>=20
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From simon.perreault@viagenie.ca  Wed May 25 11:30: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 7490F13008A for ; Wed, 25 May 2011 11:30:39 -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 VMDOSYEjqkDa for ; Wed, 25 May 2011 11:30:38 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id B0B0B130086 for ; Wed, 25 May 2011 11:30:38 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2980721CC8 for ; Wed, 25 May 2011 14:30:37 -0400 (EDT)
Message-ID: <4DDD4ACC.2050408@viagenie.ca>
Date: Wed, 25 May 2011 14:30:36 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9
MIME-Version: 1.0
To: v6ops@ietf.org
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com>
In-Reply-To: <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 18:30:39 -0000

On 2011-05-25 14:15, james woodyatt wrote:
> Can anyone here imagine a reasonable situation where an ordinary user
> would want to position that slider anywhere other than the middle
> position?

IPv6 is less likely to have a NAT in the path, so an ordinary user is
better off preferring IPv6. (No NAT means less breakage.)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From jhw@apple.com  Wed May 25 11:38: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 7586913008C for ; Wed, 25 May 2011 11:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.312
X-Spam-Level: 
X-Spam-Status: No, score=-106.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 291IAjCimm9y for ; Wed, 25 May 2011 11:38:53 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id E394213003D for ; Wed, 25 May 2011 11:38:53 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LLR00I12L3Z2XH0@mail-out.apple.com> for v6ops@ietf.org; Wed, 25 May 2011 11:38:53 -0700 (PDT)
X-AuditID: 11807137-b7cd4ae000003108-5b-4ddd4cbd0bfa
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 relay16.apple.com (Apple SCV relay) with SMTP id DF.1E.12552.DBC4DDD4; Wed, 25 May 2011 11:38:53 -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 <0LLR00L5YL4T9P30@koseret.apple.com> for v6ops@ietf.org; Wed, 25 May 2011 11:38:53 -0700 (PDT)
From: james woodyatt 
In-reply-to: <4DDD4ACC.2050408@viagenie.ca>
Date: Wed, 25 May 2011 11:38:53 -0700
Message-id: <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca>
To: Simon Perreault 
X-Mailer: Apple Mail (2.1232)
X-Brightmail-Tracker: AAAAAA==
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 18:38:54 -0000

On May 25, 2011, at 11:30 , Simon Perreault wrote:
> 
> IPv6 is less likely to have a NAT in the path, so an ordinary user is better off preferring IPv6. (No NAT means less breakage.)

Nonsense.  Happy Eyeballs chooses another path when it encounters breakage due to a NAT barrier.  The ordinary users with which I'm most acquainted will all be better off with IPv4/NAT connections that complete 200 ms sooner than otherwise functionally equivalent IPv6 connections.


--
james woodyatt 
member of technical staff, core os networking




From simon.perreault@viagenie.ca  Wed May 25 11:45: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 EDE2F1300A2 for ; Wed, 25 May 2011 11:45: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 927HqiSYCbON for ; Wed, 25 May 2011 11:45:07 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 28E6B1300A0 for ; Wed, 25 May 2011 11:45:07 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7065021F23; Wed, 25 May 2011 14:45:05 -0400 (EDT)
Message-ID: <4DDD4E30.2050904@viagenie.ca>
Date: Wed, 25 May 2011 14:45:04 -0400
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9
MIME-Version: 1.0
To: james woodyatt 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>
In-Reply-To: <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 18:45:08 -0000

On 2011-05-25 14:38, james woodyatt wrote:
> On May 25, 2011, at 11:30 , Simon Perreault wrote:
>> 
>> IPv6 is less likely to have a NAT in the path, so an ordinary user
>> is better off preferring IPv6. (No NAT means less breakage.)
> 
> Nonsense.  Happy Eyeballs chooses another path when it encounters
> breakage due to a NAT barrier.

I'm not following you.

Happy eyeballs chooses another path when it is unable to establish  an
outbound connection (e.g. when contacting a rendez-vous server). That's
not the kind of breakage I'm talking about.

The NAT breakage I'm talking about occurs after the initial connection,
when the app tries to receive a new connection from a peer (e.g. after
having published its IP address on the rendez-vous server). Happy
eyeballs is not in the picture at this stage.

If happy eyeballs chooses IPv6 in the first place, it is less likely
that there will be a NAT, and the peer-to-peer connection in the second
step is more likely to work.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From cb.list6@gmail.com  Wed May 25 11:54: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 7ABEC13007D for ; Wed, 25 May 2011 11:54:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.38
X-Spam-Level: 
X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=0.219,  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 oQ91PVhyQJp0 for ; Wed, 25 May 2011 11:54:43 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D671130077 for ; Wed, 25 May 2011 11:54:43 -0700 (PDT)
Received: by eye13 with SMTP id 13so2008eye.31 for ; Wed, 25 May 2011 11:54:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fGVj/gLpzh6d/Fz0AdFG4JVxgSIkk9SAYFAlnUEk+2E=; b=bhCf1E3D+6hd5+qo15QRCqG3daIU1f6VtbhUFLo+0tbtx0Ai1s0PYxve3iwgjZ2KVX jI9Yyyq5IYTjHjMQRXW+LTEHx+DV4aKGWLiWPMkDQFIexW4oQgVLo2FusrcbCqBQG95N a41j1bR3pOz3KUhYsb5v+UyNttWjNqcyneVaM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WKmlXS54BtqVHZdABIzTPKJGMNmTe+7NVdTavmgLdAyGrsBxlyqHO66Y3UHW5nC1E1 Y70gS67hXMl9bJFo6bTu0PMjvr9oX9ie7zCI+mrcmkCOH+ctptfZ00F3m8MQNHc18Uep iHABMg/uRBLs1bp6bVHn0m21HSDumKzoGvsdM=
MIME-Version: 1.0
Received: by 10.14.99.3 with SMTP id w3mr1668689eef.28.1306349682212; Wed, 25 May 2011 11:54:42 -0700 (PDT)
Received: by 10.14.48.14 with HTTP; Wed, 25 May 2011 11:54:42 -0700 (PDT)
In-Reply-To: <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>
Date: Wed, 25 May 2011 11:54:42 -0700
Message-ID: 
From: Cameron Byrne 
To: james woodyatt 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 18:54:44 -0000

On Wed, May 25, 2011 at 11:38 AM, james woodyatt  wrote:
> On May 25, 2011, at 11:30 , Simon Perreault wrote:
>>
>> IPv6 is less likely to have a NAT in the path, so an ordinary user is be=
tter off preferring IPv6. (No NAT means less breakage.)
>
> Nonsense. =A0Happy Eyeballs chooses another path when it encounters break=
age due to a NAT barrier. =A0The ordinary users with which I'm most acquain=
ted will all be better off with IPv4/NAT connections that complete 200 ms s=
ooner than otherwise functionally equivalent IPv6 connections.
>

James, i completely understand, we are suggesting giving the user a
possibly slightly worse experience by default.  I struggle with this
myself.

As i have stated on the list before, if we keep pushing IPv4 at the
browser level (aka not pushing IPv6), the network operators have to
keep investing in more IPv4 peering, NATs, and other IPv4 technologies
since that is where the traffic is at.  Without IPv6 traffic volumes,
there will be no investment to fix IPv6 latency, peering, and other
investments.... wait and it will come is not sufficient.... we have
learned that over the last 10 years of stalemate in IPv6 adoption. It
will be yet another chicken and egg ... people have IPv6 addresses but
the browser does not use it... because the peering on IPv6 is not
robust ...because there is no traffic ...and there is no traffic
because users use NAT444 instead because its faster... so the browers
use IPv4 and not IPv6... so the network operator does not invest in
IPv6 improvements...so ipv6 is slower, so the browser choose ipv4 ...
and that logic loops around indefinitely.

We (the IETF) need to see the big picture and bypass the obvious
chicken and egg issue that happy eyeballs may cause.  We need to
change that chicken and egg stalemate and turn it into fortuitous
cycle of increasing IPv6 traffic volumes and investment that will lead
us out of this IPv4 NAT mess.

IPv6 investments will not happen because people are "doing the right
thing" or taking the "high road"... IPv6 investments and improvements
will happen when the traffic makes it happen, and that starts at the
user.

Cameron

From jhw@apple.com  Wed May 25 12:23: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 615661300C7 for ; Wed, 25 May 2011 12:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.369
X-Spam-Level: 
X-Spam-Status: No, score=-106.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 EdpmhY9FjDYO for ; Wed, 25 May 2011 12:23:10 -0700 (PDT)
Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id CEB491300B8 for ; Wed, 25 May 2011 12:23:10 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LLR00L3AN437581@mail-out.apple.com> for v6ops@ietf.org; Wed, 25 May 2011 12:23:10 -0700 (PDT)
X-AuditID: 11807137-b7cd4ae000003108-df-4ddd571ec9bb
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 relay16.apple.com (Apple SCV relay) with SMTP id 80.CD.12552.E175DDD4; Wed, 25 May 2011 12:23:10 -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 <0LLR00LFWN6L9P40@koseret.apple.com> for v6ops@ietf.org; Wed, 25 May 2011 12:23:10 -0700 (PDT)
From: james woodyatt 
In-reply-to: 
Date: Wed, 25 May 2011 12:23:09 -0700
Message-id: <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com> 
To: "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.1232)
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 19:23:11 -0000

On May 25, 2011, at 11:54 , Cameron Byrne wrote:
> 
> We need to change that chicken and egg stalemate and turn it into fortuitous cycle of increasing IPv6 traffic volumes and investment that will lead us out of this IPv4 NAT mess.

With all due respect, no... no, we [the IETF] do not.

The IETF needs to preserve the utility of the Internet and the welfare of its users during the transition of the Internet to a dual-stack IPv4/IPv6 phase of operations.  The IETF must resist the urge to use the dubious power of standards documentation to serve the parochial interests of the network operator community in a misguided drive to seek yet another externality to exploit at the significant cost to the welfare of all Internet users.

If network operators and content providers want their subscribers and correspondents to prefer IPv6 over IPv4, then let happy eyeballs have no bias between the two, and let the Mystic Knights of Traffic Engineering make it so.  To preserve the welfare of the Internet user community, IETF must allow the invisible brass knuckles of The Market to sort out which network layer shall win in the end.


--
james woodyatt 
member of technical staff, core os networking




From dr@cluenet.de  Wed May 25 12:23: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 68D721300D2 for ; Wed, 25 May 2011 12:23: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 SwxGVAUcoZHe for ; Wed, 25 May 2011 12:23: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 A1CAE1300D1 for ; Wed, 25 May 2011 12:23:18 -0700 (PDT)
Received: by mail1.cluenet.de (Postfix, from userid 500) id D18AD1080C8; Wed, 25 May 2011 21:23:13 +0200 (CEST)
Date: Wed, 25 May 2011 21:23:13 +0200
From: Daniel Roesen 
To: v6ops@ietf.org
Message-ID: <20110525192313.GA7684@srv03.cluenet.de>
Mail-Followup-To: v6ops@ietf.org
References: <06d801cc1a72$4735e4d0$d5a1ae70$@com>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.17 (2007-11-01)
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 19:23:19 -0000

On Wed, May 25, 2011 at 04:23:06PM +0200, Olaf.Bonness@telekom.de wrote:
> I disagree with Philips opinion.
> 
> I think we have to prefer IPv6 since we simply want to push back IPv4
> in the case that IPv4 and IPv6 connectivity are equal in quality.

+1 from another operator.

A bias towards IPv6 is absolutely imperative to get rid of the LSNs
(at least dampen the scaling required) which will be widely deployed
to continue riding the dead horse IPv4.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

From dwcarder@wisc.edu  Wed May 25 12: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 EC5B51300BE for ; Wed, 25 May 2011 12:46:06 -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 Rsf4ECyO4jiK for ; Wed, 25 May 2011 12:46:06 -0700 (PDT)
Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by ietfa.amsl.com (Postfix) with ESMTP id 7420A1300B8 for ; Wed, 25 May 2011 12:46:06 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII
Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LLR00202O8T0Q00@smtpauth3.wiscmail.wisc.edu> for v6ops@ietf.org; Wed, 25 May 2011 14:46:05 -0500 (CDT)
Received: from ricotta.doit.wisc.edu (ricotta.doit.wisc.edu [144.92.67.161]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LLR00FN5O8R1D50@smtpauth3.wiscmail.wisc.edu> for v6ops@ietf.org; Wed, 25 May 2011 14:46:05 -0500 (CDT)
Date: Wed, 25 May 2011 14:46:03 -0500
From: "Dale W. Carder" 
In-reply-to: <20110525192313.GA7684@srv03.cluenet.de>
To: v6ops@ietf.org
Message-id: <20110525194603.GH85219@ricotta.doit.wisc.edu>
X-Spam-PmxInfo: Server=avs-14, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.25.193617, SenderIP=144.92.67.161
References: <06d801cc1a72$4735e4d0$d5a1ae70$@com>   <20110525192313.GA7684@srv03.cluenet.de>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 19:46:07 -0000

Thus spake Daniel Roesen (dr@cluenet.de) on Wed, May 25, 2011 at 09:23:13PM +0200:
> On Wed, May 25, 2011 at 04:23:06PM +0200, Olaf.Bonness@telekom.de wrote:
> > I disagree with Philips opinion.
> > 
> > I think we have to prefer IPv6 since we simply want to push back IPv4
> > in the case that IPv4 and IPv6 connectivity are equal in quality.
> 
> +1 from another operator.
>
> A bias towards IPv6 is absolutely imperative to get rid of the LSNs
> (at least dampen the scaling required) which will be widely deployed
> to continue riding the dead horse IPv4.

+1 from yet another.

We must balance both sides of the issue, making the user experience
acceptable while clearly rigging the election.

Dale


From pch-b2B3A6689@u-1.phicoh.com  Wed May 25 15:15: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 A192FE0783 for ; Wed, 25 May 2011 15:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 D7ZNOxTv+b4X for ; Wed, 25 May 2011 15:15:11 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id A2D91E0762 for ; Wed, 25 May 2011 15:15:10 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QPMM5-0001hFC; Thu, 26 May 2011 00:15:05 +0200
Message-Id: 
To: "Dan Wing" 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References: Your message of "Tue, 24 May 2011 17:25:40 -0700 ." <06d801cc1a72$4735e4d0$d5a1ae70$@com>  <099201cc1af6$bf214f50$3d63edf0$@com> 
In-reply-to: Your message of "Wed, 25 May 2011 09:13:55 -0700 ." <099201cc1af6$bf214f50$3d63edf0$@com> 
Date: Thu, 26 May 2011 00:15:05 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 May 2011 22:15:12 -0000

In your letter dated Wed, 25 May 2011 09:13:55 -0700 you wrote:
>> It looks like a naive implementation would take at least Tolerance
>> Interval
>> (20ms) when both an A and AAAA are present. I wonder if that is really
>> a
>> good idea. I would be prefer a connection to be available to the
>> application
>> as soon as possible. 
>
>Then Tolerance Interval is set to 0ms.
>
>> Optionally without updating the SP value.
>
>If SP isn't adjusted, we'll blindly beat the network and server.  This
>is certainly easiest to implement.  It also creates the most impact to
>the network and the server.

In trying figure out what value of SP I would want, and also how that relates
to the 'SP=SP/2' in the draft I came up with the following algorithm, which
in part may be easier to analyse.

The main goal is that I want to try the best protocol first, and that I also
want to avoid trying two protocols as much as possible. Certainly when IPv4
is behind CGN, we have to avoid placing unnecessary load on those devices as
much as possible.

So the basic idea is that SP should big enough that almost all (i.e. mean
plus a few times sigma) connections will complete in less the SP time.

Assuming SP>0 then we start with the IPv6 address. If that connection
completes in less than SP time, don't update SP because it is already big
enough.

If it takes longer than SP, start IPv4. If the IPv6 connection completes 
first then don't wait for the IPv4 connection but increase SP by some amount.
If on the other hand, IP4 completes first then decrease SP by some (possibly
different) amount.

What will happen is the following. Suppose x% of the IPv6 destinations
is bad, either because the connection will not complete at all, or because it
takes much longer than using IPv4 then in x% of the cases SP will be decreased.
If we assume the amount to increase and decrease of SP is equal, then it needs 
another x% or the connections to keep SP stable. In other words, SP will end
up a value such that x% of the properly working IPv6 connections are taking
longer than SP.

We can now easily see that the overhead is 100%: of each IPv4 connection 
that is actually required (the first x% above) there is another x% started to
keep SP balanced. 

If we now change the ratio between the values we use for increasing and
decreasing SP then we can reduce that overhead: if the increment is 10x less
than the decrement then the overhead will be 10%.

(Alternatively, if IPv4 is cheap, you can also invert the ratio and decrease
the latency in case an IPv6 address is not working)

For cached values, you just use the smallest absolute value you find in the
case (or if you find only one, then that address family).

The algorithm sofar ensures that if either IPv6 or IPv4 is working, you end up
with the right one. But if both work, you have to do something extra to
find the fastest one.

For cache values it is easy: every once in a while, say in 1% of the cases,
you just start both at the same time. If, according to the cache IPv6 was
preferred and IPv6 was also the fasted then you don't do anything. Otherwise,
you update the IPv4 value with what you found (there should no need to update
the IPv6 value because that should already be higher than the time it takes
to connect).

You can do the same thing for SP, but that is a bit tricky. In 1% of the
cases start both at the same time. Still assuming SP>0 then if IPv6 connects
first, you don't do anything. If IPv4 connects first then the next time
you also start both connections at the same time. If again IPv4 wins, you
flip the sign of SP (no need to adjust the absolute value).

This should ensure that when IPv4 is faster then IPv6 in 50% of the cases,
IPv4 is preferred. And the same goes vice versa for IPv6.

(Some changes would be required to prefer IPv6 over IPv4, but that should be
doable).



From marka@isc.org  Wed May 25 20:10: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 BE7D1E06A3 for ; Wed, 25 May 2011 20:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.604
X-Spam-Level: 
X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 nl9iDsfOaiTy for ; Wed, 25 May 2011 20:10:41 -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 0D38DE0690 for ; Wed, 25 May 2011 20:10:41 -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 4486C5F98E3; Thu, 26 May 2011 03:10: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 F049E216C7A; Thu, 26 May 2011 03:10:15 +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 90ACEFD3F20; Thu, 26 May 2011 13:11:50 +1000 (EST)
To: "Dale W. Carder" 
From: Mark Andrews 
References: <06d801cc1a72$4735e4d0$d5a1ae70$@com>   <20110525192313.GA7684@srv03.cluenet.de> <20110525194603.GH85219@ricotta.doit.wisc.edu>
In-reply-to: Your message of "Wed, 25 May 2011 14:46:03 EST." <20110525194603.GH85219@ricotta.doit.wisc.edu>
Date: Thu, 26 May 2011 13:11:50 +1000
Message-Id: <20110526031150.90ACEFD3F20@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 03:10:41 -0000

In message <20110525194603.GH85219@ricotta.doit.wisc.edu>, "Dale W. Carder" writes:
> Thus spake Daniel Roesen (dr@cluenet.de) on Wed, May 25, 2011 at 09:23:13PM +0200:
> > On Wed, May 25, 2011 at 04:23:06PM +0200, Olaf.Bonness@telekom.de wrote:
> > > I disagree with Philips opinion.
> > > 
> > > I think we have to prefer IPv6 since we simply want to push back IPv4
> > > in the case that IPv4 and IPv6 connectivity are equal in quality.
> > 
> > +1 from another operator.
> >
> > A bias towards IPv6 is absolutely imperative to get rid of the LSNs
> > (at least dampen the scaling required) which will be widely deployed
> > to continue riding the dead horse IPv4.
> 
> +1 from yet another.
> 
> We must balance both sides of the issue, making the user experience
> acceptable while clearly rigging the election.
> 
> Dale

Or we can define methods to inform hosts when they are behind a LSN
and let them use that information to depreference external IPv4
addresses.  Now is the time to do this before there is a large
installed base of CPE dual stack routers that don't pass the
information though to the hosts.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From Olaf.Bonness@telekom.de  Wed May 25 23:15: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 E74ADE0651 for ; Wed, 25 May 2011 23:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level: 
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 FzgFwd5Abnlk for ; Wed, 25 May 2011 23:15:51 -0700 (PDT)
Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id E781BE064B for ; Wed, 25 May 2011 23:15:43 -0700 (PDT)
Received: from he111296.emea1.cds.t-internal.com ([10.125.90.14]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 26 May 2011 08:14:20 +0200
Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.241]) by HE111296.EMEA1.CDS.T-INTERNAL.COM ([fe80::19ac:3fb4:a382:6df4%16]) with mapi; Thu, 26 May 2011 08:14:18 +0200
From: 
To: 
Date: Thu, 26 May 2011 08:14:17 +0200
Thread-Topic: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
Thread-Index: AcwbETuptYippJeqR6ycVKK5KjTI3QAWYhpA
Message-ID: 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>
In-Reply-To: <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 06:15:52 -0000

Hmm, strange discussion. Do you really propose that network operators use T=
E to delay IPv4 packets? I can't follow you how this would "preserve the we=
lfare of the Internet user community" when most of the traffic (IPv4) is sl=
owed down by network operators. How do you think about net neutrality?

No sorry, IMHO you are wrong this time, James.
If we want to make IPv6 happen, than we have to prefere its usage starting =
with the connection initiation.
Don't put double load to networks and servers and this will make the Eyebal=
ls more happy.

Regards
        Olaf
>
> If network operators and content providers want their
> subscribers and correspondents to prefer IPv6 over IPv4, then
> let happy eyeballs have no bias between the two, and let the
> Mystic Knights of Traffic Engineering make it so.  To
> preserve the welfare of the Internet user community, IETF
> must allow the invisible brass knuckles of The Market to sort
> out which network layer shall win in the end.
>
>
> --
> james woodyatt 
> member of technical staff, core os networking
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

From v6ops@globis.net  Wed May 25 23:44: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 AC2CDE064B for ; Wed, 25 May 2011 23:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.726
X-Spam-Level: 
X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=-0.127, 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 ssvwx3ukCeAk for ; Wed, 25 May 2011 23:44:42 -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 6BEA8E06CC for ; Wed, 25 May 2011 23:44:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6EE908700EF for ; Thu, 26 May 2011 08:44:41 +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 j+CPdBt8xWn2 for ; Thu, 26 May 2011 08:44:32 +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 2F3E98700DC for ; Thu, 26 May 2011 08:44:32 +0200 (CEST)
Message-ID: <4DDDF6D0.9070209@globis.net>
Date: Thu, 26 May 2011 08:44:32 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: "v6ops@ietf.org WG" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 06:44:43 -0000

+1 for Happy Eyeballs.

Not convinced about giving IPv6 a 100mS head start as standard. 
Especially for web pages / applications that trigger many sessions.

I really really do like the fact that the authors have not attempted to 
second guess operational people's requirements and have given network 
managers the tools they need so that they can manage their own networks 
and their own migrations (in this case via DHCPv6 or the prefix policy 
table).

Sensible defaults are fine, so we can debate if the +100mS is correct. 
I'd personally like to see somewhere nearer 0mS as default. Why handicap 
a working service?

I do think it's sensible to take the lead from a well defined parameter 
e.g. the preference RFC3484 policy table in all cases to set the sign of 
the offset. IPv4 works just fine today actually, even if RFC3484 
defaults think otherwise. If the network manager has gone to the trouble 
of over-riding the default in RFC3484 to prefer IPv4 over IPv6 then that 
should be respected.

But I'd like to go one stage further and define an explicit DHCPv6 
mechanism/ named parameter to be able to set the value of IH as well as 
the sign (+ve or -ve). Maybe not IETF style I know.

Please forgive any apparent frustration in the following text. 
Operations people will know when it's the correct time to prefer IPv6 or 
IPv4 for their own particular network for their own particular 
migration, and by how much. One size does not fit all. At the moment, 
ironically enough, "zero configuration" seems to mean a lot more work, 
because not all implementations are following the same lead for what 
features to implement, or set of default behaviors, or end node 
configuration/ signaling mechanisms. [If you have a mixed network of 
thousands of Linux and Windows and OS X and iOS devices today (plus 
"legacy" OS), you have to locally reconfigure at least one set of 
machines to make them behave consistently. For one you even have to 
compile in DHCPv6 yourself, and for another that's pretty much impossible.]

regards,
RayH

> This has been a long time coming -- sorry about that.
> This new version incorporates almost all of the feedback we received from
> the working group -- support for per-prefix "P", IPv6 head start, fully
> describing "Smoothed P".  This also added complexity.  There are some ideas
> Andrew is kicking around to reduce the complexity, but we wanted people to
> take a look at this document and see how it feels.  There is a tradeoff in
> complexity with being gentle to the network -- which is desirable if only
> certain servers or certain IPv6 prefixes are failing (but others are
> working), and we don't want to abuse the network by attempting IPv4
> connections whenever IPv6 has a small hiccup.
>
> Reading this update will require a holistic view, so please fill your coffee
> mug before diving into the document.
>
> new version:
>    http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-02	
> side-by-side differences:
>    http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-happy-eyeballs-02.txt
>
> Changes are in Appendix A.1, and are also copied below for reference.
>
> -Dan and Andrew


From pch-b2B3A6689@u-1.phicoh.com  Thu May 26 02:26: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 2CA65E0664 for ; Thu, 26 May 2011 02:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 0xYzsaFgw244 for ; Thu, 26 May 2011 02:26:35 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id DC9E5E06BE for ; Thu, 26 May 2011 02:26:33 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QPWpp-0001jGC; Thu, 26 May 2011 11:26:29 +0200
Message-Id: 
To: Olaf.Bonness@telekom.de
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com> 
In-reply-to: Your message of "Thu, 26 May 2011 08:14:17 +0200 ." 
Date: Thu, 26 May 2011 11:26:25 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 09:26:36 -0000

In your letter dated Thu, 26 May 2011 08:14:17 +0200 you wrote:
>Hmm, strange discussion. Do you really propose that network operators use TE t
>o delay IPv4 packets? I can't follow you how this would "preserve the welfare 
>of the Internet user community" when most of the traffic (IPv4) is slowed down
> by network operators. How do you think about net neutrality?
>
>No sorry, IMHO you are wrong this time, James.
>If we want to make IPv6 happen, than we have to prefere its usage starting wit
>h the connection initiation.
>Don't put double load to networks and servers and this will make the Eyeballs 
>more happy.

For many years now, people have been trying to get networks with good IPv4 
connectivity to add IPv6 support. This mostly failed. ISPs mostly didn't do 
anything. There are a few big content providers have IPv6 but many don't.

So the whole idea of getting people to prefer IPv6 over IPv4 is an illusion,
because on average nobody has IPv6 and there is no IPv6 content.

You can think about switching off IPv4 when essentially the whole world
has IPv6. We are so far from that, it is not even funny. So what's the
point of setting protocol parameters now for something that is likely
to happen a couple of decades from now?

What will happen in some places in the Internet is that various NAT boxes
will slow things down. This will automatically get the algorithm to prefer
IPv6. A similar thing may happen at content providers: if they upgrade
IPv6 support first, or ensure that the IPv6 are slightly less loaded, then
traffic will switch to IPv6. 

That way, IPv6 will be used when it actually gives better performance.



From Olaf.Bonness@telekom.de  Thu May 26 04:56: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 A8DE5E070E for ; Thu, 26 May 2011 04:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 bd1mguSD2iS9 for ; Thu, 26 May 2011 04:56:19 -0700 (PDT)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id ABE40E070D for ; Thu, 26 May 2011 04:56:18 -0700 (PDT)
Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 26 May 2011 13:56:10 +0200
Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.241]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Thu, 26 May 2011 13:56:10 +0200
From: 
To: 
Date: Thu, 26 May 2011 13:56:09 +0200
Thread-Topic: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02 
Thread-Index: Acwbh0yzMafSjcGeSM66SB6rX1JysgAEia9g
Message-ID: 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>  
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 11:56:19 -0000

Please see my remarks in line.

Philip Homburg wrote:
>
> For many years now, people have been trying to get networks
> with good IPv4
> connectivity to add IPv6 support. This mostly failed. ISPs
> mostly didn't do
> anything. There are a few big content providers have IPv6 but
> many don't.

O.k. so far, but the times are changing now. More and more content becomes =
available via IPv6.

> So the whole idea of getting people to prefer IPv6 over IPv4
> is an illusion,
> because on average nobody has IPv6 and there is no IPv6 content.

If IPv6 is not enabled than HE wouldn't start. The same if there is no AAAA=
. Don't understand you here.

> You can think about switching off IPv4 when essentially the
> whole world
> has IPv6. We are so far from that, it is not even funny. So what's the
> point of setting protocol parameters now for something that is likely
> to happen a couple of decades from now?

IMHO to pessimistic but this is not very relevant for the discussion.

> What will happen in some places in the Internet is that
> various NAT boxes
> will slow things down. This will automatically get the
> algorithm to prefer
> IPv6. A similar thing may happen at content providers: if they upgrade
> IPv6 support first, or ensure that the IPv6 are slightly less
> loaded, then
> traffic will switch to IPv6.
>
> That way, IPv6 will be used when it actually gives better performance.

I don't buy this approach "the network will solve the problem itself" or "t=
he content provider will push IPv6 and neglect IPv4".

>From my point of view I like this HE I-D as it is and think that this is a =
viable approach to solve the existing problem _and_ make IPv6 happen.
Just my 2 cent.
        Olaf

From pch-b2B3A6689@u-1.phicoh.com  Thu May 26 06:56: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 3B4B4E066A for ; Thu, 26 May 2011 06:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 lNexbn5st-Sd for ; Thu, 26 May 2011 06:56:35 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6211EE0657 for ; Thu, 26 May 2011 06:56:35 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QPb3C-0001hYC; Thu, 26 May 2011 15:56:34 +0200
Message-Id: 
To: Olaf.Bonness@telekom.de
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>   
In-reply-to: Your message of "Thu, 26 May 2011 13:56:09 +0200 ." 
Date: Thu, 26 May 2011 15:56:31 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 13:56:38 -0000

In your letter dated Thu, 26 May 2011 13:56:09 +0200 you wrote:
>From my point of view I like this HE I-D as it is and think that this is a 
>viable approach to solve the existing problem _and_ make IPv6 happen.

One thing I forgot to mention. At the moment not having IPv6 connectivity
is perfectly possible. 

It is possible that in a few years time, some people will have to have 
IPv6 connectivity, even if it is relatively poor.

Poor IPv6 connectivity for connecting to IPv6-only sites is better than
nothing. But it would be really bad if then most of the other traffic would
take the same route, just because 'we' decided that we have to promote IPv6.



From Ted.Lemon@nominum.com  Thu May 26 07:02: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 882B4130015 for ; Thu, 26 May 2011 07:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.31
X-Spam-Level: 
X-Spam-Status: No, score=-106.31 tagged_above=-999 required=5 tests=[AWL=0.289, 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 wtg38Zwwoa3f for ; Thu, 26 May 2011 07:02:13 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 934CA130016 for ; Thu, 26 May 2011 07:02:05 -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 DSNKTd5dXeOrjCKh3JL1WbkyHMlAK3WZq7dK@postini.com; Thu, 26 May 2011 07:02:05 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 BD17CF80DE for ; Thu, 26 May 2011 07:02:04 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9FED8190058; Thu, 26 May 2011 07:02:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.1.10.12] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 07:02:04 -0700
MIME-Version: 1.0 (Apple Message framework v1227)
Content-Type: text/plain; charset="iso-8859-1"
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 26 May 2011 10:02:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <3C595150-C898-4772-998F-A80C391EBC2B@nominum.com>
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com> 
To: 
X-Mailer: Apple Mail (2.1227)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 14:02:14 -0000

Le May 26, 2011 =E0 2:14 AM, 
  a =E9crit :
> Don't put double load to networks and servers and this will make the =
Eyeballs more happy.

Sorry, what?   Happy Eyeballs does not fetch the same data twice through =
different connections, so it's not even remotely accurate to say that it =
doubles the load on networks and servers.  Indeed, it goes to what I =
think are unnecessary extremes to avoid creating any extra traffic at =
all.

One thing I like about the 100ms delay is that it encourages operators =
to optimize their networks--it astonishes me that my current ISP has =
such congested border routers that the RTT to my server in California is =
>100ms.


From Olaf.Bonness@telekom.de  Thu May 26 07: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 D8C8FE0716 for ; Thu, 26 May 2011 07:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.949
X-Spam-Level: 
X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, 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 IhuQIvVT3yat for ; Thu, 26 May 2011 07:15:48 -0700 (PDT)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 13CF5E06F4 for ; Thu, 26 May 2011 07:15:47 -0700 (PDT)
Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 26 May 2011 16:15:40 +0200
Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.241]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Thu, 26 May 2011 16:15:40 +0200
From: 
To: 
Date: Thu, 26 May 2011 16:15:40 +0200
Thread-Topic: AW: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02 
Thread-Index: AcwbrK1PM1YdKM54SR+h/ACVu6YmVwAAgrHQ
Message-ID: 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>    
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 14:15:49 -0000

Hi Philip, in principle I see your point, but don't forget that HE is a ver=
y adaptive mechanism that recognises very fast (anf reacts accordingly) whe=
n IPv6 connectivity is broken.
So drawing a picture in black that all the Internet connections will be slo=
wed down just because IPv6 is a little bit prefered for the connection init=
iation phase is a bit FUD. Hence please do not generalize this.

Thx and ciao
        Olaf

> -----Urspr=FCngliche Nachricht-----
> Von: pch-b2B3A6689@u-1.phicoh.com
> [mailto:pch-b2B3A6689@u-1.phicoh.com] Im Auftrag von Philip Homburg
> Gesendet: Donnerstag, 26. Mai 2011 15:57
> An: Bonne=DF, Olaf
> Cc: v6ops@ietf.org
> Betreff: Re: AW: [v6ops] Happy eyeballs update,
> draft-ietf-v6ops-happy-eyeballs-02
>
> In your letter dated Thu, 26 May 2011 13:56:09 +0200 you wrote:
> >From my point of view I like this HE I-D as it is and think
> that this is a
> >viable approach to solve the existing problem _and_ make IPv6 happen.
>
> One thing I forgot to mention. At the moment not having IPv6
> connectivity
> is perfectly possible.
>
> It is possible that in a few years time, some people will
> have to have
> IPv6 connectivity, even if it is relatively poor.
>
> Poor IPv6 connectivity for connecting to IPv6-only sites is
> better than
> nothing. But it would be really bad if then most of the other
> traffic would
> take the same route, just because 'we' decided that we have
> to promote IPv6.
>
>
>

From Ted.Lemon@nominum.com  Thu May 26 07:23: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 1433EE0657 for ; Thu, 26 May 2011 07:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.382
X-Spam-Level: 
X-Spam-Status: No, score=-106.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 XE+n0z4Qc98y for ; Thu, 26 May 2011 07:23:46 -0700 (PDT)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id BC3DEE0678 for ; Thu, 26 May 2011 07:23:43 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTd5ib8vJlgHTK7Gt3Us7OcF3F3uo+WM/@postini.com; Thu, 26 May 2011 07:23:43 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 BC344F80DE for ; Thu, 26 May 2011 07:23:40 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B5F0D190058; Thu, 26 May 2011 07:23:40 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.1.10.12] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 07:23:40 -0700
MIME-Version: 1.0 (Apple Message framework v1227)
Content-Type: text/plain; charset="iso-8859-1"
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 26 May 2011 10:23:38 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <391C876F-8716-4684-A9C1-1745B4BA91BB@nominum.com>
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>     
To: 
X-Mailer: Apple Mail (2.1227)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 14:23:47 -0000

Le May 26, 2011 =E0 10:15 AM,  =
 a =E9crit :
> So drawing a picture in black that all the Internet connections will =
be slowed down just because IPv6 is a little bit prefered for the =
connection initiation phase is a bit FUD. Hence please do not generalize =
this.

It's possible that some people who have studied this draft may have =
missed the point that Happy Eyeballs is adaptive.   If IPv6 fails as a =
transport the first time it's attempted, it won't be preferred the next =
time the application tries to connect.   So e.g. if your web browser =
implements Happy Eyeballs, you will see that 100ms delay on the first =
web page you load, but not on any subsequent web pages.

So the 100ms delay really does provide a relatively cost-free preference =
for IPv6: the only way that it will keep preferring IPv6 is if in fact =
IPv6 works at least as well as IPv4.


From Ted.Lemon@nominum.com  Thu May 26 07:39: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 2B49BE073D for ; Thu, 26 May 2011 07:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.399
X-Spam-Level: 
X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 OzP9hgBfp306 for ; Thu, 26 May 2011 07:39:45 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id F2DE0E0713 for ; Thu, 26 May 2011 07:39:44 -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 DSNKTd5mMMmY3a/TAC7Rt/wC05pVwp83DJ1t@postini.com; Thu, 26 May 2011 07:39:45 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 D20B3F80DE for ; Thu, 26 May 2011 07:39:43 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C66B5190058; Thu, 26 May 2011 07:39:43 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.1.10.12] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 07:39:43 -0700
MIME-Version: 1.0 (Apple Message framework v1227)
Content-Type: text/plain; charset="iso-8859-1"
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 26 May 2011 10:39:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>  <3C595150-C898-4772-998F-A80C391EBC2B@nominum.com> 
To: 
X-Mailer: Apple Mail (2.1227)
Cc: IPv6 Operations Working Group 
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 14:39:46 -0000

Le May 26, 2011 =E0 10:28 AM, 
  a =E9crit :
> The "double load" was meant for the case where the delay tolerance has =
been chosen to small and the host tries an IPvX connection before a =
successful IPvY connection can return.

But this is completely inaccurate.   Properly implemented, only one =
connection will get to the point where the server process wakes up.   =
Even if both server processes wake up, data will only ever flow over one =
of the two connections.   So if every connection were =
SYN,SYN+ACK,ACK,DATA,ACK,FIN,FIN+ACK, the increased traffic would be =
minimal.   But in reality, most web connections transfer a great deal =
more data than that, so the total added network load for Happy Eyeballs =
even in the case where we don't get an ACK from the remote end in time =
is negligible.

Furthermore, this only ever happens on the first connect; subsequent =
connects are optimized based on the result of the first connect.  Even =
if every connect were an even race, the additional load would be small.  =
 But since HE optimizes according to network conditions, very few =
connections will be races, and none of the races will be even, so the =
additional load is really tiny.


From cb.list6@gmail.com  Thu May 26 08:13: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 DCFA1E0677 for ; Thu, 26 May 2011 08:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.098
X-Spam-Level: 
X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=0.900,  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 XKzBUq9aBFlw for ; Thu, 26 May 2011 08:13:09 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB7C4E0657 for ; Thu, 26 May 2011 08:13:08 -0700 (PDT)
Received: by ewy19 with SMTP id 19so413299ewy.31 for ; Thu, 26 May 2011 08:13:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wvu9/J36r3sDZ9dhWoYLSGwTJjSSretQTfU/zyEPVbY=; b=xJ/Ud+F7NVdPn02KMk3soYU/TsZpMAq76a9ms80WC4zvS5z25QD5bJO+rRq2r88+oz EPX48sq41ktSpm7v8sAf4/CoJZlxVknYZ0cZM7JXPGaXKdY5XnlrpDeoyhauKEjg8ln6 RM74osP3Kth+BAgAsFSqiUqQPR0/YiSzYMsus=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c/G0N8H6Q6Scd2QRWDHDMN1lVvBKeVrf13lvNgQ4K15lEP+CmgheSSCdfgCRvgTrDp z7JHm7zZA4fQok1hfo4FDp+47GWpeL9lvn21+tymCahssakyQr6D1ieewYb2jOX3GJUU pwRAlSYuGduXDVvj/W5zneyPsKbpBVySBDE/c=
MIME-Version: 1.0
Received: by 10.14.44.151 with SMTP id n23mr371591eeb.124.1306422787547; Thu, 26 May 2011 08:13:07 -0700 (PDT)
Received: by 10.14.48.14 with HTTP; Thu, 26 May 2011 08:13:07 -0700 (PDT)
Received: by 10.14.48.14 with HTTP; Thu, 26 May 2011 08:13:07 -0700 (PDT)
In-Reply-To: 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>  
Date: Thu, 26 May 2011 08:13:07 -0700
Message-ID: 
From: Cameron Byrne 
To: Philip Homburg 
Content-Type: multipart/alternative; boundary=0015175cfd0a2da38204a42f422e
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 15:13:15 -0000

--0015175cfd0a2da38204a42f422e
Content-Type: text/plain; charset=ISO-8859-1

On May 26, 2011 2:26 AM, "Philip Homburg"  wrote:
>
> In your letter dated Thu, 26 May 2011 08:14:17 +0200 you wrote:
> >Hmm, strange discussion. Do you really propose that network operators use
TE t
> >o delay IPv4 packets? I can't follow you how this would "preserve the
welfare
> >of the Internet user community" when most of the traffic (IPv4) is slowed
down
> > by network operators. How do you think about net neutrality?
> >
> >No sorry, IMHO you are wrong this time, James.
> >If we want to make IPv6 happen, than we have to prefere its usage
starting wit
> >h the connection initiation.
> >Don't put double load to networks and servers and this will make the
Eyeballs
> >more happy.
>
> For many years now, people have been trying to get networks with good IPv4
> connectivity to add IPv6 support. This mostly failed. ISPs mostly didn't
do
> anything. There are a few big content providers have IPv6 but many don't.
>
> So the whole idea of getting people to prefer IPv6 over IPv4 is an
illusion,
> because on average nobody has IPv6 and there is no IPv6 content.
>
> You can think about switching off IPv4 when essentially the whole world
> has IPv6. We are so far from that, it is not even funny. So what's the
> point of setting protocol parameters now for something that is likely
> to happen a couple of decades from now?
>

Heads up, APNIC and IANA are already out of ipv4 addresses.

Also, those few big content folks that are doing v6day  account for 50+% of
the be on my network (Mobile)

Ipv6 must be now.

> What will happen in some places in the Internet is that various NAT boxes
> will slow things down. This will automatically get the algorithm to prefer
> IPv6. A similar thing may happen at content providers: if they upgrade

CGN and most other types of NAT do not have a material impact on latency,
your assertion is false.

Cb

> IPv6 support first, or ensure that the IPv6 are slightly less loaded, then
> traffic will switch to IPv6.
>
> That way, IPv6 will be used when it actually gives better performance.
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--0015175cfd0a2da38204a42f422e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On May 26, 2011 2:26 AM, "Philip Homburg" <pch-v6ops@u-1.phicoh.com> wrote:

>

> In your letter dated Thu, 26 May 2011 08:14:17 +0200 you wrote:

> >Hmm, strange discussion. Do you really propose that network operat=
ors use TE t

> >o delay IPv4 packets? I can't follow you how this would "=
preserve the welfare

> >of the Internet user community" when most of the traffic (IPv=
4) is slowed down

> > by network operators. How do you think about net neutrality?

> >

> >No sorry, IMHO you are wrong this time, James.

> >If we want to make IPv6 happen, than we have to prefere its usage =
starting wit

> >h the connection initiation.

> >Don't put double load to networks and servers and this will ma=
ke the Eyeballs

> >more happy.

>

> For many years now, people have been trying to get networks with good =
IPv4

> connectivity to add IPv6 support. This mostly failed. ISPs mostly didn=
't do

> anything. There are a few big content providers have IPv6 but many don=
't.

>

> So the whole idea of getting people to prefer IPv6 over IPv4 is an ill=
usion,

> because on average nobody has IPv6 and there is no IPv6 content.

>

> You can think about switching off IPv4 when essentially the whole worl=
d

> has IPv6. We are so far from that, it is not even funny. So what's=
 the

> point of setting protocol parameters now for something that is likely<=
br>
> to happen a couple of decades from now?

>


Heads up, APNIC and IANA are already out of ipv4 addresses.=A0 


Also, those few big content folks that are doing v6day=A0 account for 50=
+% of the be on my network (Mobile)


Ipv6 must be now.


> What will happen in some places in the Internet is that various NAT=
 boxes

> will slow things down. This will automatically get the algorithm to pr=
efer

> IPv6. A similar thing may happen at content providers: if they upgrade=



CGN and most other types of NAT do not have a material impact on latency=
, your assertion is false.


Cb


> IPv6 support first, or ensure that the IPv6 are slightly less loade=
d, then

> traffic will switch to IPv6.

>

> That way, IPv6 will be used when it actually gives better performance.=


>

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

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




--0015175cfd0a2da38204a42f422e--

From jhw@apple.com  Thu May 26 08:30: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 23291E0711 for ; Thu, 26 May 2011 08:30:51 -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 4AUVX40xfNwt for ; Thu, 26 May 2011 08:30:47 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFB4E06FD for ; Thu, 26 May 2011 08:30:47 -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 <0LLT003GH71UZPX0@mail-out.apple.com> for v6ops@ietf.org; Thu, 26 May 2011 08:30:46 -0700 (PDT)
X-AuditID: 1180711d-b7c70ae00000719a-b8-4dde72264d47
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 11.0A.29082.6227EDD4; Thu, 26 May 2011 08:30:46 -0700 (PDT)
Received: from [17.113.32.149] (unknown [17.113.32.149]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LLT00B8P7372020@koseret.apple.com> for v6ops@ietf.org; Thu, 26 May 2011 08:30:46 -0700 (PDT)
From: james woodyatt 
In-reply-to: 
Date: Thu, 26 May 2011 08:30:43 -0700
Message-id: 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com> 
To: Olaf.Bonness@telekom.de
X-Mailer: Apple Mail (2.1227)
X-Brightmail-Tracker: AAAAAA==
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 15:30:51 -0000

On May 25, 2011, at 11:14 PM, Olaf.Bonness@telekom.de wrote:
> 
>  Do you really propose that network operators use TE to delay IPv4 packets?

No, I'm proposing that network operators who want users to prefer IPv6 over IPv4 should use TE to make sure that IPv6 paths are less congested than IPv4 paths.

> If we want to make IPv6 happen, than we have to prefere its usage starting with the connection initiation.


That's what you wrote, but I what I'm reading is this: "Before we network operators can make IPv6 happen, you host system implementors must cripple IPv4 for your users."

Not. Going. To. Happen.


--
james woodyatt 
member of technical staff, core os networking




From pch-b2B3A6689@u-1.phicoh.com  Thu May 26 08:41: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 0B83FE06F3 for ; Thu, 26 May 2011 08:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 xhZaSQ7YkWoo for ; Thu, 26 May 2011 08:41:22 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 19139E0655 for ; Thu, 26 May 2011 08:41:21 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QPcgV-0001iYC; Thu, 26 May 2011 17:41:15 +0200
Message-Id: 
To: Ted Lemon 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>      <391C876F-8716-4684-A9C1-1745B4BA91BB@nominum.com> 
In-reply-to: Your message of "Thu, 26 May 2011 10:23:38 -0400 ." <391C876F-8716-4684-A9C1-1745B4BA91BB@nominum.com> 
Date: Thu, 26 May 2011 17:41:04 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 15:41:23 -0000

In your letter dated Thu, 26 May 2011 10:23:38 -0400 you wrote:
>It's possible that some people who have studied this draft may have =
>missed the point that Happy Eyeballs is adaptive.   If IPv6 fails as a =
>transport the first time it's attempted, it won't be preferred the next =
>time the application tries to connect.   So e.g. if your web browser =
>implements Happy Eyeballs, you will see that 100ms delay on the first =
>web page you load, but not on any subsequent web pages.
>
>So the 100ms delay really does provide a relatively cost-free preference =
>for IPv6: the only way that it will keep preferring IPv6 is if in fact =
>IPv6 works at least as well as IPv4.

The case where IPv6 fails consistently is the easy case. Yes, HE will start
preferring IPv4 quickly. No problem.

But if IPv6 is on the order of 50ms slower than IPv4. Are you sure that the
current HE draft is also going to prefer IPv4 in that case? Or will users just
have to live with the additional latency?



From Olaf.Bonness@telekom.de  Thu May 26 08:48: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 CCFB1E06B5 for ; Thu, 26 May 2011 08:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 tbyuyLECPxpI for ; Thu, 26 May 2011 08:48:00 -0700 (PDT)
Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF4CE0655 for ; Thu, 26 May 2011 08:47:59 -0700 (PDT)
Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 26 May 2011 17:46:20 +0200
Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.241]) by HE111528.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a57::7cd:5a57]) with mapi; Thu, 26 May 2011 17:46:19 +0200
From: 
To: 
Date: Thu, 26 May 2011 17:46:19 +0200
Thread-Topic: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
Thread-Index: AcwbueiXKbkfX1M1SFKORh/PBXfaWwAASusQ
Message-ID: 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>  
In-Reply-To: 
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 15:48:01 -0000

>
> > If we want to make IPv6 happen, than we have to prefere its
> usage starting with the connection initiation.
>
>
> That's what you wrote, but I what I'm reading is this:
> "Before we network operators can make IPv6 happen, you host
> system implementors must cripple IPv4 for your users."
>
> Not. Going. To. Happen.
>
Hi James, sorry, I'm not a native English speaking person, but I'm absolute=
ly sure that your reading does not correpsond to my (may be bad) English wr=
iting. Its simply a targeted misinterpretation.

Nothing. to. add.

Olaf

From cb.list6@gmail.com  Thu May 26 09:03: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 876E0E0655 for ; Thu, 26 May 2011 09:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.468
X-Spam-Level: 
X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131,  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 RtfinN6Ou2rD for ; Thu, 26 May 2011 09:03:35 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68928E0711 for ; Thu, 26 May 2011 09:03:35 -0700 (PDT)
Received: by eye13 with SMTP id 13so467888eye.31 for ; Thu, 26 May 2011 09:03:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KyHh1Fv9106axi/llOB5u2y2NJsafCY18dlmW4TgqSs=; b=Sja8f2yRhIiIPYgWwP+4S1KHUaGL2TPmLDfA/MUxBw3NoGE+qoo/7rCekTIl5mYfpl huusZ3A2dqoNAgHK5VayGFVhiDnePnEKbz2q+zX43Lx7z5gjn8vRWnRzx1N9LGRbwyEg TsYbTMXoBLx0V7C6QdvPGAN3fwsHfFlTZyj08=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=F1Of+KN8INtbdx15AJFoUdxlFrjkiB4DVwFLlSk+zM0JFV8rfCTHeTGCUSxE5b+Cwe hJOyp2eFVq8hvyUze4qsFNAMrNmX9UsZRVdo2TCLcvhUGpCMu340nNlV+cgyPeEDwBoz gZ3xoYtCR0f6u4WF2NDcqcfMW+GouXtELDgmg=
MIME-Version: 1.0
Received: by 10.14.43.218 with SMTP id l66mr376938eeb.188.1306425814234; Thu, 26 May 2011 09:03:34 -0700 (PDT)
Received: by 10.14.48.14 with HTTP; Thu, 26 May 2011 09:03:34 -0700 (PDT)
In-Reply-To: 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>  
Date: Thu, 26 May 2011 09:03:34 -0700
Message-ID: 
From: Cameron Byrne 
To: james woodyatt 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 16:03:36 -0000

On Thu, May 26, 2011 at 8:30 AM, james woodyatt  wrote:
> On May 25, 2011, at 11:14 PM, Olaf.Bonness@telekom.de wrote:
>>
>> =A0Do you really propose that network operators use TE to delay IPv4 pac=
kets?
>
> No, I'm proposing that network operators who want users to prefer IPv6 ov=
er IPv4 should use TE to make sure that IPv6 paths are less congested than =
IPv4 paths.
>
>> If we want to make IPv6 happen, than we have to prefere its usage starti=
ng with the connection initiation.
>
>
> That's what you wrote, but I what I'm reading is this: "Before we network=
 operators can make IPv6 happen, you host system implementors must cripple =
IPv4 for your users."
>
> Not. Going. To. Happen.
>

It already happened.

"When a hostname has both IPv6 and IPv4 addresses, and the IPv6
address is listed first, we start a timer (300ms) (deliberately chosen
to be different from the backup connect job). If the timer fires, that
means the IPv6 connect() hasn't completed yet, and we start a second
socket connect() where we give it the same AddressList, except we move
all IPv6 addresses that are in front of the first IPv4 address to the
end. That way, we will use the first IPv4 address. We will race these
two connect()s and pass the first one to complete to
ConnectJob::set_socket()."

http://code.google.com/p/chromium/issues/detail?id=3D81686

Obviously this is not HE, but ... it did already happen. I am running
it now, as are thousands of others who don't know what IPv6 is.  It
works well, kudos to the Chrome crew on  release 11.0.696.71

 http://googlechromereleases.blogspot.com/

 Cameron

From dwing@cisco.com  Thu May 26 09:22: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 B087FE06E1 for ; Thu, 26 May 2011 09:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Level: 
X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 6x8zqICdAjbN for ; Thu, 26 May 2011 09:22:16 -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 7DBA2E0655 for ; Thu, 26 May 2011 09:22:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4118; q=dns/txt; s=iport; t=1306426936; x=1307636536; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=hHcLFokGk+lYNuugJGY41FS3+2Ikz7fgepvLO/NEVZM=; b=U5ofxBiYVBn2/REVQvzGj6RtDvPzkvg9ZIU23odAfg1atfY4Qj22JodN k+qlG/OOOolSwYKcM2TzssgyzYqxjGD8H84y8r/J6BRr57WHYmUgtAvJM t0x89gukMLAoFzB53MWJkW2jxn+FnqhPvyt8Kikt7Nwq+rsQxgkkWbq1p U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag8BABR93k2tJV2c/2dsb2JhbABVl2aBZIxmeIhwoDedXoYcBIZhmQg
X-IronPort-AV: E=Sophos;i="4.65,273,1304294400"; d="scan'208";a="285975450"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-4.cisco.com with ESMTP; 26 May 2011 16:22:16 +0000
Received: from dwingWS ([10.32.240.194]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p4QGMFVe021338;  Thu, 26 May 2011 16:22:15 GMT
From: "Dan Wing" 
To: "'james woodyatt'" , 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com>
In-Reply-To: <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com>
Date: Thu, 26 May 2011 09:22:15 -0700
Message-ID: <0df901cc1bc1$13cd6e10$3b684a30$@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: AcwbB73N2sQweMewQ+GMYRe2cd9HuQAtwQFw
Content-Language: en-us
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 16:22:17 -0000

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of james woodyatt
> Sent: Wednesday, May 25, 2011 11:15 AM
> To: v6ops@ietf.org WG
> Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-
> eyeballs-02
> 
> On May 25, 2011, at 04:49 , Philip Homburg wrote:
> >
> > The draft is biased towards IPv6. I wonder if that is a good idea. In
> the past, a bias towards IPv6 led to all kinds of problems. If IPv6 is
> better, let that be shown in the connection setup times.
> 
> I have to break from the majority on this and concur with Mr. Homburg.
> These little 200 milliseconds delays will add up quickly with
> repetition.

The draft does not propose a fixed 200ms headstart for IPv6.

Rather, when a host first connects to a network (e.g., it boots up), 
IPv6 will have a head start.

Then, if IPv6 shows itself worthy (IPv6 connections succeed), IPv6 will 
get even longer headstart (SP is increased).  If IPv6 shows itself 
unworthy (IPv6 connections fail), IPv6's initial headstart is reduced 
by half (SP is halved).  So, on initial connection to a network where
IPv6 connectivity is broken, IPv6 will have a 200ms, 100ms, 50ms, 
25ms, 12ms, 6ms, 3ms, 2ms, 1ms headstart for each connection.  That
is 9 connections before it becomes 0ms headstart.  If this is a 
web browser, then according to 
http://code.google.com/speed/articles/web-metrics.html, we are going
to hit about 8 hosts to render an average web page (42/5=8).

(Due to Tolerance Interval, there is an additional 20ms delay for
each connection while we're waiting for our preferred connection
(IPv6) to complete.  This would be 20ms*9=180ms.  Once IPv6 has
proven itself unworthy (connections fail), we no longer wait for
IPv6 to complete, so after 10 IPv6 connection failures, this
20ms tolerance interval goes away.)

> Picture in your mind a user interface for letting a human configure the
> bias between IPv4 and IPv6.  The proper way to present this would be a
> slider, where the middle position means without any bias between IPv4
> and IPv6, and the distance from the middle position, in either
> direction, corresponds to the amount of time a user is willing to wait
> for a connection over a specific network layer protocol when the other
> one would give them service sooner.
> 
> Can anyone here imagine a reasonable situation where an ordinary user
> would want to position that slider anywhere other than the middle
> position?

If user is behind an IPv4 NAT (and everybody is), they have a port
limit and they can only use UDP and TCP.  These are not problems
right now for many (too slow?  upgrade your home NAT to a $150 box
that supports 802.11n with some magic speed booster technology!).  
But will become a problem going forward with CGNs, where the ISP's
incentives are not aligned with the user's incentives.

> I can imagine situations where a certain class of advanced user might
> want, for troubleshooting purposes, to disable one or the other network
> layer entirely, but I can't see why I should be required by standards
> action to set a default for that conceptual slider on the vast majority
> of ordinary users to anywhere but the exact middle.
> 
> Why, oh why, would we ever think it was smart to force these delays in
> a standards track document?

1. We're trying to improve the situation today that occurs with IPv6
timeouts, slide 3 of 
http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf 

2. Naive solutions to this problem can flood the network, servers,
and NAT devices with connection attempts on both address families.  
Once widely deployed, the fear is such solutions could cause 
additional cost to users (e.g., on networks with per-packet
billing models), network operators, and server operators.

-d


> 
> --
> james woodyatt 
> member of technical staff, core os networking
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From dwing@cisco.com  Thu May 26 09:24: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 93D73E0618 for ; Thu, 26 May 2011 09:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.576
X-Spam-Level: 
X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 SU4S8Ybr5BiY for ; Thu, 26 May 2011 09:24:12 -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 F29EDE0655 for ; Thu, 26 May 2011 09:24:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=358; q=dns/txt; s=iport; t=1306427051; x=1307636651; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Njp1vG7hhKEDqXLH6TekZCs+bBYhTKHFRFyKJglDcTc=; b=eK8AZRMyupSeQcQhpNo+i7HHIcIOiMrYXZiiorsA+Q6LrEMSg+j8qxgO 2EBtY6waBtdjjIP+e3rP0LWEQ8oJRbmiVW4/gN2aqIoiPiUm6lTsR/oBu Z5aqsMyAwuZ6bCfyAicojGm9MWsmVDyo0BlV84HYcJDHijjagnO9cI26g g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAGZ93k2rRDoI/2dsb2JhbABVEJk6jGZ4iHCgOZ1ehhwEhmGYM1U
X-IronPort-AV: E=Sophos;i="4.65,273,1304294400"; d="scan'208";a="454881018"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 26 May 2011 16:24:10 +0000
Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4QGO9rb032700; Thu, 26 May 2011 16:24:09 GMT
From: "Dan Wing" 
To: "'Mark Andrews'" , "'Dale W. Carder'" 
References: <06d801cc1a72$4735e4d0$d5a1ae70$@com>			<20110525192313.GA7684@srv03.cluenet.de>	<20110525194603.GH85219@ricotta.doit.wisc.edu> <20110526031150.90ACEFD3F20@drugs.dv.isc.org>
In-Reply-To: <20110526031150.90ACEFD3F20@drugs.dv.isc.org>
Date: Thu, 26 May 2011 09:24:10 -0700
Message-ID: <0dfa01cc1bc1$57e53920$07afab60$@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: AcwbUo6QXCPdffVjQ7uEnsH/uY9EwQAbrglg
Content-Language: en-us
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 16:24:12 -0000

> Or we can define methods to inform hosts when they are behind a LSN
> and let them use that information to depreference external IPv4
> addresses.  Now is the time to do this before there is a large
> installed base of CPE dual stack routers that don't pass the
> information though to the hosts.

draft-ietf-6man-addr-select-opt can do that.

-d



From v6ops@globis.net  Thu May 26 09:30: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 747B8E068D for ; Thu, 26 May 2011 09:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.715
X-Spam-Level: 
X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=-0.116, 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 mTSCGQ95hX6i for ; Thu, 26 May 2011 09:30:43 -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 E485BE0655 for ; Thu, 26 May 2011 09:30:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2B5C4870098 for ; Thu, 26 May 2011 18:30:39 +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 7O+PU8zURBc7 for ; Thu, 26 May 2011 18:30:34 +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 063E0870089 for ; Thu, 26 May 2011 18:30:34 +0200 (CEST)
Message-ID: <4DDE8029.70606@globis.net>
Date: Thu, 26 May 2011 18:30:33 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: "v6ops@ietf.org WG" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [v6ops] Subject: Re:  Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 16:30:44 -0000

Whilst I like the concept of Happy Eyeballs, I humbly suggest that the 
WG needs to be a bit careful here in its assumptions on the use-cases.

I realize Happy Eyeballs is intended for addressing the issue of slow 
web browsing, and for Internet, and it's adaptive.

It looks like a really good solution for that problem.

But it is suggested in the draft that Happy Eyeballs could be applicable 
to other interactive applications too. And it could unintentionally 
affect other services.

 > While the application recommendations in this document are described 
in the context of HTTP clients ("web browsers") and SRV clients (e.g., 
XMPP clients) the procedure is also useful and applicable to other 
interactive applications.

Bear in mind that the adaption of the timers restarts from default every 
time a machine reboots, or reconnects to a network, or roams, or the 
cache is flushed..... they are not at all persistent by design.

I'd be delighted if IPv6 devices had the same performance as IPv4 
devices (think lack of IPv6 hardware acceleration on firewalls)

100mS latency may be very significant for a number of applications 
(especially in enterprise networks).

The use-case also makes the assumption that sessions are short lived, 
and each transaction results in a new session, hence the adaption of 
preference of IPv6 v IPv4 can have a positive effect.

For longer longer-lived sessions, the latency doesn't go away. That 
would probably not result in happy eyeballs.

How about X windows, or IP-HTTPS, or CIFS mounts, or Skype voice 
tunneling over port 80, or a whole load of other applications that are 
latency sensitive and hence which do not generally run over the Internet 
but do often run in enterprise networks?

There are also use cases where holes are punched in security devices 
based on web authentication. I can imagine that in most cases this is 
done based on source IP address. If that address alters over time ....

ISP's may also pay different traffic tariffs for upstream IPv6 and IPv4 
connectivity.

I'm OK with "Internet browsing as a default use case", but please don't 
forget to let people easily set their own preferences and tuning 
parameters on a per network basis for the use-cases that the IETF WG 
discounts today, or just haven't thought of right now. One size does not 
fit all. It's going to be a very long period of coexistence.

regards,
RayH

 >
 > Subject:
 > Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
 > From:
 > 
 > Date:
 > Thu, 26 May 2011 16:15:40 +0200
 > To:
 > 
 >
 >
 > Hi Philip, in principle I see your point, but don't forget that HE is 
a very adaptive mechanism that recognises very fast (anf reacts 
accordingly) when IPv6 connectivity is broken.
 > So drawing a picture in black that all the Internet connections will 
be slowed down just because IPv6 is a little bit prefered for the 
connection initiation phase is a bit FUD. Hence please do not generalize 
this.
 >
 > Thx and ciao
 >         Olaf
 >



From behcetsarikaya@yahoo.com  Thu May 26 09: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 C5BEDE06DF for ; Thu, 26 May 2011 09:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.992
X-Spam-Level: 
X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.607,  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 Hr6Tbm1vm3+D for ; Thu, 26 May 2011 09:34:41 -0700 (PDT)
Received: from nm28-vm1.bullet.mail.sp2.yahoo.com (nm28-vm1.bullet.mail.sp2.yahoo.com [98.139.91.235]) by ietfa.amsl.com (Postfix) with SMTP id 1C33AE0655 for ; Thu, 26 May 2011 09:34:41 -0700 (PDT)
Received: from [98.139.91.67] by nm28.bullet.mail.sp2.yahoo.com with NNFMP; 26 May 2011 16:34:41 -0000
Received: from [98.139.91.19] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 26 May 2011 16:34:41 -0000
Received: from [127.0.0.1] by omp1019.mail.sp2.yahoo.com with NNFMP; 26 May 2011 16:34:41 -0000
X-Yahoo-Newman-Property: ymail-5
X-Yahoo-Newman-Id: 40361.99745.bm@omp1019.mail.sp2.yahoo.com
Received: (qmail 40069 invoked by uid 60001); 26 May 2011 16:34:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306427680; bh=c24dxz1X2ES+0g9Zo8nC0jC/WRK1ABVCY81+0IgYVgw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MeapaXPbxUf80LPA/0oIIC9VJAVDj6Sz2DxOobbXJTR3bhoGwYccEgUq/ZfLc3sJB6Nt9OBWgRQye8xV+hhukil5yv8I+V8uq+k1+n7G+RWFRqGj/2t6Zvg5VuITGLl5aBrrcafVnoWZ+/E7ZrhThAEE96YKouHoDrBsNA4PePA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NC4jRq/1SWMShho1THbTNQrNUIYaqbB0o4QzNBzTZXDG0Uc1h4qOztUHbdAencJ1UEhzWcc0779Df/kxNGUoCFkVBVMTdsBJg1umzuy1C8YLTJfyFbQPMXDizDQ8dYAq3f97S1Dtm5QYdgPpmiDDUYgvJor+9T29Phkackpxw9g=;
Message-ID: <716289.39594.qm@web111401.mail.gq1.yahoo.com>
X-YMail-OSG: 7yVzaFsVM1lvGMfDo8i7DDIHi4Xd7UnPQ5hI0MM2qNHlVc5 tCBia2DUPB3PEkn8aUQBDBSChqf4s7lWtucWUEBmfOuJ8bBzYC82IY4k99iB VetZGFXPreoOneGECmLZrh9FApdwt4iTwj7w3E.Q3jE_jVmIGuHKYTfOHJ_Q 7JQBwVqpk0_ph8ts4gmMfnNtdtMH4CeznoL3BFYjRBEcmT5p.WIj3rVit2ol enFH2Gt5HUL3ZtSRyhOvRMQDB.f0x2SNY1YxOVdmKWRkpcjVB3dOgwGaRJPC MRDmroQPGMgwKCU7RJqRxurRZNg5NOkwZVhTsemh8LDvaLSkQsCbs5K6pmJV QxZsbT8bFQQIVUtwAA79o7JbGrg3jEyY5RXgct4T8S4JIMEH0bEAz8Z9Zzqm qQ5kG9UsTM2RvAQ--
Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Thu, 26 May 2011 09:34:40 PDT
X-Mailer: YahooMailRC/567 YahooMailWebService/0.8.111.303096
References: <3CF3E905-E526-4847-A9AC-D6A28828B208@cisco.com>  <826542.7269.qm@web111406.mail.gq1.yahoo.com> <15B2EFC5-F724-43A0-B619-637744379BA1@gmail.com>
Date: Thu, 26 May 2011 09:34:40 -0700 (PDT)
From: Behcet Sarikaya 
To: jouni korhonen 
In-Reply-To: <15B2EFC5-F724-43A0-B619-637744379BA1@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: IPv6 Operations Working Group 
Subject: Re: [v6ops] draft-sarikaya-v6ops-prefix-delegation
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2011 16:34:41 -0000

Hi Jouni,
Thanks for the review. My comments inline.




> Hello,
> 
> I read the draft and have few issues with it. The draft attempts  to give 
>generic guidance about prefix delegation in mobile networks. However,  except 
>for mentioning "WiMAX" once in the introduction and making a reference to  
>802.16 link model RFC, the draft is mostly about 3GPP GPRS or EPC (or some  
>mixture of those). Clear distinction should be made when the text applies to  
>some specific architecture and when it does not.. 
>
> 

Agreed. We clarified this in the new version.

> Regarding the shared  vs. p2p link model and DAD text I do not understand why 
>those even needs to be  discussed here.
> 

Agreed.

> The text should make it clear when the delegated prefix  is /64 and when 
>something else. E.g. in 3GPP architecture a PGW acting as a  requesting router 
>would only be asking for /64s.
> 

Agreed.

> In Section 3.1 it is  assumed that the GGSN/PGW implements a relay, which is 
>used by the client also  residing in the same GGSN/PGW. I assume the attempt is 
>to circumvent the fact  that the client cannot unicast a solicitation to the 
>server but a relay can.  This is purely an implementation/deployment option and 
>I do not see a reason to  assume such collocated functionality.
> 

Well you need a relay if the server is not on-link which could be a common case 
that's why we have it.
 
> One could also argue whether steps  2-5 in Figure 2 do happen before step 6. In 
>3GPP networks they happen in a  middle of current step 6 (which is referenced in 
>this step).
> 

Good point. Clarified this now.

> The last  paragraph in Section 3.1 is somehow misplaced. I would give it its 
>own section.  It also took me a while to figure out what was meant here.. The 
>current text is  rather confusing regarding which node has which role in each 
>step. The text  should be more explicit when the requesting router is the MN and 
>when it is the  AR, and also how these cases differ from the rest of the system 
>point of  view.
> 

Yes, we made it a new section.


> What mobile architecture Section 3.2 refers to? If it is a  "generic" 
>architecture, I am not sure why RFC2119 language is  needed.
> 

OK, corrected it.
> Section 3.4 talks about renumbering. It should be made clear  whether the 
>delegated prefix is used to number the MN itself or whether the MN  was the 
>requesting routing. In certain mobile architectures renumbering is not  
>considered at all i.e. prefixes always have an infinite lifetime. If renumbering  
>is needed that would mean tearing down the connection. Also in certain mobile  
>architectures adding new prefixes is either possible or not depending which  
>entity was the requesting router.
> 
> Why Section 3.5.1? If it needs to be  there, a bit more text is needed to build 
>to the context around  FMIP6.
> 

Agreed. We removed this section.


> Section 3.5.2: s/IMNI/IMSI
> Also I would not say MAC address  corresponds to IMSI. IMEI could be a better 
>choice.
> 

Absolutely. This was a typo now corrected.

> Section 3.5.3: What  is "broadcasting prefixes" ? For prefixes used for 
>documentation purposes see  RFC5156.
> 

Here we talk about the routing protocols like IGP, OSPF not about the 
documentation prefix. Corrected the typo on IGP.

> 
> I have hard time to see the value of this document in its  current form. The 
>overall presentation should be far more focused and more  specific on topics it 
>covers. For the parts it documents existing systems those  has to be as they are 
>in respective SDO specs. For those parts that are generic  recommendations, I 
>would like to see more reasoning why given recommendations  are considered good. 
>Mixing existing architectures and generic architectures in  the same context and 
>figures make reading really hard.
> 

It is mainly on existing architectures and informational.

If you think we should have more text, feel free to propose some.

Regards,

Behcet

From tore.anderson@redpill-linpro.com  Thu May 26 09: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 82A2AE073B for ; Thu, 26 May 2011 09:37: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=[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 HxIfI30Y+1pq for ; Thu, 26 May 2011 09:37:51 -0700 (PDT)
Received: from mailhub.linpro.no (mailhub.linpro.no [87.238.49.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6861BE071F for ; Thu, 26 May 2011 09:37:47 -0700 (PDT)
Received: from localhost (mailhub.linpro.no [87.238.49.141]) by mailhub.linpro.no (Postfix) with ESMTP id D498EC42B8; Thu, 26 May 2011 18:37:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at linpro.no
Received: from mailhub.linpro.no ([87.238.49.141]) by localhost (mailhub.linpro.no [87.238.49.141]) (amavisd-new, port 10024) with ESMTP id bJ2wXsCSGoij; Thu, 26 May 2011 18:37:45 +0200 (CEST)
Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by mailhub.linpro.no (Postfix) with ESMTP; Thu, 26 May 2011 18:37:45 +0200 (CEST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id A35B35D91F3; Thu, 26 May 2011 18:37:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at claudius.linpro.no
Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOHowvEMQW7g; Thu, 26 May 2011 18:37:45 +0200 (CEST)
Received: from envy.fud.no (77-40-195-200.dsl.no.powertech.net [77.40.195.200]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 056945D91D9; Thu, 26 May 2011 18:37:45 +0200 (CEST)
Message-ID: <4DDE8176.7090305@redpill-linpro.com>
Date: Thu, 26 May 2011 18:36:06 +0200
From: Tore Anderson 
Organization: Redpill Linpro AS
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); nb-NO; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: james woodyatt 
References: 	<37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com>	<4DDD4ACC.2050408@viagenie.ca>	<97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>		<8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 16:37:52 -0000

* james woodyatt

> That's what you wrote, but I what I'm reading is this: "Before we
> network operators can make IPv6 happen, you host system implementors
> must cripple IPv4 for your users."
> 
> Not. Going. To. Happen.

Modern operating systems are already giving IPv6 a head start over IPv4
of anywhere from 20 to 190 seconds. So isn't this «crippling» already
happening, and in a *way* more unequal manner than the 100ms we're
talking about now?

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

From Ted.Lemon@nominum.com  Thu May 26 09:54: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 AAD9113002C for ; Thu, 26 May 2011 09:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.413
X-Spam-Level: 
X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 EgpVp3RSzAVA for ; Thu, 26 May 2011 09:54:51 -0700 (PDT)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id D63B1130019 for ; Thu, 26 May 2011 09:54:50 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTd6F2rHkMdEYHdq049BTnIC2zOZCZTYD@postini.com; Thu, 26 May 2011 09:54:50 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 0B4AEF80E2 for ; Thu, 26 May 2011 09:54:50 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 02A19190058; Thu, 26 May 2011 09:54:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.1.10.12] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 09:54:49 -0700
MIME-Version: 1.0 (Apple Message framework v1227)
Content-Type: text/plain; charset="iso-8859-1"
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 26 May 2011 12:54:47 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <82321BFE-CACF-40B0-953E-BFBD7B3348F4@nominum.com>
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>  
To: james woodyatt 
X-Mailer: Apple Mail (2.1227)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 16:54:51 -0000

Le May 26, 2011 =E0 11:30 AM, james woodyatt a =E9crit :
> That's what you wrote, but I what I'm reading is this: "Before we =
network operators can make IPv6 happen, you host system implementors =
must cripple IPv4 for your users."
>=20
> Not. Going. To. Happen.

In what sense do you believe the current HE proposal cripples IPv4?


From behcetsarikaya@yahoo.com  Thu May 26 09:59: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 7E9B1130028 for ; Thu, 26 May 2011 09:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.053
X-Spam-Level: 
X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=0.546,  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 s3xX4e5vGHzd for ; Thu, 26 May 2011 09:59:28 -0700 (PDT)
Received: from nm9-vm1.bullet.mail.sp2.yahoo.com (nm9-vm1.bullet.mail.sp2.yahoo.com [98.139.91.197]) by ietfa.amsl.com (Postfix) with SMTP id CE1CF130019 for ; Thu, 26 May 2011 09:59:28 -0700 (PDT)
Received: from [98.139.91.69] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 26 May 2011 16:59:26 -0000
Received: from [98.139.91.4] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 26 May 2011 16:59:26 -0000
Received: from [127.0.0.1] by omp1004.mail.sp2.yahoo.com with NNFMP; 26 May 2011 16:59:26 -0000
X-Yahoo-Newman-Property: ymail-5
X-Yahoo-Newman-Id: 74691.76285.bm@omp1004.mail.sp2.yahoo.com
Received: (qmail 9459 invoked by uid 60001); 26 May 2011 16:59:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306429165; bh=5EaATn1IWYBzKQ51pdL2cJOBXkpEOzj6Hl0xpclMX0Q=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=j8g3gcgnWIPyb3FcJTGzsEG7qDOSyu7MYgOCpbVE7M9xoPD2rXJ2nBtBmv2BakmLGhE5fREJz5A13ErelasmSe3c4pWdlBz/0FrSpOBzJOcu7RgC0uS8rFbtBQubyKb8mD6nSEPWalHGwi1pEaIuixUepZKqU5Y5dCpRVH0zYMI=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=vSIB6whfoFRDbwolYf54Zx1v/r2CBsWC4RsJFitC0SaOtZTZg5SfR+/h45AVUif4QeoNa7pdPG71zhlnhR53Ar7OMwgL7LzSc6BGsAuetTHgiKODdoJ66vN8JkwfhGPVYinzN3LzayVgASdkA0/mT4rA38/bubJAvGjgx5LY+5Q=;
Message-ID: <449804.6587.qm@web111416.mail.gq1.yahoo.com>
X-YMail-OSG: WpwH.ucVM1kZtVJnkQ30iy7V3Ll_ZZqnEeMjUn3jwzhcGTn _T6nB233t1Z9.UPsXZ0Miv3_XyDD6G9ovZEClWAddUOlP43lpEi2gft1Wu1l OUNoiuYH6L0DSA2TXNuDgpxQtTcibjdBwb2wYknLfeaws8OwDip5A2hrMNWd zdWJlaAt5WNojChn8y5LegMkTwvNdIsvGa5D6HrBAeq0_70z8vp9powJjhN. 2OPJKp1KrQ88rLBJA5Vrz738S9y3KusoxlXIFxfMUn4svITO_PhwZvk4__X1 SzH2RZCxFkwjCJWR6QzXHg91vkvGxHI2DVmVuJjDzpnggMp_azQLR2I0CCIu 49h4DTjsUnXVLlUvTIclHdRyc7Fu.hNgN86_41ohMQ6ItO0UYOy_vlvh3m0W 3sKLb3ogWqoCSsg--
Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Thu, 26 May 2011 09:59:25 PDT
X-Mailer: YahooMailRC/567 YahooMailWebService/0.8.111.303096
Date: Thu, 26 May 2011 09:59:25 -0700 (PDT)
From: Behcet Sarikaya 
To: IPv6 Operations 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [v6ops] New Version Notification for draft-sarikaya-v6ops-prefix-delegation-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Behcet Sarikaya 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 May 2011 16:59:29 -0000

> 

> A new version of I-D, draft-sarikaya-v6ops-prefix-delegation-05.txt has been  
>successfully submitted by Behcet Sarikaya and posted to the IETF  repository.
> 
> Filename:      draft-sarikaya-v6ops-prefix-delegation
> Revision:      05
> Title:         DHCPv6 Prefix Delegation as  IPv6 Migration Tool in Mobile 
>Networks
> Creation date:      2011-05-26
> WG ID:         Individual  Submission
> Number of pages: 12
> 
> Abstract:
>    As interest on  IPv6 deployment is increasing in cellular networks
>    several migration  issues are being raised and IPv6 prefix management
>    is the one  addressed in this document.  Based on the idea that DHCPv6
>     servers can manage prefixes, we address prefix management issues such
>     as the access router offloading delegation and release tasks of the
>     prefixes to a DHCPv6 server using DHCPv6 PD.  The access router  first
>    requests a prefix for an incoming mobile node from the DHCPv6  server.
>    The access router may next stateless or stateful address  allocation
>    to the mobile node, e.g. with a Router Advertisement or  using DHCP.
>    We also describe prefix management using Authentication  Authorization
>    and Accounting servers.
> 
>                                                                                 
>      
>
> 
> 
> The IETF Secretariat
> 

From Ted.Lemon@nominum.com  Thu May 26 10:01: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 65AE3130045 for ; Thu, 26 May 2011 10:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.426
X-Spam-Level: 
X-Spam-Status: No, score=-106.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 CnBNSulFZMy9 for ; Thu, 26 May 2011 10:01:43 -0700 (PDT)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id D34D8130019 for ; Thu, 26 May 2011 10:01:42 -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 DSNKTd6Hdv4GHQKAVy5iGAY4Q9sXZuiXbNuN@postini.com; Thu, 26 May 2011 10:01:42 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 9A679F80E1 for ; Thu, 26 May 2011 10:01:40 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 92C5E190058; Thu, 26 May 2011 10:01:40 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.1.10.12] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 10:01:40 -0700
MIME-Version: 1.0 (Apple Message framework v1227)
Content-Type: text/plain; charset="iso-8859-1"
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 26 May 2011 13:01:38 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <0D26A656-BB7E-4327-9ABE-A32E44D49B41@nominum.com>
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>      <391C876F-8716-4684-A9C1-1745B4BA91BB@nominum.com> 
To: Philip Homburg 
X-Mailer: Apple Mail (2.1227)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 17:01:44 -0000

Le May 26, 2011 =E0 11:41 AM, Philip Homburg a =E9crit :
> But if IPv6 is on the order of 50ms slower than IPv4. Are you sure =
that the
> current HE draft is also going to prefer IPv4 in that case? Or will =
users just
> have to live with the additional latency?

Before I answer that question, can you prove to me that 50ms of =
additional latency is going to have a noticeable effect on users?   =
Because right now I have 100ms of latency on my IPv4 link to most =
machines on the Internet, and it seems to be working okay.   I think =
it's because 100ms is about the shortest interval anyone is likely to =
perceive that it's been chosen as the cutoff.   It's important to make =
the distinction between things that will actually affect the user =
experience, and things that will not, when deciding what sort of =
tradeoffs to make.

Remember that web browsers connect in parallel, not in series, up to a =
point, and that web sites typically already game their secondary =
downloads to take advantage of the browser cache.   So the only delay =
that's additive is DNS latency with latency on the initial connect.   We =
don't have to worry that a web page that loads 40 scripts and css files =
is going to take two additional seconds to download because of that =
additional 50ms of latency.

How many times can you tap your foot impatiently in 50ms?


From Ted.Lemon@nominum.com  Thu May 26 10: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 5057213005B for ; Thu, 26 May 2011 10:11:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.437
X-Spam-Level: 
X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 r4hbdj-ZTkv9 for ; Thu, 26 May 2011 10:11:13 -0700 (PDT)
Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 423CC130053 for ; Thu, 26 May 2011 10:11:13 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTd6JsG/KQ7cLcuI58r3F7NKMB18eLWEF@postini.com; Thu, 26 May 2011 10:11: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 5620DF80E1 for ; Thu, 26 May 2011 10:11:12 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4EFCE190058; Thu, 26 May 2011 10:11:12 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.1.10.12] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 10:11:12 -0700
MIME-Version: 1.0 (Apple Message framework v1227)
Content-Type: text/plain; charset="iso-8859-1"
From: Ted Lemon 
In-Reply-To: <4DDE8029.70606@globis.net>
Date: Thu, 26 May 2011 13:11:10 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <4DDE8029.70606@globis.net>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1227)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re:  Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 17:11:15 -0000

Le May 26, 2011 =E0 12:30 PM, Ray Hunter a =E9crit :
> How about X windows, or IP-HTTPS, or CIFS mounts, or Skype voice =
tunneling over port 80, or a whole load of other applications that are =
latency sensitive and hence which do not generally run over the Internet =
but do often run in enterprise networks?

The only one of these things that anybody actually does (rounded to the =
nearest hundred thousand) is Skype.   X windows over the Internet is, de =
facto, obsolete, whether we like it or not.   Furthermore, X was =
designed to deal with much worse latency.   The most commonly-used =
application that falls into the class you're talking about is online =
gaming.   I would expect that online gaming systems would use a much =
fancier adaptive algorithm than Happy Eyeballs to solve this problem, =
for just the reason you state.   Since these protocols are typically =
proprietary, we don't really have to worry about them--our defining =
Happy Eyeballs, unless it's implemented in the kernel (which I think is =
a tremendously bad idea) is not going to have any effect on them.

Skype spits in the eye of 50ms latency.   Also, Skype doesn't support =
IPv6, unless that's changed recently.

> There are also use cases where holes are punched in security devices =
based on web authentication. I can imagine that in most cases this is =
done based on source IP address. If that address alters over time ....

=46rom that middlebox's perspective, the two addresses are two different =
devices.   So, in the vanishingly unlikely situation that the middlebox =
even *supports* IPv6, it's just going to punch two holes.   This is not =
rocket science.


From v6ops@globis.net  Thu May 26 11:33: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 242EB130019 for ; Thu, 26 May 2011 11:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.706
X-Spam-Level: 
X-Spam-Status: No, score=-2.706 tagged_above=-999 required=5 tests=[AWL=-0.108, 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 xyY-t31QO-ZO for ; Thu, 26 May 2011 11:33:53 -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 97CB7E068C for ; Thu, 26 May 2011 11:33:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8D05E870089; Thu, 26 May 2011 20:33:50 +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 4RqDGLXfwW6k; Thu, 26 May 2011 20:33:41 +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 71D0287007D; Thu, 26 May 2011 20:33:41 +0200 (CEST)
Message-ID: <4DDE9D05.30605@globis.net>
Date: Thu, 26 May 2011 20:33:41 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Ted Lemon 
References: <4DDE8029.70606@globis.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090807030606030606010109"
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re:  Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 18:33:54 -0000

This is a multi-part message in MIME format.
--------------090807030606030606010109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Sorry Ted, all due respect but you appear to be making assumptions and 
statements about technical requirements on stuff you possibly haven't 
even seen.

Please don't try to convince me that enterprise customers are running 
"de facto obsolete" code, and that they don't have strict latency 
requirements, because they do.

Just because an application is not "a mass market 100K user application" 
doesn't mean to say they aren't financially significant to the IT industry.

X windows is alive and well in enterprise networks and designing for 
example the very latest products as I type, (together with a requirement 
of 35mS round trip network latency for a designer to be fully 
productive). This latency requirement figure was not plucked out of thin 
air and was the result of extensive user acceptability testing. FYI 
there is also a requirement in many CAD areas to be able to maintain 
these designs for 7 - 40 years or even indefinitely (automotive to 
nuclear). These software licenses also cost $25K to $100K per seat. 
Which is an awful lot of World of Warcraft subscribers.

That's just one example of something that you will not find running much 
on the Internet, and is in danger of slipping under the radar in such 
generalized discussions focused purely on requirements for browsing the web.

If enterprises didn't have these sort of latency and availability 
requirements, enterprise networks wouldn't exist, and every single 
device would just connect to the Internet. CFO's aren't daft.

So if Happy Eyeballs does have the ambition to be a more generic 
solution to the address family selection problem, it should allow tuning 
of the end node protocol selection parameters by the network manager, as 
Philip Homburg and Marc Andrews have already suggested. Otherwise make 
it a standard for Internet web browsers by all means.

regards,
RayH


Ted Lemon wrote:
> Le May 26, 2011 à 12:30 PM, Ray Hunter a écrit :
>    
>> How about X windows, or IP-HTTPS, or CIFS mounts, or Skype voice tunneling over port 80, or a whole load of other applications that are latency sensitive and hence which do not generally run over the Internet but do often run in enterprise networks?
>>      
>
> The only one of these things that anybody actually does (rounded to the nearest hundred thousand) is Skype.   X windows over the Internet is, de facto, obsolete, whether we like it or not.   Furthermore, X was designed to deal with much worse latency.   The most commonly-used application that falls into the class you're talking about is online gaming.   I would expect that online gaming systems would use a much fancier adaptive algorithm than Happy Eyeballs to solve this problem, for just the reason you state.   Since these protocols are typically proprietary, we don't really have to worry about them--our defining Happy Eyeballs, unless it's implemented in the kernel (which I think is a tremendously bad idea) is not going to have any effect on them.
>
> Skype spits in the eye of 50ms latency.   Also, Skype doesn't support IPv6, unless that's changed recently.
>
>    
>> There are also use cases where holes are punched in security devices based on web authentication. I can imagine that in most cases this is done based on source IP address. If that address alters over time ....
>>      
>
>  From that middlebox's perspective, the two addresses are two different devices.   So, in the vanishingly unlikely situation that the middlebox even *supports* IPv6, it's just going to punch two holes.   This is not rocket science.
>
>    


--------------090807030606030606010109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Sorry Ted, all due respect but you appear to be making assumptions and
statements about technical requirements on stuff you possibly haven't
even seen.



Please don't try to convince me that enterprise customers are running
"de facto obsolete" code, and that they don't have strict latency
requirements, because they do.



Just because an application is not "a mass market 100K user
application" doesn't mean to say they aren't financially significant to
the IT industry.



X windows is alive and well in enterprise networks and designing for
example the very latest products as I type, (together with a
requirement of 35mS round trip network latency for a designer to be
fully productive). This latency requirement figure was not plucked out
of thin air and was the result of extensive user acceptability testing.
FYI there is also a requirement in many CAD areas to be able to
maintain these designs for 7 - 40 years or even indefinitely
(automotive to nuclear). These software licenses also cost $25K to
$100K per seat. Which is an awful lot of World of Warcraft subscribers.



That's just one example of something that you will not find running
much on the Internet, and is in danger of slipping under the radar in
such generalized discussions focused purely on requirements for
browsing the web.



If enterprises didn't have these sort of latency and availability
requirements, enterprise networks wouldn't exist, and every single
device would just connect to the Internet. CFO's aren't daft.



So if Happy Eyeballs does have the ambition to be a more generic
solution to the address family selection problem, it should allow
tuning of the end node protocol selection parameters by the network
manager, as Philip Homburg and Marc Andrews have already suggested.
Otherwise make it a standard for Internet web browsers by all means.



regards,

RayH





Ted Lemon wrote:


  
Le May 26, 2011 à 12:30 PM, Ray Hunter a écrit :
  

  

    
How about X windows, or IP-HTTPS, or CIFS mounts, or Skype voice tunneling over port 80, or a whole load of other applications that are latency sensitive and hence which do not generally run over the Internet but do often run in enterprise networks?
    

  

  

The only one of these things that anybody actually does (rounded to the nearest hundred thousand) is Skype.   X windows over the Internet is, de facto, obsolete, whether we like it or not.   Furthermore, X was designed to deal with much worse latency.   The most commonly-used application that falls into the class you're talking about is online gaming.   I would expect that online gaming systems would use a much fancier adaptive algorithm than Happy Eyeballs to solve this problem, for just the reason you state.   Since these protocols are typically proprietary, we don't really have to worry about them--our defining Happy Eyeballs, unless it's implemented in the kernel (which I think is a tremendously bad idea) is not going to have any effect on them.

Skype spits in the eye of 50ms latency.   Also, Skype doesn't support IPv6, unless that's changed recently.

  

  

    
There are also use cases where holes are punched in security devices based on web authentication. I can imagine that in most cases this is done based on source IP address. If that address alters over time ....
    

  

  

>From that middlebox's perspective, the two addresses are two different devices.   So, in the vanishingly unlikely situation that the middlebox even *supports* IPv6, it's just going to punch two holes.   This is not rocket science.

  








--------------090807030606030606010109--

From tjc@ecs.soton.ac.uk  Thu May 26 11: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 6CFF9E06FD for ; Thu, 26 May 2011 11:47: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=[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 1zklwQ5Km0ai for ; Thu, 26 May 2011 11:47:14 -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 0DEF7E068C for ; Thu, 26 May 2011 11:47:13 -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 p4QIlBTf008791 for ; Thu, 26 May 2011 19:47:11 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p4QIlBTf008791
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1306435631; bh=TkNOfpOtaPJFtL2cHCLZ9GaEuJs=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=qvt4haB9bdSekEY2FXzVXpWsxWje9BC2GEEAhOGhEKy3dt2gn4iFSj85EJsGF8s3Y i6WPg/JAC2w1ZOvQFaznUmphUtg5bdhyDcFPDtwydPG925yhjLmsdIUKdZbY9/n5ui 3/4XetpHItgeR/sAk+wMxR+RT61LtMcBX8zmwcN0=
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 n4PJlB0035644823k5 ret-id none; Thu, 26 May 2011 19:47:11 +0100
Received: from [192.168.1.18] (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 p4QIjnkn007337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 May 2011 19:45:49 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
From: Tim Chown 
In-Reply-To: <4DDE9D05.30605@globis.net>
Date: Thu, 26 May 2011 19:45:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <4DDE8029.70606@globis.net>  <4DDE9D05.30605@globis.net> 
To: "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.1084)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n4PJlB003564482300; tid=n4PJlB0035644823k5; 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: p4QIlBTf008791
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [v6ops] Subject: Re:  Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 18:47:15 -0000

On 26 May 2011, at 19:33, Ray Hunter wrote:

>=20
> So if Happy Eyeballs does have the ambition to be a more generic =
solution to the address family selection problem, it should allow tuning =
of the end node protocol selection parameters by the network manager, as =
Philip Homburg and Marc Andrews have already suggested. Otherwise make =
it a standard for Internet web browsers by all means.

I'm a bit confused.

There's a suggestion that apps in enterprises may see 100ms latency.  HE =
is an adaptive system, but it won't be used at all if there is no AAAA =
record published for a service.  If an enterprise is publishing AAAA =
records for services that are not IPv6-enabled, and thus seeing (some) =
HE delays, there's something more fundamentally wrong (which is why =
per-service IPv6 addresses are handy, as mentioned in another =
discussion).

I see HE as a means to dramatically reduce the 21+ second timeouts that =
are seen for IPv6 accesses to sites/services outside your own control.  =
In that respect, it's a significant help, and I assume that's why Google =
have put similar behaviour into Chrome.

Tim=

From Ted.Lemon@nominum.com  Thu May 26 12:12: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 13A39E0769 for ; Thu, 26 May 2011 12:12:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.475
X-Spam-Level: 
X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.123, 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 Z3tAbd+e3OQC for ; Thu, 26 May 2011 12:12:56 -0700 (PDT)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id A7C52E0774 for ; Thu, 26 May 2011 12:12:47 -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 DSNKTd6mLXDtnNPzRfk9mkF/38g0qf/Y9Fn0@postini.com; Thu, 26 May 2011 12:12:47 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 09098F80E4 for ; Thu, 26 May 2011 12:12:45 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E7394190058; Thu, 26 May 2011 12:12:44 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
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; Thu, 26 May 2011 12:12:44 -0700
MIME-Version: 1.0 (Apple Message framework v1227)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6B402B37-7D8A-4CC3-8597-851728EB9FD3"
From: Ted Lemon 
In-Reply-To: <4DDE9D05.30605@globis.net>
Date: Thu, 26 May 2011 15:12:41 -0400
Message-ID: 
References: <4DDE8029.70606@globis.net>  <4DDE9D05.30605@globis.net>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1227)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re:  Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 19:12:57 -0000

--Apple-Mail=_6B402B37-7D8A-4CC3-8597-851728EB9FD3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

Le May 26, 2011 =E0 2:33 PM, Ray Hunter a =E9crit :
> Sorry Ted, all due respect but you appear to be making assumptions and =
statements about technical requirements on stuff you possibly haven't =
even seen.

You appear to have missed my point that custom applications probably =
won't do Happy Eyeballs.   Just because we publish a spec saying how to =
do it doesn't mean everyone will do it, or that they will do it that =
specific way.

Having said that, you posit a corporate environment where (a) IPv6 is =
configured; (b) the operators of the network can't afford to make it =
perform well, and (c) they *can* afford to spend $25k/seat on CAD =
software.   I can imagine an environment where any two of these =
conditions are true, but not all three.

The fact that you make these points as if they mean that Happy Eyeballs =
is a bad idea suggests to me that you haven't read the spec, or haven't =
understood it.


--Apple-Mail=_6B402B37-7D8A-4CC3-8597-851728EB9FD3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="iso-8859-1"

Sorry Ted, =
all due respect but you appear to be making assumptions and statements =
about technical requirements on stuff you possibly haven't even =
seen.

You appear to have missed my =
point that custom applications probably won't do Happy Eyeballs.   =
Just because we publish a spec saying how to do it doesn't mean everyone =
will do it, or that they will do it that specific =
way.

Having said that, you posit a corporate =
environment where (a) IPv6 is configured; (b) the operators of the =
network can't afford to make it perform well, and (c) they *can* afford =
to spend $25k/seat on CAD software.   I can imagine an environment =
where any two of these conditions are true, but not all =
three.

The fact that you make these points as =
if they mean that Happy Eyeballs is a bad idea suggests to me that you =
haven't read the spec, or haven't understood =
it.

=

--Apple-Mail=_6B402B37-7D8A-4CC3-8597-851728EB9FD3--

From jhw@apple.com  Thu May 26 12:18: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 11356E068C for ; Thu, 26 May 2011 12:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.407
X-Spam-Level: 
X-Spam-Status: No, score=-106.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 9kQtRY7DAx5h for ; Thu, 26 May 2011 12:18:17 -0700 (PDT)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 02015E0770 for ; Thu, 26 May 2011 12:17:23 -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 <0LLT004ZFHIJNH10@mail-out.apple.com> for v6ops@ietf.org; Thu, 26 May 2011 12:17:22 -0700 (PDT)
X-AuditID: 1180711d-b7c70ae00000719a-bd-4ddea74285ad
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 33.50.29082.247AEDD4; Thu, 26 May 2011 12:17:22 -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 <0LLT00BKNHKX2080@koseret.apple.com> for v6ops@ietf.org; Thu, 26 May 2011 12:17:22 -0700 (PDT)
From: james woodyatt 
In-reply-to: <4DDE8176.7090305@redpill-linpro.com>
Date: Thu, 26 May 2011 12:17:21 -0700
Message-id: 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>   <4DDE8176.7090305@redpill-linpro.com>
To: "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.1232)
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 19:18:18 -0000

On May 26, 2011, at 09:36 , Tore Anderson wrote:
> 
> Modern operating systems are already giving IPv6 a head start over IPv4 of anywhere from 20 to 190 seconds.

I'm absolutely certain there aren't any standards track IETF documents that RECOMMEND such behavior.

On May 26, 2011, at 09:54 , Ted Lemon wrote:
> 
> In what sense do you believe the current HE proposal cripples IPv4?

I see that I-D.ietf-v6ops-happy-eyeballs-02 specifies an Initial Headstart of 100 milliseconds.  I think that unnecessarily places a delay on IPv4 connectivity at initial conditions.  It should be sufficient for hosts that serialize any concurrent flow initiations over a short time interval to sort their destination addresses using the RFC3484bis default policy.  I'd leave out the Initial Headstart state variable.

I'll admit that I don't have much hope that Happy Eyeballs will work very well-- I think a more advanced heuristic will turn out to be required.  However, the specification of the Initial Headstart is especially difficult for me to accept.  That just looks to me like it flies in the face of the name of the draft.  Maybe we should call it, "Mostly Happy Eyeballs, *After* The Initial Headstart Period" or something like that.


--
james woodyatt 
member of technical staff, core os networking




From v6ops@globis.net  Thu May 26 13:08: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 74CD3E06E1 for ; Thu, 26 May 2011 13:08:34 -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.100, 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 mwBSadgpC1nf for ; Thu, 26 May 2011 13:08:33 -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 63387E0689 for ; Thu, 26 May 2011 13:08:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A60438700AB; Thu, 26 May 2011 22:08:31 +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 mJytR3BlDnsM; Thu, 26 May 2011 22:08:23 +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 E48CB870098; Thu, 26 May 2011 22:08:22 +0200 (CEST)
Message-ID: <4DDEB336.7000701@globis.net>
Date: Thu, 26 May 2011 22:08:22 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Ted Lemon 
References: <4DDE8029.70606@globis.net>  <4DDE9D05.30605@globis.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re:  Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 20:08:34 -0000

Ted Lemon wrote:
> my point that custom appl
I'm tempted to just let your reaction go without comment.

I have taken the time to read the spec carefully and provided positive 
feedback on how IMHO you could improve a very good draft even more so 
that it is applicable to a larger set of use-cases driven by an 
alternate view of end users' requirements.

If you read my previous posts you will see that:

1) I am very positive about Happy Eyeballs.

2) I think that the coexistence period of IPv4 and IPv6 is going to be 
very long. Perhaps 10 years or even more.

IPv6 will not get turned on instantly in an enterprise with a complex IT 
service stack and 100K desktops in 50+ countries.

Enterprises are going to run quickly to turn on IPv6 on the Internet 
facing edge systems, but internal systems will take far longer to 
migrate, especially in factory environments where downtime is limited.

As I'm sure you are aware, Windows is already running IPv6 by default, 
and is today setting up 6to4 connections over an IPv4 network by 
default. It's not a question of IPv6 being configured. Sometimes it's on 
by default.

Who knows what applications and latency requirements will pop up in the 
coming 10 years?

Where's the experimental evidence that an additional arbitrary 100mS or 
50mS or even 10mS is acceptable to users?

If you look at ping pong protocols like CIFS, we all know they're bad, 
we all know the throughput is proportional to the inverse of the 
latency, and yet they are still found in all sorts of modern 
implementations. 50mS versus 10mS latency reduces throughput by a factor 
of 5.

3) Roll out on Intercontinental enterprise networks is provider dependent.

Some customers have 4 or 5 different MPLS providers. Intercontinental 
networks are also limited by speed of light delay. It is likely during 
the transition that IPv6 transits may have less direct physical routes 
than the current IPv4 network. Maybe the undersea fibers haven't even 
been lit up yet for IPv6. No amount of money may be able to tune IPv6 
adequately for all providers simultaneously.

4) Custom apps do not mean custom stacks.

The CAD server software and user license is expensive, but the server OS 
is standard Linux, the PC client OS it runs on is standard Windows or 
Linux, as is the X windows product running on the client and server.

Any underlying commercial product in that software stack may make 
assumptions and implement Happy Eyeballs without knowing that the custom 
CAD application even exists.

Telnet is another simple example. 150-200mS is the accepted round trip 
delay for usable character echo. If you add on to inter-continental 
speed of light delays, an additional max of say 100mS for Happy 
Eyeballs, (if it is the first session to be established after Happy 
Eyeballs clears it's cache) could tip the user-acceptability for remote 
(global) applications. And please don't suggest local echo. That would 
not pass all user-acceptability tests.

Now I'm sure you'll accept that telnet is not a $100K app, but which may 
well be something that people consider "generic" and implement Happy 
Eyeballs in, not considering that telnet may be running over 
inter-continental links and have a character echo delay limit on user 
acceptability in certain environments and certain apps.

Happy Eyeballs currently claims to work for "interactive applications" 
and yet possibly introduces additional latency to an existing working 
service that has been tuned for user acceptance. Maybe it needs a health 
warning before people implement it? I sincerely hope not. I'd rather 
avoid that and improve the draft right now, so that it can be tuned to 
match the individual end users' requirements, and so that it is 
future-proof for use-cases that the original designers either haven't 
considered or which don't match the assumptions they made about user 
acceptability.

regards,
RayH

From Ted.Lemon@nominum.com  Thu May 26 15:45: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 34473130029 for ; Thu, 26 May 2011 15:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.485
X-Spam-Level: 
X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 e+MN93LU+ncQ for ; Thu, 26 May 2011 15:45:32 -0700 (PDT)
Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 73704130026 for ; Thu, 26 May 2011 15:45:32 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTd7YC9IdvO0zUwg7xTmrXCDNXHfYXnPC@postini.com; Thu, 26 May 2011 15:45:32 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 9E978F80E8 for ; Thu, 26 May 2011 15:45:31 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 963FE190058; Thu, 26 May 2011 15:45:31 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
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; Thu, 26 May 2011 15:45:31 -0700
MIME-Version: 1.0 (Apple Message framework v1227)
Content-Type: text/plain; charset="iso-8859-1"
From: Ted Lemon 
In-Reply-To: 
Date: Thu, 26 May 2011 18:45:30 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <0951ACB3-513E-45B4-B0F3-B7CD6F80B395@nominum.com>
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>   <4DDE8176.7090305@redpill-linpro.com> 
To: james woodyatt 
X-Mailer: Apple Mail (2.1227)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 22:45:33 -0000

Le May 26, 2011 =E0 3:17 PM, james woodyatt a =E9crit :
> I see that I-D.ietf-v6ops-happy-eyeballs-02 specifies an Initial =
Headstart of 100 milliseconds.  I think that unnecessarily places a =
delay on IPv4 connectivity at initial conditions.

It's not unnecessary, in the sense that there is no identified need to =
do it.   The need has been stated.   You may disagree that the need =
exists, but that's a separate question.

Moreover, you seem to have some instinctive belief that any price is too =
high a price to pay to address this need.   But you haven't said what =
you think the actual cost of that 100ms delay is.   What bad thing =
happens because of that delay?   The delay itself is just a delay. Until =
you identify a bad outcome that results from that delay, the delay =
itself is value-neutral.


From Ted.Lemon@nominum.com  Thu May 26 16: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 2274AE075C for ; Thu, 26 May 2011 16:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.492
X-Spam-Level: 
X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 ZhrlleksNdni for ; Thu, 26 May 2011 16:01:32 -0700 (PDT)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4CBE06BA for ; Thu, 26 May 2011 16:01:31 -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 DSNKTd7byv5CAhT8EjidfiVOaWjHpSkkmSvJ@postini.com; Thu, 26 May 2011 16:01:31 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 B4CDF1B8531 for ; Thu, 26 May 2011 16:01:30 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A9EFE190058; Thu, 26 May 2011 16:01:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
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; Thu, 26 May 2011 16:01:30 -0700
MIME-Version: 1.0 (Apple Message framework v1227)
Content-Type: text/plain; charset="iso-8859-1"
From: Ted Lemon 
In-Reply-To: <4DDEB336.7000701@globis.net>
Date: Thu, 26 May 2011 19:01:29 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <4DDE8029.70606@globis.net>  <4DDE9D05.30605@globis.net>  <4DDEB336.7000701@globis.net>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1227)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re:  Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 23:01:33 -0000

Le May 26, 2011 =E0 4:08 PM, Ray Hunter a =E9crit :
> I have taken the time to read the spec carefully and provided positive =
feedback on how IMHO you could improve a very good draft even more so =
that it is applicable to a larger set of use-cases driven by an =
alternate view of end users' requirements.

I think we are talking past each other.   In order for there to be =
latency resulting from happy eyeballs with the 100ms headstart, the =
following conditions must apply:

- You must set up AAAA records in the DNS for the server that provides =
the service for which latency is an issue.
- The software that talks to that server must implement happy eyeballs, =
even though it has constraints that make implementing happy eyeballs a =
bad idea.
- IPv6 connectivity from some client to that host must have latency that =
is sufficient to impact performance, yet still less than 100ms more than =
the latency on the IPv4 network.

This is an extremely constrained set of conditions.   Which, according =
to you, applies to about 100k devices.   All of which are managed by =
professional, yet apparently incompetent, IT departments.

So I'm really having trouble imagining a scenario in which the problem =
you are concerned about will occur.   And you seem to be proposing that =
we change the spec to accommodate these 100k mismanaged hosts.

Just to be clear here, I personally think that the right thing to do is =
simply launch both connections at the same time, and take the one that =
connects first.   However, there's been substantial pushback on this =
proposal because people think it will create too much extra load.   So =
we have this compromise of introducing some latency, and we can either =
do it to IPv6, or to IPv4.   If we do it to IPv6, it will mean that =
traffic that could quite successfully go over IPv6 will go over IPv4 =
instead; indeed, if we prefer IPv4 to IPv6, the same problem you are =
concerned about could easily occur.

So are you in fact proposing that we run a fair race, or that we run an =
unfair race with IPv4 being given the advantage?


From marka@isc.org  Thu May 26 16:40: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 78741E0788 for ; Thu, 26 May 2011 16:40:07 -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 AdVAQKLU6K7L for ; Thu, 26 May 2011 16:40:06 -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 0E444E077E for ; Thu, 26 May 2011 16:40:06 -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 1BC1F5F98FA; Thu, 26 May 2011 23:39:48 +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 27CCD216C7B; Thu, 26 May 2011 23:39:46 +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 A9B15FEA941; Fri, 27 May 2011 09:41:24 +1000 (EST)
To: Ted Lemon 
From: Mark Andrews 
References: <4DDE8029.70606@globis.net>  <4DDE9D05.30605@globis.net>  <4DDEB336.7000701@globis.net> 
In-reply-to: Your message of "Thu, 26 May 2011 19:01:29 -0400." 
Date: Fri, 27 May 2011 09:41:24 +1000
Message-Id: <20110526234124.A9B15FEA941@drugs.dv.isc.org>
Cc: Ray Hunter , "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 May 2011 23:40:07 -0000

In message , Ted Lemon writes:
> Le May 26, 2011 =E0 4:08 PM, Ray Hunter a =E9crit :
> > I have taken the time to read the spec carefully and provided positive fe=
> edback on how IMHO you could improve a very good draft even more so that it=
>  is applicable to a larger set of use-cases driven by an alternate view of =
> end users' requirements.
> 
> I think we are talking past each other.   In order for there to be latency =
> resulting from happy eyeballs with the 100ms headstart, the following condi=
> tions must apply:
> 
> - You must set up AAAA records in the DNS for the server that provides the =
> service for which latency is an issue.
> - The software that talks to that server must implement happy eyeballs, eve=
> n though it has constraints that make implementing happy eyeballs a bad ide=
> a.
> - IPv6 connectivity from some client to that host must have latency that is=
>  sufficient to impact performance, yet still less than 100ms more than the =
> latency on the IPv4 network.
> 
> This is an extremely constrained set of conditions.   Which, according to y=
> ou, applies to about 100k devices.   All of which are managed by profession=
> al, yet apparently incompetent, IT departments.
> 
> So I'm really having trouble imagining a scenario in which the problem you =
> are concerned about will occur.   And you seem to be proposing that we chan=
> ge the spec to accommodate these 100k mismanaged hosts.
> 
> Just to be clear here, I personally think that the right thing to do is sim=
> ply launch both connections at the same time, and take the one that connect=
> s first.   However, there's been substantial pushback on this proposal beca=
> use people think it will create too much extra load.   So we have this comp=
> romise of introducing some latency, and we can either do it to IPv6, or to =
> IPv4.   If we do it to IPv6, it will mean that traffic that could quite suc=
> cessfully go over IPv6 will go over IPv4 instead; indeed, if we prefer IPv4=
>  to IPv6, the same problem you are concerned about could easily occur.
> 
> So are you in fact proposing that we run a fair race, or that we run an unf=
> air race with IPv4 being given the advantage?

Ted go try the code available at my blog, referenced in happy-eyeballs.
It does a 200ms delay, then 100, 50, 25 ... for subseqent connection
attempts.  We don't need dual connection attempts for what should
be very low failure rates once the broken 6to4 connections are
essentially removed from the equation which will be well before
code with this "fix" in it is replaced.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From dwing@cisco.com  Thu May 26 17: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 6BAB8E0743 for ; Thu, 26 May 2011 17:57:01 -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 X70D17JsOL8f for ; Thu, 26 May 2011 17:57:00 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 666ACE06E9 for ; Thu, 26 May 2011 17:57:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5021; q=dns/txt; s=iport; t=1306457820; x=1307667420; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=IHzMbCCSfTZSt8VjSmnz2V/0sB4ASsfm4+Tq6WJFQfo=; b=VRuVYsXQTCjJZP/h6MaMBpTRqjwsQFWMg1hadiX25oXgidbGvpUCjeq9 9VLi3r8s2epcA914Ft+GxH2IghGOHGcPxHAZBWZ/J0rUgER8pUWrfSHNC v/T6wE6Lv2J8P8vR5yXB0HReqKUj8QXBvHHIPEkDZDzqgwyKn3hVYH3gv Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkBAD/23k2rRDoH/2dsb2JhbABUl2uBZIxmeIhwnzadX4YcBIZhmQg
X-IronPort-AV: E=Sophos;i="4.65,277,1304294400"; d="scan'208";a="324546184"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 27 May 2011 00:57:00 +0000
Received: from dwingWS ([128.107.105.236]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4R0v0tW020134; Fri, 27 May 2011 00:57:00 GMT
From: "Dan Wing" 
To: "'Ray Hunter'" , "'Ted Lemon'" 
References: <4DDE8029.70606@globis.net>	 <4DDE9D05.30605@globis.net>
In-Reply-To: <4DDE9D05.30605@globis.net>
Date: Thu, 26 May 2011 17:57:00 -0700
Message-ID: <11d901cc1c08$fc0bce50$f4236af0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acwb04m/sNa+2u4yRDGBNlSyPbPi/gAM7qnA
Content-Language: en-us
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Subject: Re:  Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 May 2011 00:57:01 -0000

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Ray Hunter
> Sent: Thursday, May 26, 2011 11:34 AM
> To: Ted Lemon
> Cc: v6ops@ietf.org WG
> Subject: Re: [v6ops] Subject: Re: Happy eyeballs update, draft-ietf-
> v6ops-happy-eyeballs-02
>=20
> Sorry Ted, all due respect but you appear to be making assumptions and
> statements about technical requirements on stuff you possibly haven't
> even seen.
>=20
> Please don't try to convince me that enterprise customers are running
> "de facto obsolete" code, and that they don't have strict latency
> requirements, because they do.
>=20
> Just because an application is not "a mass market 100K user
> application" doesn't mean to say they aren't financially significant =
to
> the IT industry.
>=20
> X windows is alive and well in enterprise networks and designing for
> example the very latest products as I type, (together with a
> requirement of 35mS round trip network latency for a designer to be
> fully productive). This latency requirement figure was not plucked out
> of thin air and was the result of extensive user acceptability =
testing.
> FYI there is also a requirement in many CAD areas to be able to
> maintain these designs for 7 - 40 years or even indefinitely
> (automotive to nuclear). These software licenses also cost $25K to
> $100K per seat. Which is an awful lot of World of Warcraft =
subscribers.
>=20
> That's just one example of something that you will not find running
> much on the Internet, and is in danger of slipping under the radar in
> such generalized discussions focused purely on requirements for
> browsing the web.

It is for these reasons that Happy Eyeballs supports different behavior
for different IPv6 prefixes. =20

Happy Eyeballs has more than just its "IPv6 is working" or "IPv6=20
is failing" variable (called Smoothed P).  Happy Eyeballs also=20
includes a per-prefix exception cache, which can handle cases=20
where IPv6 is working well within the enterprise but failing to=20
the Internet.  The exception cache described in the I-D can=20
be improved.  For example, the exception cache could be pre-populated
with information that is useful (e.g., based on information from
draft-ietf-6man-addr-select-opt could cause Happy Eyeballs to
give a *very* strong preference to an enterprise's own internal
IPv6 prefix).

> If enterprises didn't have these sort of latency and availability
> requirements, enterprise networks wouldn't exist, and every single
> device would just connect to the Internet. CFO's aren't daft.
>=20
> So if Happy Eyeballs does have the ambition to be a more generic
> solution to the address family selection problem, it should allow
> tuning of the end node protocol selection parameters by the network
> manager, as Philip Homburg and Marc Andrews have already suggested.

Such ability is suggested in the I-D, and could be gleaned from
existing DHCPv6 parameters.  Or we may decide to define new DHCPv6
parameters for such tuning.

-d

> Otherwise make it a standard for Internet web browsers by all means.
>=20
> regards,
> RayH
>=20
>=20
> Ted Lemon wrote:
>=20
> 	Le May 26, 2011 =E0 12:30 PM, Ray Hunter a =E9crit :
>=20
>=20
> 		How about X windows, or IP-HTTPS, or CIFS mounts, or Skype
> voice tunneling over port 80, or a whole load of other applications
> that are latency sensitive and hence which do not generally run over
> the Internet but do often run in enterprise networks?
>=20
>=20
>=20
> 	The only one of these things that anybody actually does (rounded
> to the nearest hundred thousand) is Skype.   X windows over the
> Internet is, de facto, obsolete, whether we like it or not.
> Furthermore, X was designed to deal with much worse latency.   The =
most
> commonly-used application that falls into the class you're talking
> about is online gaming.   I would expect that online gaming systems
> would use a much fancier adaptive algorithm than Happy Eyeballs to
> solve this problem, for just the reason you state.   Since these
> protocols are typically proprietary, we don't really have to worry
> about them--our defining Happy Eyeballs, unless it's implemented in =
the
> kernel (which I think is a tremendously bad idea) is not going to have
> any effect on them.
>=20
> 	Skype spits in the eye of 50ms latency.   Also, Skype doesn't
> support IPv6, unless that's changed recently.
>=20
>=20
>=20
> 		There are also use cases where holes are punched in
> security devices based on web authentication. I can imagine that in
> most cases this is done based on source IP address. If that address
> alters over time ....
>=20
>=20
>=20
> 	From that middlebox's perspective, the two addresses are two
> different devices.   So, in the vanishingly unlikely situation that =
the
> middlebox even *supports* IPv6, it's just going to punch two holes.
> This is not rocket science.
>=20
>=20
>=20



From marka@isc.org  Thu May 26 21:24: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 5994EE0690 for ; Thu, 26 May 2011 21:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.609
X-Spam-Level: 
X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SPOOF_COM2COM=2.536, SARE_SPOOF_COM2OTH=2.536, SPOOF_COM2COM=2.272, SPOOF_COM2OTH=2.044]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfXz3jAUso03 for ; Thu, 26 May 2011 21:23:48 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id 22BBA130010 for ; Thu, 26 May 2011 21:23:48 -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 B7C47C949D; Fri, 27 May 2011 04:18:31 +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 0B74D216C7A; Fri, 27 May 2011 04:18:31 +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 74819FFD8BB; Fri, 27 May 2011 14:20:09 +1000 (EST)
To: Ray Hunter 
From: Mark Andrews 
References: <4DDE8029.70606@globis.net>  <4DDE9D05.30605@globis.net>  <4DDEB336.7000701@globis.net>
In-reply-to: Your message of "Thu, 26 May 2011 22:08:22 +0200." <4DDEB336.7000701@globis.net>
Date: Fri, 27 May 2011 14:20:09 +1000
Message-Id: <20110527042009.74819FFD8BB@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 May 2011 04:24:01 -0000

In message <4DDEB336.7000701@globis.net>, Ray Hunter writes:
> Ted Lemon wrote:
> > my point that custom appl
> I'm tempted to just let your reaction go without comment.
> 
> I have taken the time to read the spec carefully and provided positive 
> feedback on how IMHO you could improve a very good draft even more so 
> that it is applicable to a larger set of use-cases driven by an 
> alternate view of end users' requirements.
> 
> If you read my previous posts you will see that:
> 
> 1) I am very positive about Happy Eyeballs.
> 
> 2) I think that the coexistence period of IPv4 and IPv6 is going to be 
> very long. Perhaps 10 years or even more.
> 
> IPv6 will not get turned on instantly in an enterprise with a complex IT 
> service stack and 100K desktops in 50+ countries.
> 
> Enterprises are going to run quickly to turn on IPv6 on the Internet 
> facing edge systems, but internal systems will take far longer to 
> migrate, especially in factory environments where downtime is limited.
> 
> As I'm sure you are aware, Windows is already running IPv6 by default, 
> and is today setting up 6to4 connections over an IPv4 network by 
> default. It's not a question of IPv6 being configured. Sometimes it's on 
> by default.
> 
> Who knows what applications and latency requirements will pop up in the 
> coming 10 years?
> 
> Where's the experimental evidence that an additional arbitrary 100mS or 
> 50mS or even 10mS is acceptable to users?
> 
> If you look at ping pong protocols like CIFS, we all know they're bad, 
> we all know the throughput is proportional to the inverse of the 
> latency, and yet they are still found in all sorts of modern 
> implementations. 50mS versus 10mS latency reduces throughput by a factor 
> of 5.
> 
> 3) Roll out on Intercontinental enterprise networks is provider dependent.
> 
> Some customers have 4 or 5 different MPLS providers. Intercontinental 
> networks are also limited by speed of light delay. It is likely during 
> the transition that IPv6 transits may have less direct physical routes 
> than the current IPv4 network. Maybe the undersea fibers haven't even 
> been lit up yet for IPv6. No amount of money may be able to tune IPv6 
> adequately for all providers simultaneously.
> 
> 4) Custom apps do not mean custom stacks.
> 
> The CAD server software and user license is expensive, but the server OS 
> is standard Linux, the PC client OS it runs on is standard Windows or 
> Linux, as is the X windows product running on the client and server.
> 
> Any underlying commercial product in that software stack may make 
> assumptions and implement Happy Eyeballs without knowing that the custom 
> CAD application even exists.
> 
> Telnet is another simple example. 150-200mS is the accepted round trip 
> delay for usable character echo. If you add on to inter-continental 
> speed of light delays, an additional max of say 100mS for Happy 
> Eyeballs, (if it is the first session to be established after Happy 
> Eyeballs clears it's cache) could tip the user-acceptability for remote 
> (global) applications. And please don't suggest local echo. That would 
> not pass all user-acceptability tests.

Native/6rd/local tunnel to Native/6rd/local tunnel is approximately
equal in performance to IPv4.  When *one* end of the connection is
6to4 *and* there isn't local relays (which any ISP which offers IPv6
should be running for reverse traffic generated by their customers)
you get a small additional latency.

Even with non-local tunnel end points it is still often comparible.
(www.ipv6.ripe.net appears to not be setting hlim correctly when
generating replies)

[drugs:~/cvs/9.4.x] marka% traceroute -I www.ripe.net
traceroute to www.ripe.net (193.0.6.139), 64 hops max, 72 byte packets
 1  bsdi (192.168.191.233)  63.925 ms  1.391 ms  0.982 ms
 2  10.72.0.1 (10.72.0.1)  7.900 ms  9.012 ms  8.173 ms
 3  bla2-ge0-0-1.gw.optusnet.com.au (198.142.160.185)  11.673 ms  11.412 ms  8.519 ms
 4  bla5-ge13-0.gw.optusnet.com.au (211.29.125.249)  7.910 ms  8.584 ms  8.309 ms
 5  203.208.191.5 (203.208.191.5)  158.422 ms  157.694 ms  157.606 ms
 6  cw.com.any2ix.coresite.com (206.223.143.96)  169.433 ms  159.543 ms  157.109 ms
 7  xe-7-2-0-xcr1.ash.cw.net (195.2.28.1)  409.945 ms  402.041 ms  413.517 ms
 8  xe-11-1-0-xcr1.nyk.cw.net (195.2.21.181)  409.958 ms  407.851 ms  404.836 ms
 9  xe-3-1-0-xcr1.lnd.cw.net (195.2.25.198)  409.894 ms  412.656 ms  409.774 ms
10  xe-7-3-0-xcr1.lsw.cw.net (195.2.25.134)  407.561 ms  404.797 ms  314.972 ms
11  xe-9-3-0-xcr1.amd.cw.net (195.2.25.202)  401.322 ms  407.849 ms  409.888 ms
12  * * *
13  www.ripe.net (193.0.6.139)  359.622 ms  400.558 ms  409.767 ms
[drugs:~/cvs/9.4.x] marka% traceroute6 -l -I www.ripe.net
traceroute6 to www.ripe.net (2001:67c:2e8:22::c100:68b) from 2001:470:1f00:820:6233:4bff:fe01:7585, 64 hops max, 16 byte packets
 1  bsdi (2001:470:1f00:820:2e0:29ff:fe19:c02d)  19.152 ms  1.248 ms  1.149 ms
 2  dviscorg.tunnel.tserv1.fmt.ipv6.he.net (2001:470:1f00:ffff::5a0)  166.151 ms  166.802 ms  169.871 ms
 3  v702.core1.fmt1.he.net (2001:470:0:1f::1)  169.598 ms  177.313 ms  182.231 ms
 4  10gigabitethernet1-2.core1.sjc2.he.net (2001:470:0:2f::2)  167.109 ms  171.035 ms  168.418 ms
 5  10gigabitethernet3-3.core1.den1.he.net (2001:470:0:1b4::2)  196.435 ms  192.550 ms  198.616 ms
 6  10gigabitethernet1-1.core1.chi1.he.net (2001:470:0:1af::1)  217.557 ms  291.472 ms  302.521 ms
 7  10gigabitethernet7-2.core1.nyc4.he.net (2001:470:0:1c6::1)  307.526 ms  345.985 ms  302.500 ms
 8  10gigabitethernet3-3.core1.lon1.he.net (2001:470:0:128::2)  406.787 ms  341.936 ms  396.796 ms
 9  10gigabitethernet1-1.core1.ams1.he.net (2001:470:0:3f::2)  326.308 ms  329.117 ms  406.218 ms
10  amsix-501.xe-0-0-0.jun1.bit-1.network.bit.nl (2001:7f8:1::a501:2859:2)  408.763 ms  401.435 ms  408.666 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  www.ipv6.ripe.net (2001:67c:2e8:22::c100:68b)  402.841 ms !  405.661 ms !  410.330 ms !
[drugs:~/cvs/9.4.x] marka% 

I will admit that having a not local tunnel end point will introduce
big delays.

[drugs:~/cvs/9.4.x] marka% traceroute6 -Il www.aarnet.edu.au
traceroute6 to www.aarnet.edu.au (2001:388:1:4041::800) from 2001:470:1f00:820:6233:4bff:fe01:7585, 64 hops max, 16 byte packets
 1  bsdi (2001:470:1f00:820:2e0:29ff:fe19:c02d)  7.626 ms  1.240 ms  1.164 ms
 2  dviscorg.tunnel.tserv1.fmt.ipv6.he.net (2001:470:1f00:ffff::5a0)  166.750 ms  167.300 ms  167.445 ms
 3  v702.core1.fmt1.he.net (2001:470:0:1f::1)  166.078 ms  165.613 ms  172.338 ms
 4  10gigabitethernet1-1.core1.pao1.he.net (2001:470:0:2e::2)  172.103 ms  172.361 ms  206.173 ms
 5  xe-0-0-0.bb1.a.pao.aarnet.net.au (2001:504:d::b1)  167.818 ms  166.810 ms  166.644 ms
 6  so-3-1-0.bb1.a.syd.aarnet.net.au (2001:388:1:14::1)  330.779 ms  404.319 ms  413.099 ms
 7  so-0-1-0.bb1.a.cbr.aarnet.net.au (2001:388:1:c::1)  404.547 ms  407.836 ms  409.120 ms
 8  2001:388:1:4030:5675:d0ff:fea6:7880 (2001:388:1:4030:5675:d0ff:fea6:7880)  413.582 ms  406.345 ms  407.862 ms
 9  www.ipv6.aarnet.edu.au (2001:388:1:4041::800)  329.204 ms  389.227 ms  404.533 ms
[drugs:~/cvs/9.4.x] marka% traceroute -I www.aarnet.edu.au
traceroute to www.aarnet.edu.au (202.158.201.38), 64 hops max, 72 byte packets
 1  bsdi (192.168.191.233)  1.421 ms  2.327 ms  1.009 ms
 2  10.72.0.1 (10.72.0.1)  8.832 ms  27.643 ms  9.822 ms
 3  bla1-ge13-1.gw.optusnet.com.au (198.142.163.49)  9.628 ms  8.141 ms  9.247 ms
 4  xe-3-1-0.sd22.optus.net.au (119.225.9.253)  18.363 ms  10.113 ms  9.615 ms
 5  * * *
 6  bundle-ether15.ken39.sydney.telstra.net (165.228.132.205)  17.820 ms  11.391 ms  9.451 ms
 7  bundle-ether6.ken-core4.sydney.telstra.net (203.50.6.145)  24.087 ms  10.645 ms  12.256 ms
 8  tengigabitethernet4-1.ken37.sydney.telstra.net (203.50.20.52)  10.499 ms  9.987 ms  9.536 ms
 9  aarnet6.lnk.telstra.net (139.130.0.78)  11.534 ms  12.515 ms  14.519 ms
10  ge-6-0-0.bb1.a.syd.aarnet.net.au (202.158.202.17)  10.187 ms  11.035 ms  12.468 ms
11  so-0-1-0.bb1.a.cbr.aarnet.net.au (202.158.194.41)  13.722 ms  16.148 ms  16.010 ms
12  webmail.aarnet.edu.au (202.158.201.18)  14.758 ms  20.644 ms  14.402 ms
13  aarnet.biz (202.158.201.38)  15.945 ms  14.884 ms  17.338 ms
[drugs:~/cvs/9.4.x] marka% 

However even this this need not be problematic for most applications.

> Now I'm sure you'll accept that telnet is not a $100K app, but which may 
> well be something that people consider "generic" and implement Happy 
> Eyeballs in, not considering that telnet may be running over 
> inter-continental links and have a character echo delay limit on user 
> acceptability in certain environments and certain apps.

And thoses that have those limits will fix things.  The home user
*can* turn off 6to4 or they *can* ask their ISP to run a 6to4 relay
for them.  Enterprises *can* get native ipv6 and/or local tunnel
end points.  It's not like good IPv6 is impossible to get if you
need interactive performance.  There really is enough interconnects
these days.  Strange routings are almost a thing of the past.
It's just getting your local link to support ipv6 that is the problem.

> Happy Eyeballs currently claims to work for "interactive applications" 
> and yet possibly introduces additional latency to an existing working 
> service that has been tuned for user acceptance. Maybe it needs a health 
> warning before people implement it? I sincerely hope not. I'd rather 
> avoid that and improve the draft right now, so that it can be tuned to 
> match the individual end users' requirements, and so that it is 
> future-proof for use-cases that the original designers either haven't 
> considered or which don't match the assumptions they made about user 
> acceptability.
> 
> regards,
> RayH
> _______________________________________________
> 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 v6ops@globis.net  Thu May 26 22: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 ACE10E074E for ; Thu, 26 May 2011 22:47:15 -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.094, 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 HQqCNzFQFshh for ; Thu, 26 May 2011 22:47:11 -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 01C60E06F2 for ; Thu, 26 May 2011 22:47:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B1EE38700E6; Fri, 27 May 2011 07:47:08 +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 oE-2lblTFKJl; Fri, 27 May 2011 07:47:03 +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 6956387007D; Fri, 27 May 2011 07:47:03 +0200 (CEST)
Message-ID: <4DDF3AD7.9090400@globis.net>
Date: Fri, 27 May 2011 07:47:03 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Mark Andrews 
References: <4DDE8029.70606@globis.net>  <4DDE9D05.30605@globis.net>  <4DDEB336.7000701@globis.net> <20110527042009.74819FFD8BB@drugs.dv.isc.org>
In-Reply-To: <20110527042009.74819FFD8BB@drugs.dv.isc.org>
Content-Type: multipart/alternative; boundary="------------060801020102080702000504"
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 May 2011 05:47:15 -0000

This is a multi-part message in MIME format.
--------------060801020102080702000504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mark Andrews wrote:
> In message<4DDEB336.7000701@globis.net>, Ray Hunter writes:
>    
> 
> However even this this need not be problematic for most applications.
>
>    
"Most applications" is not good enough for some end users of IPv4 and IPv6.


>> Now I'm sure you'll accept that telnet is not a $100K app, but which may
>> well be something that people consider "generic" and implement Happy
>> Eyeballs in, not considering that telnet may be running over
>> inter-continental links and have a character echo delay limit on user
>> acceptability in certain environments and certain apps.
>>      
>
> And thoses that have those limits will fix things.  The home user
> *can* turn off 6to4 or they *can* ask their ISP to run a 6to4 relay
> for them.  Enterprises *can* get native ipv6 and/or local tunnel
> end points.  It's not like good IPv6 is impossible to get if you
> need interactive performance.  There really is enough interconnects
> these days.  Strange routings are almost a thing of the past.
> It's just getting your local link to support ipv6 that is the problem.
>
>    
>>      
More assumptions about what is acceptable to an end user, what services 
are globally available, what standards have been implemented in existing 
products, what migration path people will take to IPv6, and what power 
an end user has to fix things when using pre-compiled or older or 
off-the-self products.

Where's the experimental evidence that the Internet represents the only 
valid set of end user requirements for IETF standards? Existence of 
networks other than the Internet that also run IP point in the opposite 
direction.

Tight control of latency is a hot issue in the SLA for many end users of 
IETF protocols, and this is not currently addressed by the public 
Internet or the current draft.

AFAIK The IETF has never ever made a statement saying that IPv6 needs to 
be faster than IPv4 (by handicapping IPv4) in order to promote IPv6 
adoption, nor should it IMHO.

All I'm saying is that if there is an address family priority preference 
parameter in a protocol, then the IETF should give network managers the 
tools they need to be able tune their own networks to match their own 
end user requirements during a long period of coexistence, and 
preferably on a per link basis (e.g. via DHCPv6).

I personally would prefer if the default was neutral bias, so that the 
"best address family" with the lowest latency was selected. I could live 
with another default, provided it was easy to override by a standard 
mechanism. I'm pretty sure ISPs could live with another set of default 
tuning parameters for AF selection if they could easily tune the 
protocol to their apparent requirement to promote IPv6 over IPv4 (to 
avoid overloading expensive CGN devices or whatever else), although I'll 
let them represent their own views and requirements.

Is it really such a big deal to give network managers some knobs to 
turn, together with an easy and standard communication mechanism to do 
this? The existing mechanism that covered AF preference selection 
(RFC3484) recognised this requirement for a need to implement different 
policies for different networks at different times during the transition 
(although IMHO the standardized tuning tools and communication methods 
are rather lacking at this time).

regards,
RayH

--------------060801020102080702000504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Mark Andrews wrote:


  
In message <4DDEB336.7000701@globis.net>, Ray Hunter writes:
  

<snip>

  
However even this this need not be problematic for most applications.

  



"Most applications" is not good enough for some end users of IPv4 and
IPv6. 







  

  

    
Now I'm sure you'll accept that telnet is not a $100K app, but which may 
well be something that people consider "generic" and implement Happy 
Eyeballs in, not considering that telnet may be running over 
inter-continental links and have a character echo delay limit on user 
acceptability in certain environments and certain apps.
    

  

  

And thoses that have those limits will fix things.  The home user
*can* turn off 6to4 or they *can* ask their ISP to run a 6to4 relay
for them.  Enterprises *can* get native ipv6 and/or local tunnel
end points.  It's not like good IPv6 is impossible to get if you
need interactive performance.  There really is enough interconnects
these days.  Strange routings are almost a thing of the past.
It's just getting your local link to support ipv6 that is the problem.

  

  

    
    

  



More assumptions about what is acceptable to an end user, what services
are globally available, what standards have been implemented in
existing products, what migration path people will take to IPv6, and
what power an end user has to fix things when using pre-compiled or
older or off-the-self products.



Where's the experimental evidence that the Internet represents the only
valid set of end user requirements for IETF standards? Existence of
networks other than the Internet that also run IP point in the opposite
direction.



Tight control of latency is a hot issue in the SLA for many end users
of IETF protocols, and this is not currently addressed by the public
Internet or the current draft.



AFAIK The IETF has never ever made a statement saying that IPv6 needs
to be faster than IPv4 (by handicapping IPv4) in order to promote IPv6
adoption, nor should it IMHO.



All I'm saying is that if there is an address family priority
preference parameter in a protocol, then the IETF should give network
managers the tools they need to be able tune their own networks to
match their own end user requirements during a long period of
coexistence, and preferably on a per link basis (e.g. via DHCPv6).



I personally would prefer if the default was neutral bias, so that the
"best address family" with the lowest latency was selected. I could
live with another default, provided it was easy to override by a
standard mechanism. I'm pretty sure ISPs could live with another set of
default tuning parameters for AF selection if they could easily tune
the protocol to their apparent requirement to promote IPv6 over IPv4
(to avoid overloading expensive CGN devices or whatever else), although
I'll let them represent their own views and requirements.



Is it really such a big deal to give network managers some knobs to
turn, together with an easy and standard communication mechanism to do
this? The existing mechanism that covered AF preference selection
(RFC3484) recognised this requirement for a need to implement different
policies for different networks at different times during the
transition (although IMHO the standardized tuning tools and
communication methods are rather lacking at this time).



regards,

RayH




--------------060801020102080702000504--

From dr@cluenet.de  Fri May 27 04:47: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 1C99FE0688 for ; Fri, 27 May 2011 04:47:48 -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 AqENs2-xwVQ8 for ; Fri, 27 May 2011 04:47:47 -0700 (PDT)
Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 729A2E0679 for ; Fri, 27 May 2011 04:47:46 -0700 (PDT)
Received: by mail1.cluenet.de (Postfix, from userid 500) id B5BD81080B0; Fri, 27 May 2011 13:47:44 +0200 (CEST)
Date: Fri, 27 May 2011 13:47:44 +0200
From: Daniel Roesen 
To: v6ops@ietf.org
Message-ID: <20110527114744.GA29481@srv03.cluenet.de>
Mail-Followup-To: v6ops@ietf.org
References: <4DDDF6D0.9070209@globis.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4DDDF6D0.9070209@globis.net>
User-Agent: Mutt/1.5.17 (2007-11-01)
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 May 2011 11:47:48 -0000

On Thu, May 26, 2011 at 08:44:32AM +0200, Ray Hunter wrote:
> Sensible defaults are fine, so we can debate if the +100mS is correct. I'd 
> personally like to see somewhere nearer 0mS as default. Why handicap a 
> working service?

Because cost of providing this service will explode in the future (LSN),
and "working" will certainly undergo significant redefinitions.

Don't continue riding dead horses more than absolutely required.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

From Ted.Lemon@nominum.com  Fri May 27 06:40: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 9AC70E07DE for ; Fri, 27 May 2011 06:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.504
X-Spam-Level: 
X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.094, 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 gDRs8lSVBhq9 for ; Fri, 27 May 2011 06:40:51 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id C8216E06DD for ; Fri, 27 May 2011 06:40:50 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTd+p4h2YbfVaEq9ghwqF143H2ZY/3B9F@postini.com; Fri, 27 May 2011 06:40:50 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 BC2A91B83F6 for ; Fri, 27 May 2011 06:40:49 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id ABB09190058; Fri, 27 May 2011 06:40:49 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
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, 27 May 2011 06:40:49 -0700
MIME-Version: 1.0 (Apple Message framework v1227)
Content-Type: multipart/alternative; boundary="Apple-Mail=_234507E7-D1F1-412D-B737-4CF18108648C"
From: Ted Lemon 
In-Reply-To: <4DDF3AD7.9090400@globis.net>
Date: Fri, 27 May 2011 09:40:45 -0400
Message-ID: <9091FF4A-4793-4EED-AAD6-9586484813C1@nominum.com>
References: <4DDE8029.70606@globis.net>  <4DDE9D05.30605@globis.net>  <4DDEB336.7000701@globis.net> <20110527042009.74819FFD8BB@drugs.dv.isc.org> <4DDF3AD7.9090400@globis.net>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1227)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 May 2011 13:40:51 -0000

--Apple-Mail=_234507E7-D1F1-412D-B737-4CF18108648C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

Le May 27, 2011 =E0 1:47 AM, Ray Hunter a =E9crit :
> Is it really such a big deal to give network managers some knobs to =
turn, together with an easy and standard communication mechanism to do =
this? The existing mechanism that covered AF preference selection =
(RFC3484) recognised this requirement for a need to implement different =
policies for different networks at different times during the transition =
(although IMHO the standardized tuning tools and communication methods =
are rather lacking at this time).

Not only is it not a big deal, but as several people have explained to =
you, there exist mechanisms already that we think are adequate.   But =
you insist that those mechanisms aren't adequate.   You haven't actually =
made any argument as to why they are inadequate; although you seem =
certain that they are not.

It would be awfully nice if we could actually identify what it is about =
the existing methods doesn't work for you.   If you think there is some =
new mechanism that is needed, it would be helpful if you could describe =
such a mechanism.   It would also help if you could explain why it is =
better than the mechanisms we've already described.  Then we could have =
a discussion about whether that mechanism is easier or harder to =
implement than existing mechanisms, and whether it would be more or less =
effective.


--Apple-Mail=_234507E7-D1F1-412D-B737-4CF18108648C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="iso-8859-1"

Is it really =
such a big deal to give network managers some knobs to turn, together =
with an easy and standard communication mechanism to do this? The =
existing mechanism that covered AF preference selection (RFC3484) =
recognised this requirement for a need to implement different policies =
for different networks at different times during the transition =
(although IMHO the standardized tuning tools and communication methods =
are rather lacking at this time).

Not =
only is it not a big deal, but as several people have explained to you, =
there exist mechanisms already that we think are adequate.   But =
you insist that those mechanisms aren't adequate.   You haven't =
actually made any argument as to why they are inadequate; although you =
seem certain that they are not.

It would be =
awfully nice if we could actually identify what it is about the existing =
methods doesn't work for you.   If you think there is some new =
mechanism that is needed, it would be helpful if you could describe such =
a mechanism.   It would also help if you could explain why it is =
better than the mechanisms we've already described.  Then we could =
have a discussion about whether that mechanism is easier or harder to =
implement than existing mechanisms, and whether it would be more or less =
effective.

=

--Apple-Mail=_234507E7-D1F1-412D-B737-4CF18108648C--

From Fred.L.Templin@boeing.com  Fri May 27 07: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 00E29E06A2 for ; Fri, 27 May 2011 07:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.485
X-Spam-Level: 
X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114,  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 WfvnZXWwt6u9 for ; Fri, 27 May 2011 07:19:02 -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 442C0E066A for ; Fri, 27 May 2011 07:19:01 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4REIv6V015530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 27 May 2011 09:18:57 -0500 (CDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4REIuKC005223 for ; Fri, 27 May 2011 09:18:56 -0500 (CDT)
Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4REIuBn005215 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Fri, 27 May 2011 09:18:56 -0500 (CDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 27 May 2011 07:18:56 -0700
From: "Templin, Fred L" 
To: "v6ops@ietf.org WG" 
Date: Fri, 27 May 2011 07:18:55 -0700
Thread-Topic: [v6ops] Subject: Re: Happy eyeballs update,draft-ietf-v6ops-happy-eyeballs-02
Thread-Index: Acwcc7v0fpKy2EG1Qm21dOTzmk6ZiAABMwfg
Message-ID: 
References: <4DDE8029.70606@globis.net><4DDE9D05.30605@globis.net><4DDEB336.7000701@globis.net><20110527042009.74819FFD8BB@drugs.dv.isc.org><4DDF3AD7.9090400@globis.net> <9091FF4A-4793-4EED-AAD6-9586484813C1@nominum.com>
In-Reply-To: <9091FF4A-4793-4EED-AAD6-9586484813C1@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
Subject: Re: [v6ops] Subject: Re: Happy eyeballs 	update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 May 2011 14:19:03 -0000

Hi,

If I set address selection policy rules that de-prefer
certain IPv6 prefixes (e.g., 2001:db8:0:1::/64) and makes
them to be of lesser priority than IPv4, will HE respect
that and use IPv4?

Thanks - Fred=

From v6ops@globis.net  Fri May 27 07:52: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 B3BAFE072F for ; Fri, 27 May 2011 07:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.311
X-Spam-Level: 
X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[AWL=-1.453, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_64=0.6, SARE_RMML_Stock4=1.54]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNbIVqImN8Vv for ; Fri, 27 May 2011 07:52:16 -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 A653AE070B for ; Fri, 27 May 2011 07:52:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 159938700CA; Fri, 27 May 2011 16:52:14 +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 6GIcf8tUh+o3; Fri, 27 May 2011 16:52:08 +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 F06A5870023; Fri, 27 May 2011 16:52:07 +0200 (CEST)
Message-ID: <4DDFBA97.2000801@globis.net>
Date: Fri, 27 May 2011 16:52:07 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Ted Lemon 
References: <4DDE8029.70606@globis.net>  <4DDE9D05.30605@globis.net>  <4DDEB336.7000701@globis.net> <20110527042009.74819FFD8BB@drugs.dv.isc.org> <4DDF3AD7.9090400@globis.net> <9091FF4A-4793-4EED-AAD6-9586484813C1@nominum.com>
In-Reply-To: <9091FF4A-4793-4EED-AAD6-9586484813C1@nominum.com>
Content-Type: multipart/alternative; boundary="------------050900020507090004010006"
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 May 2011 14:52:17 -0000

This is a multi-part message in MIME format.
--------------050900020507090004010006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Interesting concept of engineering: there are solutions and they are all 
just fine, but why do you insist on coming with that daft requirement 
after we've already designed? ;)

See existing thread on RFC3484 bis 
http://www.ietf.org/mail-archive/web/ipv6/current/msg13920.html for my 
input to how RFC3484 address family selection does not meet my 
customer's requirements today to be able to prefer IPv4 in an 
operational network to avoid excessive latency for interactive 
applications in the presence of IPv6 over tunnels but still allowing 
them to roll out IPv6 native, and a suggestion to improve this by 
codifying address selection policy of RFC3484 bis into DHCPv6.

And also a suggestion of adding one or more separate tables to the 
prefix policy table to be able to codify rules in policy, rather than 
these being hard coded into operating systems or applications. e.g. 
whether RFC1918 addresses should be considered global (in the presence 
of IPv4 NAT) or truly local (isolated IPv4 RFC1918 islands once IPv6 
becomes ubiquitous and the IPv4 Internet is becoming fragmented for CGN 
or whatever other reason)

The basic point is that one size does not fit all. Otherwise the 
Internet would be the only IP network in the World. And it clearly isn't.

The IPv6 end node implementations today do not have standardized default 
behavior.

One vendor will turn on DHCPv6. Another vendor hates the whole concept 
of DHCPv6 and will possibly implement DHCPv6, but not enable it.

One vendor will turn on temporary addresses by default. Another will not 
because they hate the idea.

Today's infrastructures are multi-vendor. To achieve consistent behavior 
a network manager has to manually override default settings on every 
single machine of the flavor they don't like, no matter whether you are 
a fan of SLAAC or DHCPv6. You can't win. Yes they will work together on 
the wire, but is it easy to operate and manage?Just ask any real busy 
network administrator today who performs daily operations in a large 
commercial environment and has to trace problems what he/she thinks 
about that and whether today's tools help them do their job.

One vendor will turn on Happy Eyeballs on one application. Another will 
not. One person wants IPv6 preferred today. Another doesn't.

The IPv6 end node implementations today do not have standard ways of 
being able to over ride those defaults (which have anyway not been 
coordinated across the industry).

So over riding of any defaults that are not appropriate for a particular 
end users' requirements relies on operating system specific / 
proprietary management techniques such as Microsoft Active Directory.

However, in these days of the exploding numbers of devices, Internet of 
Everything, highly mobile devices, devices running multiple interfaces 
and technologies, and Bring Your Own Device, these assumptions of host 
management control being equal to network management control are 
breaking down.

The IPv6 set of standards does not have a standard way of communicating 
or signaling appropriate behavior from a network device to an end node. 
DHCPv6 might grow to become that standard, but there is certainly no 
consensus at this time. DHCPv6 today isn't even backwards compatible 
with all of DHCPv4 e.g. all of the vendor extensions.

If you compare that situation to say 3G or GSM mobile telephone 
networks, you will see that these standards do exist in that World for 
similar functions (although obviously using different protocols). And 
for a good reason. These standards are needed when devices are produced 
by different vendors, are highly mobile, some devices are rapidly turned 
over whilst others have long operational lifetimes, and they are all 
managed by different entities.

There are standards for network equipment behavior (including backwards 
compatibility and release management). There are standards for end node 
behavior (again including release management). There are standards for 
signaling between a network operators device and an end terminal to 
ensure that the end node behaves in a manner appropriate for that 
operators network.

I'm not saying the Internet should go as far as those ITU style 
standards, as they also have their downsides. But I am flagging up that 
existing assumptions about how defaults and settings on IT and Internet 
systems are expected to be managed should be challenged. Hard coding 
settings is not the way to make this transition/ deployment a success. IMHO

If you need further evidence that people need more control of how the 
end nodes behave on their networks today, I suggest the WG casts its net 
wider to attempt to quantify all end user requirements and Service Level 
Agreements that exist for all systems running IPv4 operationally today, 
and how each one will translate into IPv6 in the future.

Everything from light bulbs to web surfing to stock trading systems to 
electricity network control systems to spacecraft control systems to 
nuclear power plants.
[Many of which also include standard off the shelf operating systems and 
applications and IETF defined standard protocols in some part of their 
operations]

This has been addressed before in the v6ops list, so is nothing new, but 
it did not seem to gain traction there for whatever reason.

See http://tools.ietf.org/html/draft-vandevelde-v6ops-pref-ps-00

Regards,
RayH

Ted Lemon wrote:
> Le May 27, 2011 à 1:47 AM, Ray Hunter a écrit :
>> Is it really such a big deal to give network managers some knobs to 
>> turn, together with an easy and standard communication mechanism to 
>> do this? The existing mechanism that covered AF preference selection 
>> (RFC3484) recognised this requirement for a need to implement 
>> different policies for different networks at different times during 
>> the transition (although IMHO the standardized tuning tools and 
>> communication methods are rather lacking at this time).
>
> Not only is it not a big deal, but as several people have explained to 
> you, there exist mechanisms already that we think are adequate.   But 
> you insist that those mechanisms aren't adequate.   You haven't 
> actually made any argument as to why they are inadequate; although you 
> seem certain that they are not.
>
> It would be awfully nice if we could actually identify what it is 
> about the existing methods doesn't work for you.   If you think there 
> is some new mechanism that is needed, it would be helpful if you could 
> describe such a mechanism.   It would also help if you could explain 
> why it is better than the mechanisms we've already described.  Then we 
> could have a discussion about whether that mechanism is easier or 
> harder to implement than existing mechanisms, and whether it would be 
> more or less effective.
>


--------------050900020507090004010006
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Interesting concept of engineering: there are solutions and they are
all just fine, but why do you insist on coming with that daft
requirement after we've already designed? ;)



See existing thread on RFC3484 bis
http://www.ietf.org/mail-archive/web/ipv6/current/msg13920.html for my
input to how RFC3484 address family selection does not meet my
customer's requirements today to be able to prefer IPv4 in an
operational network to avoid excessive latency for interactive
applications in the presence of IPv6 over tunnels but still allowing
them to roll out IPv6 native, and a suggestion to improve this by
codifying address selection policy of RFC3484 bis into DHCPv6.



And also a suggestion of adding one or more separate tables to the
prefix policy table to be able to codify rules in policy, rather than
these being hard coded into operating systems or applications. e.g.
whether RFC1918 addresses should be considered global (in the presence
of IPv4 NAT) or truly local (isolated IPv4 RFC1918 islands once IPv6
becomes ubiquitous and the IPv4 Internet is becoming fragmented for CGN
or whatever other reason)



The basic point is that one size does not fit all. Otherwise the
Internet would be the only IP network in the World. And it clearly
isn't.



The IPv6 end node implementations today do not have standardized
default behavior.



One vendor will turn on DHCPv6. Another vendor hates the whole concept
of DHCPv6 and will possibly implement DHCPv6, but not enable it.



One vendor will turn on temporary addresses by default. Another will
not because they hate the idea.



Today's infrastructures are multi-vendor. To achieve consistent
behavior a network manager has to manually override default
settings on every single machine of the flavor they don't like, no
matter whether you are a fan of
SLAAC or DHCPv6. You can't win. Yes they will work together on the
wire, but is it easy to operate and manage?Just ask any real busy
network administrator today who performs daily operations in a large
commercial environment and has to trace problems what he/she thinks
about
that and whether today's tools help them do their job.



One vendor will turn on Happy Eyeballs on one application. Another will
not. One person wants IPv6 preferred today. Another doesn't.



The IPv6 end node implementations today do not have standard ways of
being able to over ride those defaults (which have anyway not been
coordinated across the industry).



So over riding of any defaults that are not appropriate for a
particular end users' requirements relies on operating system specific
/ proprietary management techniques such as Microsoft Active Directory.



However, in these days of the exploding numbers of devices, Internet of
Everything, highly mobile devices, devices running multiple interfaces
and technologies, and Bring Your Own Device, these assumptions of host
management control being equal to network management control are
breaking down.



The IPv6 set of standards does not have a standard way of communicating
or signaling appropriate behavior from a network device to an end node.
DHCPv6 might grow to become that standard, but there is certainly no
consensus at this time. DHCPv6 today isn't even backwards compatible
with all of DHCPv4 e.g. all of the vendor extensions.



If you compare that situation to say 3G or GSM mobile telephone
networks, you will see that these standards do exist in that World for
similar functions (although obviously using different protocols). And
for a good reason. These standards are needed when devices are produced
by different vendors, are highly mobile, some devices are rapidly
turned over whilst others have long operational lifetimes, and they are
all managed by different entities.



There are standards for network equipment behavior (including backwards
compatibility and release management). There are standards for end node
behavior (again including release management). There are standards for
signaling between a network operators device and an end terminal to
ensure that the end node behaves in a manner appropriate for that
operators network.



I'm not saying the Internet should go as far as those ITU style
standards, as they also have their downsides. But I am flagging up that
existing assumptions about how defaults and settings on IT and Internet
systems are expected to be managed should be challenged. Hard coding
settings is not the way to make this transition/ deployment a success.
IMHO



If you need further evidence that people need more control of how the
end nodes behave on their networks today, I suggest the WG casts its
net wider to attempt to quantify all end user requirements and Service
Level Agreements that exist for all systems running IPv4 operationally
today, and how each one will translate into IPv6 in the future.



Everything from light bulbs to web surfing to stock trading systems to
electricity network control systems to spacecraft control systems to
nuclear power plants.

[Many of which also include standard off the shelf operating systems
and applications and IETF defined standard protocols in some part of
their operations]



This has been addressed before in the v6ops list, so is nothing new,
but it did not seem to gain traction there for whatever reason.



See http://tools.ietf.org/html/draft-vandevelde-v6ops-pref-ps-00



Regards,

RayH



Ted Lemon wrote:


  

  
Le May 27, 2011 à 1:47 AM, Ray Hunter a écrit :

  
Is
it really such a big deal to give network managers some knobs to turn,
together with an easy and standard communication mechanism to do this?
The existing mechanism that covered AF preference selection (RFC3484)
recognised this requirement for a need to implement different policies
for different networks at different times during the transition
(although IMHO the standardized tuning tools and communication methods
are rather lacking at this time).

  

  

  
Not only is it not a big deal, but as several people have
explained to you, there exist mechanisms already that we think are
adequate.   But you insist that those mechanisms aren't adequate.   You
haven't actually made any argument as to why they are inadequate;
although you seem certain that they are not.

  


  

  
It would be awfully nice if we could actually identify what it
is about the existing methods doesn't work for you.   If you think
there is some new mechanism that is needed, it would be helpful if you
could describe such a mechanism.   It would also help if you could
explain why it is better than the mechanisms we've already described.
 Then we could have a discussion about whether that mechanism is easier
or harder to implement than existing mechanisms, and whether it would
be more or less effective.

  


  








--------------050900020507090004010006--

From Fred.L.Templin@boeing.com  Fri May 27 08: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 210B3E0809 for ; Fri, 27 May 2011 08:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.121
X-Spam-Level: 
X-Spam-Status: No, score=-5.121 tagged_above=-999 required=5 tests=[AWL=-1.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock4=1.54]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoAu7FHOWdxw for ; Fri, 27 May 2011 08:49:06 -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 95C53E080D for ; Fri, 27 May 2011 08:49:06 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4RFmuJl003235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 May 2011 08:48:57 -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 p4REtfXN015727; Fri, 27 May 2011 07:55:41 -0700 (PDT)
Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4REteRx015704 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 27 May 2011 07:55:41 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 27 May 2011 08:48:55 -0700
From: "Templin, Fred L" 
To: Ray Hunter , Ted Lemon 
Date: Fri, 27 May 2011 08:48:54 -0700
Thread-Topic: [v6ops] Subject: Re: Happy eyeballs update,draft-ietf-v6ops-happy-eyeballs-02
Thread-Index: AcwcfcP3d7o6p2u7QXa4b5QlDrEGSAAB03Wg
Message-ID: 
References: <4DDE8029.70606@globis.net><4DDE9D05.30605@globis.net><4DDEB336.7000701@globis.net><20110527042009.74819FFD8BB@dru gs.dv.isc.org><4DDF3AD7.9090400@globis.net><9091FF4A-4793-4EED-AAD6-9586484813C1@nominum.com> <4DDFBA97.2000801@globis.net>
In-Reply-To: <4DDFBA97.2000801@globis.net>
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_E1829B60731D1740BB7A0626B4FAF0A65C6A729707XCHNW01Vnwnos_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re: Happy eyeballs 	update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 May 2011 15:49:08 -0000

--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A729707XCHNW01Vnwnos_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ray,

Based on your link to the RFC3484 thread, you seem to be still
concerned about ISATAP. Please have a look at the latest draft
to see if it satisfies the concerns:

http://www.ietf.org/id/draft-templin-v6ops-isops-07.txt

Thanks - Fred

________________________________
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of R=
ay Hunter
Sent: Friday, May 27, 2011 7:52 AM
To: Ted Lemon
Cc: v6ops@ietf.org WG
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update,draft-ietf-v6ops-ha=
ppy-eyeballs-02

Interesting concept of engineering: there are solutions and they are all ju=
st fine, but why do you insist on coming with that daft requirement after w=
e've already designed? ;)

See existing thread on RFC3484 bis http://www.ietf.org/mail-archive/web/ipv=
6/current/msg13920.html for my input to how RFC3484 address family selectio=
n does not meet my customer's requirements today to be able to prefer IPv4 =
in an operational network to avoid excessive latency for interactive applic=
ations in the presence of IPv6 over tunnels but still allowing them to roll=
 out IPv6 native, and a suggestion to improve this by codifying address sel=
ection policy of RFC3484 bis into DHCPv6.

And also a suggestion of adding one or more separate tables to the prefix p=
olicy table to be able to codify rules in policy, rather than these being h=
ard coded into operating systems or applications. e.g. whether RFC1918 addr=
esses should be considered global (in the presence of IPv4 NAT) or truly lo=
cal (isolated IPv4 RFC1918 islands once IPv6 becomes ubiquitous and the IPv=
4 Internet is becoming fragmented for CGN or whatever other reason)

The basic point is that one size does not fit all. Otherwise the Internet w=
ould be the only IP network in the World. And it clearly isn't.

The IPv6 end node implementations today do not have standardized default be=
havior.

One vendor will turn on DHCPv6. Another vendor hates the whole concept of D=
HCPv6 and will possibly implement DHCPv6, but not enable it.

One vendor will turn on temporary addresses by default. Another will not be=
cause they hate the idea.

Today's infrastructures are multi-vendor. To achieve consistent behavior a =
network manager has to manually override default settings on every single m=
achine of the flavor they don't like, no matter whether you are a fan of SL=
AAC or DHCPv6. You can't win. Yes they will work together on the wire, but =
is it easy to operate and manage?Just ask any real busy network administrat=
or today who performs daily operations in a large commercial environment an=
d has to trace problems what he/she thinks about that and whether today's t=
ools help them do their job.

One vendor will turn on Happy Eyeballs on one application. Another will not=
. One person wants IPv6 preferred today. Another doesn't.

The IPv6 end node implementations today do not have standard ways of being =
able to over ride those defaults (which have anyway not been coordinated ac=
ross the industry).

So over riding of any defaults that are not appropriate for a particular en=
d users' requirements relies on operating system specific / proprietary man=
agement techniques such as Microsoft Active Directory.

However, in these days of the exploding numbers of devices, Internet of Eve=
rything, highly mobile devices, devices running multiple interfaces and tec=
hnologies, and Bring Your Own Device, these assumptions of host management =
control being equal to network management control are breaking down.

The IPv6 set of standards does not have a standard way of communicating or =
signaling appropriate behavior from a network device to an end node. DHCPv6=
 might grow to become that standard, but there is certainly no consensus at=
 this time. DHCPv6 today isn't even backwards compatible with all of DHCPv4=
 e.g. all of the vendor extensions.

If you compare that situation to say 3G or GSM mobile telephone networks, y=
ou will see that these standards do exist in that World for similar functio=
ns (although obviously using different protocols). And for a good reason. T=
hese standards are needed when devices are produced by different vendors, a=
re highly mobile, some devices are rapidly turned over whilst others have l=
ong operational lifetimes, and they are all managed by different entities.

There are standards for network equipment behavior (including backwards com=
patibility and release management). There are standards for end node behavi=
or (again including release management). There are standards for signaling =
between a network operators device and an end terminal to ensure that the e=
nd node behaves in a manner appropriate for that operators network.

I'm not saying the Internet should go as far as those ITU style standards, =
as they also have their downsides. But I am flagging up that existing assum=
ptions about how defaults and settings on IT and Internet systems are expec=
ted to be managed should be challenged. Hard coding settings is not the way=
 to make this transition/ deployment a success. IMHO

If you need further evidence that people need more control of how the end n=
odes behave on their networks today, I suggest the WG casts its net wider t=
o attempt to quantify all end user requirements and Service Level Agreement=
s that exist for all systems running IPv4 operationally today, and how each=
 one will translate into IPv6 in the future.

Everything from light bulbs to web surfing to stock trading systems to elec=
tricity network control systems to spacecraft control systems to nuclear po=
wer plants.
[Many of which also include standard off the shelf operating systems and ap=
plications and IETF defined standard protocols in some part of their operat=
ions]

This has been addressed before in the v6ops list, so is nothing new, but it=
 did not seem to gain traction there for whatever reason.

See http://tools.ietf.org/html/draft-vandevelde-v6ops-pref-ps-00

Regards,
RayH

Ted Lemon wrote:
Le May 27, 2011 =E0 1:47 AM, Ray Hunter a =E9crit :
Is it really such a big deal to give network managers some knobs to turn, t=
ogether with an easy and standard communication mechanism to do this? The e=
xisting mechanism that covered AF preference selection (RFC3484) recognised=
 this requirement for a need to implement different policies for different =
networks at different times during the transition (although IMHO the standa=
rdized tuning tools and communication methods are rather lacking at this ti=
me).

Not only is it not a big deal, but as several people have explained to you,=
 there exist mechanisms already that we think are adequate.   But you insis=
t that those mechanisms aren't adequate.   You haven't actually made any ar=
gument as to why they are inadequate; although you seem certain that they a=
re not.

It would be awfully nice if we could actually identify what it is about the=
 existing methods doesn't work for you.   If you think there is some new me=
chanism that is needed, it would be helpful if you could describe such a me=
chanism.   It would also help if you could explain why it is better than th=
e mechanisms we've already described.  Then we could have a discussion abou=
t whether that mechanism is easier or harder to implement than existing mec=
hanisms, and whether it would be more or less effective.



--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A729707XCHNW01Vnwnos_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Ray,


 


Based on your link to the RFC3484 thread, you seem=
 to be=20
still


concerned about ISATAP. Please have a look at =
;the=20
latest draft


to see if it satisfies the concerns:=



 


http://www=
.ietf.org/id/draft-templin-v6ops-isops-07.txt


 


Thanks - Fred



  

  

  From: v6ops-bounces@ietf.org=20
  [mailto:v6ops-bounces@ietf.org] On Behalf Of Ray Hunter
Sent=
:=20
  Friday, May 27, 2011 7:52 AM
To: Ted Lemon
Cc:=20
  v6ops@ietf.org WG
Subject: Re: [v6ops] Subject: Re: Happy eyeba=
lls=20
  update,draft-ietf-v6ops-happy-eyeballs-02


  
Interesting concept of engineering: there are solutions and th=
ey=20
  are all just fine, but why do you insist on coming with that daft require=
ment=20
  after we've already designed? ;)

See existing thread on RFC3484 bi=
s =
http://www.ietf.org/mail-archive/web/ipv6/current/msg13920.html=20
  for my input to how RFC3484 address family selection does not meet my=20
  customer's requirements today to be able to prefer IPv4 in an operational=
=20
  network to avoid excessive latency for interactive applications in the=20
  presence of IPv6 over tunnels but still allowing them to roll out IPv6 na=
tive,=20
  and a suggestion to improve this by codifying address selection policy of=
=20
  RFC3484 bis into DHCPv6.

And also a suggestion of adding one or mo=
re=20
  separate tables to the prefix policy table to be able to codify rules in=
=20
  policy, rather than these being hard coded into operating systems or=20
  applications. e.g. whether RFC1918 addresses should be considered global =
(in=20
  the presence of IPv4 NAT) or truly local (isolated IPv4 RFC1918 islands o=
nce=20
  IPv6 becomes ubiquitous and the IPv4 Internet is becoming fragmented for =
CGN=20
  or whatever other reason)

The basic point is that one size does no=
t fit=20
  all. Otherwise the Internet would be the only IP network in the World. An=
d it=20
  clearly isn't.

The IPv6 end node implementations today do not have=
=20
  standardized default behavior.

One vendor will turn on DHCPv6. Ano=
ther=20
  vendor hates the whole concept of DHCPv6 and will possibly implement DHCP=
v6,=20
  but not enable it.

One vendor will turn on temporary addresses by=
=20
  default. Another will not because they hate the idea.

Today's=20
  infrastructures are multi-vendor. To achieve consistent behavior a networ=
k=20
  manager has to manually override default settings on every single machine=
 of=20
  the flavor they don't like, no matter whether you are a fan of SLAAC or=20
  DHCPv6. You can't win. Yes they will work together on the wire, but is it=
 easy=20
  to operate and manage?Just ask any real busy network administrator today =
who=20
  performs daily operations in a large commercial environment and has to tr=
ace=20
  problems what he/she thinks about that and whether today's tools help the=
m do=20
  their job.

One vendor will turn on Happy Eyeballs on one applicati=
on.=20
  Another will not. One person wants IPv6 preferred today. Another=20
  doesn't.

The IPv6 end node implementations today do not have stand=
ard=20
  ways of being able to over ride those defaults (which have anyway not bee=
n=20
  coordinated across the industry).

So over riding of any defaults t=
hat=20
  are not appropriate for a particular end users' requirements relies on=20
  operating system specific / proprietary management techniques such as=20
  Microsoft Active Directory.

However, in these days of the explodin=
g=20
  numbers of devices, Internet of Everything, highly mobile devices, device=
s=20
  running multiple interfaces and technologies, and Bring Your Own Device, =
these=20
  assumptions of host management control being equal to network management=
=20
  control are breaking down.

The IPv6 set of standards does not have=
 a=20
  standard way of communicating or signaling appropriate behavior from a ne=
twork=20
  device to an end node. DHCPv6 might grow to become that standard, but the=
re is=20
  certainly no consensus at this time. DHCPv6 today isn't even backwards=20
  compatible with all of DHCPv4 e.g. all of the vendor extensions.

I=
f you=20
  compare that situation to say 3G or GSM mobile telephone networks, you wi=
ll=20
  see that these standards do exist in that World for similar functions=20
  (although obviously using different protocols). And for a good reason. Th=
ese=20
  standards are needed when devices are produced by different vendors, are=
=20
  highly mobile, some devices are rapidly turned over whilst others have lo=
ng=20
  operational lifetimes, and they are all managed by different=20
  entities.

There are standards for network equipment behavior (incl=
uding=20
  backwards compatibility and release management). There are standards for =
end=20
  node behavior (again including release management). There are standards f=
or=20
  signaling between a network operators device and an end terminal to ensur=
e=20
  that the end node behaves in a manner appropriate for that operators=20
  network.

I'm not saying the Internet should go as far as those ITU=
=20
  style standards, as they also have their downsides. But I am flagging up =
that=20
  existing assumptions about how defaults and settings on IT and Internet=20
  systems are expected to be managed should be challenged. Hard coding sett=
ings=20
  is not the way to make this transition/ deployment a success. IMHO
If=20
  you need further evidence that people need more control of how the end no=
des=20
  behave on their networks today, I suggest the WG casts its net wider to=20
  attempt to quantify all end user requirements and Service Level Agreement=
s=20
  that exist for all systems running IPv4 operationally today, and how each=
 one=20
  will translate into IPv6 in the future.

Everything from light bulb=
s to=20
  web surfing to stock trading systems to electricity network control syste=
ms to=20
  spacecraft control systems to nuclear power plants.
[Many of which als=
o=20
  include standard off the shelf operating systems and applications and IET=
F=20
  defined standard protocols in some part of their operations]

This =
has=20
  been addressed before in the v6ops list, so is nothing new, but it did no=
t=20
  seem to gain traction there for whatever reason.

See htt=
p://tools.ietf.org/html/draft-vandevelde-v6ops-pref-ps-00

Regard=
s,
RayH

Ted=20
  Lemon wrote:=20
  

    

    
Le May 27, 2011 =E0 1:47 AM, Ray Hunter a =E9crit :

    
Is=20
      it really such a big deal to give network managers some knobs to turn=
,=20
      together with an easy and standard communication mechanism to do this=
? The=20
      existing mechanism that covered AF preference selection (RFC3484)=20
      recognised this requirement for a need to implement different policie=
s for=20
      different networks at different times during the transition (although=
 IMHO=20
      the standardized tuning tools and communication methods are rather la=
cking=20
      at this time).


    
Not only is it not a big deal, but as several people have explaine=
d to=20
    you, there exist mechanisms already that we think are adequate.   =
But=20
    you insist that those mechanisms aren't adequate.   You haven't=20
    actually made any argument as to why they are inadequate; although you =
seem=20
    certain that they are not.

    


    
It would be awfully nice if we could actually identify what it is =
about=20
    the existing methods doesn't work for you.   If you think there is=
 some=20
    new mechanism that is needed, it would be helpful if you could describe=
 such=20
    a mechanism.   It would also help if you could explain why it is b=
etter=20
    than the mechanisms we've already described.  Then we could have a=
=20
    discussion about whether that mechanism is easier or harder to implemen=
t=20
    than existing mechanisms, and whether it would be more or less=20
    effective.

    




--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A729707XCHNW01Vnwnos_--

From pch-b2B3A6689@u-1.phicoh.com  Fri May 27 12: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 3BA98E0858 for ; Fri, 27 May 2011 12:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[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 9uYNfIbBWUnR for ; Fri, 27 May 2011 12:56:48 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFD2E084F for ; Fri, 27 May 2011 12:56:48 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QQ39J-0001hzC; Fri, 27 May 2011 21:56:45 +0200
Message-Id: 
To: Ted Lemon 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>      <391C876F-8716-4684-A9C1-1745B4BA91BB@nominum.com>  <0D26A656-BB7E-4327-9ABE-A32E44D49B41@nominum.com> 
In-reply-to: Your message of "Thu, 26 May 2011 13:01:38 -0400 ." <0D26A656-BB7E-4327-9ABE-A32E44D49B41@nominum.com> 
Date: Fri, 27 May 2011 21:56:44 +0200
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 May 2011 19:56:49 -0000

In your letter dated Thu, 26 May 2011 13:01:38 -0400 you wrote:
>Le May 26, 2011 =E0 11:41 AM, Philip Homburg a =E9crit :
>> But if IPv6 is on the order of 50ms slower than IPv4. Are you sure =
>that the
>> current HE draft is also going to prefer IPv4 in that case? Or will =
>users just
>> have to live with the additional latency?
>
>Before I answer that question, can you prove to me that 50ms of =
>additional latency is going to have a noticeable effect on users?   =
>Because right now I have 100ms of latency on my IPv4 link to most =
>machines on the Internet, and it seems to be working okay.   I think =
>it's because 100ms is about the shortest interval anyone is likely to =
>perceive that it's been chosen as the cutoff.   It's important to make =
>the distinction between things that will actually affect the user =
>experience, and things that will not, when deciding what sort of =
>tradeoffs to make.

I'm not a human-computer-interface expert, so I can only guess. There is 
difference between users noticing a difference, and users complaining. 

My latency to a lot of nearby sites is 20ms. And my guess is that I would
notice if there would be another 50ms.

>Remember that web browsers connect in parallel, not in series, up to a =
>point, and that web sites typically already game their secondary =
>downloads to take advantage of the browser cache.   So the only delay =
>that's additive is DNS latency with latency on the initial connect.   We =
>don't have to worry that a web page that loads 40 scripts and css files =
>is going to take two additional seconds to download because of that =
>additional 50ms of latency.

I think you may be a bit too optimistic. There are plenty of pages that are
way more complex than that.


From Ted.Lemon@nominum.com  Fri May 27 13:02: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 DFCD3E0834 for ; Fri, 27 May 2011 13:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.446
X-Spam-Level: 
X-Spam-Status: No, score=-106.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 vK7em9qMRR0x for ; Fri, 27 May 2011 13:02:12 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 22BF8E0746 for ; Fri, 27 May 2011 13:02:11 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTeADQ5TDriaD7dsuDobapdYV3rSQLkSb@postini.com; Fri, 27 May 2011 13:02:12 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 16F38F8033 for ; Fri, 27 May 2011 13:02:11 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id EFB0D190058; Fri, 27 May 2011 13:02:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.1.10.12] (173.162.214.218) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 27 May 2011 13:02:10 -0700
MIME-Version: 1.0 (Apple Message framework v1227)
Content-Type: text/plain; charset="iso-8859-1"
From: Ted Lemon 
In-Reply-To: 
Date: Fri, 27 May 2011 16:02:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>      <391C876F-8716-4684-A9C1-1745B4BA91BB@nominum.com>  <0D26A656-BB7E-4327-9ABE-A32E44D49B41@nominum.com> 
To: Philip Homburg 
X-Mailer: Apple Mail (2.1227)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 May 2011 20:02:13 -0000

Le May 27, 2011 =E0 3:56 PM, Philip Homburg a =E9crit :
> I'm not a human-computer-interface expert, so I can only guess. There =
is=20
> difference between users noticing a difference, and users complaining.=20=


If you can only guess, doesn't that mean that you don't know?   If you =
don't know the answer to a question, how does it help anyone for you to =
guess?

(BTW, you definitely will notice a 50ms increase in latency if it =
happens for every packet in a lockstep protocol.   But we're talking =
about TCP here, and TCP is a sliding-window protocol.)


From joelja@bogus.com  Sat May 28 01:00: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 3F38CE06A6 for ; Sat, 28 May 2011 01:00:26 -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=[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 rB02aTs9y9-d for ; Sat, 28 May 2011 01:00:25 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 53363E064B for ; Sat, 28 May 2011 01:00:25 -0700 (PDT)
Received: from [IPv6:2001:43f8:220:216:129a:ddff:feb1:e750] ([IPv6:2001:43f8:220:216:129a:ddff:feb1:e750]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p4S80F2s036196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 28 May 2011 08:00:21 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: <3C595150-C898-4772-998F-A80C391EBC2B@nominum.com>
Date: Sat, 28 May 2011 01:00:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> <4DDD4ACC.2050408@viagenie.ca> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>  <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>  <3C595150-C898-4772-998F-A80C391EBC2B@nominum.com>
To: Ted Lemon 
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]); Sat, 28 May 2011 08:00:24 +0000 (UTC)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 May 2011 08:00:26 -0000

On May 26, 2011, at 7:02 AM, Ted Lemon wrote:

> Le May 26, 2011 =E0 2:14 AM, 
>  a =E9crit :
>> Don't put double load to networks and servers and this will make the =
Eyeballs more happy.
>=20
> Sorry, what?   Happy Eyeballs does not fetch the same data twice =
through different connections, so it's not even remotely accurate to say =
that it doubles the load on networks and servers.  Indeed, it goes to =
what I think are unnecessary extremes to avoid creating any extra =
traffic at all.
>=20
> One thing I like about the 100ms delay is that it encourages operators =
to optimize their networks--it astonishes me that my current ISP has =
such congested border routers that the RTT to my server in California is =
>100ms.

Delay is delay, the happy eyeballs approach is considered saluribious, =
because it is better than what happens today rather than because adding =
overhead on connect is considered a generally good idea.

joel

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


From v6ops@globis.net  Sat May 28 07:30: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 4B2DEE06E3 for ; Sat, 28 May 2011 07:30:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.23
X-Spam-Level: 
X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-1.372,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_64=0.6, SARE_RMML_Stock4=1.54]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-FYgcYjSpLT for ; Sat, 28 May 2011 07:30:52 -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 B3EABE0688 for ; Sat, 28 May 2011 07:30:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3A6C98700E3; Sat, 28 May 2011 16:30:48 +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 3zyCH0xBEycc; Sat, 28 May 2011 16:30:31 +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 CBEE98700E1; Sat, 28 May 2011 16:30:30 +0200 (CEST)
Message-ID: <4DE10706.8060506@globis.net>
Date: Sat, 28 May 2011 16:30:30 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: "Templin, Fred L" 
References: <4DDE8029.70606@globis.net><4DDE9D05.30605@globis.net><4DDEB336.7000701@globis.net><20110527042009.74819FFD8BB@dru	gs.dv.isc.org><4DDF3AD7.9090400@globis.net><9091FF4A-4793-4EED-AAD6-9586484813C1@nominum.com> <4DDFBA97.2000801@globis.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020203090000000300040201"
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re: Happy eyeballs 	update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 May 2011 14:30:54 -0000

This is a multi-part message in MIME format.
--------------020203090000000300040201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

I would hope people reading the v6ops list just recognize someone 
applying ITIL principles and processes to the discussion, no matter what 
the technology. Please rest assured that I also pose similar questions 
and follow similar steps when introducing any new service, or provider, 
or indeed anything else significantly new to the operational environment 
that has potential to affect the SLA, but of course that doesn't get 
posted to this list.

best regards,
RayH

Templin, Fred L wrote:
> Ray,
> Based on your link to the RFC3484 thread, you seem to be still
> concerned about ISATAP. Please have a look at the latest draft
> to see if it satisfies the concerns:
> http://www.ietf.org/id/draft-templin-v6ops-isops-07.txt
> Thanks - Fred
>
>     ------------------------------------------------------------------------
>     *From:* v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] *On
>     Behalf Of *Ray Hunter
>     *Sent:* Friday, May 27, 2011 7:52 AM
>     *To:* Ted Lemon
>     *Cc:* v6ops@ietf.org WG
>     *Subject:* Re: [v6ops] Subject: Re: Happy eyeballs
>     update,draft-ietf-v6ops-happy-eyeballs-02
>
>     Interesting concept of engineering: there are solutions and they
>     are all just fine, but why do you insist on coming with that daft
>     requirement after we've already designed? ;)
>
>     See existing thread on RFC3484 bis
>     http://www.ietf.org/mail-archive/web/ipv6/current/msg13920.html
>     for my input to how RFC3484 address family selection does not meet
>     my customer's requirements today to be able to prefer IPv4 in an
>     operational network to avoid excessive latency for interactive
>     applications in the presence of IPv6 over tunnels but still
>     allowing them to roll out IPv6 native, and a suggestion to improve
>     this by codifying address selection policy of RFC3484 bis into DHCPv6.
>
>     And also a suggestion of adding one or more separate tables to the
>     prefix policy table to be able to codify rules in policy, rather
>     than these being hard coded into operating systems or
>     applications. e.g. whether RFC1918 addresses should be considered
>     global (in the presence of IPv4 NAT) or truly local (isolated IPv4
>     RFC1918 islands once IPv6 becomes ubiquitous and the IPv4 Internet
>     is becoming fragmented for CGN or whatever other reason)
>
>     The basic point is that one size does not fit all. Otherwise the
>     Internet would be the only IP network in the World. And it clearly
>     isn't.
>
>     The IPv6 end node implementations today do not have standardized
>     default behavior.
>
>     One vendor will turn on DHCPv6. Another vendor hates the whole
>     concept of DHCPv6 and will possibly implement DHCPv6, but not
>     enable it.
>
>     One vendor will turn on temporary addresses by default. Another
>     will not because they hate the idea.
>
>     Today's infrastructures are multi-vendor. To achieve consistent
>     behavior a network manager has to manually override default
>     settings on every single machine of the flavor they don't like, no
>     matter whether you are a fan of SLAAC or DHCPv6. You can't win.
>     Yes they will work together on the wire, but is it easy to operate
>     and manage?Just ask any real busy network administrator today who
>     performs daily operations in a large commercial environment and
>     has to trace problems what he/she thinks about that and whether
>     today's tools help them do their job.
>
>     One vendor will turn on Happy Eyeballs on one application. Another
>     will not. One person wants IPv6 preferred today. Another doesn't.
>
>     The IPv6 end node implementations today do not have standard ways
>     of being able to over ride those defaults (which have anyway not
>     been coordinated across the industry).
>
>     So over riding of any defaults that are not appropriate for a
>     particular end users' requirements relies on operating system
>     specific / proprietary management techniques such as Microsoft
>     Active Directory.
>
>     However, in these days of the exploding numbers of devices,
>     Internet of Everything, highly mobile devices, devices running
>     multiple interfaces and technologies, and Bring Your Own Device,
>     these assumptions of host management control being equal to
>     network management control are breaking down.
>
>     The IPv6 set of standards does not have a standard way of
>     communicating or signaling appropriate behavior from a network
>     device to an end node. DHCPv6 might grow to become that standard,
>     but there is certainly no consensus at this time. DHCPv6 today
>     isn't even backwards compatible with all of DHCPv4 e.g. all of the
>     vendor extensions.
>
>     If you compare that situation to say 3G or GSM mobile telephone
>     networks, you will see that these standards do exist in that World
>     for similar functions (although obviously using different
>     protocols). And for a good reason. These standards are needed when
>     devices are produced by different vendors, are highly mobile, some
>     devices are rapidly turned over whilst others have long
>     operational lifetimes, and they are all managed by different entities.
>
>     There are standards for network equipment behavior (including
>     backwards compatibility and release management). There are
>     standards for end node behavior (again including release
>     management). There are standards for signaling between a network
>     operators device and an end terminal to ensure that the end node
>     behaves in a manner appropriate for that operators network.
>
>     I'm not saying the Internet should go as far as those ITU style
>     standards, as they also have their downsides. But I am flagging up
>     that existing assumptions about how defaults and settings on IT
>     and Internet systems are expected to be managed should be
>     challenged. Hard coding settings is not the way to make this
>     transition/ deployment a success. IMHO
>
>     If you need further evidence that people need more control of how
>     the end nodes behave on their networks today, I suggest the WG
>     casts its net wider to attempt to quantify all end user
>     requirements and Service Level Agreements that exist for all
>     systems running IPv4 operationally today, and how each one will
>     translate into IPv6 in the future.
>
>     Everything from light bulbs to web surfing to stock trading
>     systems to electricity network control systems to spacecraft
>     control systems to nuclear power plants.
>     [Many of which also include standard off the shelf operating
>     systems and applications and IETF defined standard protocols in
>     some part of their operations]
>
>     This has been addressed before in the v6ops list, so is nothing
>     new, but it did not seem to gain traction there for whatever reason.
>
>     See http://tools.ietf.org/html/draft-vandevelde-v6ops-pref-ps-00
>
>     Regards,
>     RayH
>
>     Ted Lemon wrote:
>>     Le May 27, 2011 à 1:47 AM, Ray Hunter a écrit :
>>>     Is it really such a big deal to give network managers some knobs
>>>     to turn, together with an easy and standard communication
>>>     mechanism to do this? The existing mechanism that covered AF
>>>     preference selection (RFC3484) recognised this requirement for a
>>>     need to implement different policies for different networks at
>>>     different times during the transition (although IMHO the
>>>     standardized tuning tools and communication methods are rather
>>>     lacking at this time).
>>
>>     Not only is it not a big deal, but as several people have
>>     explained to you, there exist mechanisms already that we think
>>     are adequate.   But you insist that those mechanisms aren't
>>     adequate.   You haven't actually made any argument as to why they
>>     are inadequate; although you seem certain that they are not.
>>
>>     It would be awfully nice if we could actually identify what it is
>>     about the existing methods doesn't work for you.   If you think
>>     there is some new mechanism that is needed, it would be helpful
>>     if you could describe such a mechanism.   It would also help if
>>     you could explain why it is better than the mechanisms we've
>>     already described.  Then we could have a discussion about whether
>>     that mechanism is easier or harder to implement than existing
>>     mechanisms, and whether it would be more or less effective.
>>


--------------020203090000000300040201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


I would hope people reading the v6ops list just recognize someone
applying ITIL principles and processes to the discussion, no matter
what the technology. Please rest assured that I also pose similar
questions and follow similar steps when introducing any new service, or
provider, or indeed anything else significantly new to the operational
environment that has potential to affect the SLA, but of course that
doesn't get posted to this list.



best regards,

RayH



Templin, Fred L wrote:


  
  
  
Ray,

  
 

  
Based on your link to the
RFC3484 thread, you seem to be still

  
concerned about ISATAP. Please
have a look at the latest draft

  
to see if it satisfies the
concerns:

  
 

  
  
 

  
Thanks - Fred

  

  

    

    
 From:
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
    Ray Hunter

    Sent: Friday, May 27, 2011 7:52 AM

    To: Ted Lemon

    Cc: v6ops@ietf.org WG

    Subject: Re: [v6ops] Subject: Re: Happy eyeballs
update,draft-ietf-v6ops-happy-eyeballs-02

    

    

Interesting concept of engineering: there are solutions and they are
all just fine, but why do you insist on coming with that daft
requirement after we've already designed? ;)

    

See existing thread on RFC3484 bis http://www.ietf.org/mail-archive/web/ipv6/current/msg13920.html
for my input to how RFC3484 address family selection does not meet my
customer's requirements today to be able to prefer IPv4 in an
operational network to avoid excessive latency for interactive
applications in the presence of IPv6 over tunnels but still allowing
them to roll out IPv6 native, and a suggestion to improve this by
codifying address selection policy of RFC3484 bis into DHCPv6.

    

And also a suggestion of adding one or more separate tables to the
prefix policy table to be able to codify rules in policy, rather than
these being hard coded into operating systems or applications. e.g.
whether RFC1918 addresses should be considered global (in the presence
of IPv4 NAT) or truly local (isolated IPv4 RFC1918 islands once IPv6
becomes ubiquitous and the IPv4 Internet is becoming fragmented for CGN
or whatever other reason)

    

The basic point is that one size does not fit all. Otherwise the
Internet would be the only IP network in the World. And it clearly
isn't.

    

The IPv6 end node implementations today do not have standardized
default behavior.

    

One vendor will turn on DHCPv6. Another vendor hates the whole concept
of DHCPv6 and will possibly implement DHCPv6, but not enable it.

    

One vendor will turn on temporary addresses by default. Another will
not because they hate the idea.

    

Today's infrastructures are multi-vendor. To achieve consistent
behavior a network manager has to manually override default settings on
every single machine of the flavor they don't like, no matter whether
you are a fan of SLAAC or DHCPv6. You can't win. Yes they will work
together on the wire, but is it easy to operate and manage?Just ask any
real busy network administrator today who performs daily operations in
a large commercial environment and has to trace problems what he/she
thinks about that and whether today's tools help them do their job.

    

One vendor will turn on Happy Eyeballs on one application. Another will
not. One person wants IPv6 preferred today. Another doesn't.

    

The IPv6 end node implementations today do not have standard ways of
being able to over ride those defaults (which have anyway not been
coordinated across the industry).

    

So over riding of any defaults that are not appropriate for a
particular end users' requirements relies on operating system specific
/ proprietary management techniques such as Microsoft Active Directory.

    

However, in these days of the exploding numbers of devices, Internet of
Everything, highly mobile devices, devices running multiple interfaces
and technologies, and Bring Your Own Device, these assumptions of host
management control being equal to network management control are
breaking down.

    

The IPv6 set of standards does not have a standard way of communicating
or signaling appropriate behavior from a network device to an end node.
DHCPv6 might grow to become that standard, but there is certainly no
consensus at this time. DHCPv6 today isn't even backwards compatible
with all of DHCPv4 e.g. all of the vendor extensions.

    

If you compare that situation to say 3G or GSM mobile telephone
networks, you will see that these standards do exist in that World for
similar functions (although obviously using different protocols). And
for a good reason. These standards are needed when devices are produced
by different vendors, are highly mobile, some devices are rapidly
turned over whilst others have long operational lifetimes, and they are
all managed by different entities.

    

There are standards for network equipment behavior (including backwards
compatibility and release management). There are standards for end node
behavior (again including release management). There are standards for
signaling between a network operators device and an end terminal to
ensure that the end node behaves in a manner appropriate for that
operators network.

    

I'm not saying the Internet should go as far as those ITU style
standards, as they also have their downsides. But I am flagging up that
existing assumptions about how defaults and settings on IT and Internet
systems are expected to be managed should be challenged. Hard coding
settings is not the way to make this transition/ deployment a success.
IMHO

    

If you need further evidence that people need more control of how the
end nodes behave on their networks today, I suggest the WG casts its
net wider to attempt to quantify all end user requirements and Service
Level Agreements that exist for all systems running IPv4 operationally
today, and how each one will translate into IPv6 in the future.

    

Everything from light bulbs to web surfing to stock trading systems to
electricity network control systems to spacecraft control systems to
nuclear power plants.

[Many of which also include standard off the shelf operating systems
and applications and IETF defined standard protocols in some part of
their operations]

    

This has been addressed before in the v6ops list, so is nothing new,
but it did not seem to gain traction there for whatever reason.

    

See http://tools.ietf.org/html/draft-vandevelde-v6ops-pref-ps-00

    

Regards,

RayH

    

Ted Lemon wrote:
    

      

      
Le May 27, 2011 à 1:47 AM, Ray Hunter a écrit :

      
Is
it really such a big deal to give network managers some knobs to turn,
together with an easy and standard communication mechanism to do this?
The existing mechanism that covered AF preference selection (RFC3484)
recognised this requirement for a need to implement different policies
for different networks at different times during the transition
(although IMHO the standardized tuning tools and communication methods
are rather lacking at this time).

      

      

      
Not only is it not a big deal, but as several people have
explained to you, there exist mechanisms already that we think are
adequate.   But you insist that those mechanisms aren't adequate.   You
haven't actually made any argument as to why they are inadequate;
although you seem certain that they are not.

      


      

      
It would be awfully nice if we could actually identify what
it is about the existing methods doesn't work for you.   If you think
there is some new mechanism that is needed, it would be helpful if you
could describe such a mechanism.   It would also help if you could
explain why it is better than the mechanisms we've already described.
 Then we could have a discussion about whether that mechanism is easier
or harder to implement than existing mechanisms, and whether it would
be more or less effective.

      


      

    

  








--------------020203090000000300040201--

From v6ops@globis.net  Sat May 28 08:21: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 8E72BE06CA for ; Sat, 28 May 2011 08:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level: 
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.067,  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 UKa7W91itTG1 for ; Sat, 28 May 2011 08:21:37 -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 B9BADE06BC for ; Sat, 28 May 2011 08:21:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 465E28700D0; Sat, 28 May 2011 17:21:35 +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 DRuQP-DTNDRb; Sat, 28 May 2011 17:21:30 +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 F27B6870023; Sat, 28 May 2011 17:21:29 +0200 (CEST)
Message-ID: <4DE112F9.2050108@globis.net>
Date: Sat, 28 May 2011 17:21:29 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Ted Lemon ,  Philip Homburg , "v6ops@ietf.org WG" 
Content-Type: multipart/alternative; boundary="------------000308080909070201070207"
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 May 2011 15:21:39 -0000

This is a multi-part message in MIME format.
--------------000308080909070201070207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

>
> Subject:
> Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
> From:
> Ted Lemon 
> Date:
> Fri, 27 May 2011 16:02:07 -0400
>
> To:
> Philip Homburg 
> CC:
> v6ops@ietf.org
>
> Content-Transfer-Encoding:
> quoted-printable
> Precedence:
> list
> MIME-Version:
> 1.0 (Apple Message framework v1227)
> References:
>  
> <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> 
> <4DDD4ACC.2050408@viagenie.ca> 
> <97023678-4CB9-4A73-A3ED-358957A246CC@apple.com> 
>  
> <8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com> 
>  
>  
>  
>  
>  
> <391C876F-8716-4684-A9C1-1745B4BA91BB@nominum.com> 
>  
> <0D26A656-BB7E-4327-9ABE-A32E44D49B41@nominum.com> 
> 
> In-Reply-To:
> 
> Message-ID:
> 
> Content-Type:
> text/plain; charset="iso-8859-1"
> Message:
> 2
>
>
> Le May 27, 2011 à 3:56 PM, Philip Homburg a écrit :
>    
>> >  I'm not a human-computer-interface expert, so I can only guess. There is
>> >  difference between users noticing a difference, and users complaining.
>>      
>
> If you can only guess, doesn't that mean that you don't know?   If you don't know the answer to a question, how does it help anyone for you to guess?
>
> (BTW, you definitely will notice a 50ms increase in latency if it happens for every packet in a lockstep protocol.   But we're talking about TCP here, and TCP is a sliding-window protocol.)
>
>
>    
I have worked with people who measure user satisfaction. It can be a 
tricky business, with people fooling themselves unless you go for an ABX 
type test. One second can be significant on web page load times, 
depending in what the user is doing at that time.

In enterprise networks, length is much more important than width IMVHO. 
People seem to be prepared to pay a lot of money for latency reduction. 
Witness the success of WAN optimization. QoS is generally the number one 
unsolved challenge I come across. Not getting the large bandwidths at 
the right price.

TCP may well have a sliding window, but what about the applications 
running over it?

Telnet character echo for example. Or multiple serial SQL queries at 
start up?

There are enough badly written apps out there that ping pong at higher 
levels.
Users of those apps will definitely notice a change from 10mS to 50mS. 
(100 packets per second versus 20)

And what about TCP slow start? That also multiplies up the effect of 
latency for short lived sessions.

We could possibly avoid this discussion by simply reversing the default 
to be "choose the fastest address family" as Philip originally proposed, 
and then adding some mechanism for the ISP's that really need to force 
use of IPv6 by handicapping IPv4 if they so wish (and at their business 
risk). They could possibly even do that with a network latency simulator 
unit on their IPv4 interconnect ;) I don't believe in handicapping the 
majority for the needs of the few.

Talking of usability experts, before we conclude in the WG that the 
whole World will be either happy or unhappy with happy eyeballs 02 and 
the proposed hard-coded default settings, have there been any 
quantitative double-blind tests done on the effects on user satisfaction 
with real web pages with the two alternative settings (handicap IPv4 
with IH = 100mS versus no preference of Address Family = IH of 0mS)?

Would seem an easy enough test to set up, and worthwhile doing given 
that we all seem to think that the draft is generally a great idea, 
whilst the current discussion seems mainly to center around the choice 
of the default value for IH IMVHO.

Although the next follow up question might be, "where is the acceptable 
tolerance level if an IH>0 is a requirement from the WG for the hard 
coded default"?

Not so easy to answer, but perhaps another pointer that IH=0 might be 
the correct choice for default, so setting IH>0 is at the risk of 
whoever wants to do that.

best regards,
RayH

--------------000308080909070201070207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit










  

    
      

        
        
Subject:
        

Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02		
      

      

        
        
From: 

Ted Lemon <Ted.Lemon@nominum.com>		
      

      

        
        
Date: 

Fri, 27 May 2011 16:02:07 -0400		
      

    
  

  

    
      

        
        
To: 

Philip Homburg <pch-v6ops@u-1.phicoh.com>		
      

      

        
        
CC: 

v6ops@ietf.org		
      

    
  

  

    
      

        
        
Content-Transfer-Encoding:
        

quoted-printable		
      

      

        
        
Precedence:
        

list		
      

      

        
        
MIME-Version:
        

1.0 (Apple Message framework v1227)		
      

      

        
        
References:
        

<m1QPCao-0001h6C@stereo.hq.phicoh.net>
<37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com>
<4DDD4ACC.2050408@viagenie.ca>
<97023678-4CB9-4A73-A3ED-358957A246CC@apple.com>
<BANLkTi=RK_Cxcu4O5Y11bb=Uc4vnjnGpKA@mail.gmail.com>
<8FDEAC5E-9BB2-4F8C-9160-BD0817EC7610@apple.com>
<CE8995AB5D178F44A2154F5C9A97CAF4024D31C96B7C@HE111541.emea1.cds.t-internal.com>
<m1QPWpp-0001jGC@stereo.hq.phicoh.net>
<CE8995AB5D178F44A2154F5C9A97CAF4024D31D001F1@HE111541.emea1.cds.t-internal.com>
<m1QPb3C-0001hYC@stereo.hq.phicoh.net>
<CE8995AB5D178F44A2154F5C9A97CAF4024D31D00375@HE111541.emea1.cds.t-internal.com>
<391C876F-8716-4684-A9C1-1745B4BA91BB@nominum.com>
<m1QPcgV-0001iYC@stereo.hq.phicoh.net>
<0D26A656-BB7E-4327-9ABE-A32E44D49B41@nominum.com>
<m1QQ39J-0001hzC@stereo.hq.phicoh.net>		
      

      

        
        
In-Reply-To:
        

<m1QQ39J-0001hzC@stereo.hq.phicoh.net>		
      

      

        
        
Message-ID:
        

<D17F0B51-45E1-471E-80B9-F710FD231682@nominum.com>		
      

      

        
        
Content-Type:
        

text/plain; charset="iso-8859-1"		
      

      

        
        
Message:
        

2		
      

    
  

  

  

  
Le May 27, 2011 à 3:56 PM, Philip Homburg a écrit :
  

  

    
> I'm not a human-computer-interface expert, so I can only guess. There is 
> difference between users noticing a difference, and users complaining. 
    

  

  

If you can only guess, doesn't that mean that you don't know?   If you don't know the answer to a question, how does it help anyone for you to guess?

(BTW, you definitely will notice a 50ms increase in latency if it happens for every packet in a lockstep protocol.   But we're talking about TCP here, and TCP is a sliding-window protocol.)


  

  



I have worked with people who measure user satisfaction. It can be a
tricky business, with people fooling themselves unless you go for an
ABX type test. One second can be significant on web page load times,
depending in what the user is doing at that time.



In enterprise networks, length is much more important than width IMVHO.
People seem to be prepared to pay a lot of money for latency reduction.
Witness the success of WAN optimization. QoS is generally the number
one unsolved challenge I come across. Not getting the large bandwidths
at the right price.



TCP may well have a sliding window, but what about the applications
running over it?



Telnet character echo for example. Or multiple serial SQL queries at
start up?



There are enough badly written apps out there that ping pong at higher
levels.

Users of those apps will definitely notice a change from 10mS to 50mS.
(100 packets per second versus 20)



And what about TCP slow start? That also multiplies up the effect of
latency for short lived sessions.



We could possibly avoid this discussion by simply reversing the default
to be "choose the fastest address family" as Philip originally
proposed, and then adding some mechanism for the ISP's that really need
to force use of IPv6 by handicapping IPv4 if they so wish (and at their
business risk). They could possibly even do that with a network latency
simulator unit on their IPv4 interconnect ;) I don't believe in
handicapping the majority for the needs of the few.



Talking of usability experts, before we conclude in the WG that the
whole World will be either happy or unhappy with happy eyeballs 02 and
the proposed hard-coded default settings, have there been any
quantitative double-blind tests done on the effects on user
satisfaction with real web pages with the two alternative settings
(handicap IPv4 with IH = 100mS versus no preference of Address Family =
IH of 0mS)?



Would seem an easy enough test to set up, and worthwhile doing given
that we all seem to think that the draft is generally a great idea,
whilst the current discussion seems mainly to center around the choice
of the default value for IH IMVHO.



Although the next follow up question might be, "where is the acceptable
tolerance level if an IH>0 is a requirement from the WG for the hard
coded default"?



Not so easy to answer, but perhaps another pointer that IH=0 might be
the correct choice for default, so setting IH>0 is at the risk of
whoever wants to do that.



best regards,

RayH




--------------000308080909070201070207--

From dr@cluenet.de  Sat May 28 08:31: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 D0515E06CA for ; Sat, 28 May 2011 08:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 rjOCAPSCyEQQ for ; Sat, 28 May 2011 08:31:41 -0700 (PDT)
Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id E4C3DE06BC for ; Sat, 28 May 2011 08:31:40 -0700 (PDT)
Received: by mail1.cluenet.de (Postfix, from userid 500) id 98D2A1082ED; Sat, 28 May 2011 17:31:39 +0200 (CEST)
Date: Sat, 28 May 2011 17:31:39 +0200
From: Daniel Roesen 
To: v6ops@ietf.org
Message-ID: <20110528153139.GA22761@srv03.cluenet.de>
Mail-Followup-To: v6ops@ietf.org
References: <4DE112F9.2050108@globis.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4DE112F9.2050108@globis.net>
User-Agent: Mutt/1.5.17 (2007-11-01)
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 May 2011 15:31:41 -0000

On Sat, May 28, 2011 at 05:21:29PM +0200, Ray Hunter wrote:
> TCP may well have a sliding window, but what about the applications running 
> over it?
>
> Telnet character echo for example. Or multiple serial SQL queries at start 
> up?
>
> There are enough badly written apps out there that ping pong at higher 
> levels.
> Users of those apps will definitely notice a change from 10mS to 50mS. (100 
> packets per second versus 20)

Indeed. I went thru months long escalation when a customer upgraded from
a 4ms RTT direct 2mbps line between two of their sites to a 8mbps 12ms RTT
MPLS L3VPN connection. For their application, it made the difference
between "somewhat sluggish" to "absolutely unusable, we have to wait up
to 15 minutes for results".

Turned out their custom application frontend was using SQL to speak to
the backend at the other site, and hundreds of ping-pong round trips
happening, easily seen and visualized with a TCP analyzer. It was easy to
calculate that it was not the technology swap from direct E1 to multiple
bundled SDSL lines, but the increased RTT in combination with a lousy
written application expecting LAN-type latency.

And that was just 4ms to 12ms.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

From Ted.Lemon@nominum.com  Sat May 28 08: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 EAC57E06DA for ; Sat, 28 May 2011 08:50:35 -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 rhRJCcslzOzZ for ; Sat, 28 May 2011 08:50:34 -0700 (PDT)
Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 56CAEE0664 for ; Sat, 28 May 2011 08:50:34 -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 DSNKTeEZyaUY2JE3Rk98DFDpiNleApy3TJ5G@postini.com; Sat, 28 May 2011 08:50:34 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 E6498F800E for ; Sat, 28 May 2011 08:50:13 -0700 (PDT)
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D382C190058; Sat, 28 May 2011 08:50:13 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.1.9] (64.215.212.152) by exchange-01.win.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 28 May 2011 08:50:13 -0700
MIME-Version: 1.0 (Apple Message framework v1227)
Content-Type: text/plain; charset="iso-8859-1"
From: Ted Lemon 
In-Reply-To: <4DE112F9.2050108@globis.net>
Date: Sat, 28 May 2011 11:50:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <8EE9A28C-1B0D-41AF-A019-9B15A0E31B11@nominum.com>
References: <4DE112F9.2050108@globis.net>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1227)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 May 2011 15:50:36 -0000

Le May 28, 2011 =E0 11:21 AM, Ray Hunter a =E9crit :
> I have worked with people who measure user satisfaction. It can be a =
tricky business, with people fooling themselves unless you go for an ABX =
type test. One second can be significant on web page load times, =
depending in what the user is doing at that time.

Absolutely.   A second is a long time.

> In enterprise networks, length is much more important than width =
IMVHO. People seem to be prepared to pay a lot of money for latency =
reduction. Witness the success of WAN optimization. QoS is generally the =
number one unsolved challenge I come across. Not getting the large =
bandwidths at the right price.

I have a friend who used to work at a company that did high-speed =
arbitrage over networks.   They cared about latency.   They *really* =
cared about latency.  I certainly would not claim that latency is never =
important, nor even that 50ms of latency is such a small amount that it =
is never important.

> Telnet character echo for example. Or multiple serial SQL queries at =
start up?

For the former, 50ms isn't detectable.   It's too short.   Latency =
certainly matters with telnet, but 50ms isn't the benchmark.   For =
sequential SQL queries, you're talking about a custom app.   The =
implementor would have to choose to implement happy eyeballs--it's not =
like it just happens.

> There are enough badly written apps out there that ping pong at higher =
levels.
> Users of those apps will definitely notice a change from 10mS to 50mS. =
(100 packets per second versus 20)

Again, why do you expect that the implementors of these apps would =
prioritize implementing Happy Eyeballs over fixing their lockstep bugs?  =
 These are probably legacy apps that work "well enough" and that nobody =
wants to mess with.   They aren't going to be doing Happy Eyeballs.   =
Feel free to contradict me with real examples.

> And what about TCP slow start? That also multiplies up the effect of =
latency for short lived sessions.

Sure, but only for short-lived sessions that are in that >0<=3D100 =
latency gap.   If the latency variation is higher than that, the IPv6 =
connection won't win the race, and subsequent attempts will have a =
reduced preference for IPv6, so that the lag will be eliminated quickly. =
  And it's not very much lag to begin with.

> We could possibly avoid this discussion by simply reversing the =
default to be "choose the fastest address family" as Philip originally =
proposed, and then adding some mechanism for the ISP's that really need =
to force use of IPv6 by handicapping IPv4 if they so wish (and at their =
business risk). They could possibly even do that with a network latency =
simulator unit on their IPv4 interconnect ;) I don't believe in =
handicapping the majority for the needs of the few.

But we don't know which address family is fastest.  Furthermore, you are =
misstating the problem.   The problem is not that we are always going to =
wait 100ms before trying IPv6.   The problem is that we are going to =
give IPv6 a 100ms head start when IPv6 is available *and* the host we =
are trying to connect to supports it.   Sometimes this will be the right =
choice: IPv6 connectivity will be at parity with IPv4, or IPv6 will be =
faster than IPv4, or IPv4 to that host might not even work.   Sometimes =
it will be the wrong choice: IPv4 would have been faster, and we wasted =
100ms.

And a key factor here is that there are things we can do to tune the =
network to avoid making the wrong choice.   It's not the case that a =
happy-eyeballs-implementing app will necessarily choose wrong in these =
cases, because there are things that the network manager can do to =
prevent it.   You would like there to be more things the network manager =
can do.

> Talking of usability experts, before we conclude in the WG that the =
whole World will be either happy or unhappy with happy eyeballs 02 and =
the proposed hard-coded default settings, have there been any =
quantitative double-blind tests done on the effects on user satisfaction =
with real web pages with the two alternative settings (handicap IPv4 =
with IH =3D 100mS versus no preference of Address Family =3D IH of 0mS)?

How would you set this up?   I guess you could set up a pessimal =
configuration, and see what happens.   But then you'd only be testing =
how this plays in the worst case.   The Chrome implementation is working =
fine for me on a v4-only network and a dual-stack network with =
comparable latency, but that doesn't really tell us anything.


From rogerj@gmail.com  Sat May 28 10:00: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 7A4D2E0719 for ; Sat, 28 May 2011 10:00:20 -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=[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 E7m1Z3jSNiBJ for ; Sat, 28 May 2011 10:00:19 -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 52B63E073A for ; Sat, 28 May 2011 10:00:19 -0700 (PDT)
Received: by wyb29 with SMTP id 29so2151253wyb.31 for ; Sat, 28 May 2011 10:00:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FJoHeOD9yENXwLINZL1jktkJ6TgnFh+gppW8ENaAmvM=; b=hzaEMfv+313953M5yAAspa4o1fgvc8+kq6xlkrOiztwqJbMP/EIpOhBGf1CVAkz+ij qvydVVUiZRY3lih1o2zUl+/KSnwjCQeTwN86LPb79y6RhrW1kxHiWHIC4H+Tiqpsq0Jf EcUdAQJijmpC4jMmJB9fhZ9ZcVV21g//04AZk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wqE3Ka3s8pnsglk2mY8/kDqzzPlYBjHcSY6on2ZZb8v1AbP4TY/kHwhaIXrQKGZay5 nGlRXSCxYWPHXnUI6XaLuvZVu1FOwVsyFmy51Yo/q3S1lwrWb9O9jidnChIiNigg+hur BbfCDTF20jYoWu7n+69azAaKbs1NWzD/IsehI=
MIME-Version: 1.0
Received: by 10.227.23.200 with SMTP id s8mr3290919wbb.87.1306602016755; Sat, 28 May 2011 10:00:16 -0700 (PDT)
Received: by 10.227.143.135 with HTTP; Sat, 28 May 2011 10:00:16 -0700 (PDT)
In-Reply-To: <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com>
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com>
Date: Sat, 28 May 2011 19:00:16 +0200
Message-ID: 
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: james woodyatt 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 May 2011 17:00:20 -0000

On Wed, May 25, 2011 at 8:15 PM, james woodyatt  wrote:
> On May 25, 2011, at 04:49 , Philip Homburg wrote:
>>
>> The draft is biased towards IPv6. I wonder if that is a good idea. In th=
e past, a bias towards IPv6 led to all kinds of problems. If IPv6 is better=
, let that be shown in the connection setup times.
>
> I have to break from the majority on this and concur with Mr. Homburg. =
=A0These little 200 milliseconds delays will add up quickly with repetition=
.
>
> Picture in your mind a user interface for letting a human configure the b=
ias between IPv4 and IPv6. =A0The proper way to present this would be a sli=
der, where the middle position means without any bias between IPv4 and IPv6=
, and the distance from the middle position, in either direction, correspon=
ds to the amount of time a user is willing to wait for a connection over a =
specific network layer protocol when the other one would give them service =
sooner.
>
> Can anyone here imagine a reasonable situation where an ordinary user wou=
ld want to position that slider anywhere other than the middle position?
>
> I can imagine situations where a certain class of advanced user might wan=
t, for troubleshooting purposes, to disable one or the other network layer =
entirely, but I can't see why I should be required by standards action to s=
et a default for that conceptual slider on the vast majority of ordinary us=
ers to anywhere but the exact middle.
>
> Why, oh why, would we ever think it was smart to force these delays in a =
standards track document?


I really really would like everyone to be forced over to IPv6, I
really do. I could accept a breakage on IPv4 just to get it done.


But... I do not think IETF can prefer IPv6 over IPv4 yet, it's too
soon. We should not be biased toward any right now.

We should instead give three suggested "values", and suggest people
should consider the future and recommend people to prefer IPv6.
1.) prefer IPv4 over IPv6 use this value
2.) do not prefer any, use this value
3.) prefer IPv6 over IPv4, use this value


If IPv6 is better it will "win" the race anyway in the end. And I
belive it will.



--=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 v6ops@globis.net  Sat May 28 10:04: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 5DBBCE073A for ; Sat, 28 May 2011 10:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level: 
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064,  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 qg0GUAvhc4p0 for ; Sat, 28 May 2011 10:04: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 64DC1E070C for ; Sat, 28 May 2011 10:04:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 248008700E3; Sat, 28 May 2011 19:04: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 82scud5UnQqQ; Sat, 28 May 2011 19:04:01 +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 142308700DF; Sat, 28 May 2011 19:04:01 +0200 (CEST)
Message-ID: <4DE12B00.9050300@globis.net>
Date: Sat, 28 May 2011 19:04:00 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Ted Lemon , "v6ops@ietf.org WG" , Philip Homburg 
References: <4DE112F9.2050108@globis.net> <8EE9A28C-1B0D-41AF-A019-9B15A0E31B11@nominum.com>
In-Reply-To: <8EE9A28C-1B0D-41AF-A019-9B15A0E31B11@nominum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 May 2011 17:04:08 -0000

Ted Lemon wrote:
> How would you set this up? I guess you could set up a pessimal 
> configuration, and see what happens. But then you'd only be testing 
> how this plays in the worst case. The Chrome implementation is working 
> fine for me on a v4-only network and a dual-stack network with 
> comparable latency, but that doesn't really tell us anything.
>    
You'd be better of asking a real expert to design the test, but I would 
imagine something similar to other ABX double blind tests: you  
automatically compile multiple copies of the application statically 
linked to a lib with IH either set to 0 or 100 on a semi-random basis 
calling them build 1 .. n. You'd store the compilation settings of IH 
used for each build in a file that you only examine after conducting the 
trials. You have a network nightmare box that automatically switches in 
say 90mS of additional latency semi-randomly for the IPv6 traffic every 
X seconds (again logging the actual settings automatically and warning 
you when a new setting had been applied, but without revealing what the 
setting actually was) You sit behind your computer and use the various 
builds to load standard pages that won't cache, noting whether you 
thought there was latency present or not, and at the end whether you 
thought the build was IH=0 or IH=100. After sufficient trials, you open 
the build and latency log files and look at the correlation for how many 
times you guessed correctly. Repeat with other values of IH and or 
latency and or test subjects until bored/ result is clear whether 
additional latency is detectable or not and whether the IH compilation 
setting had an impact on if the test subject could detect it.

From gert@space.net  Sat May 28 13:04: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 1C5F8E076B for ; Sat, 28 May 2011 13:04: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 4qrC4Zh0Tv9H for ; Sat, 28 May 2011 13:04:03 -0700 (PDT)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D585E06EE for ; Sat, 28 May 2011 13:04:01 -0700 (PDT)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 2DB09F8111 for ; Sat, 28 May 2011 22:04:00 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 06E22F8156 for ; Sat, 28 May 2011 22:04:00 +0200 (CEST)
Received: (qmail 23649 invoked by uid 1007); 28 May 2011 22:03:59 +0200
Date: Sat, 28 May 2011 22:03:59 +0200
From: Gert Doering 
To: Ray Hunter 
Message-ID: <20110528200359.GR45955@Space.Net>
References: <4DE112F9.2050108@globis.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4DE112F9.2050108@globis.net>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 May 2011 20:04:04 -0000

Hi,

On Sat, May 28, 2011 at 05:21:29PM +0200, Ray Hunter wrote:
> TCP may well have a sliding window, but what about the applications 
> running over it?
> 
> Telnet character echo for example. Or multiple serial SQL queries at 
> start up?
> 
> There are enough badly written apps out there that ping pong at higher 
> levels.
> Users of those apps will definitely notice a change from 10mS to 50mS. 
> (100 packets per second versus 20)

Don't mix session startup delay with in-session roundtrip delay.

Way different things.  You're concerned about in-session RTT, while
happy eyeballs will add initial session startup delay.

> And what about TCP slow start? That also multiplies up the effect of 
> latency for short lived sessions.

Completely irrelevant for the discussion at hand.  TCP is not modified,
and no extra delay is added to individual TCP packets.

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 marka@isc.org  Sat May 28 18:25: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 3F863E0684 for ; Sat, 28 May 2011 18:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.267
X-Spam-Level: **
X-Spam-Status: No, score=2.267 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_WANT=2.3, MIME_8BIT_HEADER=0.3, SARE_URI_EQUALS=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 vMEV7E4huHEO for ; Sat, 28 May 2011 18:25: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 891EDE0657 for ; Sat, 28 May 2011 18:25:01 -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 44E545F98B7; Sun, 29 May 2011 01:24:36 +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 E0295216C7A; Sun, 29 May 2011 01:24:27 +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 61E891012EED; Sun, 29 May 2011 11:26:07 +1000 (EST)
To: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
From: Mark Andrews 
References:  <37093F5E-9BB2-4342-AC19-8E57EB7851EE@apple.com> 
In-reply-to: Your message of "Sat, 28 May 2011 19:00:16 +0200." 
Date: Sun, 29 May 2011 11:26:07 +1000
Message-Id: <20110529012607.61E891012EED@drugs.dv.isc.org>
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 May 2011 01:25:04 -0000

In message , =?ISO-8859-1?Q?Roger_J=F8rgensen?= writes:
> On Wed, May 25, 2011 at 8:15 PM, james woodyatt  wrote:
> > On May 25, 2011, at 04:49 , Philip Homburg wrote:
> >>
> >> The draft is biased towards IPv6. I wonder if that is a good idea. In th=
> e past, a bias towards IPv6 led to all kinds of problems. If IPv6 is better=
> , let that be shown in the connection setup times.
> >
> > I have to break from the majority on this and concur with Mr. Homburg. =
> =A0These little 200 milliseconds delays will add up quickly with repetition.
> >
> > Picture in your mind a user interface for letting a human configure the b=
> ias between IPv4 and IPv6. =A0The proper way to present this would be a sli=
> der, where the middle position means without any bias between IPv4 and IPv6=
> , and the distance from the middle position, in either direction, correspon=
> ds to the amount of time a user is willing to wait for a connection over a =
> specific network layer protocol when the other one would give them service =
> sooner.
> >
> > Can anyone here imagine a reasonable situation where an ordinary user wou=
> ld want to position that slider anywhere other than the middle position?
> >
> > I can imagine situations where a certain class of advanced user might wan=
> t, for troubleshooting purposes, to disable one or the other network layer =
> entirely, but I can't see why I should be required by standards action to s=
> et a default for that conceptual slider on the vast majority of ordinary us=
> ers to anywhere but the exact middle.
> >
> > Why, oh why, would we ever think it was smart to force these delays in a =
> standards track document?

What delay?  Native vs native is equal.
 
> I really really would like everyone to be forced over to IPv6, I
> really do. I could accept a breakage on IPv4 just to get it done.
> 
> But... I do not think IETF can prefer IPv6 over IPv4 yet, it's too
> soon. We should not be biased toward any right now.

The problem is that if there isn't a connection bias that we won't
know when it is safe to turn off IPv4.  Without a bias you will
have a 50/50 split in traffic.  Tunneling of IPv6 will mostly
disappear in a couple of years time as ISPs bring up native IPv6,
you can see the trend happening today.  ISP's really don't want to
be running transitioning technology or CGN's.  Both are overhead
on top of native.

If using a transition technology to get IPv6 gives you unacceptable
performance for what you are doing then turn it off and wait until
you can get native or switch providers to get native.

Remember for most applications marginal difference in rtt cause by
using transition technology is not noticible.  Additionally a 100ms
bias will stop you using really bad tunnel end point w.r.t. to where
you are connecting to so it puts a upper bound on the extra rtt,
(100ms + IPv4 rtt).

I'm in Sydney, Australia and the tunnel end point is in California.
The following is with a 100 ms bias.

e.g.
[drugs:~] marka% ./a.out www.aarnet.edu.au
trying 2001:388:1:4041::800
trying 202.158.201.38
connected 202.158.201.38
connect_to_host(www.aarnet.edu.au) -> 5 in 122 ms
[drugs:~] marka% ping www.aarnet.edu.au
PING www.aarnet.edu.au (202.158.201.38): 56 data bytes
64 bytes from 202.158.201.38: icmp_seq=0 ttl=116 time=18.556 ms
64 bytes from 202.158.201.38: icmp_seq=1 ttl=116 time=20.606 ms
^C
--- www.aarnet.edu.au ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 18.556/19.581/20.606/1.025 ms
[drugs:~] marka% ping6 www.aarnet.edu.au
PING6(56=40+8+8 bytes) 2001:470:1f00:820:6233:4bff:fe01:7585 --> 2001:388:1:4041::800
16 bytes from 2001:388:1:4041::800, icmp_seq=0 hlim=56 time=406.336 ms
^C
--- www.aarnet.edu.au ping6 statistics ---
2 packets transmitted, 1 packets received, 50.0% packet loss
round-trip min/avg/max/std-dev = 406.336/406.336/406.336/0.000 ms

[drugs:~] marka% 

For Europe and America using tunneled IPv6 has no negative impact
for me.  Connecting to Australian sites it will have a negative
impact but a 100 ms bias will remove it.  Connecting to most of
Asia there is no negative impact from the tunnel.

Mark

> We should instead give three suggested "values", and suggest people
> should consider the future and recommend people to prefer IPv6.
> 1.) prefer IPv4 over IPv6 use this value
> 2.) do not prefer any, use this value
> 3.) prefer IPv6 over IPv4, use this value
> 
> 
> If IPv6 is better it will "win" the race anyway in the end. And I
> belive it will.
> 
> 
> 
> -- =
> 
> 
> 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
> _______________________________________________
> 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 v6ops@globis.net  Sat May 28 21:41: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 AA839E06F0 for ; Sat, 28 May 2011 21:41:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.061,  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 6zytAh++mCMV for ; Sat, 28 May 2011 21:41:52 -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 4995DE06E9 for ; Sat, 28 May 2011 21:41:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BBBB18700E5; Sun, 29 May 2011 06:41:49 +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 u-LrrlyXTrBt; Sun, 29 May 2011 06:41:40 +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 C4CFD8700B2; Sun, 29 May 2011 06:41:40 +0200 (CEST)
Message-ID: <4DE1CE84.1000203@globis.net>
Date: Sun, 29 May 2011 06:41:40 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Gert Doering 
References: <4DE112F9.2050108@globis.net> <20110528200359.GR45955@Space.Net>
In-Reply-To: <20110528200359.GR45955@Space.Net>
Content-Type: multipart/alternative; boundary="------------000306090608090405010007"
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 May 2011 04:41:52 -0000

This is a multi-part message in MIME format.
--------------000306090608090405010007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gert Doering wrote:
> Don't mix session startup delay with in-session roundtrip delay.
> Way different things.  You're concerned about in-session RTT, while
> happy eyeballs will add initial session startup delay.
>
>    
>> And what about TCP slow start? That also multiplies up the effect of
>> latency for short lived sessions.
>>      
>
> Completely irrelevant for the discussion at hand.  TCP is not modified,
> and no extra delay is added to individual TCP packets.
>
> Gert Doering
>          -- NetMaster
>    
Depends on the statistics for RTT for IPv4 v IPv6. If they are semi 
random distributions around an underlying equivalent latency then it 
will make little difference and IPv6 will be preferred but not cause any 
"harm." If the RTT difference has a static offset due to structural 
differences in path, then the initial offset will remain valid for all 
packets, because IPv6 got that initial head start but was still chosen.

Different boxes and services could cause very different physical / 
switching paths through the enterprise network

Possible issues in the enterprise that are probably not often an issue 
in the Internet: Network provider P may not be at all IPv6 capable, so 
you tunnel or temporarily contract another provider for IPv6 for that 
portion of the network (tunneling usually means losing DSCP QoS), WAN 
optimization vendor R is not yet IPv6 capable, Firewall vendor J 
implements hardware acceleration for IPv4 but not IPv6, Load balancer 
vendor X fast switches IPv4 but process switches IPv6, policy based 
routing may send some IPv4 via Internet offload to reduce costs but IPv6 
runs direct via MPLS (no IPv6 NAT means that the return path is 
difficult to engineer for policy based routing if traffic ends up at the 
same subnet), so some of these cases are where IPv4 should actually be 
preferred even though it is apparently slower for the SYN ACK race.

I agree it's a dilemma to choose the right value for the default, hence 
my preference is IH=0 or as close to 0 as possible that it is not 
detectable by users.

Regards,
RayH

--------------000306090608090405010007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Gert Doering wrote:

Don't
mix session startup delay with in-session roundtrip delay.

  
Way different things.  You're concerned about in-session RTT, while
happy eyeballs will add initial session startup delay.

  

  

    
And what about TCP slow start? That also multiplies up the effect of 
latency for short lived sessions.
    

  

  

Completely irrelevant for the discussion at hand.  TCP is not modified,
and no extra delay is added to individual TCP packets.

Gert Doering
        -- NetMaster
  



Depends on the statistics for RTT for IPv4 v IPv6. If they are semi
random distributions around an underlying equivalent latency then it
will make little difference and IPv6 will be preferred but not cause
any "harm." If the RTT difference has a static offset due to structural
differences in path, then the initial offset will remain valid for all
packets, because IPv6 got that initial head start but was still chosen.



Different boxes and services could cause very different physical /
switching paths through the enterprise network



Possible issues in the enterprise that are probably not often an issue
in the Internet: Network provider P may not be at all IPv6 capable, so
you tunnel or temporarily contract another provider for IPv6 for that
portion of the network (tunneling usually means losing DSCP QoS), WAN
optimization vendor R is not yet IPv6 capable, Firewall vendor J
implements hardware acceleration for IPv4 but not IPv6, Load balancer
vendor X fast switches IPv4 but process switches IPv6, policy based
routing may send some IPv4 via Internet offload to reduce costs but
IPv6 runs direct via MPLS (no IPv6 NAT means that the return path is
difficult to engineer for policy based routing if traffic ends up at
the same subnet), so some of these cases are where IPv4 should actually
be preferred even though it is apparently slower for the SYN ACK race.



I agree it's a dilemma to choose the right value for the default, hence
my preference is IH=0 or as close to 0 as possible that it is not
detectable by users.



Regards,

RayH




--------------000306090608090405010007--

From jason_livingood@cable.comcast.com  Sun May 29 07:46: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 66B63E0744; Sun, 29 May 2011 07:46:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.462
X-Spam-Level: 
X-Spam-Status: No, score=-108.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 8mhnAIAaeY+l; Sun, 29 May 2011 07:46:14 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 10669E0747; Sun, 29 May 2011 07:46:09 -0700 (PDT)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.127838399; Sun, 29 May 2011 10:46:05 -0400
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Sun, 29 May 2011 10:46:05 -0400
From: "Livingood, Jason" 
To: Bernard Aboba , "v6ops@ietf.org" , "ietf@ietf.org" 
Thread-Topic: Last Call:  (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC
Thread-Index: AQHMHg8dRgI0NSSQz0ewTR5MPZMciA==
Date: Sun, 29 May 2011 14:46:03 +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.10.0.110310
x-originating-ip: [24.40.55.72]
Content-Type: multipart/alternative; boundary="_000_CA07C26B28868jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Subject: Re: [v6ops] Last Call:  (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 May 2011 14:46:16 -0000

--_000_CA07C26B28868jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Bernard =96 I've finally found the time to close out the last bits of fe=
edback in this version of the draft. Your comments will be incorporated sho=
rtly into a =9604 version of the document. Please see specific replies inli=
ne below.

Thanks!
Jason


On 4/18/11 2:08 PM, "Bernard Aboba" > wrote:

Overall, I think this is a useful document.

My suggestions below mostly relate to potential organizational improvements=
, as well as as a bit more detail in some areas.

Section 2

This section talks about how white-listing works, but does not talk about p=
otential mechanisms by which the whitelist is determined.  For example, in =
addition to techniques for manually maintaining the whitelist, there have b=
een some suggestions that would involve automatic determinations (e.g. only=
 answering with AAAA RRs if the query comes in over IPv6).   It might be us=
eful to cover some of the proposals, since they might have different implic=
ations.

[JL] I added a bit of text in the ad hoc DNS whitelisting section noting th=
at there are two approaches. I did not include the part about only respondi=
ng with a AAAA RR if the query comes in via IPv6, as I've not heard much ab=
out this in practice and discussion from implementers seems to indicate tha=
t even if they recursive server sent the query over IPv6 they still may hav=
e end hosts that are broken.

Section 2.1

Is the term "IP address" here intended to include both IPv4 and IPv6 addres=
ses?

[JL] Yes, and I updated the text to clarify that.

Section 3


   At least one highly-trafficked domain has noted that they have
   received requests to not send DNS responses with AAAA resource
   records to particular resolvers.  In this case, the operators of
   those recursive resolvers have expressed a concern that their IPv6
   network infrastructure is not yet ready to handle the large traffic
   volume which may be associated with the hosts in their network
   connecting to the websites of these domains.  This concern is clearly
   a temporary consideration relating to the deployment of IPv6 network
   infrastructure on the part of networks with end user hosts, rather
   than a long-term concern.  These end user networks may also have
   other tools at their disposal in order to address this concern,
   including applying rules to network equipment such as routers and
   firewalls (this will necessarily vary by the type of network, as well
   as the technologies used and the design of a given network), as well
   as configuration of their recursive resolvers (though modifying or
   suppressing AAAA resource records in a DNSSEC-signed domain on a
   Security-Aware Resolver will be problematic Section 10.1).

[BA]  This paragraph seems to be distinguishing "blacklisting" from "whitel=
isting" as well as describing some of the implications of attempting to sup=
press AAAA RRs in the recursive resolver.  It might be worthwhile to introd=
uce the distinction between "blacklisting" and "whitelisting" earlier on.
Such a section might also include the following paragraph from Section 7.3.=
7:

[JL] Good idea =96 I added a brief section contrasting whitelisting and bla=
cklisting, including some of the text you suggest.

   It is unclear when and if it would be appropriate to change from
   whitelisting to blacklisting, and whether or how this could feasibly
   be coordinated across the Internet, which may be proposed or
   implemented on an ad hoc basis when a majority of networks (or
   allocated IPv6 address blocks) have been whitelisted.  Finally, some
   parties implementing DNS whitelisting consider this to be a temporary
   measure.  As such, it is not clear how these parties will judge the
   network conditions to have changed sufficiently to justify disabling
   DNS whitelisting and/or what the process and timing will be in order
   to discontinue this practice.

Section 4


   While in Section 1 the level of IPv6-related impairment has been
   estimated to be as high as 0.078% of Internet users, which is a
   primary motivation cited for the practice of DNS whitelisting, it is
   not clear if the level of IPv4-related impairment is more or less
   that this percentage (which in any case is likely to have declined
   since its original citation).  Indeed, as at least one document
   reviewer has pointed out, it may simply be that websites are only
   measuring IPv6 impairments and not IPv4 impairments, whether because
   IPv6 is new or whether those websites are simply unable to or are
   otherwise not in a position to be able to measure IPv4 impairment
   (since this could result in no Internet access whatsoever).  As a
   result, it is worth considering that IPv4-related impairment could
   exceed that of IPv6-related impairment and that such IPv4-related
   impairment may have simply been accepted as "background noise" on the
   Internet for a variety of reasons.  Of course, this comparison of the
   level of worldwide IPv6 impairments to IPv4 impairments is
   speculation, as the author is not aware of any good measurement of
   IPv4-related impairments which are comparable in nature to the IPv6-
   related impairment measurements which have recently been conducted
   around the world.

[BA] It seems to me that discussion of measurement issues should probably c=
ome earlier in the document, possibly in its own section.
My suggestion is to move this paragraph as well other paragraphs referring =
to measurement into its own section (Section 1.1?).
The following paragraph from Section 3.2 might be a candidate:

[JL] Good suggestion - I have done so. I moved the impairment percentage ci=
tation to section 3 and have greatly re-worked section 3 to address this (a=
nd add a new motivation I've heard from one implementer).


   Finally, some domains, have run IPv6 experiments whereby they added
   AAAA resource records and observed and measured errors [Heise Online
   Experiment], which should be important reading for any domain
   contemplating either the use of DNS whitelisting or simply adding
   IPv6 addressing to their site.


Section 6

This section talks about Adhoc versus universal deployment scenarios.  It s=
trikes me that the underlying distinction is not so much the universality o=
f whitelisting deployment as much as whether the whitelists are shared or i=
ndependent. The document seems to argue that independence is the most likel=
y outcome:


   It is probably unlikely that a single clearinghouse for
   managing whitelisting is possible; it will more likely be unique to
   the source content owners and/or domains which implement DNS
   whitelists.

[BA] While a single clearinghouse might be unlikely, I'm not sure that this=
 necessarily argues against the likelihood of multiple clearinghouses.  It =
might be helpful to provide a little more detail on the motivation behind t=
he views on the likelihood of clearinghouses emerging (e.g. is this based o=
n discussions with content providers?).  For example, if the concept of IPv=
6 whitelisting becomes more widespread among smaller content providers, it =
would seem that the need for clearinghouses might emerge.

[JL] Added a note on this.


Section 7.3.3

It seems to me that there might be some operational implications that might=
 arise from some potential whitelisting mechanisms such as differentiating =
DNS queries sent over IPv6 versus IPv4.

[JL] Good feedback =96 I'll incorporate that into the I-D.


Section 7.6


   At the same time, as noted in Section 3, some highly-trafficked
   domains may find the prospect of transitioning to IPv6 daunting
   without having some short-term ability to incrementally control the
   amount and source of IPv6 traffic to their domains.

[BA] The issue of traffic control is a distinct problem. This is partially =
discussed in Section 3 (from the point of view of the recursive resolver ow=
ner),
but here it is referring to the problem as experienced by the content owner=
.  Perhaps it would make sense to make the distinction between the
"impairment" and "traffic control" problems earlier? (maybe even in Section=
 1, referring to a subsequent discussion in Section 3).


Section 8.3.1

This section refers to fixes for the "impairment" problem, but as noted abo=
ve, there may also be other potential motivations for whitelisting.

[JL] Indeed. Based on your suggestion for section 3, I hope to have address=
ed this.

Section 9

   World IPv6 Day, sponsored by the Internet Society [World IPv6 Day],
   is scheduled to occur on June 8, 2011.  This will be an opportunity
   for domains to add AAAA resource records to the DNS without using DNS
   whitelisting.  As a result, this is likely an excellent opportunity
   for domains to evaluate the utility or necessity of DNS whitelisting,
   even in the short-term.  A major German news website, Heise Online,
   also ran a similar IPv6 experiment whereby they added AAAA resource
   records and observed and measured any errors [Heise Online
   Experiment], which is important reading for any domain contemplating
   either the use of DNS whitelisting or simply adding IPv6 addressing
   to their site.

[BA] You might consider moving this paragraph into a separate "measurement"=
 section (e.g. Section 1.1).

[JL] Thanks for all the feedback!




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
From: The IESG >
To: IETF-Announce >
Reply-to: iesg-secretary@ietf.org
Subject: Last Call:  (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC
X-RSN: 1/0/934/8529/9220

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv6 AAAA DNS Whitelisting Implications'
 as an
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-04-29. Exceptiona=
lly, comments may be
sent to iesg@ietf.org instead. In either case, please=
 retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impli=
cations/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impli=
cations/



No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

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

--_000_CA07C26B28868jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <96C0E23E1C58B341B4DB68B1BEBF7C14@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable











Hi Bernard =96 I've finally found the time to close out the last bits =
of feedback in this version of the draft. Your comments will be incorporate=
d shortly into a =9604 version of the document. Please see specific replies=
 inline below.











Thanks!


Jason















On 4/18/11 2:08 PM, "Bernard Aboba" <bernard_aboba@hotmail.com> wrote:













Overall, I think this is a useful document.  =




My suggestions below mostly relate to potential organizational improvements=
, as well as as a bit more detail in some areas.



Section 2



This section talks about how white-listing works, but does not talk about p=
otential mechanisms by which the whitelist is determined.  For example=
, in addition to techniques for manually maintaining the whitelist, there h=
ave been some suggestions that would
 involve automatic determinations (e.g. only answering with AAAA RRs if the=
 query comes in over IPv6).   It might be useful to cover some of=
 the proposals, since they might have different implications. 













[JL] I added a bit of text in the ad hoc DNS whitelisting section noti=
ng that there are two approaches. I did not include the part about only res=
ponding with a AAAA RR if the query comes in via IPv6, as I've not heard mu=
ch about this in practice and discussion
 from implementers seems to indicate that even if they recursive server sen=
t the query over IPv6 they still may have end hosts that are broken.












Section 2.1



Is the term "IP address" here intended to include both IPv4 and I=
Pv6 addresses? 












[JL] Yes, and I updated the text to clarify that.












Section 3




   At least one highly-trafficked domain has noted that they have
 =
  received requests to not send DNS responses with AAAA resource
   reco=
rds to particular resolvers.  In this case, the operators of
   those re=
cursive resolvers have expressed a concern that their IPv6
   network in=
frastructure is not yet ready to handle the large traffic
   volume whic=
h may be associated with the hosts in their network
   connecting to the=
 websites of these domains.  This concern is clearly
   a temporary cons=
ideration relating to the deployment of IPv6 network
   infrastructure o=
n the part of networks with end user hosts, rather
   than a long-term c=
oncern.  These end user networks may also have
   other tools at their d=
isposal in order to address this concern,
   including applying rules to=
 network equipment such as routers and
   firewalls (this will necessari=
ly vary by the type of network, as well
   as the technologies used and =
the design of a given network), as well
   as configuration of their rec=
ursive resolvers (though modifying or
   suppressing AAAA resource recor=
ds in a DNSSEC-signed domain on a
   Security-Aware Resolver will be pro=
blematic Section 10.1).



[BA]  This paragraph seems to be distinguishing "blacklisting&quo=
t; from "whitelisting" as well as describing some of the implicat=
ions of attempting to suppress AAAA RRs in the recursive resolver.  It=
 might be worthwhile to introduce the distinction between "blacklistin=
g"
 and "whitelisting" earlier on. 











Such a section might also include the following pa=
ragraph from Section 7.3.7:












[JL] Good idea =96 I added a brief section contrasting whitelisting an=
d blacklisting, including some of the text you suggest. 









   It is unclear when and if it would be appropriate to change from   whitelisting to blacklisting, and whether or how this could feasibly   be coordinated across the Internet, which may be proposed or
   impl=
emented on an ad hoc basis when a majority of networks (or
   allocated =
IPv6 address blocks) have been whitelisted.  Finally, some
   parties im=
plementing DNS whitelisting consider this to be a temporary
   measure. =
 As such, it is not clear how these parties will judge the
   network co=
nditions to have changed sufficiently to justify disabling
   DNS whitel=
isting and/or what the process and timing will be in order
   to discont=
inue this practice.



Section 4




   While in Section 1 the level of IPv6-related impairment has been   estimated to be as high as 0.078% of Internet users, which is a
   p=
rimary motivation cited for the practice of DNS whitelisting, it is
   n=
ot clear if the level of IPv4-related impairment is more or less
   that=
 this percentage (which in any case is likely to have declined
   since =
its original citation).  Indeed, as at least one document
   reviewer ha=
s pointed out, it may simply be that websites are only
   measuring IPv6=
 impairments and not IPv4 impairments, whether because
   IPv6 is new or=
 whether those websites are simply unable to or are
   otherwise not in =
a position to be able to measure IPv4 impairment
   (since this could re=
sult in no Internet access whatsoever).  As a
   result, it is worth con=
sidering that IPv4-related impairment could
   exceed that of IPv6-relat=
ed impairment and that such IPv4-related
   impairment may have simply b=
een accepted as "background noise" on the
   Internet for a va=
riety of reasons.  Of course, this comparison of the
   level of worldwi=
de IPv6 impairments to IPv4 impairments is
   speculation, as the author=
 is not aware of any good measurement of
   IPv4-related impairments whi=
ch are comparable in nature to the IPv6-
   related impairment measureme=
nts which have recently been conducted
   around the world.

[BA] =
It seems to me that discussion of measurement issues should probably come e=
arlier in the document, possibly in its own section.  
My suggestion is =
to move this paragraph as well other paragraphs referring to measurement in=
to its own section (Section 1.1?). 
The following paragraph from Section=
 3.2 might be a candidate:









[JL] Good suggestion - I have done so. I moved the impairment percenta=
ge citation to section 3 and have greatly re-worked section 3 to address th=
is (and add a new motivation I've heard from one implementer).














   Finally, some domains, have run IPv6 experiments whereby they added=

   AAAA resource records and observed and measured errors [Heise Online=

   Experiment], which should be important reading for any domain
   =
contemplating either the use of DNS whitelisting or simply adding
   IPv=
6 addressing to their site.


Section 6



This section talks about Adhoc versus universal deployment scenarios. =
 It strikes me that the underlying distinction is not so much the universal=
ity of whitelisting deployment as much as whether the whitelists are shared=
 or independent. The document seems to
 argue that independence is the most likely outcome:




   It is probably unlikely that a single clearinghouse for
   manag=
ing whitelisting is possible; it will more likely be unique to
   the so=
urce content owners and/or domains which implement DNS
   whitelists.


[BA] While a single clearinghouse might be unlikely, I'm not sure that this=
 necessarily argues against the likelihood of multiple clearinghouses. =
; It might be helpful to provide a little more detail on the motivation beh=
ind the views on the likelihood of clearinghouses
 emerging (e.g. is this based on discussions with content providers?). =
; For example, if the concept of IPv6 whitelisting becomes more widespread =
among smaller content providers, it would seem that the need for clearingho=
uses might emerge.












[JL] Added a note on this.

















Section 7.3.3



It seems to me that there might be some operational implications that might=
 arise from some potential whitelisting mechanisms such as differentiating =
DNS queries sent over IPv6 versus IPv4. 













[JL] Good feedback =96 I'll incorporate that into the I-D.

















Section 7.6




   At the same time, as noted in Section 3, some highly-trafficked
=
   domains may find the prospect of transitioning to IPv6 daunting
   wi=
thout having some short-term ability to incrementally control the
   amo=
unt and source of IPv6 traffic to their domains.

[BA] The issue of t=
raffic control is a distinct problem. This is partially discussed in Sectio=
n 3 (from the point of view of the recursive resolver owner),
but here i=
t is referring to the problem as experienced by the content owner.  Perhaps=
 it would make sense to make the distinction between the 
"impairme=
nt" and "traffic control" problems earlier? (maybe even in S=
ection 1, referring to a subsequent discussion in Section 3). 


Section 8.3.1



This section refers to fixes for the "impairment" problem, but as=
 noted above, there may also be other potential motivations for whitelistin=
g.













[JL] Indeed. Based on your suggestion for section 3, I hope to have ad=
dressed this. 












Section 9


   World IPv6 Day, sponsored by the Internet Society [World IPv6 Day],=

   is scheduled to occur on June 8, 2011.  This will be an opportunity<=
br>   for domains to add AAAA resource records to the DNS without using DNS=

   whitelisting.  As a result, this is likely an excellent opportunity<=
br>   for domains to evaluate the utility or necessity of DNS whitelisting,=

   even in the short-term.  A major German news website, Heise Online,<=
br>   also ran a similar IPv6 experiment whereby they added AAAA resource   records and observed and measured any errors [Heise Online
   Exper=
iment], which is important reading for any domain contemplating
   eithe=
r the use of DNS whitelisting or simply adding IPv6 addressing
   to the=
ir site.

[BA] You might consider moving this paragraph into a separa=
te "measurement" section (e.g. Section 1.1). 














[JL] Thanks for all the feedback!

















=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From: The IESG <iesg-secretar=
y@ietf.org> 

To: IETF-Announce <ietf-announ=
ce@ietf.org> 

Reply-to: iesg-secretary@ietf.or=
g 

Subject: Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-=
03.txt> (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC&n=
bsp;

X-RSN: 1/0/934/8529/9220 

 

The IESG has received a request from the IPv6 Operations WG (v6ops) to =
;

consider the following document: 

- 'IPv6 AAAA DNS Whitelisting Implications' 

<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt> as an&nbs=
p;

Informational RFC 

 

The IESG plans to make a decision in the next few weeks, and solicits =


final comments on this action. Please send substantive comments to the =
;

ietf@ietf.org mailing lists by 2011-04=
-29. Exceptionally, comments may be 

sent to iesg@ietf.org instead. In eith=
er case, please retain the 

beginning of the Subject line to allow automated sorting. 

 

The file can be obtained via 

http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aa=
aa-whitelisting-implications/ 

 

IESG discussion can be tracked via 

http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aa=
aa-whitelisting-implications/ 

 

 

 

No IPR declarations have been submitted directly on this I-D. 

_______________________________________________ 

IETF-Announce mailing list 

IETF-Announce@ietf.org <=
br>
https://www=
.ietf.org/mailman/listinfo/ietf-announce 

  





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






--_000_CA07C26B28868jasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Sun May 29 08:00: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 BBB28E0724; Sun, 29 May 2011 08:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.462
X-Spam-Level: 
X-Spam-Status: No, score=-108.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 hAGP-JN-gyyr; Sun, 29 May 2011 08:00:02 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id BDD86E0662; Sun, 29 May 2011 08:00:01 -0700 (PDT)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.127841958; Sun, 29 May 2011 10:59:59 -0400
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Sun, 29 May 2011 10:59:59 -0400
From: "Livingood, Jason" 
To: Pekka Savola , "ietf@ietf.org" 
Thread-Topic: Last Call:  (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC
Thread-Index: AQHMA/eJ2U8mTDel70eZQwUjZTUiCZSkGjUA
Date: Sun, 29 May 2011 14:59:58 +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.10.0.110310
x-originating-ip: [24.40.55.72]
Content-Type: multipart/alternative; boundary="_000_CA07D4B4288A8jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , "draft-ietf-v6ops-v6-aaaa-whitelisting-implications@tools.ietf.org" 
Subject: Re: [v6ops] Last Call:  (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 May 2011 15:00:03 -0000

--_000_CA07D4B4288A8jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thank you for your review, and a =9604 revision is coming soon. Other comme=
nts inline below.

Thanks!
Jason


On 4/26/11 5:51 AM, "Pekka Savola" > wrote:

On Fri, 15 Apr 2011, The IESG wrote:
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv6 AAAA DNS Whitelisting Implications'
   as an
Informational RFC

This is an ops-dir review of
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.

The document is readable and could be published as-is.  I share some of the
concerns already expressed in the document, but I think the doc strikes a
reasonable balance between the concerns and practical points.

One bigger comment:
-------------------

Section 6 on deployment scenarios seems too black and white: either it is
done ad-hoc or (completely) universally.  The latter is unfeasible.

[JL] I received similar feedback from others and have tried to address this=
 better in the upcoming =9604 version.

The document should cover a middle ground which is already discussed in
[NW-Article-DNS-WL], i.e., one or more whitelisting information providers
would be used by multiple content networks.  This has many benefits compare=
d
to completely ad-hoc model, and is feasible compared to universal model.

[JL] Added a note concerning this in the I-D.


The "universal deployment model" proposition has created ripples throughout
the document (one such place is S 7.3.7), and I think the document might
have been clearer if that was taken out completely -- or at least, issues
related to each deployment model would be more clearly separated.

[JL] Good question, which is such a meta-concern that I'm going to list it =
in the open items tracker at the end of the document for consideration afte=
r the =9604 update (since so many other changes are taking place in that ve=
rsion).

8.3.1. Solving Current End User IPv6 Impairments
...
    One challenge with this option is the potential difficulty of
    motivating members of the Internet community to work collectively
    towards this goal, sharing the labor, time, and costs related to such
    an effort.  Of course, since just such a community effort is now
    underway for IPv6, it is possible that this would call for only a
    moderate amount of additional work.

... I would observe that ad-hoc whitelisting is already requiring a lot of
work from each of whitelisting providers.  Would this require more than
that?  If the alternative is to do nothing (no whitelisting, no user
impairment notification) that is clear the winner from the selfish POV. But
if the choice is between whitelisting and alerting, I don't see much
difference between the two.  Both could benefit from joint activities, but
both can also be operated in an ad-hoc fashion.


editorial:
----------

7.3.7. Additional Implications If Deployed On An Ad Hoc Basis

    Additional implications, should this be deployed on an ad hoc basis,
    could include scalability problems relating to operational processes,
    monitoring, and ACL updates.

... this could be read to imply that S 7.3.1-6 would be applicable to
universal deployment.  This is not what is meant.  Maybe clarify somewhat
like as follows:

    Previous subsections described implications that apply to both ad-hoc a=
nd
    universal deployment models.  Some additional implications are specific
    to ad-hoc deployment models, namely ...

[JL] Great suggestion! I have made this change.


S 7.5

    governmental, and/or cultural conflicts, given the new control point
    which has be established with DNS whitelisting.  For example, in one

s/be/been/

[JL] Corrected


    [IPv6 Brokenness]
               Anderson, T., "Measuring and Combating IPv6 Brokenness",
               Reseaux IP Europeens (RIPE) 61st Meeting, November 2011,
               .


s/2011/2010/

[JL] Corrected

Thanks again,
Jason




--_000_CA07D4B4288A8jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <1683F4A21A115746A01FE832CED5E63D@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable









Thank you for your review, and a =9604 revision is coming soon. Other =
comments inline below.







Thanks!


Jason














On 4/26/11 5:51 AM, "Pekka Savola" <pekkas@netcore.fi> wrote:









On Fri, 15 Apr 2011, The IESG wrote:




The IESG has received a request from the IPv6 Operations WG (v6ops) to=



consider the following document:


- 'IPv6 AAAA DNS Whitelisting Implications'


  <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.=
txt> as an


Informational RFC









This is an ops-dir review of


draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.







The document is readable and could be published as-is.  I sh=
are some of the


concerns already expressed in the document, but I think the doc strike=
s a


reasonable balance between the concerns and practical points.







One bigger comment:


-------------------







Section 6 on deployment scenarios seems too black and white: either it=
 is


done ad-hoc or (completely) universally.  The latter is unfe=
asible.









[JL] I received similar feedback from others and have tried to address=
 this better in the upcoming =9604 version.









The document should cover a middle ground which is already discussed i=
n


[NW-Article-DNS-WL], i.e., one or more whitelisting information provid=
ers


would be used by multiple content networks.  This has many b=
enefits compared


to completely ad-hoc model, and is feasible compared to universal mode=
l.









[JL] Added a note concerning this in the I-D.














The "universal deployment model" proposition has created rip=
ples throughout


the document (one such place is S 7.3.7), and I think the document mig=
ht


have been clearer if that was taken out completely -- or at least, iss=
ues


related to each deployment model would be more clearly separated.








[JL] Good question, which is such a meta-concern that I'm going to lis=
t it in the open items tracker at the end of the document for consideration=
 after the =9604 update (since so many other changes are taking place in th=
at version).









8.3.1. Solving Current End User IPv6 Impairments


...


    One challenge with this option is the potentia=
l difficulty of


    motivating members of the Internet community t=
o work collectively


    towards this goal, sharing the labor, time, an=
d costs related to such


    an effort.  Of course, since just su=
ch a community effort is now


    underway for IPv6, it is possible that this wo=
uld call for only a


    moderate amount of additional work.







... I would observe that ad-hoc whitelisting is already requiring a lo=
t of


work from each of whitelisting providers.  Would this requir=
e more than


that?  If the alternative is to do nothing (no whitelisting,=
 no user


impairment notification) that is clear the winner from the selfish POV=
. But


if the choice is between whitelisting and alerting, I don't see much

difference between the two.  Both could benefit from joint a=
ctivities, but


both can also be operated in an ad-hoc fashion.












editorial:


----------







7.3.7. Additional Implications If Deployed On An Ad Hoc Basis







    Additional implications, should this be deploy=
ed on an ad hoc basis,


    could include scalability problems relating to=
 operational processes,


    monitoring, and ACL updates.







... this could be read to imply that S 7.3.1-6 would be applicable to<=
/div>

universal deployment.  This is not what is meant.  =
;Maybe clarify somewhat


like as follows:







    Previous subsections described implications th=
at apply to both ad-hoc and


    universal deployment models.  Some a=
dditional implications are specific


    to ad-hoc deployment models, namely ...









[JL] Great suggestion! I have made this change.














S 7.5







    governmental, and/or cultural conflicts, given=
 the new control point


    which has be established with DNS whitelisting=
.  For example, in one







s/be/been/









[JL] Corrected














    [IPv6 Brokenness]


           &nbs=
p;   Anderson, T., "Measuring and Combating IPv6 Brokenness&=
quot;,


           &nbs=
p;   Reseaux IP Europeens (RIPE) 61st Meeting, November 2011,

           &nbs=
p;   <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.












s/2011/2010/









[JL] Corrected 







Thanks again,


Jason























--_000_CA07D4B4288A8jasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Sun May 29 08:51: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 589BBE06F5; Sun, 29 May 2011 08:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.41
X-Spam-Level: 
X-Spam-Status: No, score=-108.41 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 KlGiccO8y4kk; Sun, 29 May 2011 08:51:34 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 40FE6E0662; Sun, 29 May 2011 08:51:33 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.127855909; Sun, 29 May 2011 11:51:29 -0400
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; Sun, 29 May 2011 11:51:29 -0400
From: "Livingood, Jason" 
To: Tony Finch 
Thread-Topic: [v6ops] Review of draft-v6ops-v6-aaaa-whitelisting-implications-03
Thread-Index: AQHMFHFvSahZTyvge0GXycpBfGiyA5SkB6aA
Date: Sun, 29 May 2011 15:51:28 +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.10.0.110310
x-originating-ip: [24.40.55.72]
Content-Type: multipart/alternative; boundary="_000_CA07E369288F6jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , IETF Discussion 
Subject: Re: [v6ops] Review of draft-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 May 2011 15:51:35 -0000

--_000_CA07E369288F6jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


In the case at hand, the list does not contain AAAA RRs as the abstract
suggests, it contains IPv6-capable resolvers. The whitelist isn't
published in the DNS, so it doesn't match the existing use of the phrase
"DNS whitelist".

[JL] Oops! Thanks for noticing this =96 I have corrected it in the Abstract=
 and Introduction (in my upcoming =9604 update).

Thanks for catching this,
Jason

--_000_CA07E369288F6jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <727E924DA7DC4C468E7FD3E98425E83B@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable


















In the case at hand, the list does not contain AAAA RRs as the abstrac=
t


suggests, it contains IPv6-capable resolvers. The whitelist isn't

published in the DNS, so it doesn't match the existing use of the phra=
se


"DNS whitelist".









[JL] Oops! Thanks for noticing this =96 I have corrected it in the Abs=
tract and Introduction (in my upcoming =9604 update).







Thanks for catching this,


Jason




--_000_CA07E369288F6jasonlivingoodcablecomcastcom_--

From dhc@dcrocker.net  Sun May 29 09:50: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 34070E06F6; Sun, 29 May 2011 09:50:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.588
X-Spam-Level: 
X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011,  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 b36Fc50SZf+v; Sun, 29 May 2011 09:50:29 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2A8E06C0; Sun, 29 May 2011 09:50:29 -0700 (PDT)
Received: from [192.168.1.3] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4TGoJ8v001652 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 29 May 2011 09:50:24 -0700
Message-ID: <4DE27946.7000704@dcrocker.net>
Date: Sun, 29 May 2011 09:50:14 -0700
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Jason Livingood 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 29 May 2011 09:50:25 -0700 (PDT)
Cc: "v6ops@ietf.org" , IETF Discussion 
Subject: [v6ops] Fwd: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 May 2011 16:50:33 -0000

On 5/29/2011 7:46 AM, Livingood, Jason wrote:
 > Hi Bernard – I've finally found the time to close out the last bits of
 > feedback > in this version of the draft.


Jason,

Perhaps my filters misfiled your followup to the "formal" review I was asked to 
do, or perhaps my earlier, informal, and vary narrow review muddied the waters, 
but I am not finding your response to the Apps Area review.

For convenience, here it is again.

d/

-------- Original Message --------
Subject: Review of:  draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03	
          *(formal for apps area)*
Date: Mon, 09 May 2011 10:18:51 -0700
From: Dave CROCKER 
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
To: IETF Discussion 
CC: v6ops@ietf.org , Apps Review 

(This is an "official" and significantly extended version of an informal and
narrow review I posted earlier.  /d)



Howdy.

I have been selected as the Applications Area Review Team reviewer for this
draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you may
receive. Please wait for direction from your document shepherd or AD before
posting a new version of the draft.



Review (v2):

Title:  IPv6 AAAA DNS Whitelisting Implications
I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

By:     D. Crocker 
Date:   <>



Summary
=======

This draft covers a a dual-stack problem in which a target host's DNS entry
contains records for IPv4 and IPv6, but returning IPv6 information to a DNS
client can cause problems. The paper discusses for resolving this through use of
a a DNS-based mechanism that manually lists response preferences to select which
DNS records to return.  The paper describes the mechanism and explores various
effects and possibilities of its use, including the difference between using it
selectively among a smaller number of sites, versus universally.

The draft is a serious effort to explore the use of such a mechanism and it
touches many different issues.  It is generally well-organized and clearly
written, although it very much needs the aid of a professional technical editor.
The writing often assumes too much knowledge by the reader.

The paper's exploration of universal adoption seems to vary between considering
that goal practical versus considering it only as a matter of completeness for
discussing the full range of possibilities.  That is, it is not clear whether
the paper views this alternative as practically possible and even preferred,
versus only a matter for academic thoroughness. The paper needs to take a basic
position about feasibility, explain it in terms of comparable adoption efforts
at Internet-scale, and then make its treatment of universal adoption a bit more
consistent.

When introducing terms, mechanisms, configurations and scenarios, the paper
needs to be more careful to describe them adequately for a reader new to the
topic.  This is not a matter of having a tutorial about the DNS, but rather a
tutorial for this type of mechanism and when and how it can be used.

As a specific example, the document cites "domain-by-domain" use, but I am not
clear how that would work, in terms of configuration and cross-net information
exchange.  One question is how the server knows the 'domain' of the client?

The document should careful to distinguish what is existing practice, versus
what is being explored as added possibilities.  The difference in concreteness
and certitude between the two is substantial.

The document's use of the term whitelisting appears to continue an existing,
recent use, for this type of mechanism.  Unfortunately it directly conflicts
with long-standing use of the term by the anti-abuse community for whitelisting
in the DNS. Its use here also seems to be a mismatch with the word's dictionary
semantics, which is most naturally used to distinguish yes/no choices, rather
than either/or choices.  So there is no intuitive sense of "goodness" (whitelist
= yes) or "badness" (blacklist) for this use. The word "preferences" seems more
in line with the meaning of the mechanism.



Detailed Comments
=================


> Abstract
>
>    The objective of this document is to describe what the whitelisting
>    of DNS AAAA resource records is, hereafter referred to as DNS

RRs are whitelisted?  Isn't it the addresses and not the records that are
whitelisted?

Does this mean putting whitelisting records into the DNS or does it mean
something else?

Comcast's own considerable expertise notwithstanding, has this doc been vetted
with a range of organizations that actually DO whitelisting?  Has it been
circulated through MAAWG and APWG?  Any comments from Spamhaus?  The
Acknowledgements list does not seem to indicate a range of whitelist ops folks
whose names I know.  (But then, I only know a few...)


>    whitelisting, as well as the implications of this emerging practice
>    and what alternatives may exist.  The audience for this document is
>    the Internet community generally, including the IETF and IPv6
>    implementers.

I suspect that product marketers won't have much interest in this.  I suspect
that the target for this is anti-abuse technical and operations staff. In any
event, the targetting statement should be more precise.


> 1.  Introduction
>
>    This document describes the emerging practice of whitelisting of DNS

One natural, semantic problem with the term 'whitelist' is that it does not
really match the function being performed.  The white/black distinction implies
goodness -- or as Wikipedia says, "priviledge".  Instead, the use here is for
preference or priority.  What would a "blacklist" be, here?  Also note it is not
obvious what it means to be whitelisted, here?  Does it mean to choose the AAAA
records or the A records?

This is more like a 'Preference' or 'Configuration' list.

At the least, the name for this should be IPv6 Resolver Whitelisting.  It makes
clear /what/ is being "whitelisted".


>    AAAA resource records (RRs), which contain IPv6 addresses, hereafter
>    referred to as DNS whitelisting.  The document explores the

This provides a name, but not a function.  That is, it does not say what this
mechanisms actually /does/ or is /for/.


>    implications of this emerging practice are and what alternatives may
>    exist.
>
>    The practice of DNS whitelisting appears to have first been used by
>    major web content sites (sometimes described herein as "highly-

It's use for email anti-abuse dates back farther.

    

    




Specifically within the context of the DNS, the term whitelisting is therefore
made ambiguous.

A google query for "whitelist dns" also demonstrates the history and current
ambiguity.


>    trafficked domains" or "major domains").  These web site operators,
>    or domain operators, observed that when they added AAAA resource
>    records to their authoritative DNS servers in order to support IPv6
>    access to their content that a small fraction of end users had slow
>    or otherwise impaired access to a given web site with both AAAA and A
>    resource records.  The fraction of users with such impaired access
>    has been estimated to be roughly 0.078% of total Internet users
>    [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
>    Brokenness].  Thus, in an example Internet Service Provider (ISP)
>    network of 10 million users, approximately 7,800 of those users may
>    experience such impaired access.

At a minimum, these sorts of statistics need to be normalized across IPv6
users/traffic, given how small a percentage that is, in total users and total
traffic.  If that's what is meant it should be stated.  If it isn't, the
statistic should be recalculated and explained a bit more precisely.


>    As a result of this impairment affecting end users of a given domain,
>    a few major domains have either implemented DNS whitelisting or are
>    considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].
>    When implemented, DNS whitelisting in practice means that a domain's
>    authoritative DNS will return a AAAA resource record to DNS recursive
>    resolvers [RFC1035] on the whitelist, while returning no AAAA
>    resource records to DNS resolvers which are not on the whitelist.  It

This explanation of the function should be offered sooner and should be
summarized in the Abstract.


>    is important to note that these major domains are motivated by a
>    desire to maintain a high-quality user experience for all of their

Rather than being important to note, this sentence sounds oddly like marketing
hype, in a technical specification.  It is gratuitous because specified features
are never added to /lower/ the quality of the user experience, for example.

In addition, the mechanism also affects client activity that has no user
directly involved.


>    users.  By engaging in DNS whitelisting, they are attempting to
>    shield users with impaired access from the symptoms of those
>    impairments.

The /technical/ statement that should be here is that they are attempting to
provide a work-around for problematic behaviors in dual-stack IPv4/IPv6
environments.

The paper should make more clear exactly where the problem lies and when. If it
can occur for a number of reasons, explaining each of those scenarios would be
useful.


>    Critics of the practice of DNS whitelisting have articulated several
>    concerns.  Among these are that:
>
>    o  DNS whitelisting is a very different behavior from the current
>       practice concerning the publishing of IPv4 address resource
>       records,
>
>    o  that it may create a two-tiered Internet,
>
>    o  that policies concerning whitelisting and de-whitelisting are
>       opaque,
>
>
>
>
>
> Livingood                Expires August 26, 2011                [Page 5]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    o  that DNS whitelisting reduces interest in the deployment of IPv6,
>
>    o  that new operational and management burdens are created,

well, yeah... in fact it should be noted that the burdens are particularly
onerous at scale.


>    o  and that the costs and negative implications of DNS whitelisting
>       outweigh the perceived benefits, compared to fixing underlying
>       impairments.

and it doesn't scale.

and it violates an extremely basic premise of cross-Internet interoperability by
requiring prior arrangement.


>    This document explores the reasons and motivations for DNS
>    whitelisting.  It also explores the outlined concerns regarding this
>    practice.  Readers will hopefully better understand what DNS
>    whitelisting is, why some parties are implementing it, and what
>    criticisms of the practice exist.
>
>
> 2.  How DNS Whitelisting Works

How IPv6 AAAA DNS Whitelisting Works.

(Anti-spam DNS Whitelisting works rather differently...)


>    DNS whitelisting is implemented in authoritative DNS servers.  These
>    servers implement IP address-based restrictions on AAAA query
>    responses.  So far, DNS whitelisting has been primarily implemented
>    by web server operators deploying IPv6-enabled services.  For a given

Really?  This is web-specific?  The same restrictions are not applied for other
applications?

So if the same client-side hosts attempt to contact the server for email or
xmpp, they won't get the same handling?


>    operator of a website, such as www.example.com, the operator
>    essentially applies an access control list (ACL) on the authoritative
>    DNS servers for the domain example.com.  The ACL is populated with

An ACL usually is a yes/no mechanism.  Here, however, the mechanism is for
asserting a preference for IPv6 over IPv4.

That does not seem to match the definition of ACL that I'm used to, unless the
semantic is defined as denying IPv4 access to the listed clients.

The term ACL is particularly odd to use if the mechanism pertains to responses
rather than queries.


>    the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive

Either address type can be listed?  So this really is a pure 'preferences'
mechanism?

Which settings count as whitelisting?  Do any count as blacklisting?



>    resolvers on the Internet, which have been authorized to receive AAAA
>    resource record responses.  These DNS recursive resolvers are
>    operated by third parties, such as ISPs, universities, governments,
>    businesses, and individual end users.  If a DNS recursive resolver IS
>    NOT matched in the ACL, then AAAA resource records will NOT be sent
>    in response to a query for a hostname in the example.com domain.

This configuration appears to ensure the maximum barrier to adoption for IPv6,
since it means that IPv6 will not work automatically.  It will only work for
hosts that are manually configured to receive responses with v6 records.

That's a rather major implication.  It's a default that is probably meant to
apply during the very early stages of adoption, when there are few users of the
newer mechanism.

It's probably worth discussing it in more detail, including discussing when to
change the default...


>    However, if a DNS recursive resolver IS matched in the ACL, then AAAA
>    resource records will be sent in response to a query for a given
>    hostname in the example.com domain.  While these are not network-
>    layer access controls they are nonetheless access controls that are a
>    factor for end users and other parties like network operators,
>    especially as networks and hosts transition from one network address
>    family to another (IPv4 to IPv6).


Also, all of this clarifies the function of this listing mechanism and suggests
a very different name, to be more precise and accurate in naming it:

     IPv6 DNS Response Preference List.


>    In practice, DNS whitelisting generally means that a very small
>    fraction of the DNS recursive resolvers on the Internet (those in the
>    whitelist ACL) will receive AAAA responses.  The large majority of
>    DNS resolvers on the Internet will therefore receive only A resource
>    records containing IPv4 addresses.  Thus, quite simply, the
>    authoritative server hands out different answers depending upon who
>    is asking; with IPv4 and IPv6 resource records for some on the
>    authorized whitelist, and only IPv4 resource records for everyone
>    else.  See Section 2.1 and Figure 1 for a description of how this
>
>
>
> Livingood                Expires August 26, 2011                [Page 6]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    works.
>
>    Finally, DNS whitelisting can be deployed in two primary ways:
>    universally on a global basis, or on an ad hoc basis.  Deployment on
>    a universal deployment basis means that DNS whitelisting is
>    implemented on all authoritative DNS servers, across the entire
>    Internet.  In contrast, deployment on an ad hoc basis means that only
>    some authoritative DNS servers, and perhaps even only a few,
>    implement DNS whitelisting.  These two potential deployment models
>    are described in Section 6.
>
> 2.1.  Description of the Operation of DNS Whitelisting
>
>    The system logic of DNS whitelisting is as follows:
>
>    1.  The authoritative DNS server for example.com receives DNS queries
>        for the A (IPv4) and AAAA (IPv6) address resource records for the
>        FQDN www.example.com, for which AAAA (IPv6) resource records
>        exist.

This means that the mechanism is /only/ triggered when /both/ address records
are queried?  A query for only one type of address record won't trigger the list
lookup?  I think that doesn't match other statements in the document.


>    2.  The authoritative DNS server examines the IP address of the DNS
>        recursive resolver sending the AAAA (IPv6) query.

"examines"?  Examines it for what?  What does this step mean?


>    3.  The authoritative DNS server checks this IP address against the
>        access control list (ACL) that is the DNS whitelist.
>
>    4.  If the DNS recursive resolver's IP address IS matched in the ACL,
>        then the response to that specific DNS recursive resolver can
>        contain AAAA (IPv6) address resource records.

Oh.  This is not about whether to send responses /over/ v6 vs. v4?  This is
whether to /include/ a particular type of RR in responses???

In that case an appropriate name for this mechanism is more like:

    DNS Response Content Preference List

And this seems even less like an ACL than it did before.  (I assume the
justification is that access is being prevented by virtue of not supplying the
address, but still...)


>    5.  If the DNS recursive resolver's IP address IS NOT matched in the
>        ACL, then the response to that specific DNS recursive resolver
>        cannot contain AAAA (IPv6) address resource records.  In this
>        case, the server should return a response with the response code
>        (RCODE) being set to 0 (No Error) with an empty answer section
>        for the AAAA record query.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Livingood                Expires August 26, 2011                [Page 7]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    ---------------------------------------------------------------------
>    A query is sent from a DNS recursive resolver that IS NOT on the DNS
>    whitelist:
>
>                Request                      Request
>            www.example.com                  www.example.com
>                  AAAA    +-------------+     AAAA    +-----------------+
>      ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
>      ||  ||       A      | **IS NOT**  |      A      | IN A exists     |
>    +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
>    +--------+     A      | example.com |      A      |                 |
>       Host    <--------- |  WHITELIST  |  <--------- |                 |
>     Computer   A Record  +-------------+  A Record   +-----------------+
>                Response   DNS Recursive   Response       example.com
>               (only IPv4)   Resolver     (only IPv4)    Authoritative
>                               #1                           Server
>    ---------------------------------------------------------------------
>    A query is sent from a DNS recursive resolver that IS on the DNS
>    whitelist:
>
>                Request                      Request
>            www.example.com                  www.example.com
>                 AAAA     +-------------+     AAAA    +-----------------+
>      ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
>      ||  ||       A      |   **IS**    |      A      | IN A exists     |
>    +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
>    +--------+   AAAA     | example.com |     AAAA    |                 |
>       Host    <--------- |  WHITELIST  |  <--------- |                 |
>     Computer      A      |             |      A      |                 |
>               <--------- |             |  <--------- |                 |
>               A and AAAA +-------------+ A and AAAA  +-----------------+
>                Record     DNS Recursive   Record        example.com
>               Responses     Resolver     Responses      Authoritative
>               (IPv4+IPv6)      #2        (IPv4+IPv6)       Server
>    ---------------------------------------------------------------------
>
>               Figure 1: DNS Whitelisting - Functional Diagram

This diagram is confusing to me.  I suspect that a protocol exchange sequence
format, in the style of:

      Host             Resolver 1            Authoritative

           ---------->
                                  --------->
                                 <---------
          <----------

will be considerably more helpful.


> 3.  What Problems Are Implementers Trying To Solve?

This is a very useful section and it is probably worth moving it higher, to
precede the 'how it works' section.


>    As noted in Section 1, domains which implement DNS whitelisting are
>    attempting to protect a few users of their domain, who have impaired
>    IPv6 access, from having a negative experience (poor performance).

By the way, what does 'impaired v6 access' mean?

I think there needs to be a simple, direct description of what occurs without
this mechanism.

For example, perhaps you mean that a host can send DNS queries using IPv6 but
cannot receive DNS responses over IPv6? Perhaps you mean that the host can send
IPv6 but cannot receive it.  (That's a different scale and scope of problem from
the first example I gave.)

This brief, summary problem statement should be included in the Abstract, to
make /much/ more clear what this mechanism is for.


>    While it is outside the scope of this document to explore the various
>    reasons why a particular user's system (host) may have impaired IPv6
>    access, for the users who experience this impairment it is a very
>    real performance impact.  It would affect access to all or most dual
>
>
>
> Livingood                Expires August 26, 2011                [Page 8]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    stack services to which the user attempts to connect.  This negative
>    end user experience can range from someone slower than usual (as
>    compared to native IPv4-based access), to extremely slow, to no
>    access to the domain whatsoever.

Rather than repeat that this is about end-users, it sounds more that this is
about whether a service works or does not work, whether a user is directly
present or not.


>    While one can debate whether DNS whitelisting is the optimal solution
>    to the end user experience problem, it is quite clear that DNS
>    whitelisting implementers are interested in maximizing the
>    performance of their services for end users as a primary motivation
>    for implementation.

You keep citing 'performance' but haven't described what sort of performance
degradation takes place. Is this really about relatively better or worse
performance -- and if so, how -- or is this about working or not working?

Also rather than saying what implementers are interested in, it's probably more
helpful to note that the practice is now significantly established and therefore
worth documenting, independent of its possible controversy.


>    At least one highly-trafficked domain has noted that they have
>    received requests to not send DNS responses with AAAA resource
>    records to particular resolvers.  In this case, the operators of

"At least one" seems a rather tiny statistic.  Perhaps the actual statistic is
significantly larger?


>    those recursive resolvers have expressed a concern that their IPv6

I suspect that it's not resolvers that are doing the expressing, since their
vocabulary is usually too limited...


>    network infrastructure is not yet ready to handle the large traffic
>    volume which may be associated with the hosts in their network
>    connecting to the websites of these domains.  This concern is clearly

So even though the site allows v6 DNS queries to go out from a host, it can't
really support having the host use v6?

Wow. I do understand why service providers often have to work around silliness
at the client side, but this problem at the client side seems particularly
egregious.


>    a temporary consideration relating to the deployment of IPv6 network
>    infrastructure on the part of networks with end user hosts, rather
>    than a long-term concern.  These end user networks may also have

Again this goal of short-term usage is worth noting earlier, including in the
Abstract.


>    other tools at their disposal in order to address this concern,
>    including applying rules to network equipment such as routers and
>    firewalls (this will necessarily vary by the type of network, as well
>    as the technologies used and the design of a given network), as well
>    as configuration of their recursive resolvers (though modifying or
>    suppressing AAAA resource records in a DNSSEC-signed domain on a
>    Security-Aware Resolver will be problematic Section 10.1).
>
>    Some implementers with highly-trafficked domains have explained that
>    DNS whitelisting is a necessary, though temporary, risk reduction
>    tactic intended to ease their transition to IPv6 and minimize any
>    perceived risk in such a transition.  As a result, they perceive this
>    as a tactic to enable them to incrementally enable IPv6 connectivity
>    to their domains during the early phases of their transition to IPv6.
>
>    Finally, some domains, have run IPv6 experiments whereby they added
>    AAAA resource records and observed and measured errors [Heise Online
>    Experiment], which should be important reading for any domain
>    contemplating either the use of DNS whitelisting or simply adding
>    IPv6 addressing to their site.
>
>
> 4.  Concerns Regarding DNS Whitelisting
>
>    There are a number of potential implications relating to DNS
>    whitelisting, which have been raised as concerns by some parts of the
>    Internet community.  Many of those potential implications are further

I think the implications are not conditional; they exist rather than being
potential.  The 'potential' is that what is implicated will come to pass.



>
> Livingood                Expires August 26, 2011                [Page 9]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    enumerated here and in Section 7.

Pro forma question:  Why are implications discussed in multiple places?


>    Some parties in the Internet community, including ISPs, are concerned

This style of text personalizes the issues unnecessarily (IMO).  It does not
really matter who holds the concerns, or else they'd be described more precisely.

I suggest merely noting that there are concerns and then listing and discussing
the concerns, rather than adding text to attribute the concerns to others, even
if the conclusion of your text is that a particular concern is not valid.


>    that the practice of DNS whitelisting for IPv6 address resource
>    records represents a departure from the generally accepted practices
>    regarding IPv4 address resource records in the DNS on the Internet
>    [Whitelisting Concerns].  These parties explain their belief that for

"These parties explain their belief" is an example of personalization that is
not needed.  This isn't about the believers.  It is about possible problems.


>    A resource records, containing IPv4 addresses, once an authoritative
>    server operator adds the A record to the DNS, then any DNS recursive
>    resolver on the Internet can receive that A record in response to a

This does not appear to be a grammatically valid sentence.  My guess is that
deleting "A resource... addresses" fixes this.

And by the way, the document's reference to "recursive" resolvers is mostly
likely incorrect.  The problem is not restricted only to that very specific type
of resolver, is it?

If in fact it /is/ specific to them -- and your following text describes an
indirect effects scenario where it might be -- I suggest calling out the
configuration at the beginning, along the lines of:

      One way the problem with returning AAAA records can be experienced is when
recursive resolvers are used.  Although that resolver might support IPv6, its
client hosts might not.  So, returning an AAAA record will mean that these
limited hosts will be given an unusable address.

And this type of description belongs in the text describing the motivating
problem(s), rather than buried in the 'concerns' discussion.

(The text, here, pertains to A records, but the problem I've described uses the
same configuration but for AAAA records with mixed v6 support.)


>    query.  By extension, this means that any of the hosts connected to
>    any of these DNS recursive resolvers can receive the IPv4 address
>    resource records for a given FQDN.  This enables new server hosts
>    which are connected to the Internet, and for which a fully qualified
>    domain name (FQDN) such as www.example.com has been added to the DNS
>    with an IPv4 address record, to be almost immediately reachable by
>    any host on the Internet.  In this case, these new servers hosts
>    become more and more widely accessible as new networks and new end
>    user hosts connect to the Internet over time, capitalizing on and
>    increasing so-called "network effects" (also called network
>    externalities).  It also means that the new server hosts do not need
>    to know about these new networks and new end user hosts in order to
>    make their content and applications available to them, in essence
>    that each end in this end-to-end model is responsible for connecting
>    to the Internet and once they have done so they can connect to each
>    other without additional impediments or middle networks or
>    intervening networks or servers knowing about these end points and
>    whether one is allowed to contact the other.

Hmmm.  This rather lengthy bit of prose appears merely to be explaining the
basic and long-standing DNS value proposition???


>    In contrast, the concern is that DNS whitelisting may fundamentally
>    change this model.  In the altered DNS whitelisting end-to-end model,
>    one end (where the end user is located) cannot readily connect to the
>    other end (where the content is located), without parts of the middle
>    (recursive resolvers) used by one end (the client, or end user hosts)
>    being known to an intermediary (authoritative nameservers) and
>    approved for access to the resource at the end.  As new networks
>    connect to the Internet over time, those networks need to contact any
>    and all domains which have implemented DNS whitelisting in order to
>    apply to be added to their DNS whitelist, in the hopes of making the
>    content and applications residing on named server hosts in those
>    domains accessible by the end user hosts on that new network.
>    Furthermore, this same need to contact all domains implementing DNS
>    whitelisting also applies to all pre-existing (but not whitelisted)
>    networks connected to the Internet.
>
>    In the current IPv4 Internet when a new server host is added to the
>    Internet it is generally widely available to all end user hosts and
>    networks, when DNS whitelisting of IPv6 resource records is used,

If it is available to the hosts, it is available to the network.

networks, when -> networks. When


>
>
>
> Livingood                Expires August 26, 2011               [Page 10]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    these new server hosts are not accessible to any end user hosts or
>    networks until such time as the operator of the authoritative DNS

They are still accessible.  The IP-level mechanisms still work.

They are not reachable when using the domain name.


>    servers for those new server hosts expressly authorizes access to
>    those new server hosts by adding DNS recursive resolvers around the
>    Internet to the ACL.  This has the potential to be a significant

This is a good example of the reason the term ACL is inappropriate:  It implies
a security protection that does not actually exist.  The hosts are still accessible.


>    change in reachability of content and applications by end users and
>    networks as these end user hosts and networks transition to IPv6,
>    resulting in more (but different) breakage.  A concern expressed is
>    that if much of the content that end users are most interested in is
>    not accessible as a result, then end users and/or networks may resist
>    adoption of IPv6 or actively seek alternatives to it, such as using
>    multi-layer network address translation (NAT) techniques like NAT444
>    [I-D.shirasaki-nat444] on a long-term basis.  There is also concern
>    that this practice also could disrupt the continued increase in
>    Internet adoption by end users if they cannot simply access new
>    content and applications but must instead contact the operator of
>    their DNS recursive resolver, such as their ISP or another third
>    party, to have their DNS recursive resolver authorized for access to
>    the content or applications that interests them.  Meanwhile, these
>    parties say, over 99.9% of the other end users that are also using
>    that same network or DNS recursive resolver are unable to access the
>    IPv6-based content, despite their experience being a positive one.
>
>    While in Section 1 the level of IPv6-related impairment has been
>    estimated to be as high as 0.078% of Internet users, which is a

8 hundredths of one percent?

That's considered a high percentage?

Even if it is 8%, is that considered high?


> 5.2.  Similarities to DNS Load Balancing
>
>    DNS whitelisting also has some similarities to DNS load balancing.
>    There are of course many ways that DNS load balancing can be
>    performed.  In one example, multiple IP address resource records (A
>    and/or AAAA) can be added to the DNS for a given FQDN.  This approach
>    is referred to as DNS round robin [RFC1794].  DNS round robin may
>    also be employed where SRV resource records are used [RFC2782].

Right, but that's algorithmic rather than involving the manual method, described
here. So it does not seem comparable.


> 6.  Likely Deployment Scenarios
>
>    In considering how DNS whitelisting may emerge more widely, there are
>    two likely deployment scenarios, which are explored below.
>
>    In either of these deployment scenarios, it is possible that
>    reputable third parties could create and maintain DNS whitelists, in
>    much the same way that blacklists are used for reducing email spam.
>    In the email context, a mail operator subscribes to one or more of
>    these lists and as such the operational processes for additions and
>    deletions to the list are managed by a third party.  A similar model
>    could emerge for DNS whitelisting, whether deployment occurs
>    universally or on an ad hoc basis.

The challenges of email whitelists and blacklists should be cited, since it
provides a rich base of experience for such an effort, at scale.


> 6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis
>
>    The seemingly most likely deployment scenario is where some

Most likely?  This is not already established practice?


>    authoritative DNS server operators implement DNS whitelisting but
>    many or most others do not do so.  What can make this scenario
>    challenging from the standpoint of a DNS recursive resolver operator
>    is determining which domains implement DNS whitelisting, particularly
>    since a domain may not do so as they initially transition to IPv6,
>    and may instead do so later.  Thus, a DNS recursive resolver operator
>
>
>
> Livingood                Expires August 26, 2011               [Page 13]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    may initially believe that they can receive AAAA responses as a
>    domain adopts IPv6, but then notice via end user reports that they no
>    longer receive AAAA responses due to that domain adopting DNS
>    whitelisting.  Of course, a domain's IPv6 transition may be
>    effectively invisible to recursive server operators due to the effect
>    of DNS whitelisting.

This suggests that every listing at the server needs a contact record for
periodic checks whether to renew the listing.


>
>    In contrast to a universal deployment of DNS whitelisting
>    Section 6.2, deployment on an ad hoc basis is likely to be
>    significantly more challenging from an operational, monitoring, and

Oh?  Use in small scale is more challenging than use of manual exceptions list
at large scale?  That's a very unexpected view.


>    troubleshooting standpoint.  In this scenario, a DNS recursive
>    resolver operator will have no way to systematically determine
>    whether DNS whitelisting is or is not implemented for a domain, since
>    the absence of AAAA resource records may simply be indicative that
>    the domain has not yet added IPv6 addressing for the domain, rather
>    than that they have done so but have restricted query access via DNS

The premise is that, in large scale use, servers /will/ have a way to
systematically determine whether it is implemented?  What are the existing
examples of having such a capability for other Internet protocols and services?


>    whitelisting.  As a result, discovering which domains implement DNS
>    whitelisting, in order to differentiate them from those that do not,
>    is likely to be challenging.
>
>    One benefit of DNS whitelisting being deployed on an ad hoc basis is
>    that only the domains that are interested in doing so would have to
>    upgrade their authoritative DNS servers in order to implement the
>    ACLs necessary to perform DNS whitelisting.
>
>    In this potential deployment scenario, it is also possible that a
>    given domain will implement DNS whitelisting temporarily.  A domain,
>    particularly a highly-trafficked domain, may choose to do so in order
>    to ease their transition to IPv6 through a selective deployment and
>    minimize any perceived risk in such a transition.
>
> 6.2.  Deploying DNS Whitelisting Universally
>
>    The least likely deployment scenario is one where DNS whitelisting is
>    implemented on all authoritative DNS servers, across the entire
>    Internet.  While this scenario seems less likely than ad hoc
>    deployment due to some parties not sharing the concerns that have so
>    far motivated the use of DNS whitelisting, it is nonetheless
>    conceivable that it could be one of the ways in which DNS
>    whitelisting is deployed.

Significantly, the partial-deployment model casts this mechanism as a transition
expedient -- as the document reasonably describes it -- whereas universal
deployment casts it as a fundamental change to the architecture.

Given that it would take decades to achieve relatively full deployment of this
'across the entire Internet', what is the benefit of discussing this highly
unlikely scenario?  Is it really "conceivable"?  I doubt it. If you think
otherwise, the paper needs to explore the deployment and adoption issues in much
more detail, because I don't see how it could work.


>    In order for this deployment scenario to occur, it is likely that DNS
>    whitelisting functionality would need to be built into all
>    authoritative DNS server software, and that all operators of
>    authoritative DNS servers would have to upgrade their software and
>    enable this functionality.  It is likely that new Internet Draft
>    documents would need to be developed which describe how to properly
>    configure, deploy, and maintain DNS whitelisting.  As a result, it is
>
>
>
> Livingood                Expires August 26, 2011               [Page 14]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    unlikely that DNS whitelisting would, at least in the next several
>    years, become universally deployed.  Furthermore, these DNS
>    whitelists are likely to vary on a domain-by-domain basis, depending
>    upon a variety of factors.  Such factors may include the motivation
>    of each domain owner, the location of the DNS recursive resolvers in
>    relation to the source content, as well as various other parameters
>    that may be transitory in nature, or unique to a specific end user
>    host type.  It is probably unlikely that a single clearinghouse for
>    managing whitelisting is possible; it will more likely be unique to
>    the source content owners and/or domains which implement DNS
>    whitelists.
>
>    While this scenario may be unlikely, it may carry some benefits.
>    First, parties performing troubleshooting would not have to determine
>    whether or not DNS whitelisting was being used, as it always would be
>    in use.  In addition, if universally deployed, it is possible that
>    the criteria for being added to or removed from a DNS whitelist could
>    be standardized across the entire Internet.  Nevertheless, even if
>    uniform DNS whitelisting policies were not standardized, is also
>    possible that a central registry of these policies could be developed
>    and deployed in order to make it easier to discover them, a key part
>    of achieving transparency regarding DNS whitelisting.

Is any of this paragraph realistic?  Obviously my asking means I don't it is.
These seem to be of theoretical rather than pragmatic interest.  ("If everyone
refuses to shoot, there will be no wars.")

It's true that this is an "implications" paper rather than a BCP, but still...


>
> 7.  Implications of DNS Whitelisting
>
>    There are many potential implications of DNS whitelisting.  The key
>    potential implications are detailed below.
>
> 7.1.  Architectural Implications
>
>    DNS whitelisting could be perceived as modifying the end-to-end model
>    and/or the general notion of the architecture that prevails on the

I'll suggest that perception is not a major issue about a technical topic like
this.  (It's not entirely irrelevant, of course, but I suspect it is quite minor.)

The major issue is whether it /actually/ modifies the end-to-end nature of the
DNS.  And I think it does, as well as modifying the "spontaneous
interoperability" expectation for most Internet mechanism, since it requires
prior registration.


> 7.2.  Public IPv6 Address Reachability Implications
>
>    The predominant experience of end user hosts and servers on the IPv4-
>    addressed Internet today is that when a new server with a public IPv4
>    address is added to the DNS, that it is then globally accessible by

This sentence is not quite correct, in strict technical terms.  Since this is a
technical discussion, we need to be precise:  the host is reachable when the
routing tables make it reachable.  That's strictly a mapper of IP Address
handling, not name-to-address mapping.

What you mean is that its domain name is immediately useful for reaching it.


>    IPv4-addressed hosts.  This is a generalization and in Section 5
>    there are examples of common cases where this may not necessarily be
>    the case.  For the purposes of this argument, that concept of
>    accessibility can be considered "pervasive reachability".  It has so
>    far been assumed that the same expectations of pervasive reachability
>    would exist in the IPv6-addressed Internet.  However, if DNS
>    whitelisting is deployed, this will not be the case since only end
>    user hosts using DNS recursive resolvers which are included in the

again, you mean /name-based/ reachability.


>
>
>
> Livingood                Expires August 26, 2011               [Page 16]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    ACL of a given domain using DNS whitelisting would be able to reach
>    new servers in that given domain via IPv6 addresses.  The expectation
>    of any end user host being able to connect to any server (essentially
>    both hosts, just at either end of the network), defined here as
>    "pervasive reachability", will change to "restricted reachability"
>    with IPv6.
>
>    Establishing DNS whitelisting as an accepted practice in the early
>    phases of mass IPv6 deployment could well establish it as an integral
>    part of how IPv6 DNS resource records are deployed globally.  As a
>    result, it is then possible that DNS whitelisting could live on for
>    decades on the Internet as a key foundational element of domain name
>    management that we will all live with for a long time.

(that last sentence could benefit from some editing.)


>    It is a critical to understand that the concept of reachability
>    described above depends upon a knowledge or awareness of an address
>    in the DNS.  Thus, in order to establish reachability to an end
>    point, a host is dependent upon looking up an IP address in the DNS

If this section were started with a sentence like this, then there would not be
a problem with the other references' being confused with address-based routing
reachability.


>    when a FQDN is used.  When DNS whitelisting is used, it is quite
>    likely the case that an IPv6-enabled end user host could ping or
>    connect to an example server host, even though the FQDN associated
>    with that server host is restricted via a DNS whitelist.  Since most

First, I suspect that "example" doesn't add meaning to the sentence.  Second,
pinging and connecting might happen with or without the whitelist entry.  So I
do not understand what import there is in this sentence.


>    Internet applications and hosts such as web servers depend upon the
>    DNS, and as end users connect to FQDNs such as www.example.com and do
>    not remember or wish to type in an IP address, the notion of
>    reachability described here should be understood to include knowledge
>    how to associate a name with a network address.

Again, this 'premise' statement should introduce the sub-section, not end it.


>
> 7.3.  Operational Implications
>
>    This section explores some of the operational implications which may
>    occur as a result of, are related to, or become necessary when
>    engaging in the practice of DNS whitelisting.
>
> 7.3.1.  De-Whitelisting May Occur

The more general version of this issue is 'synchronization'.  Entries in the
whitelist need to be synchronized with host status and capabilities.


>    It is possible for a DNS recursive resolver added to a whitelist to
>    then be removed from the whitelist, also known as de-whitelisting.
>    Since de-whitelisting can occur, through a decision by the
>    authoritative server operator, the domain owner, or even due to a
>    technical error, an operator of a DNS recursive resolver will have
>    new operational and monitoring requirements and/or needs as noted in
>    Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5.
>
> 7.3.2.  Authoritative DNS Server Operational Implications
>
>    Operators of authoritative servers may need to maintain an ACL a

a -> on a (?)


>    server-wide basis affecting all domains, on a domain-by-domain basis,
>
>
> Livingood                Expires August 26, 2011               [Page 17]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    as well as on a combination of the two.  As a result, operational

I'm not really understanding the first sentence.  One problem might be that its
discussing an implication of some configuration or usage options that have not
been previously specified, so that the reference here might be overly cryptic.

For example, I don't know what "affecting all domains" actually means.  It
almost sounds as if it could mean "everyone gets AAAA records" or "no one gets
AAAA records" yet I'm reaonably certain that is /not/ what is meant.


>    practices and software capabilities may need to be developed in order
>    to support such functionality.  In addition, processes may need to be
>    put in place to protect against inadvertently adding or removing IP
>    addresses, as well as systems and/or processes to respond to such
>    incidents if and when they occur.  For example, a system may be
>    needed to record DNS whitelisting requests, report on their status
>    along a workflow, add IP addresses when whitelisting has been
>    approved, remove IP addresses when they have been de-whitelisted, log
>    the personnel involved and timing of changes, schedule changes to
>    occur in the future, and to roll back any inadvertent changes.

Might be worth starting with a simple, broad summary statement, possibly along
the lines of:

    An AAAA DNS Whitelist serves as a critical infrastructure service; to be
useful it needs careful and extensive administration, monitoring and operation.
  Each new and essential mechanism creates substantial follow-on support costs.


>    Operators may also need implement new forms of monitoring in order to
>    apply change control, as noted briefly in Section 7.3.4.
>
> 7.3.3.  DNS Recursive Resolver Server Operational Implications
>
>    Operators of DNS recursive resolvers, which may include ISPs,
>    enterprises, universities, governments, individual end users, and
>    many other parties, are likely to need to implement new forms of
>    monitoring, as noted briefly in Section 7.3.4.  But more critically,
>    such operators may need to add people, processes, and systems in
>    order to manage large numbers of DNS whitelisting applications as
>    part of their own IPv6 transition, for all domains that the end users
>    of such servers are interested in now or in which they may be

I think the summary observation is simple and should be stated directly:  This
is a manual mechanism that becomes expensive in time and personnel effort as it
scales up.


>    interested in the future.  As anticipation of interesting domains is
>    likely infeasible, it is more likely that operators may either choose
>    to only apply to be whitelisted for a domain based upon one or more
>    end user requests, or that they will attempt to do so for all domains
>    that they can ascertain to be engaging in DNS whitelisting.

"attempt to do so for all domain that they can ascertain to be engaging in DNS
whitelisting"  appears to be saying to do whitelisting for domains that do
whitelisting.  I don't understand.


>
>    When operators apply for DNS whitelisting for all domains, that may

"apply for DNS whitelisting for all domains" -- again I'm not understanding what
this means.


> 7.3.5.  Implications of Operational Momentum
>
>    It seems plausible that once DNS whitelisting is implemented it will
>    be very difficult to deprecate such technical and operational
>    practices.  This assumption is based in an understanding of human

in -> on


>    nature, not to mention physics.  For example, as Sir Issac Newton
>    noted, "Every object in a state of uniform motion tends to remain in
>    that state of motion unless an external force is applied to it" [Laws

Code does not have momenum.  Neither do configurations or lists.  This really
isn't about physics.

It is entirely about group psychology, as you note, and the administrative
challenges in the logistics of large-scale operational changes (which probably
/does/ have something to with physics, but it seems a stretch to credit Newton.
How about Heisenberg?...)


>    of Motion].  Thus, once DNS whitelisting is implemented it is quite
>    likely that it would take considerable effort to deprecate the
>    practice and remove it everywhere on the Internet - it will otherwise
>    simply remain in place in perpetuity.  To better illustrate this
>    point, one could consider one example (of many) that there are many
>    email servers continuing to attempt to query or otherwise check anti-
>
>
>
> Livingood                Expires August 26, 2011               [Page 19]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    spam DNS blocklists which have long ago ceased to exist.
>
> 7.3.6.  Troubleshooting Implications
>
>    The implications of DNS whitelisted present many challenges, which
>    have been detailed in Section 7.  These challenges may negatively

But this is /still/ section 7.  Can you be more specific?  Or perhaps say
"throughout this section".


>    affect the end users' ability to troubleshoot, as well as that of DNS
>    recursive resolver operators, ISPs, content providers, domain owners
>    (where they may be different from the operator of the authoritative
>    DNS server for their domain), and other third parties.  This may make
>    the process of determining why a server is not reachable
>    significantly more complex.
>
> 7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis
>
>    Additional implications, should this be deployed on an ad hoc basis,
>    could include scalability problems relating to operational processes,

I'm pretty sure that scaling problems for this exist in all scenarios, not just
ad hoc usage.


>    monitoring, and ACL updates.  In particular, it seems likely that as
>    the number of domains that are using DNS whitelisting increases, as
>    well as the number of IPv6-capable networks requesting to be
>    whitelisted, that there is an increased likelihood of configuration
>    and other operational errors, especially with respect to the ACLs
>    themselves.
>
>    It is unclear when and if it would be appropriate to change from
>    whitelisting to blacklisting, and whether or how this could feasibly
>    be coordinated across the Internet, which may be proposed or

Actually the question of coordination is quite clear and rather fundamental:

      No.

Anyone believing otherwise needs to cite a successful example, at Internet scale
and diversity, more recently than the 1983 switch to IP (which didn't go all
that well anyhow...)

Simple, unambiguous showstoppers should be stated in a simple and direct manner.
  When there is room for debate, softer language makes sense.  Again, if the
question of coordination really is subject to debate, then the basis needs to be
stated.  (Good luck!)


>    implemented on an ad hoc basis when a majority of networks (or
>    allocated IPv6 address blocks) have been whitelisted.  Finally, some
>    parties implementing DNS whitelisting consider this to be a temporary
>    measure.  As such, it is not clear how these parties will judge the
>    network conditions to have changed sufficiently to justify disabling
>    DNS whitelisting and/or what the process and timing will be in order
>    to discontinue this practice.
>
>    One further potential implication is that an end user with only an
>    IPv4 address, using a DNS resolver which has not been whitelisted by
>    any domains, would not be able to get any AAAA resource records.  In
>    such a case, this could give that end user the incorrect impression
>    that there is no IPv6-based content on the Internet since they are
>    unable to discover any IPv6 addresses via the DNS.
>
> 7.4.  Homogeneity May Be Encouraged
>
>    A broad trend which has existed on the Internet appears to be a move
>    towards increasing levels of heterogeneity.  One manifestation of

increasing levels of heterogeneity -> more heterogeneity

(I think heterogeneity does not have 'levels'.)

Substantively:  say the nature of the heterogeneity within the initial claim.
For example, there is /less/ heterogeneity of ISPs, given industry
consolidation.  There is less heterogeneity of infrastructure equipment such as
routers.  Etc.


>    this is in an increasing number, variety, and customization of end
>    user hosts, including home network, operating systems, client
>
>
>
> Livingood                Expires August 26, 2011               [Page 20]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    software, home network devices, and personal computing devices.  This
>    trend appears to have had a positive effect on the development and
>    growth of the Internet.  A key facet of this that has evolved is the
>    ability of the end user to connect any technically compliant device
>    or use any technically compatible software to connect to the
>    Internet.  Not only does this trend towards greater heterogeneity
>    reduce the control which is exerted in the middle of the network,
>    described in positive terms in [Tussle in Cyberspace], [Rethinking
>    the Internet], and [RFC3724], but it can also help to enable greater
>    and more rapid innovation at the edges.
>
>    An unfortunate implication of the adoption of DNS whitelisting may be
>    the encouragement of a reversal of this trend, which would be a move

the encouragement of -> to encourage


> 8.1.  Implement DNS Whitelisting Universally
>
>    One obvious solution is to implement DNS whitelisted universally, and
>    to do so using some sort of centralized registry of DNS whitelisting
>    policies, contracts, processes, or other information.  This potential
>    solution seems unlikely at the current time.

I'm pretty sure that the only thing that is obvious about a premise of universal
adoption is that it's not practical.  Seriously.

At the least, this section needs to be less cavalier about putting this
alternative forward as a "solution", especially given the rather serious
drawbacks/problems with it.


> 8.2.  Implement DNS Whitelisting On An Ad Hoc Basis
>
>    If DNS whitelisting is to be adopted, it is likely to be adopted on

"is to be"?  I thought it already had a significant installed base.


>    this ad hoc, or domain-by-domain basis.  Therefore, only those
>    domains interested in DNS whitelisting would need to adopt the
>    practice, though as noted herein discovering that they a given domain
>    has done so may be problematic.  Also in this scenario, ad hoc use by
>    a particular domain may be a temporary measure that has been adopted
>    to ease the transition of the domain to IPv6 over some short-term
>    timeframe.
>
> 8.3.  Do Not Implement DNS Whitelisting
>
>    As an alternative to adopting DNS whitelisting, the Internet
>    community generally can choose to take no action whatsoever,
>    perpetuating the current predominant authoritative DNS operational
>    model on the Internet, and leave it up to end users with IPv6-related
>    impairments to discover and fix those impairments.
>

That is, place the burden of fixing a problem on those creating it?


>
>
>
>
> Livingood                Expires August 26, 2011               [Page 23]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
> 8.3.1.  Solving Current End User IPv6 Impairments
>
>    A further extension of not implementing DNS whitelisting, is to also
>    endeavor to actually fix the underlying technical problems that have
>    prompted the consideration of DNS whitelisting in the first place, as
>    an alternative to trying to apply temporary workarounds to avoid the
>    symptoms of underlying end user IPv6 impairments.  A first step is
>    obviously to identify which users have such impairments, which would
>    appear to be possible, and then to communicate this information to
>    end users.  Such end user communication is likely to be most helpful
>    if the end user is not only alerted to a potential problem but is
>    given careful and detailed advice on how to resolve this on their
>    own, or where they can seek help in doing so.  Section 11 may also be
>    relevant in this case.
>
>    One challenge with this option is the potential difficulty of
>    motivating members of the Internet community to work collectively
>    towards this goal, sharing the labor, time, and costs related to such
>    an effort.  Of course, since just such a community effort is now
>    underway for IPv6, it is possible that this would call for only a
>    moderate amount of additional work.

This 'challenge' is at the core of /all/ adoption efforts for Internet protocols
and services that entail distributed adoption.


>    Despite any potential challenges, many in the Internet community are
>    already working towards this goal and/or have expressed a general
>    preference for this approach.

If this is not already an organized effort with a website, sponsoring
consortium, or the like, it should be.  If it is, then cite it in this doc!

>
> 8.3.2.  Gain Experience Using IPv6 Transition Names
>
>    Another alternative is for domains to gain experience using an FQDN
>    which has become common for domains beginning the transition to IPv6;
>    ipv6.example.com and www.ipv6.example.com.  This can be a way for a
>    domain to gain IPv6 experience and increase IPv6 use on a relatively
>    controlled basis, and to inform any plans for DNS whitelisting with
>    experience.

I do not understand what this means.

What is it for?  What are the results?  How are theyused?


> 9.  Is DNS Whitelisting a Recommended Practice?
>
>    Opinions in the Internet community concerning whether or not DNS
>    whitelisting is a recommended practice are understandably quite
>    varied.  However, there is clear consensus that DNS whitelisting is
>    at best a useful temporary measure which a domain may choose to

If that is a clear consensus, then it makes even less sense to promote the idea
of universal adoption, given the timescale needed to achieve it.


> 10.  Security Considerations
>
>    There are no particular security considerations if DNS whitelisting
>    is not adopted, as this is how the public Internet works today with A
>    resource records.

Or rather, failure to adopt a mechanism like this or repair the underlying
problem, for those sites experiencing that problem, will result in a denial of
service, albeit not an intentional one.  Still, that's a pretty basic security
issue.


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From jason_livingood@cable.comcast.com  Sun May 29 10:56: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 95DAEE073C; Sun, 29 May 2011 10:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.423
X-Spam-Level: 
X-Spam-Status: No, score=-108.423 tagged_above=-999 required=5 tests=[AWL=0.040, 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 IP1Q5PEYQL84; Sun, 29 May 2011 10:56:06 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id B0FE7E0720; Sun, 29 May 2011 10:56:05 -0700 (PDT)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.127890250; Sun, 29 May 2011 13:55:54 -0400
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; Sun, 29 May 2011 13:55:54 -0400
From: "Livingood, Jason" 
To: Dave Crocker 
Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
Thread-Index: AQHMHiCFaQ1rFgbAjU2uc45go6jhX5SkFwWA
Date: Sun, 29 May 2011 17:55:53 +0000
Message-ID: 
In-Reply-To: <4DE27946.7000704@dcrocker.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [24.40.55.70]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , IETF Discussion 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 May 2011 17:56:10 -0000

It's still in my queue -- I have 10 or 11 emails remaining to go through.


Jason

On 5/29/11 12:50 PM, "Dave CROCKER"  wrote:

>
>On 5/29/2011 7:46 AM, Livingood, Jason wrote:
> > Hi Bernard =AD I've finally found the time to close out the last bits o=
f
> > feedback > in this version of the draft.
>
>
>Jason,
>
>Perhaps my filters misfiled your followup to the "formal" review I was
>asked to=20
>do, or perhaps my earlier, informal, and vary narrow review muddied the
>waters,=20
>but I am not finding your response to the Apps Area review.
>
>For convenience, here it is again.
>
>d/
>
>-------- Original Message --------
>Subject: Review of:
>draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03=09
>          *(formal for apps area)*
>Date: Mon, 09 May 2011 10:18:51 -0700
>From: Dave CROCKER 
>Reply-To: dcrocker@bbiw.net
>Organization: Brandenburg InternetWorking
>To: IETF Discussion 
>CC: v6ops@ietf.org , Apps Review 
>
>(This is an "official" and significantly extended version of an informal
>and
>narrow review I posted earlier.  /d)
>
>
>
>Howdy.
>
>I have been selected as the Applications Area Review Team reviewer for
>this
>draft (for background on apps-review, please see
>http://www.apps.ietf.org/content/applications-area-review-team).
>
>Please resolve these comments along with any other Last Call comments you
>may
>receive. Please wait for direction from your document shepherd or AD
>before
>posting a new version of the draft.
>
>
>
>Review (v2):
>
>Title:  IPv6 AAAA DNS Whitelisting Implications
>I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
>
>By:     D. Crocker 
>Date:   <>
>
>
>
>Summary
>=3D=3D=3D=3D=3D=3D=3D
>
>This draft covers a a dual-stack problem in which a target host's DNS
>entry
>contains records for IPv4 and IPv6, but returning IPv6 information to a
>DNS
>client can cause problems. The paper discusses for resolving this through
>use of
>a a DNS-based mechanism that manually lists response preferences to
>select which
>DNS records to return.  The paper describes the mechanism and explores
>various
>effects and possibilities of its use, including the difference between
>using it
>selectively among a smaller number of sites, versus universally.
>
>The draft is a serious effort to explore the use of such a mechanism and
>it
>touches many different issues.  It is generally well-organized and clearly
>written, although it very much needs the aid of a professional technical
>editor.
>The writing often assumes too much knowledge by the reader.
>
>The paper's exploration of universal adoption seems to vary between
>considering
>that goal practical versus considering it only as a matter of
>completeness for
>discussing the full range of possibilities.  That is, it is not clear
>whether
>the paper views this alternative as practically possible and even
>preferred,
>versus only a matter for academic thoroughness. The paper needs to take a
>basic
>position about feasibility, explain it in terms of comparable adoption
>efforts
>at Internet-scale, and then make its treatment of universal adoption a
>bit more
>consistent.
>
>When introducing terms, mechanisms, configurations and scenarios, the
>paper
>needs to be more careful to describe them adequately for a reader new to
>the
>topic.  This is not a matter of having a tutorial about the DNS, but
>rather a
>tutorial for this type of mechanism and when and how it can be used.
>
>As a specific example, the document cites "domain-by-domain" use, but I
>am not
>clear how that would work, in terms of configuration and cross-net
>information
>exchange.  One question is how the server knows the 'domain' of the
>client?
>
>The document should careful to distinguish what is existing practice,
>versus
>what is being explored as added possibilities.  The difference in
>concreteness
>and certitude between the two is substantial.
>
>The document's use of the term whitelisting appears to continue an
>existing,
>recent use, for this type of mechanism.  Unfortunately it directly
>conflicts
>with long-standing use of the term by the anti-abuse community for
>whitelisting
>in the DNS. Its use here also seems to be a mismatch with the word's
>dictionary
>semantics, which is most naturally used to distinguish yes/no choices,
>rather
>than either/or choices.  So there is no intuitive sense of "goodness"
>(whitelist
>=3D yes) or "badness" (blacklist) for this use. The word "preferences"
>seems more
>in line with the meaning of the mechanism.
>
>
>
>Detailed Comments
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>> Abstract
>>
>>    The objective of this document is to describe what the whitelisting
>>    of DNS AAAA resource records is, hereafter referred to as DNS
>
>RRs are whitelisted?  Isn't it the addresses and not the records that are
>whitelisted?
>
>Does this mean putting whitelisting records into the DNS or does it mean
>something else?
>
>Comcast's own considerable expertise notwithstanding, has this doc been
>vetted
>with a range of organizations that actually DO whitelisting?  Has it been
>circulated through MAAWG and APWG?  Any comments from Spamhaus?  The
>Acknowledgements list does not seem to indicate a range of whitelist ops
>folks
>whose names I know.  (But then, I only know a few...)
>
>
>>    whitelisting, as well as the implications of this emerging practice
>>    and what alternatives may exist.  The audience for this document is
>>    the Internet community generally, including the IETF and IPv6
>>    implementers.
>
>I suspect that product marketers won't have much interest in this.  I
>suspect
>that the target for this is anti-abuse technical and operations staff. In
>any
>event, the targetting statement should be more precise.
>
>
>> 1.  Introduction
>>
>>    This document describes the emerging practice of whitelisting of DNS
>
>One natural, semantic problem with the term 'whitelist' is that it does
>not
>really match the function being performed.  The white/black distinction
>implies
>goodness -- or as Wikipedia says, "priviledge".  Instead, the use here is
>for
>preference or priority.  What would a "blacklist" be, here?  Also note it
>is not
>obvious what it means to be whitelisted, here?  Does it mean to choose
>the AAAA
>records or the A records?
>
>This is more like a 'Preference' or 'Configuration' list.
>
>At the least, the name for this should be IPv6 Resolver Whitelisting.  It
>makes
>clear /what/ is being "whitelisted".
>
>
>>    AAAA resource records (RRs), which contain IPv6 addresses, hereafter
>>    referred to as DNS whitelisting.  The document explores the
>
>This provides a name, but not a function.  That is, it does not say what
>this
>mechanisms actually /does/ or is /for/.
>
>
>>    implications of this emerging practice are and what alternatives may
>>    exist.
>>
>>    The practice of DNS whitelisting appears to have first been used by
>>    major web content sites (sometimes described herein as "highly-
>
>It's use for email anti-abuse dates back farther.
>
>    
>
>    
>
>
>m.ibm.help.domino.admin.doc/DOC/H_USING_DNS_whitelists_OVER.html>
>
>Specifically within the context of the DNS, the term whitelisting is
>therefore
>made ambiguous.
>
>A google query for "whitelist dns" also demonstrates the history and
>current
>ambiguity.
>
>
>>    trafficked domains" or "major domains").  These web site operators,
>>    or domain operators, observed that when they added AAAA resource
>>    records to their authoritative DNS servers in order to support IPv6
>>    access to their content that a small fraction of end users had slow
>>    or otherwise impaired access to a given web site with both AAAA and A
>>    resource records.  The fraction of users with such impaired access
>>    has been estimated to be roughly 0.078% of total Internet users
>>    [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
>>    Brokenness].  Thus, in an example Internet Service Provider (ISP)
>>    network of 10 million users, approximately 7,800 of those users may
>>    experience such impaired access.
>
>At a minimum, these sorts of statistics need to be normalized across IPv6
>users/traffic, given how small a percentage that is, in total users and
>total
>traffic.  If that's what is meant it should be stated.  If it isn't, the
>statistic should be recalculated and explained a bit more precisely.
>
>
>>    As a result of this impairment affecting end users of a given domain,
>>    a few major domains have either implemented DNS whitelisting or are
>>    considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].
>>    When implemented, DNS whitelisting in practice means that a domain's
>>    authoritative DNS will return a AAAA resource record to DNS recursive
>>    resolvers [RFC1035] on the whitelist, while returning no AAAA
>>    resource records to DNS resolvers which are not on the whitelist.  It
>
>This explanation of the function should be offered sooner and should be
>summarized in the Abstract.
>
>
>>    is important to note that these major domains are motivated by a
>>    desire to maintain a high-quality user experience for all of their
>
>Rather than being important to note, this sentence sounds oddly like
>marketing
>hype, in a technical specification.  It is gratuitous because specified
>features
>are never added to /lower/ the quality of the user experience, for
>example.
>
>In addition, the mechanism also affects client activity that has no user
>directly involved.
>
>
>>    users.  By engaging in DNS whitelisting, they are attempting to
>>    shield users with impaired access from the symptoms of those
>>    impairments.
>
>The /technical/ statement that should be here is that they are attempting
>to
>provide a work-around for problematic behaviors in dual-stack IPv4/IPv6
>environments.
>
>The paper should make more clear exactly where the problem lies and when.
>If it
>can occur for a number of reasons, explaining each of those scenarios
>would be
>useful.
>
>
>>    Critics of the practice of DNS whitelisting have articulated several
>>    concerns.  Among these are that:
>>
>>    o  DNS whitelisting is a very different behavior from the current
>>       practice concerning the publishing of IPv4 address resource
>>       records,
>>
>>    o  that it may create a two-tiered Internet,
>>
>>    o  that policies concerning whitelisting and de-whitelisting are
>>       opaque,
>>
>>
>>
>>
>>
>> Livingood                Expires August 26, 2011                [Page 5]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>>    o  that DNS whitelisting reduces interest in the deployment of IPv6,
>>
>>    o  that new operational and management burdens are created,
>
>well, yeah... in fact it should be noted that the burdens are particularly
>onerous at scale.
>
>
>>    o  and that the costs and negative implications of DNS whitelisting
>>       outweigh the perceived benefits, compared to fixing underlying
>>       impairments.
>
>and it doesn't scale.
>
>and it violates an extremely basic premise of cross-Internet
>interoperability by
>requiring prior arrangement.
>
>
>>    This document explores the reasons and motivations for DNS
>>    whitelisting.  It also explores the outlined concerns regarding this
>>    practice.  Readers will hopefully better understand what DNS
>>    whitelisting is, why some parties are implementing it, and what
>>    criticisms of the practice exist.
>>
>>
>> 2.  How DNS Whitelisting Works
>
>How IPv6 AAAA DNS Whitelisting Works.
>
>(Anti-spam DNS Whitelisting works rather differently...)
>
>
>>    DNS whitelisting is implemented in authoritative DNS servers.  These
>>    servers implement IP address-based restrictions on AAAA query
>>    responses.  So far, DNS whitelisting has been primarily implemented
>>    by web server operators deploying IPv6-enabled services.  For a given
>
>Really?  This is web-specific?  The same restrictions are not applied for
>other
>applications?
>
>So if the same client-side hosts attempt to contact the server for email
>or
>xmpp, they won't get the same handling?
>
>
>>    operator of a website, such as www.example.com, the operator
>>    essentially applies an access control list (ACL) on the authoritative
>>    DNS servers for the domain example.com.  The ACL is populated with
>
>An ACL usually is a yes/no mechanism.  Here, however, the mechanism is for
>asserting a preference for IPv6 over IPv4.
>
>That does not seem to match the definition of ACL that I'm used to,
>unless the
>semantic is defined as denying IPv4 access to the listed clients.
>
>The term ACL is particularly odd to use if the mechanism pertains to
>responses
>rather than queries.
>
>
>>    the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive
>
>Either address type can be listed?  So this really is a pure 'preferences'
>mechanism?
>
>Which settings count as whitelisting?  Do any count as blacklisting?
>
>
>
>>    resolvers on the Internet, which have been authorized to receive AAAA
>>    resource record responses.  These DNS recursive resolvers are
>>    operated by third parties, such as ISPs, universities, governments,
>>    businesses, and individual end users.  If a DNS recursive resolver IS
>>    NOT matched in the ACL, then AAAA resource records will NOT be sent
>>    in response to a query for a hostname in the example.com domain.
>
>This configuration appears to ensure the maximum barrier to adoption for
>IPv6,
>since it means that IPv6 will not work automatically.  It will only work
>for
>hosts that are manually configured to receive responses with v6 records.
>
>That's a rather major implication.  It's a default that is probably meant
>to
>apply during the very early stages of adoption, when there are few users
>of the
>newer mechanism.
>
>It's probably worth discussing it in more detail, including discussing
>when to
>change the default...
>
>
>>    However, if a DNS recursive resolver IS matched in the ACL, then AAAA
>>    resource records will be sent in response to a query for a given
>>    hostname in the example.com domain.  While these are not network-
>>    layer access controls they are nonetheless access controls that are a
>>    factor for end users and other parties like network operators,
>>    especially as networks and hosts transition from one network address
>>    family to another (IPv4 to IPv6).
>
>
>Also, all of this clarifies the function of this listing mechanism and
>suggests
>a very different name, to be more precise and accurate in naming it:
>
>     IPv6 DNS Response Preference List.
>
>
>>    In practice, DNS whitelisting generally means that a very small
>>    fraction of the DNS recursive resolvers on the Internet (those in the
>>    whitelist ACL) will receive AAAA responses.  The large majority of
>>    DNS resolvers on the Internet will therefore receive only A resource
>>    records containing IPv4 addresses.  Thus, quite simply, the
>>    authoritative server hands out different answers depending upon who
>>    is asking; with IPv4 and IPv6 resource records for some on the
>>    authorized whitelist, and only IPv4 resource records for everyone
>>    else.  See Section 2.1 and Figure 1 for a description of how this
>>
>>
>>
>> Livingood                Expires August 26, 2011                [Page 6]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>>    works.
>>
>>    Finally, DNS whitelisting can be deployed in two primary ways:
>>    universally on a global basis, or on an ad hoc basis.  Deployment on
>>    a universal deployment basis means that DNS whitelisting is
>>    implemented on all authoritative DNS servers, across the entire
>>    Internet.  In contrast, deployment on an ad hoc basis means that only
>>    some authoritative DNS servers, and perhaps even only a few,
>>    implement DNS whitelisting.  These two potential deployment models
>>    are described in Section 6.
>>
>> 2.1.  Description of the Operation of DNS Whitelisting
>>
>>    The system logic of DNS whitelisting is as follows:
>>
>>    1.  The authoritative DNS server for example.com receives DNS queries
>>        for the A (IPv4) and AAAA (IPv6) address resource records for the
>>        FQDN www.example.com, for which AAAA (IPv6) resource records
>>        exist.
>
>This means that the mechanism is /only/ triggered when /both/ address
>records
>are queried?  A query for only one type of address record won't trigger
>the list
>lookup?  I think that doesn't match other statements in the document.
>
>
>>    2.  The authoritative DNS server examines the IP address of the DNS
>>        recursive resolver sending the AAAA (IPv6) query.
>
>"examines"?  Examines it for what?  What does this step mean?
>
>
>>    3.  The authoritative DNS server checks this IP address against the
>>        access control list (ACL) that is the DNS whitelist.
>>
>>    4.  If the DNS recursive resolver's IP address IS matched in the ACL,
>>        then the response to that specific DNS recursive resolver can
>>        contain AAAA (IPv6) address resource records.
>
>Oh.  This is not about whether to send responses /over/ v6 vs. v4?  This
>is
>whether to /include/ a particular type of RR in responses???
>
>In that case an appropriate name for this mechanism is more like:
>
>    DNS Response Content Preference List
>
>And this seems even less like an ACL than it did before.  (I assume the
>justification is that access is being prevented by virtue of not
>supplying the
>address, but still...)
>
>
>>    5.  If the DNS recursive resolver's IP address IS NOT matched in the
>>        ACL, then the response to that specific DNS recursive resolver
>>        cannot contain AAAA (IPv6) address resource records.  In this
>>        case, the server should return a response with the response code
>>        (RCODE) being set to 0 (No Error) with an empty answer section
>>        for the AAAA record query.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Livingood                Expires August 26, 2011                [Page 7]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>>    ---------------------------------------------------------------------
>>    A query is sent from a DNS recursive resolver that IS NOT on the DNS
>>    whitelist:
>>
>>                Request                      Request
>>            www.example.com                  www.example.com
>>                  AAAA    +-------------+     AAAA    +-----------------+
>>      ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
>>      ||  ||       A      | **IS NOT**  |      A      | IN A exists     |
>>    +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
>>    +--------+     A      | example.com |      A      |                 |
>>       Host    <--------- |  WHITELIST  |  <--------- |                 |
>>     Computer   A Record  +-------------+  A Record   +-----------------+
>>                Response   DNS Recursive   Response       example.com
>>               (only IPv4)   Resolver     (only IPv4)    Authoritative
>>                               #1                           Server
>>    ---------------------------------------------------------------------
>>    A query is sent from a DNS recursive resolver that IS on the DNS
>>    whitelist:
>>
>>                Request                      Request
>>            www.example.com                  www.example.com
>>                 AAAA     +-------------+     AAAA    +-----------------+
>>      ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
>>      ||  ||       A      |   **IS**    |      A      | IN A exists     |
>>    +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
>>    +--------+   AAAA     | example.com |     AAAA    |                 |
>>       Host    <--------- |  WHITELIST  |  <--------- |                 |
>>     Computer      A      |             |      A      |                 |
>>               <--------- |             |  <--------- |                 |
>>               A and AAAA +-------------+ A and AAAA  +-----------------+
>>                Record     DNS Recursive   Record        example.com
>>               Responses     Resolver     Responses      Authoritative
>>               (IPv4+IPv6)      #2        (IPv4+IPv6)       Server
>>    ---------------------------------------------------------------------
>>
>>               Figure 1: DNS Whitelisting - Functional Diagram
>
>This diagram is confusing to me.  I suspect that a protocol exchange
>sequence
>format, in the style of:
>
>      Host             Resolver 1            Authoritative
>
>           ---------->
>                                  --------->
>                                 <---------
>          <----------
>
>will be considerably more helpful.
>
>
>> 3.  What Problems Are Implementers Trying To Solve?
>
>This is a very useful section and it is probably worth moving it higher,
>to
>precede the 'how it works' section.
>
>
>>    As noted in Section 1, domains which implement DNS whitelisting are
>>    attempting to protect a few users of their domain, who have impaired
>>    IPv6 access, from having a negative experience (poor performance).
>
>By the way, what does 'impaired v6 access' mean?
>
>I think there needs to be a simple, direct description of what occurs
>without
>this mechanism.
>
>For example, perhaps you mean that a host can send DNS queries using IPv6
>but
>cannot receive DNS responses over IPv6? Perhaps you mean that the host
>can send
>IPv6 but cannot receive it.  (That's a different scale and scope of
>problem from
>the first example I gave.)
>
>This brief, summary problem statement should be included in the Abstract,
>to
>make /much/ more clear what this mechanism is for.
>
>
>>    While it is outside the scope of this document to explore the various
>>    reasons why a particular user's system (host) may have impaired IPv6
>>    access, for the users who experience this impairment it is a very
>>    real performance impact.  It would affect access to all or most dual
>>
>>
>>
>> Livingood                Expires August 26, 2011                [Page 8]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>>    stack services to which the user attempts to connect.  This negative
>>    end user experience can range from someone slower than usual (as
>>    compared to native IPv4-based access), to extremely slow, to no
>>    access to the domain whatsoever.
>
>Rather than repeat that this is about end-users, it sounds more that this
>is
>about whether a service works or does not work, whether a user is directly
>present or not.
>
>
>>    While one can debate whether DNS whitelisting is the optimal solution
>>    to the end user experience problem, it is quite clear that DNS
>>    whitelisting implementers are interested in maximizing the
>>    performance of their services for end users as a primary motivation
>>    for implementation.
>
>You keep citing 'performance' but haven't described what sort of
>performance
>degradation takes place. Is this really about relatively better or worse
>performance -- and if so, how -- or is this about working or not working?
>
>Also rather than saying what implementers are interested in, it's
>probably more
>helpful to note that the practice is now significantly established and
>therefore
>worth documenting, independent of its possible controversy.
>
>
>>    At least one highly-trafficked domain has noted that they have
>>    received requests to not send DNS responses with AAAA resource
>>    records to particular resolvers.  In this case, the operators of
>
>"At least one" seems a rather tiny statistic.  Perhaps the actual
>statistic is
>significantly larger?
>
>
>>    those recursive resolvers have expressed a concern that their IPv6
>
>I suspect that it's not resolvers that are doing the expressing, since
>their
>vocabulary is usually too limited...
>
>
>>    network infrastructure is not yet ready to handle the large traffic
>>    volume which may be associated with the hosts in their network
>>    connecting to the websites of these domains.  This concern is clearly
>
>So even though the site allows v6 DNS queries to go out from a host, it
>can't
>really support having the host use v6?
>
>Wow. I do understand why service providers often have to work around
>silliness
>at the client side, but this problem at the client side seems particularly
>egregious.
>
>
>>    a temporary consideration relating to the deployment of IPv6 network
>>    infrastructure on the part of networks with end user hosts, rather
>>    than a long-term concern.  These end user networks may also have
>
>Again this goal of short-term usage is worth noting earlier, including in
>the
>Abstract.
>
>
>>    other tools at their disposal in order to address this concern,
>>    including applying rules to network equipment such as routers and
>>    firewalls (this will necessarily vary by the type of network, as well
>>    as the technologies used and the design of a given network), as well
>>    as configuration of their recursive resolvers (though modifying or
>>    suppressing AAAA resource records in a DNSSEC-signed domain on a
>>    Security-Aware Resolver will be problematic Section 10.1).
>>
>>    Some implementers with highly-trafficked domains have explained that
>>    DNS whitelisting is a necessary, though temporary, risk reduction
>>    tactic intended to ease their transition to IPv6 and minimize any
>>    perceived risk in such a transition.  As a result, they perceive this
>>    as a tactic to enable them to incrementally enable IPv6 connectivity
>>    to their domains during the early phases of their transition to IPv6.
>>
>>    Finally, some domains, have run IPv6 experiments whereby they added
>>    AAAA resource records and observed and measured errors [Heise Online
>>    Experiment], which should be important reading for any domain
>>    contemplating either the use of DNS whitelisting or simply adding
>>    IPv6 addressing to their site.
>>
>>
>> 4.  Concerns Regarding DNS Whitelisting
>>
>>    There are a number of potential implications relating to DNS
>>    whitelisting, which have been raised as concerns by some parts of the
>>    Internet community.  Many of those potential implications are further
>
>I think the implications are not conditional; they exist rather than being
>potential.  The 'potential' is that what is implicated will come to pass.
>
>
>
>>
>> Livingood                Expires August 26, 2011                [Page 9]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>>    enumerated here and in Section 7.
>
>Pro forma question:  Why are implications discussed in multiple places?
>
>
>>    Some parties in the Internet community, including ISPs, are concerned
>
>This style of text personalizes the issues unnecessarily (IMO).  It does
>not
>really matter who holds the concerns, or else they'd be described more
>precisely.
>
>I suggest merely noting that there are concerns and then listing and
>discussing
>the concerns, rather than adding text to attribute the concerns to
>others, even
>if the conclusion of your text is that a particular concern is not valid.
>
>
>>    that the practice of DNS whitelisting for IPv6 address resource
>>    records represents a departure from the generally accepted practices
>>    regarding IPv4 address resource records in the DNS on the Internet
>>    [Whitelisting Concerns].  These parties explain their belief that for
>
>"These parties explain their belief" is an example of personalization
>that is
>not needed.  This isn't about the believers.  It is about possible
>problems.
>
>
>>    A resource records, containing IPv4 addresses, once an authoritative
>>    server operator adds the A record to the DNS, then any DNS recursive
>>    resolver on the Internet can receive that A record in response to a
>
>This does not appear to be a grammatically valid sentence.  My guess is
>that
>deleting "A resource... addresses" fixes this.
>
>And by the way, the document's reference to "recursive" resolvers is
>mostly
>likely incorrect.  The problem is not restricted only to that very
>specific type
>of resolver, is it?
>
>If in fact it /is/ specific to them -- and your following text describes
>an
>indirect effects scenario where it might be -- I suggest calling out the
>configuration at the beginning, along the lines of:
>
>      One way the problem with returning AAAA records can be experienced
>is when
>recursive resolvers are used.  Although that resolver might support IPv6,
>its
>client hosts might not.  So, returning an AAAA record will mean that these
>limited hosts will be given an unusable address.
>
>And this type of description belongs in the text describing the motivating
>problem(s), rather than buried in the 'concerns' discussion.
>
>(The text, here, pertains to A records, but the problem I've described
>uses the
>same configuration but for AAAA records with mixed v6 support.)
>
>
>>    query.  By extension, this means that any of the hosts connected to
>>    any of these DNS recursive resolvers can receive the IPv4 address
>>    resource records for a given FQDN.  This enables new server hosts
>>    which are connected to the Internet, and for which a fully qualified
>>    domain name (FQDN) such as www.example.com has been added to the DNS
>>    with an IPv4 address record, to be almost immediately reachable by
>>    any host on the Internet.  In this case, these new servers hosts
>>    become more and more widely accessible as new networks and new end
>>    user hosts connect to the Internet over time, capitalizing on and
>>    increasing so-called "network effects" (also called network
>>    externalities).  It also means that the new server hosts do not need
>>    to know about these new networks and new end user hosts in order to
>>    make their content and applications available to them, in essence
>>    that each end in this end-to-end model is responsible for connecting
>>    to the Internet and once they have done so they can connect to each
>>    other without additional impediments or middle networks or
>>    intervening networks or servers knowing about these end points and
>>    whether one is allowed to contact the other.
>
>Hmmm.  This rather lengthy bit of prose appears merely to be explaining
>the
>basic and long-standing DNS value proposition???
>
>
>>    In contrast, the concern is that DNS whitelisting may fundamentally
>>    change this model.  In the altered DNS whitelisting end-to-end model,
>>    one end (where the end user is located) cannot readily connect to the
>>    other end (where the content is located), without parts of the middle
>>    (recursive resolvers) used by one end (the client, or end user hosts)
>>    being known to an intermediary (authoritative nameservers) and
>>    approved for access to the resource at the end.  As new networks
>>    connect to the Internet over time, those networks need to contact any
>>    and all domains which have implemented DNS whitelisting in order to
>>    apply to be added to their DNS whitelist, in the hopes of making the
>>    content and applications residing on named server hosts in those
>>    domains accessible by the end user hosts on that new network.
>>    Furthermore, this same need to contact all domains implementing DNS
>>    whitelisting also applies to all pre-existing (but not whitelisted)
>>    networks connected to the Internet.
>>
>>    In the current IPv4 Internet when a new server host is added to the
>>    Internet it is generally widely available to all end user hosts and
>>    networks, when DNS whitelisting of IPv6 resource records is used,
>
>If it is available to the hosts, it is available to the network.
>
>networks, when -> networks. When
>
>
>>
>>
>>
>> Livingood                Expires August 26, 2011               [Page 10]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>>    these new server hosts are not accessible to any end user hosts or
>>    networks until such time as the operator of the authoritative DNS
>
>They are still accessible.  The IP-level mechanisms still work.
>
>They are not reachable when using the domain name.
>
>
>>    servers for those new server hosts expressly authorizes access to
>>    those new server hosts by adding DNS recursive resolvers around the
>>    Internet to the ACL.  This has the potential to be a significant
>
>This is a good example of the reason the term ACL is inappropriate:  It=20
>implies
>a security protection that does not actually exist.  The hosts are still=20
>accessible.
>
>
>>    change in reachability of content and applications by end users and
>>    networks as these end user hosts and networks transition to IPv6,
>>    resulting in more (but different) breakage.  A concern expressed is
>>    that if much of the content that end users are most interested in is
>>    not accessible as a result, then end users and/or networks may resist
>>    adoption of IPv6 or actively seek alternatives to it, such as using
>>    multi-layer network address translation (NAT) techniques like NAT444
>>    [I-D.shirasaki-nat444] on a long-term basis.  There is also concern
>>    that this practice also could disrupt the continued increase in
>>    Internet adoption by end users if they cannot simply access new
>>    content and applications but must instead contact the operator of
>>    their DNS recursive resolver, such as their ISP or another third
>>    party, to have their DNS recursive resolver authorized for access to
>>    the content or applications that interests them.  Meanwhile, these
>>    parties say, over 99.9% of the other end users that are also using
>>    that same network or DNS recursive resolver are unable to access the
>>    IPv6-based content, despite their experience being a positive one.
>>
>>    While in Section 1 the level of IPv6-related impairment has been
>>    estimated to be as high as 0.078% of Internet users, which is a
>
>8 hundredths of one percent?
>
>That's considered a high percentage?
>
>Even if it is 8%, is that considered high?
>
>
>> 5.2.  Similarities to DNS Load Balancing
>>
>>    DNS whitelisting also has some similarities to DNS load balancing.
>>    There are of course many ways that DNS load balancing can be
>>    performed.  In one example, multiple IP address resource records (A
>>    and/or AAAA) can be added to the DNS for a given FQDN.  This approach
>>    is referred to as DNS round robin [RFC1794].  DNS round robin may
>>    also be employed where SRV resource records are used [RFC2782].
>
>Right, but that's algorithmic rather than involving the manual method,=20
>described
>here. So it does not seem comparable.
>
>
>> 6.  Likely Deployment Scenarios
>>
>>    In considering how DNS whitelisting may emerge more widely, there are
>>    two likely deployment scenarios, which are explored below.
>>
>>    In either of these deployment scenarios, it is possible that
>>    reputable third parties could create and maintain DNS whitelists, in
>>    much the same way that blacklists are used for reducing email spam.
>>    In the email context, a mail operator subscribes to one or more of
>>    these lists and as such the operational processes for additions and
>>    deletions to the list are managed by a third party.  A similar model
>>    could emerge for DNS whitelisting, whether deployment occurs
>>    universally or on an ad hoc basis.
>
>The challenges of email whitelists and blacklists should be cited, since=20
>it
>provides a rich base of experience for such an effort, at scale.
>
>
>> 6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis
>>
>>    The seemingly most likely deployment scenario is where some
>
>Most likely?  This is not already established practice?
>
>
>>    authoritative DNS server operators implement DNS whitelisting but
>>    many or most others do not do so.  What can make this scenario
>>    challenging from the standpoint of a DNS recursive resolver operator
>>    is determining which domains implement DNS whitelisting, particularly
>>    since a domain may not do so as they initially transition to IPv6,
>>    and may instead do so later.  Thus, a DNS recursive resolver operator
>>
>>
>>
>> Livingood                Expires August 26, 2011               [Page 13]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>>    may initially believe that they can receive AAAA responses as a
>>    domain adopts IPv6, but then notice via end user reports that they no
>>    longer receive AAAA responses due to that domain adopting DNS
>>    whitelisting.  Of course, a domain's IPv6 transition may be
>>    effectively invisible to recursive server operators due to the effect
>>    of DNS whitelisting.
>
>This suggests that every listing at the server needs a contact record for
>periodic checks whether to renew the listing.
>
>
>>
>>    In contrast to a universal deployment of DNS whitelisting
>>    Section 6.2, deployment on an ad hoc basis is likely to be
>>    significantly more challenging from an operational, monitoring, and
>
>Oh?  Use in small scale is more challenging than use of manual exceptions=
=20
>list
>at large scale?  That's a very unexpected view.
>
>
>>    troubleshooting standpoint.  In this scenario, a DNS recursive
>>    resolver operator will have no way to systematically determine
>>    whether DNS whitelisting is or is not implemented for a domain, since
>>    the absence of AAAA resource records may simply be indicative that
>>    the domain has not yet added IPv6 addressing for the domain, rather
>>    than that they have done so but have restricted query access via DNS
>
>The premise is that, in large scale use, servers /will/ have a way to
>systematically determine whether it is implemented?  What are the existing
>examples of having such a capability for other Internet protocols and=20
>services?
>
>
>>    whitelisting.  As a result, discovering which domains implement DNS
>>    whitelisting, in order to differentiate them from those that do not,
>>    is likely to be challenging.
>>
>>    One benefit of DNS whitelisting being deployed on an ad hoc basis is
>>    that only the domains that are interested in doing so would have to
>>    upgrade their authoritative DNS servers in order to implement the
>>    ACLs necessary to perform DNS whitelisting.
>>
>>    In this potential deployment scenario, it is also possible that a
>>    given domain will implement DNS whitelisting temporarily.  A domain,
>>    particularly a highly-trafficked domain, may choose to do so in order
>>    to ease their transition to IPv6 through a selective deployment and
>>    minimize any perceived risk in such a transition.
>>
>> 6.2.  Deploying DNS Whitelisting Universally
>>
>>    The least likely deployment scenario is one where DNS whitelisting is
>>    implemented on all authoritative DNS servers, across the entire
>>    Internet.  While this scenario seems less likely than ad hoc
>>    deployment due to some parties not sharing the concerns that have so
>>    far motivated the use of DNS whitelisting, it is nonetheless
>>    conceivable that it could be one of the ways in which DNS
>>    whitelisting is deployed.
>
>Significantly, the partial-deployment model casts this mechanism as a=20
>transition
>expedient -- as the document reasonably describes it -- whereas universal
>deployment casts it as a fundamental change to the architecture.
>
>Given that it would take decades to achieve relatively full deployment of=
=20
>this
>'across the entire Internet', what is the benefit of discussing this=20
>highly
>unlikely scenario?  Is it really "conceivable"?  I doubt it. If you think
>otherwise, the paper needs to explore the deployment and adoption issues=20
>in much
>more detail, because I don't see how it could work.
>
>
>>    In order for this deployment scenario to occur, it is likely that DNS
>>    whitelisting functionality would need to be built into all
>>    authoritative DNS server software, and that all operators of
>>    authoritative DNS servers would have to upgrade their software and
>>    enable this functionality.  It is likely that new Internet Draft
>>    documents would need to be developed which describe how to properly
>>    configure, deploy, and maintain DNS whitelisting.  As a result, it is
>>
>>
>>
>> Livingood                Expires August 26, 2011               [Page 14]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>>    unlikely that DNS whitelisting would, at least in the next several
>>    years, become universally deployed.  Furthermore, these DNS
>>    whitelists are likely to vary on a domain-by-domain basis, depending
>>    upon a variety of factors.  Such factors may include the motivation
>>    of each domain owner, the location of the DNS recursive resolvers in
>>    relation to the source content, as well as various other parameters
>>    that may be transitory in nature, or unique to a specific end user
>>    host type.  It is probably unlikely that a single clearinghouse for
>>    managing whitelisting is possible; it will more likely be unique to
>>    the source content owners and/or domains which implement DNS
>>    whitelists.
>>
>>    While this scenario may be unlikely, it may carry some benefits.
>>    First, parties performing troubleshooting would not have to determine
>>    whether or not DNS whitelisting was being used, as it always would be
>>    in use.  In addition, if universally deployed, it is possible that
>>    the criteria for being added to or removed from a DNS whitelist could
>>    be standardized across the entire Internet.  Nevertheless, even if
>>    uniform DNS whitelisting policies were not standardized, is also
>>    possible that a central registry of these policies could be developed
>>    and deployed in order to make it easier to discover them, a key part
>>    of achieving transparency regarding DNS whitelisting.
>
>Is any of this paragraph realistic?  Obviously my asking means I don't it=
=20
>is.
>These seem to be of theoretical rather than pragmatic interest.  ("If=20
>everyone
>refuses to shoot, there will be no wars.")
>
>It's true that this is an "implications" paper rather than a BCP, but=20
>still...
>
>
>>
>> 7.  Implications of DNS Whitelisting
>>
>>    There are many potential implications of DNS whitelisting.  The key
>>    potential implications are detailed below.
>>
>> 7.1.  Architectural Implications
>>
>>    DNS whitelisting could be perceived as modifying the end-to-end model
>>    and/or the general notion of the architecture that prevails on the
>
>I'll suggest that perception is not a major issue about a technical topic=
=20
>like
>this.  (It's not entirely irrelevant, of course, but I suspect it is=20
>quite minor.)
>
>The major issue is whether it /actually/ modifies the end-to-end nature=20
>of the
>DNS.  And I think it does, as well as modifying the "spontaneous
>interoperability" expectation for most Internet mechanism, since it=20
>requires
>prior registration.
>
>
>> 7.2.  Public IPv6 Address Reachability Implications
>>
>>    The predominant experience of end user hosts and servers on the IPv4-
>>    addressed Internet today is that when a new server with a public IPv4
>>    address is added to the DNS, that it is then globally accessible by
>
>This sentence is not quite correct, in strict technical terms.  Since=20
>this is a
>technical discussion, we need to be precise:  the host is reachable when=20
>the
>routing tables make it reachable.  That's strictly a mapper of IP Address
>handling, not name-to-address mapping.
>
>What you mean is that its domain name is immediately useful for reaching=20
>it.
>
>
>>    IPv4-addressed hosts.  This is a generalization and in Section 5
>>    there are examples of common cases where this may not necessarily be
>>    the case.  For the purposes of this argument, that concept of
>>    accessibility can be considered "pervasive reachability".  It has so
>>    far been assumed that the same expectations of pervasive reachability
>>    would exist in the IPv6-addressed Internet.  However, if DNS
>>    whitelisting is deployed, this will not be the case since only end
>>    user hosts using DNS recursive resolvers which are included in the
>
>again, you mean /name-based/ reachability.
>
>
>>
>>
>>
>> Livingood                Expires August 26, 2011               [Page 16]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>>    ACL of a given domain using DNS whitelisting would be able to reach
>>    new servers in that given domain via IPv6 addresses.  The expectation
>>    of any end user host being able to connect to any server (essentially
>>    both hosts, just at either end of the network), defined here as
>>    "pervasive reachability", will change to "restricted reachability"
>>    with IPv6.
>>
>>    Establishing DNS whitelisting as an accepted practice in the early
>>    phases of mass IPv6 deployment could well establish it as an integral
>>    part of how IPv6 DNS resource records are deployed globally.  As a
>>    result, it is then possible that DNS whitelisting could live on for
>>    decades on the Internet as a key foundational element of domain name
>>    management that we will all live with for a long time.
>
>(that last sentence could benefit from some editing.)
>
>
>>    It is a critical to understand that the concept of reachability
>>    described above depends upon a knowledge or awareness of an address
>>    in the DNS.  Thus, in order to establish reachability to an end
>>    point, a host is dependent upon looking up an IP address in the DNS
>
>If this section were started with a sentence like this, then there would=20
>not be
>a problem with the other references' being confused with address-based=20
>routing
>reachability.
>
>
>>    when a FQDN is used.  When DNS whitelisting is used, it is quite
>>    likely the case that an IPv6-enabled end user host could ping or
>>    connect to an example server host, even though the FQDN associated
>>    with that server host is restricted via a DNS whitelist.  Since most
>
>First, I suspect that "example" doesn't add meaning to the sentence. =20
>Second,
>pinging and connecting might happen with or without the whitelist entry. =
=20
>So I
>do not understand what import there is in this sentence.
>
>
>>    Internet applications and hosts such as web servers depend upon the
>>    DNS, and as end users connect to FQDNs such as www.example.com and do
>>    not remember or wish to type in an IP address, the notion of
>>    reachability described here should be understood to include knowledge
>>    how to associate a name with a network address.
>
>Again, this 'premise' statement should introduce the sub-section, not end=
=20
>it.
>
>
>>
>> 7.3.  Operational Implications
>>
>>    This section explores some of the operational implications which may
>>    occur as a result of, are related to, or become necessary when
>>    engaging in the practice of DNS whitelisting.
>>
>> 7.3.1.  De-Whitelisting May Occur
>
>The more general version of this issue is 'synchronization'.  Entries in=20
>the
>whitelist need to be synchronized with host status and capabilities.
>
>
>>    It is possible for a DNS recursive resolver added to a whitelist to
>>    then be removed from the whitelist, also known as de-whitelisting.
>>    Since de-whitelisting can occur, through a decision by the
>>    authoritative server operator, the domain owner, or even due to a
>>    technical error, an operator of a DNS recursive resolver will have
>>    new operational and monitoring requirements and/or needs as noted in
>>    Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5.
>>
>> 7.3.2.  Authoritative DNS Server Operational Implications
>>
>>    Operators of authoritative servers may need to maintain an ACL a
>
>a -> on a (?)
>
>
>>    server-wide basis affecting all domains, on a domain-by-domain basis,
>>
>>
>> Livingood                Expires August 26, 2011               [Page 17]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>>    as well as on a combination of the two.  As a result, operational
>
>I'm not really understanding the first sentence.  One problem might be=20
>that its
>discussing an implication of some configuration or usage options that=20
>have not
>been previously specified, so that the reference here might be overly=20
>cryptic.
>
>For example, I don't know what "affecting all domains" actually means.  It
>almost sounds as if it could mean "everyone gets AAAA records" or "no one=
=20
>gets
>AAAA records" yet I'm reaonably certain that is /not/ what is meant.
>
>
>>    practices and software capabilities may need to be developed in order
>>    to support such functionality.  In addition, processes may need to be
>>    put in place to protect against inadvertently adding or removing IP
>>    addresses, as well as systems and/or processes to respond to such
>>    incidents if and when they occur.  For example, a system may be
>>    needed to record DNS whitelisting requests, report on their status
>>    along a workflow, add IP addresses when whitelisting has been
>>    approved, remove IP addresses when they have been de-whitelisted, log
>>    the personnel involved and timing of changes, schedule changes to
>>    occur in the future, and to roll back any inadvertent changes.
>
>Might be worth starting with a simple, broad summary statement, possibly=20
>along
>the lines of:
>
>    An AAAA DNS Whitelist serves as a critical infrastructure service; to=
=20
>be
>useful it needs careful and extensive administration, monitoring and=20
>operation.
>  Each new and essential mechanism creates substantial follow-on support=20
>costs.
>
>
>>    Operators may also need implement new forms of monitoring in order to
>>    apply change control, as noted briefly in Section 7.3.4.
>>
>> 7.3.3.  DNS Recursive Resolver Server Operational Implications
>>
>>    Operators of DNS recursive resolvers, which may include ISPs,
>>    enterprises, universities, governments, individual end users, and
>>    many other parties, are likely to need to implement new forms of
>>    monitoring, as noted briefly in Section 7.3.4.  But more critically,
>>    such operators may need to add people, processes, and systems in
>>    order to manage large numbers of DNS whitelisting applications as
>>    part of their own IPv6 transition, for all domains that the end users
>>    of such servers are interested in now or in which they may be
>
>I think the summary observation is simple and should be stated directly: =
=20
>This
>is a manual mechanism that becomes expensive in time and personnel effort=
=20
>as it
>scales up.
>
>
>>    interested in the future.  As anticipation of interesting domains is
>>    likely infeasible, it is more likely that operators may either choose
>>    to only apply to be whitelisted for a domain based upon one or more
>>    end user requests, or that they will attempt to do so for all domains
>>    that they can ascertain to be engaging in DNS whitelisting.
>
>"attempt to do so for all domain that they can ascertain to be engaging=20
>in DNS
>whitelisting"  appears to be saying to do whitelisting for domains that do
>whitelisting.  I don't understand.
>
>
>>
>>    When operators apply for DNS whitelisting for all domains, that may
>
>"apply for DNS whitelisting for all domains" -- again I'm not=20
>understanding what
>this means.
>
>
>> 7.3.5.  Implications of Operational Momentum
>>
>>    It seems plausible that once DNS whitelisting is implemented it will
>>    be very difficult to deprecate such technical and operational
>>    practices.  This assumption is based in an understanding of human
>
>in -> on
>
>
>>    nature, not to mention physics.  For example, as Sir Issac Newton
>>    noted, "Every object in a state of uniform motion tends to remain in
>>    that state of motion unless an external force is applied to it" [Laws
>
>Code does not have momenum.  Neither do configurations or lists.  This=20
>really
>isn't about physics.
>
>It is entirely about group psychology, as you note, and the administrative
>challenges in the logistics of large-scale operational changes (which=20
>probably
>/does/ have something to with physics, but it seems a stretch to credit=20
>Newton.
>How about Heisenberg?...)
>
>
>>    of Motion].  Thus, once DNS whitelisting is implemented it is quite
>>    likely that it would take considerable effort to deprecate the
>>    practice and remove it everywhere on the Internet - it will otherwise
>>    simply remain in place in perpetuity.  To better illustrate this
>>    point, one could consider one example (of many) that there are many
>>    email servers continuing to attempt to query or otherwise check anti-
>>
>>
>>
>> Livingood                Expires August 26, 2011               [Page 19]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>>    spam DNS blocklists which have long ago ceased to exist.
>>
>> 7.3.6.  Troubleshooting Implications
>>
>>    The implications of DNS whitelisted present many challenges, which
>>    have been detailed in Section 7.  These challenges may negatively
>
>But this is /still/ section 7.  Can you be more specific?  Or perhaps say
>"throughout this section".
>
>
>>    affect the end users' ability to troubleshoot, as well as that of DNS
>>    recursive resolver operators, ISPs, content providers, domain owners
>>    (where they may be different from the operator of the authoritative
>>    DNS server for their domain), and other third parties.  This may make
>>    the process of determining why a server is not reachable
>>    significantly more complex.
>>
>> 7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis
>>
>>    Additional implications, should this be deployed on an ad hoc basis,
>>    could include scalability problems relating to operational processes,
>
>I'm pretty sure that scaling problems for this exist in all scenarios,=20
>not just
>ad hoc usage.
>
>
>>    monitoring, and ACL updates.  In particular, it seems likely that as
>>    the number of domains that are using DNS whitelisting increases, as
>>    well as the number of IPv6-capable networks requesting to be
>>    whitelisted, that there is an increased likelihood of configuration
>>    and other operational errors, especially with respect to the ACLs
>>    themselves.
>>
>>    It is unclear when and if it would be appropriate to change from
>>    whitelisting to blacklisting, and whether or how this could feasibly
>>    be coordinated across the Internet, which may be proposed or
>
>Actually the question of coordination is quite clear and rather=20
>fundamental:
>
>      No.
>
>Anyone believing otherwise needs to cite a successful example, at=20
>Internet scale
>and diversity, more recently than the 1983 switch to IP (which didn't go=20
>all
>that well anyhow...)
>
>Simple, unambiguous showstoppers should be stated in a simple and direct=20
>manner.
>  When there is room for debate, softer language makes sense.  Again, if=20
>the
>question of coordination really is subject to debate, then the basis=20
>needs to be
>stated.  (Good luck!)
>
>
>>    implemented on an ad hoc basis when a majority of networks (or
>>    allocated IPv6 address blocks) have been whitelisted.  Finally, some
>>    parties implementing DNS whitelisting consider this to be a temporary
>>    measure.  As such, it is not clear how these parties will judge the
>>    network conditions to have changed sufficiently to justify disabling
>>    DNS whitelisting and/or what the process and timing will be in order
>>    to discontinue this practice.
>>
>>    One further potential implication is that an end user with only an
>>    IPv4 address, using a DNS resolver which has not been whitelisted by
>>    any domains, would not be able to get any AAAA resource records.  In
>>    such a case, this could give that end user the incorrect impression
>>    that there is no IPv6-based content on the Internet since they are
>>    unable to discover any IPv6 addresses via the DNS.
>>
>> 7.4.  Homogeneity May Be Encouraged
>>
>>    A broad trend which has existed on the Internet appears to be a move
>>    towards increasing levels of heterogeneity.  One manifestation of
>
>increasing levels of heterogeneity -> more heterogeneity
>
>(I think heterogeneity does not have 'levels'.)
>
>Substantively:  say the nature of the heterogeneity within the initial=20
>claim.
>For example, there is /less/ heterogeneity of ISPs, given industry
>consolidation.  There is less heterogeneity of infrastructure equipment=20
>such as
>routers.  Etc.
>
>
>>    this is in an increasing number, variety, and customization of end
>>    user hosts, including home network, operating systems, client
>>
>>
>>
>> Livingood                Expires August 26, 2011               [Page 20]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>>    software, home network devices, and personal computing devices.  This
>>    trend appears to have had a positive effect on the development and
>>    growth of the Internet.  A key facet of this that has evolved is the
>>    ability of the end user to connect any technically compliant device
>>    or use any technically compatible software to connect to the
>>    Internet.  Not only does this trend towards greater heterogeneity
>>    reduce the control which is exerted in the middle of the network,
>>    described in positive terms in [Tussle in Cyberspace], [Rethinking
>>    the Internet], and [RFC3724], but it can also help to enable greater
>>    and more rapid innovation at the edges.
>>
>>    An unfortunate implication of the adoption of DNS whitelisting may be
>>    the encouragement of a reversal of this trend, which would be a move
>
>the encouragement of -> to encourage
>
>
>> 8.1.  Implement DNS Whitelisting Universally
>>
>>    One obvious solution is to implement DNS whitelisted universally, and
>>    to do so using some sort of centralized registry of DNS whitelisting
>>    policies, contracts, processes, or other information.  This potential
>>    solution seems unlikely at the current time.
>
>I'm pretty sure that the only thing that is obvious about a premise of=20
>universal
>adoption is that it's not practical.  Seriously.
>
>At the least, this section needs to be less cavalier about putting this
>alternative forward as a "solution", especially given the rather serious
>drawbacks/problems with it.
>
>
>> 8.2.  Implement DNS Whitelisting On An Ad Hoc Basis
>>
>>    If DNS whitelisting is to be adopted, it is likely to be adopted on
>
>"is to be"?  I thought it already had a significant installed base.
>
>
>>    this ad hoc, or domain-by-domain basis.  Therefore, only those
>>    domains interested in DNS whitelisting would need to adopt the
>>    practice, though as noted herein discovering that they a given domain
>>    has done so may be problematic.  Also in this scenario, ad hoc use by
>>    a particular domain may be a temporary measure that has been adopted
>>    to ease the transition of the domain to IPv6 over some short-term
>>    timeframe.
>>
>> 8.3.  Do Not Implement DNS Whitelisting
>>
>>    As an alternative to adopting DNS whitelisting, the Internet
>>    community generally can choose to take no action whatsoever,
>>    perpetuating the current predominant authoritative DNS operational
>>    model on the Internet, and leave it up to end users with IPv6-related
>>    impairments to discover and fix those impairments.
>>
>
>That is, place the burden of fixing a problem on those creating it?
>
>
>>
>>
>>
>>
>> Livingood                Expires August 26, 2011               [Page 23]
>> =0C
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>>
>>
>> 8.3.1.  Solving Current End User IPv6 Impairments
>>
>>    A further extension of not implementing DNS whitelisting, is to also
>>    endeavor to actually fix the underlying technical problems that have
>>    prompted the consideration of DNS whitelisting in the first place, as
>>    an alternative to trying to apply temporary workarounds to avoid the
>>    symptoms of underlying end user IPv6 impairments.  A first step is
>>    obviously to identify which users have such impairments, which would
>>    appear to be possible, and then to communicate this information to
>>    end users.  Such end user communication is likely to be most helpful
>>    if the end user is not only alerted to a potential problem but is
>>    given careful and detailed advice on how to resolve this on their
>>    own, or where they can seek help in doing so.  Section 11 may also be
>>    relevant in this case.
>>
>>    One challenge with this option is the potential difficulty of
>>    motivating members of the Internet community to work collectively
>>    towards this goal, sharing the labor, time, and costs related to such
>>    an effort.  Of course, since just such a community effort is now
>>    underway for IPv6, it is possible that this would call for only a
>>    moderate amount of additional work.
>
>This 'challenge' is at the core of /all/ adoption efforts for Internet=20
>protocols
>and services that entail distributed adoption.
>
>
>>    Despite any potential challenges, many in the Internet community are
>>    already working towards this goal and/or have expressed a general
>>    preference for this approach.
>
>If this is not already an organized effort with a website, sponsoring
>consortium, or the like, it should be.  If it is, then cite it in this=20
>doc!
>
>>
>> 8.3.2.  Gain Experience Using IPv6 Transition Names
>>
>>    Another alternative is for domains to gain experience using an FQDN
>>    which has become common for domains beginning the transition to IPv6;
>>    ipv6.example.com and www.ipv6.example.com.  This can be a way for a
>>    domain to gain IPv6 experience and increase IPv6 use on a relatively
>>    controlled basis, and to inform any plans for DNS whitelisting with
>>    experience.
>
>I do not understand what this means.
>
>What is it for?  What are the results?  How are theyused?
>
>
>> 9.  Is DNS Whitelisting a Recommended Practice?
>>
>>    Opinions in the Internet community concerning whether or not DNS
>>    whitelisting is a recommended practice are understandably quite
>>    varied.  However, there is clear consensus that DNS whitelisting is
>>    at best a useful temporary measure which a domain may choose to
>
>If that is a clear consensus, then it makes even less sense to promote=20
>the idea
>of universal adoption, given the timescale needed to achieve it.
>
>
>> 10.  Security Considerations
>>
>>    There are no particular security considerations if DNS whitelisting
>>    is not adopted, as this is how the public Internet works today with A
>>    resource records.
>
>Or rather, failure to adopt a mechanism like this or repair the underlying
>problem, for those sites experiencing that problem, will result in a=20
>denial of
>service, albeit not an intentional one.  Still, that's a pretty basic=20
>security
>issue.
>
>
>d/
>--=20
>
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www.ietf.org/mailman/listinfo/ietf
>
>
>--=20
>
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net


From jason_livingood@cable.comcast.com  Sun May 29 11:25: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 9B48BE06CF; Sun, 29 May 2011 11:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.462
X-Spam-Level: 
X-Spam-Status: No, score=-108.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 m85vPQVStaK5; Sun, 29 May 2011 11:25:02 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 41DE9E0681; Sun, 29 May 2011 11:25:02 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.127898619; Sun, 29 May 2011 14:24:53 -0400
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; Sun, 29 May 2011 14:24:53 -0400
From: "Livingood, Jason" 
To: Dave Crocker , IETF Discussion 
Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
Thread-Index: AQHMBsW3LiUPFMmWEU6SoHUAcEeS2ZSkTdkA
Date: Sun, 29 May 2011 18:24:53 +0000
Message-ID: 
In-Reply-To: <4DBB4A83.7010408@dcrocker.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [69.141.126.196]
Content-Type: multipart/alternative; boundary="_000_CA08012028910jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 May 2011 18:25:04 -0000

--_000_CA08012028910jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thank you for your thorough review, Dave. Changes will be made in an upcomi=
ng =9604 revision. Some more specific comments can be found inline below.

Thanks!
JL

PS =96 I have at least one other email from you in my queue for this I-D =
=96 I've not forgotten about it. :-)

On 4/29/11 7:32 PM, "Dave CROCKER" > wrote:


Review:

Title:  IPv6 AAAA DNS Whitelisting Implications
I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

By:     D. Crocker >
Date:   29 April 2011


Summary:

This draft is a discussion of a technique for resolving a dual-stack proble=
m
between IPv4 and IPv6, through the use of special DNS records.

The document appears to continue a recent use of the term 'whitelisting' th=
at
strongly conflicts with long-standing use of the term by the anti-abuse com=
munity.

The document needs to do a more careful job of introducing the problem it i=
s
solving and the explaining the way the 'whitelisting' mechanism works.

I also very strongly encourage finding a different term.

[JL] There's been a great deal of discussion on the mailing list about this=
. While it appears the consensus is to leave it as-is, your point is well n=
oted and I have listed this in the Open Items list of the =9604 draft and w=
ill be consulting with the WG chairs for direction on the matter.


d/


Abstract

    The objective of this document is to describe what the whitelisting
    of DNS AAAA resource records is, hereafter referred to as DNS

RRs are whitelisted?  Isn't it the addresses and not the records that are
whitelisted?

Does this mean putting whitelisting records into the DNS or does it mean
something else?

[JL] You are quite correct. Another reviewer also noted my error in this se=
ntence and it is corrected in the =9604 version.

Comcast's own considerable expertise notwithstanding, has this doc been vet=
ted
with a range of organizations that actually DO whitelisting?

[JL] Folks from organizations that perform or are considering IPv6 DNS whit=
elisting have provided feedback on the draft, which has been incorporated i=
nto previous versions. Additional feedback has been shared which will be in=
 the =9604 revision.

Has it been
circulated through MAAWG and APWG?  Any comments from Spamhaus?  The
Acknowledgements list does not seem to indicate a range of whitelist ops fo=
lks
whose names I know.  (But then, I only know a few...)

[JL] It has not specifically been sent to groups like MAAWG, as I think thi=
s form of DNS server-related whitelisting is different from mail server whi=
telisting. I can certainly do so, but I'm not sure those groups will be int=
erested as it is not particularly anti-abuse related.

    whitelisting, as well as the implications of this emerging practice
    and what alternatives may exist.  The audience for this document is
    the Internet community generally, including the IETF and IPv6
    implementers.

I suspect that product marketers won't have much interest in this.  I suspe=
ct
that the target for this is anti-abuse technical and operations staff.

[JL] You are doing a good job illustrating the confusion over the use of th=
e term 'whitelisting'. ;-) The target is actually not A/A tech and ops pers=
onnel, since the draft is specifically related to the IPv6 transition and n=
ot A/A or even messaging.



1.  Introduction

    This document describes the emerging practice of whitelisting of DNS
    AAAA resource records (RRs), which contain IPv6 addresses, hereafter
    referred to as DNS whitelisting.  The document explores the
    implications of this emerging practice are and what alternatives may
    exist.

    The practice of DNS whitelisting appears to have first been used by
    major web content sites (sometimes described herein as "highly-

Really?  Not for email first?

[JL] You now get a +2 for further illustrating the potential for confusion =
over the terms. ;-) But I'm referring specifically to this (which is how th=
e updated =9604 text reads):
"whitelisting of DNS recursive resolvers in order to limit AAAA resource re=
cords responses"

    trafficked domains" or "major domains").  These web site operators,
    or domain operators, observed that when they added AAAA resource
    records to their authoritative DNS servers in order to support IPv6

Oh.  You mean /IPv6/ whitelisting.

    access to their content that a small fraction of end users had slow
    or otherwise impaired access to a given web site with both AAAA and A
    resource records.  The fraction of users with such impaired access
    has been estimated to be roughly 0.078% of total Internet users
    [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
    Brokenness].  Thus, in an example Internet Service Provider (ISP)
    network of 10 million users, approximately 7,800 of those users may
    experience such impaired access.

At a minimum, these sorts of statistics need to be normalized across IPv6
users/traffic, given how small a percentage that is in total users and tota=
l
traffice.  If that's what is meant it should be stated.  If it isn't, the
statistic should be recalculated.

[JL] Not sure what you mean=85 I'm simply citing a statistic shared by a ma=
jor website, which appears to be based on a very large set of users from ar=
ound the world (from many networks). I agree it is a small percentage (and =
it appears to be shrinking =97 to be confirmed on World IPv6 Day). One of t=
he reactions to the practice is often that it is a lot to go through for su=
ch a small percentage of users. Of course, it is now also apparent that the=
 =9603 did not adequately summarize all of the motivations for the practice=
 and so the =9604 update will list some additional ones relating to the des=
ire to incrementally add IPv6 traffic, gradually mature IPv6 routes and ope=
rational procedures, etc. So it is my hope that a fuller picture of the mot=
ivations will emerge in the =9604 update.

    As a result of this impairment affecting end users of a given domain,
    a few major domains have either implemented DNS whitelisting or are
    considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].

How or why does whitelisting affect slow performance for these folk?

[JL] If an end user has an IPv6-related impairment, they may only have an I=
Pv4 address but the mere fact of seeing a AAAA RR response will cause them =
to have no access or very slow access (waiting through various client timeo=
uts, which most users will not do) to the FQDN that had a AAAA RR. So in su=
ch cases, whitelisting is used so that these impaired users never see the A=
AAA RR in the response.

    When implemented, DNS whitelisting in practice means that a domain's
    authoritative DNS will return a AAAA resource record to DNS recursive
    resolvers [RFC1035] on the whitelist, while returning no AAAA
    resource records to DNS resolvers which are not on the whitelist.  It

Oh.  The whitelisting is for resolving a conflict between AAAA and A record=
 choices?

Normally, the term 'whitelisting' is used to refer to bypass anti-abuse
mechanisms.  This appears to be for something else and it seems odd to call=
 it
whitelisting.

[JL] You are now up to a +3 on illustrating this point. ;-) I'm going to st=
op counting now, because you are getting too good it it. In all seriousness=
, I have recorded this as one of the main open issues to be sorted out on t=
he draft with the WG chairs. (And as you know I'm quite familiar with it's =
usage in the email area.)  :-)


Note the more typical use of the term:

    

    



It appears that some v6 folks have chosen to co-opt a distinctive and very =
well
established anti-abuse term for an entirely different purpose.

[JL] BTW, don't shoot the messenger! ;-) I'm just documenting what's the cu=
rrent term being used.

    is important to note that these major domains are motivated by a
    desire to maintain a high-quality user experience for all of their
    users.  By engaging in DNS whitelisting, they are attempting to
    shield users with impaired access from the symptoms of those
    impairments.

    Critics of the practice of DNS whitelisting have articulated several
    concerns.  Among these are that:

    o  DNS whitelisting is a very different behavior from the current
       practice concerning the publishing of IPv4 address resource
       records,

    o  that it may create a two-tiered Internet,

    o  that policies concerning whitelisting and de-whitelisting are
       opaque,





Livingood                Expires August 26, 2011                [Page 5]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    o  that DNS whitelisting reduces interest in the deployment of IPv6,

Well, it certainly suggests that there is a problem handling v4/v6 in dual =
stack
environments cleanly.  And it certainly seems that dealing with the underly=
ing
problem would be better.

Beyond that, this appears to be a hack that is useful but not scalable.

[JL] I believe even the implementers agree with you there. I think it was V=
int to may have called this useful "temporary scaffolding" but conceded tha=
t it really doesn't scale over the long-term.




    o  that new operational and management burdens are created,

well, yeah...


    o  and that the costs and negative implications of DNS whitelisting
       outweigh the perceived benefits, compared to fixing underlying
       impairments.

    This document explores the reasons and motivations for DNS
    whitelisting.  It also explores the outlined concerns regarding this
    practice.  Readers will hopefully better understand what DNS
    whitelisting is, why some parties are implementing it, and what
    criticisms of the practice exist.



--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


--_000_CA08012028910jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <8072E79D71FBF74EA7619C68455B0F73@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable









Thank you for your thorough review, Dave. Changes will be made in an u=
pcoming =9604 revision. Some more specific comments can be found inline bel=
ow. 









Thanks!


JL







PS =96 I have at least one other email from you in my queue for this I=
-D =96 I've not forgotten about it. :-)







On 4/29/11 7:32 PM, "Dave CROCKER" <dhc@dcrocker.net> wrote:














Review:







Title:  IPv6 AAAA DNS Whitelisting Implications


I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-impl=
ications-03







By:     D. Crocker <dcrocker@bbiw.net>


Date:   29 April 2011












Summary:







This draft is a discussion of a technique for resolving a dual-stack p=
roblem



between IPv4 and IPv6, through the use of special DNS records.







The document appears to continue a recent use of the term 'whitelistin=
g' that



strongly conflicts with long-standing use of the term by the anti-abus=
e community.







The document needs to do a more careful job of introducing the problem=
 it is



solving and the explaining the way the 'whitelisting' mechanism works.=








I also very strongly encourage finding a different term.









[JL] There's been a great deal of discussion on the mailing list about=
 this. While it appears the consensus is to leave it as-is, your point is w=
ell noted and I have listed this in the Open Items list of the =9604 draft =
and will be consulting with the WG
 chairs for direction on the matter.














d/














Abstract







    The objective of this document is to describe =
what the whitelisting


    of DNS AAAA resource records is, hereafter ref=
erred to as DNS









RRs are whitelisted?  Isn't it the addresses and not the rec=
ords that are 


whitelisted?







Does this mean putting whitelisting records into the DNS or does it me=
an 


something else?









[JL] You are quite correct. Another reviewer also noted my error in th=
is sentence and it is corrected in the =9604 version.









Comcast's own considerable expertise notwithstanding, has this doc bee=
n vetted


with a range of organizations that actually DO whitelisting? &nbs=
p;









[JL] Folks from organizations that perform or are considering IPv6 DNS=
 whitelisting have provided feedback on the draft, which has been incorpora=
ted into previous versions. Additional feedback has been shared which will =
be in the =9604 revision.









Has it been 


circulated through MAAWG and APWG?  Any comments from Spamha=
us?  The 


Acknowledgements list does not seem to indicate a range of whitelist o=
ps folks



whose names I know.  (But then, I only know a few...)









[JL] It has not specifically been sent to groups like MAAWG, as I thin=
k this form of DNS server-related whitelisting is different from mail serve=
r whitelisting. I can certainly do so, but I'm not sure those groups will b=
e interested as it is not particularly
 anti-abuse related. 











    whitelisting, as well as the implications of t=
his emerging practice


    and what alternatives may exist.  Th=
e audience for this document is


    the Internet community generally, including th=
e IETF and IPv6


    implementers.









I suspect that product marketers won't have much interest in this.&nbs=
p; I suspect



that the target for this is anti-abuse technical and operations staff.=










[JL] You are doing a good job illustrating the confusion over the use =
of the term 'whitelisting'. ;-) The target is actually not A/A tech and ops=
 personnel, since the draft is specifically related to the IPv6 transition =
and not A/A or even messaging.







<snip>











1.  Introduction







    This document describes the emerging practice =
of whitelisting of DNS


    AAAA resource records (RRs), which contain IPv=
6 addresses, hereafter


    referred to as DNS whitelisting.  Th=
e document explores the


    implications of this emerging practice are and=
 what alternatives may


    exist.







    The practice of DNS whitelisting appears to ha=
ve first been used by


    major web content sites (sometimes described h=
erein as "highly-









Really?  Not for email first?









[JL] You now get a +2 for further illustrating the potential for c=
onfusion over the terms. ;-) But I'm referring specifically to this (which =
is how the updated =9604 text reads): 


"whitelisting of DNS recursive resolvers in order to limit AAA=
A resource records responses"











    trafficked domains" or "major domains&quo=
t;).  These web site operators,


    or domain operators, observed that when they a=
dded AAAA resource


    records to their authoritative DNS servers in =
order to support IPv6









Oh.  You mean /IPv6/ whitelisting.









    access to their content that a small fraction =
of end users had slow


    or otherwise impaired access to a given web si=
te with both AAAA and A


    resource records.  The fraction of u=
sers with such impaired access


    has been estimated to be roughly 0.078% of tot=
al Internet users


    [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating=
 IPv6 Adoption] [IPv6


    Brokenness].  Thus, in an example In=
ternet Service Provider (ISP)


    network of 10 million users, approximately 7,8=
00 of those users may


    experience such impaired access.









At a minimum, these sorts of statistics need to be normalized across I=
Pv6 


users/traffic, given how small a percentage that is in total users and=
 total



traffice.  If that's what is meant it should be stated. =
; If it isn't, the 


statistic should be recalculated.









[JL] Not sure what you mean=85 I'm simply citing a statistic shared by=
 a major website, which appears to be based on a very large set of users fr=
om around the world (from many networks). I agree it is a small percentage =
(and it appears to be shrinking =97
 to be confirmed on World IPv6 Day). One of the reactions to the practice i=
s often that it is a lot to go through for such a small percentage of users=
. Of course, it is now also apparent that the =9603 did not adequately summ=
arize
all of the motivations for the practice and so the =9604 update will=
 list some additional ones relating to the desire to incrementally add IPv6=
 traffic, gradually mature IPv6 routes and operational procedures, etc. So =
it is my hope that a fuller picture
 of the motivations will emerge in the =9604 update.











    As a result of this impairment affecting end u=
sers of a given domain,


    a few major domains have either implemented DN=
S whitelisting or are


    considering doing so [NW-Article-DNS-WL] [IPv6=
 Whitelist Operations].









How or why does whitelisting affect slow performance for these folk?








[JL] If an end user has an IPv6-related impairment, they may only have=
 an IPv4 address but the mere fact of seeing a AAAA RR response will cause =
them to have no access or very slow access (waiting through various client =
timeouts, which most users will
 not do) to the FQDN that had a AAAA RR. So in such cases, whitelisting is =
used so that these impaired users never see the AAAA RR in the response.&nb=
sp;











    When implemented, DNS whitelisting in practice mean=
s that a domain's


    authoritative DNS will return a AAAA resource =
record to DNS recursive


    resolvers [RFC1035] on the whitelist, while re=
turning no AAAA


    resource records to DNS resolvers which are no=
t on the whitelist.  It









Oh.  The whitelisting is for resolving a conflict between AA=
AA and A record choices?











Normally, the term 'whitelisting' is used to refer to bypass anti-abus=
e 


mechanisms.  This appears to be for something else and it se=
ems odd to call it



whitelisting.









[JL] You are now up to a +3 on illustrating this point. ;-) I'm go=
ing to stop counting now, because you are getting too good it it. In all se=
riousness, I have recorded this as one of the main open issues to be sorted=
 out on the draft with the WG chairs.
 (And as you know I'm quite familiar with it's usage in the email area.) &n=
bsp;:-)














Note the more typical use of the term:



























It appears that some v6 folks have chosen to co-opt a distinctive and =
very well



established anti-abuse term for an entirely different purpose.









[JL] BTW, don't shoot the messenger! ;-) I'm just documenting what's t=
he current term being used.  











    is important to note that these major domains are m=
otivated by a


    desire to maintain a high-quality user experie=
nce for all of their


    users.  By engaging in DNS whitelist=
ing, they are attempting to


    shield users with impaired access from the sym=
ptoms of those


    impairments.







    Critics of the practice of DNS whitelisting ha=
ve articulated several


    concerns.  Among these are that:






    o  DNS whitelisting is a very differ=
ent behavior from the current


       practice concerning the publishin=
g of IPv4 address resource


       records,







    o  that it may create a two-tiered I=
nternet,







    o  that policies concerning whitelis=
ting and de-whitelisting are


       opaque,



























Livingood          &=
nbsp;     Expires August 26, 2011   =
;            &n=
bsp;[Page 5]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












    o  that DNS whitelisting reduces int=
erest in the deployment of IPv6,









Well, it certainly suggests that there is a problem handling v4/v6 in =
dual stack



environments cleanly.  And it certainly seems that dealing w=
ith the underlying



problem would be better.







Beyond that, this appears to be a hack that is useful but not scalable=
.









[JL] I believe even the implementers agree with you there. I think it =
was Vint to may have called this useful "temporary scaffolding" b=
ut conceded that it really doesn't scale over the long-term. 


























    o  that new operational and manageme=
nt burdens are created,









well, yeah...














    o  and that the costs and negative i=
mplications of DNS whitelisting


       outweigh the perceived benefits, =
compared to fixing underlying


       impairments.







    This document explores the reasons and motivat=
ions for DNS


    whitelisting.  It also explores the =
outlined concerns regarding this


    practice.  Readers will hopefully be=
tter understand what DNS


    whitelisting is, why some parties are implemen=
ting it, and what


    criticisms of the practice exist.



















-- 







   Dave Crocker


   Brandenburg InternetWorking


   bbiw.net











--_000_CA08012028910jasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Sun May 29 11: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 C9F17E0681; Sun, 29 May 2011 11:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.431
X-Spam-Level: 
X-Spam-Status: No, score=-108.431 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 HPtPoPvcCJ96; Sun, 29 May 2011 11:39:20 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 60124E0679; Sun, 29 May 2011 11:39:20 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.127903203; Sun, 29 May 2011 14:39:16 -0400
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; Sun, 29 May 2011 14:39:16 -0400
From: "Livingood, Jason" 
To: John Leslie 
Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
Thread-Index: AQHMCOv6mKPvFhmqvkGMTGM1myPoTpR54w2AgACT4YCAKdacgA==
Date: Sun, 29 May 2011 18:39:15 +0000
Message-ID: 
In-Reply-To: <20110502234421.GX10460@verdi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [24.40.55.70]
Content-Type: multipart/alternative; boundary="_000_CA0807E12894Djasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , IETF Discussion 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 May 2011 18:39:21 -0000

--_000_CA0807E12894Djasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi John - Thanks for the detailed review. I'm planning a -04 update soon, F=
WIW.

Specific responses inline below.

Thx,
Jason


On 5/2/11 7:44 PM, "John Leslie" > wrote:

Livingood, Jason > wrote:
To: John Leslie >...
As I read it, this says that certain DNS servers will be configured
to _not_ return AAAA records to AAAA queries by default.
This strikes me as a really-strange transition mechanism.
Depends on a number of factors for a content provider.

   Actually, no -- none of these factors make me feel it's any less than
_REALLY_ strange.

The more traffic a domain receives the more likely they are to consider
this practice as a transition mechanism from what I have observed.

   "Transition mechanism" is really-close to an oxymoron.

This practice can give a large domain some level of control in turning
on IPv6 access to their content, whereas they would lack this since
they would turn it on for everyone when publishing the AAAA RR in the
DNS.

   It doesn't give nearly as much control as they seem to think it does.
This blocks AAAA records, not based on the host interested in using them,
but based on some feature (IP address?) of the intermediate DNS resolver.

[JL] Quite so, and many in the WG feel it is difficult to use the resolver =
as a proxy for end use host IPv6-related impairment. Nevertheless, implemen=
ters feel it is good enough and the best available mechanism, and works rel=
iably enough for their (temporary) use.

It's traditional to configure hosts to use two (or more) DNS resolvers
to mimimize the delays and disruptions.

   It will be very common for an end-host to alternate AAAA-requests
between one resolver which happens to be AAAA-blocked and another which
happens to be "whitelisted". I cringe in fear of taking the support
calls from such customers.

[JL] You and me both!!  ;-)

Once a comfort level and operational stability is achieved I would
expect most domains to move away from the practice, but that is TBD.

   I would expect a painful number of domains to forget it's there. :^(

[JL] Fair enough =96 which is why the 'risk of operational momentum' has be=
en noted in the I-D. I don't know if it'll happen with this practice, but i=
t would not be the first time that a temporary mechanism becomes a foundati=
onal one.

Certainly what happens on World IPv6 Day will bear on this question
in important ways (when AAAA RRs are published without the use of
DNS whitelisting).

   I predict a majority will turn off AAAA records for their regular
www.example.com on WorldIPv6Day+1.

[JL] To some extent this is expected =97 everyone will want to do some data=
 analysis afterwards before they make a decision on what to do next. But ce=
rtainly Heise Online (as cited in the I-D) and others feel the risk was low=
 enough on their domains to go ahead and publish a AAAA RR. Every domain wi=
ll be different and make the decision on their own.

   But that's OK: there are other ways to make progress.

   And the pressure should probably be applied to browser-software writers,
so that when an end-user finds himself IPv6-impaired, he can simply shift
to a different browser,

    Color me thoroghly confused.
Hopefully that's more over the practice than the document;

   Indeed, I _am_ more confused by the practice than the document.

   But the document is confusing enough! What does it encourage me to
_do_?

[JL] Suggest I simplify the document, I'm sure. ;-) I've made some effort t=
o do this for the =9604 version based on all the feedback on =9603. I'm als=
o planning a top-to-bottom simplification after the =9604.  So, point well-=
taken.    :-)


if you wish to see improvements in the I-D just say so.

   Personally, I wish you'd do a nearly-global

s/DNS whitelisting/AAAA-blocking/

   It's a much more descriptive term.

[JL] The naming of the practice is noted as an Open Item in the draft, so I=
'll be discussing that with the WG chairs.

   Also, I'd appreciate less of "this solve a transition problem" and
more of "this doesn't even do what the folks seem to think it does".

   It's arguably reasonable to AAAA-block to DNS resolvers whose
managers ask for it; but it's not at all reasonable to AAAA-block by
default. IMHO, it would be better to tell folks that ask you to
AAAA-block to switch to resolver software that can AAAA-block to
certain end-users. After all, the problem _isn't_ localized on the
DNS resolver.

   And the document does nothing to help me figure out what to do to
enable a venturesome customer to _use_ IPv6 to a site that turns on
this AAAA-blocking!

   :^( :^(

[JL] All good feedback =96 thanks!

Jason




--
John Leslie >


--_000_CA0807E12894Djasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable









Hi John - Thanks for the detailed review. I'm planning a -04 update so=
on, FWIW. 







Specific responses inline below.







Thx,


Jason














On 5/2/11 7:44 PM, "John Leslie" <john@jlc.net> wrote:









Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:




To: John Leslie <john@jlc.net&g=
t;...




As I read it, this says that certain DNS servers will be configured

to _not_ return AAAA records to AAAA queries by default.




This strikes me as a really-strange transition mechanism.




Depends on a number of factors for a content provider.









   Actually, no -- none of these factors make me feel it's a=
ny less than


_REALLY_ strange.









The more traffic a domain receives the more likely they are to conside=
r


this practice as a transition mechanism from what I have observed.








   "Transition mechanism" is really-close to an ox=
ymoron.









This practice can give a large domain some level of control in turning=



on IPv6 access to their content, whereas they would lack this since

they would turn it on for everyone when publishing the AAAA RR in the<=
/div>

DNS.









   It doesn't give nearly as much control as they seem to th=
ink it does.


This blocks AAAA records, not based on the host interested in using th=
em,


but based on some feature (IP address?) of the intermediate DNS resolv=
er.









[JL] Quite so, and many in the WG feel it is difficult to use the reso=
lver as a proxy for end use host IPv6-related impairment. Nevertheless, imp=
lementers feel it is good enough and the best available mechanism, and work=
s reliably enough for their (temporary)
 use. 









It's traditional to configure hosts to use two (or more) DNS resolvers=



to mimimize the delays and disruptions.







   It will be very common for an end-host to alternate AAAA-=
requests


between one resolver which happens to be AAAA-blocked and another whic=
h


happens to be "whitelisted". I cringe in fear of taking the =
support


calls from such customers.









[JL] You and me both!!  ;-)











Once a comfort level and operational stability is achieved I would

expect most domains to move away from the practice, but that is TBD.








   I would expect a painful number of domains to forget it's=
 there. :^(









[JL] Fair enough =96 which is why the 'risk of operational momentum' h=
as been noted in the I-D. I don't know if it'll happen with this practice, =
but it would not be the first time that a temporary mechanism becomes a fou=
ndational one.











Certainly what happens on World IPv6 Day will bear on this question

in important ways (when AAAA RRs are published without the use of

DNS whitelisting).









   I predict a majority will turn off AAAA records for their=
 regular


www.example.com on WorldIPv6Day+1.









[JL] To some extent this is expected =97 everyone will want to do some=
 data analysis afterwards before they make a decision on what to do next. B=
ut certainly Heise Online (as cited in the I-D) and others feel the risk wa=
s low enough on their domains to go
 ahead and publish a AAAA RR. Every domain will be different and make the d=
ecision on their own.









   But that's OK: there are other ways to make progress.






   And the pressure should probably be applied to browser-so=
ftware writers,


so that when an end-user finds himself IPv6-impaired, he can simply sh=
ift


to a different browser,









    Color me thoroghly confused.




Hopefully that's more over the practice than the document;









   Indeed, I _am_ more confused by the practice than the doc=
ument.







   But the document is confusing enough! What does it encour=
age me to


_do_?









[JL] Suggest I simplify the document, I'm sure. ;-) I've made some eff=
ort to do this for the =9604 version based on all the feedback on =9603. I'=
m also planning a top-to-bottom simplification after the =9604.  So, p=
oint well-taken.    :-) 
















if you wish to see improvements in the I-D just say so.









   Personally, I wish you'd do a nearly-global







s/DNS whitelisting/AAAA-blocking/







   It's a much more descriptive term.









[JL] The naming of the practice is noted as an Open Item in the draft,=
 so I'll be discussing that with the WG chairs.









   Also, I'd appreciate less of "this solve a transitio=
n problem" and


more of "this doesn't even do what the folks seem to think it doe=
s".







   It's arguably reasonable to AAAA-block to DNS resolvers w=
hose


managers ask for it; but it's not at all reasonable to AAAA-block by

default. IMHO, it would be better to tell folks that ask you to


AAAA-block to switch to resolver software that can AAAA-block to


certain end-users. After all, the problem _isn't_ localized on the

DNS resolver.







   And the document does nothing to help me figure out what =
to do to


enable a venturesome customer to _use_ IPv6 to a site that turns on

this AAAA-blocking!







   :^( :^(









[JL] All good feedback =96 thanks!







Jason
























--


John Leslie <john@jlc.net>










--_000_CA0807E12894Djasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Sun May 29 11: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 79904E0736; Sun, 29 May 2011 11:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.436
X-Spam-Level: 
X-Spam-Status: No, score=-108.436 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 C8GHfs7PSXCH; Sun, 29 May 2011 11:44:26 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9A93EE0679; Sun, 29 May 2011 11:44:25 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.127904555; Sun, 29 May 2011 14:44:22 -0400
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; Sun, 29 May 2011 14:44:21 -0400
From: "Livingood, Jason" 
To: Russ Mundy , "secdir@ietf.org" 
Thread-Topic: secdir review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
Thread-Index: AQHMCTn9fR3di036FkigKoxmcb9XeZSkTl2A
Date: Sun, 29 May 2011 18:44:21 +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.10.0.110310
x-originating-ip: [24.40.55.70]
Content-Type: multipart/alternative; boundary="_000_CA080B2E28969jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-v6-aaaa-whitelisting-implications.all@tools.ietf.org" , "iesg@ietf.org" 
Subject: Re: [v6ops] secdir review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 May 2011 18:44:27 -0000

--_000_CA080B2E28969jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks for your review, Russ. I'll be posting an updated =9604 revision soo=
n, once I make it through all the bits of other feedback in my queue. Some =
specific responses are inline below.

Thank you!
JL

On 5/2/11 3:58 PM, "Russ Mundy" > wrote:


I have reviewed this document as part of the security directorate's ongoing=
 effort to review all IETF documents being processed by the IESG.  These co=
mments were written primarily for the benefit of the security area director=
s. Document editors and WG chairs should treat these comments just like any=
 other last call comments.

I found the document to be well written as well as providing sound technica=
l descriptions of the topic of DNS Whitelisting.

>From a security review perspective, I do have a suggestion for section 10 S=
ecurity Considerations.  The section infers (at least to me) that there is =
something different or unique for configuring DNS Whitelist configuration p=
rotection from other configuration settings for name servers.  Unless I've =
misunderstood how servers actually implement whitelisting, it uses the same=
 configuration mechanisms and files as any other name server ACL or many ot=
her name server configuration settings - _all_ the configuration settings f=
or a name server should be protected so that only authorized individuals ca=
n change them.  Modifying the wording to say something to the effect of "Ju=
st as all configuration settings for name servers should be protected by ap=
propriate procedures and systems ..."

[JL] Great suggestion =97 and that has been added to the upcoming update.



Russ Mundy




--_000_CA080B2E28969jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <879C5D45CCCA6D44B1EA095AED59746F@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable









Thanks for your review, Russ. I'll be posting an updated =9604 revisio=
n soon, once I make it through all the bits of other feedback in my queue. =
Some specific responses are inline below.







Thank you!


JL









On 5/2/11 3:58 PM, "Russ Mundy" <mundy@tislabs.com> wrote:














I have reviewed this document as part of the security directorate's on=
going effort to review all IETF documents being processed by the IESG. =
; These comments were written primarily for the benefit of the securit=
y area directors. Document editors and WG
 chairs should treat these comments just like any other last call comments.=








I found the document to be well written as well as providing sound tec=
hnical descriptions of the topic of DNS Whitelisting.  







From a security review perspective, I do have a suggestion for section=
 10 Security Considerations.  The section infers (at least to me)=
 that there is something different or unique for configuring DNS Whitelist =
configuration protection from other configuration
 settings for name servers.  Unless I've misunderstood how server=
s actually implement whitelisting, it uses the same configuration mechanism=
s and files as any other name server ACL or many other name server configur=
ation settings - _all_ the configuration settings
 for a name server should be protected so that only authorized individuals =
can change them.  Modifying the wording to say something to the e=
ffect of "Just as all configuration settings for name servers should b=
e protected by appropriate procedures and systems
 ..."









[JL] Great suggestion =97 and that has been added to the upcoming upda=
te. 



















Russ Mundy





















--_000_CA080B2E28969jasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Sun May 29 11: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 E10D6E0679; Sun, 29 May 2011 11:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.14
X-Spam-Level: 
X-Spam-Status: No, score=-108.14 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 OeTF20mCzEK6; Sun, 29 May 2011 11:58:19 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4AAE0655; Sun, 29 May 2011 11:58:18 -0700 (PDT)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.127908696; Sun, 29 May 2011 14:58:17 -0400
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; Sun, 29 May 2011 14:58:17 -0400
From: "Livingood, Jason" 
To: SM 
Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
Thread-Index: AQHMHjJYFGTxfxCN70iOl1y/SIOLQw==
Date: Sun, 29 May 2011 18:58:15 +0000
Message-ID: 
In-Reply-To: <6.2.5.6.2.20110502215922.05513e20@resistor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [24.40.55.70]
Content-Type: multipart/alternative; boundary="_000_CA080C7728976jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , IETF Discussion 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 May 2011 18:58:21 -0000

--_000_CA080C7728976jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi =96 Thanks for the feedback and see a few selected responses inline belo=
w. A =9604 update is coming soon.

Thanks
JL

On 5/3/11 4:43 AM, "SM" > wrote:

Hi Jason,
At 11:48 02-05-2011, Livingood, Jason wrote:
In any of the various IPv6 fora (including v6ops at the IETF) "DNS
Whitelisting" is how this practice is typically labeled. When writing the
draft I felt this could be confusing outside of IPv6 circles and so
lengthened it to "IPv6 DNS AAAA Whitelisting" in the title.

In any case, "I don't like what it is called" is difficult to act on. ;-)
If there are recommendations on alternatives, I'm all ears.

Repurposing a sentence from the
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03:

   "By engaging in a DNS tradeoff, they are attempting to
    shield users with impaired access from the symptoms of those
    impairments."

Web content providers use a DNS tradeoff to avoid losing quality and
money as most ISPs are reluctant to pour money into IPv6.  At least
Comcast has a plan to provide each of their users with
18,446,744,073,709,551,616 IPv6 addresses.

[JL] What has become more apparent since the =9603 draft is that it is not =
just about the impairment level. Even (or perhaps especially) if every ISP =
was 100% dual stack, some large domains would still want or need a mechanis=
m to incrementally control the addition of IPv6 traffic to their domain. I =
have tried to add some new text to the =9604 update to better explain this =
on behalf of implementers or potential implementers.

Given that draft-ietf-v6ops-v6-aaaa-whitelisting-implications has
been reviewed by DNSOP and v6ops, and that the intended status is
Informational, it is difficult to give it a "DNP".  RFC 3901 mentions
"Policy Based Avoidance of Name Space Fragmentation".  The DNS
technique used in the draft (split-view) contributes to name space
fragmentation.

If you wanted to argue for "DNP", you could have the following text
from the v6ops Charter at the bottom of the list:

  "IPv6 operational and deployment issues with specific protocols or
   technologies (such as Applications, Transport Protocols, Routing
   Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
   the groups or areas responsible for those protocols or technologies.
   However, the v6ops WG may provide input to those areas/groups, as
   needed, and cooperate with those areas/groups in reviewing solutions
   to IPv6 operational and deployment problems."

If you want to argue against "DNP", you can always say that you are
merely documenting the stupid things people have to do get IPv6 deployed.

I am stupid but I am not that stupid to go and argue about a draft
that has been blessed by DNSOP and v6ops.  :-)  Andrew Sullivan
mentioned WCP [1].  That RFC sub-series does not exist yet.  The best
fit is FYI.

[JL] Yup.

As a comment that will not be considered as part of the Last Call, I
would have given the draft a DNP if I had to review it.  I don't have
to say that as the draft already got a five DISCUSS rating.  That
won't prevent a well-known search engine from deploying the mechanism
described in this draft.  Someone might come to me and say that
"well-known search does this, why can't you do it; it's even a
RFC".  I'll read the Mathematical Principles of Natural Philosophy to
see whether I can find an answer to that. :-)

[JL] I came at this from the perspective of someone who had a bad experienc=
e with whitelisting and was extremely concerned by all of the implications =
if it became a long-standing practice (see an early document here, http://w=
ww.comcast6.net/IPv6_DNS_Whitelisting_Concerns_20100416.pdf). As a WG docum=
ent the consensus was to make sure that the motivations were documented, as=
 well as the potential implications.  In my personal opinion, I can underst=
and why some domains may choose to adopt the practice and I may do the same=
 in their situation. At the same time, I hope as few domains as possible do=
 this and that it is as short-lived as possible. Then again, if the Interne=
t crashes and burns on World IPv6 Day, then who knows what will happen.

On an unrelated note, there was a mistake in the message I posted
previously [2].  The last sentence should be read as:

  As I do not meet the religious requirements, I cannot take a
position on this draft.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg66311.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg66203.html



--_000_CA080C7728976jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <3108CE0C1C705945A4C9CFD5C4FD6CD4@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable









Hi =96 Thanks for the feedback and see a few selected responses inline=
 below. A =9604 update is coming soon.









Thanks


JL







On 5/3/11 4:43 AM, "SM" <sm@resistor.net> wrote:









Hi Jason,


At 11:48 02-05-2011, Livingood, Jason wrote:




In any of the various IPv6 fora (including v6ops at the IETF) "DN=
S


Whitelisting" is how this practice is typically labeled. When wri=
ting the


draft I felt this could be confusing outside of IPv6 circles and so

lengthened it to "IPv6 DNS AAAA Whitelisting" in the title.<=
/div>






In any case, "I don't like what it is called" is difficult t=
o act on. ;-)


If there are recommendations on alternatives, I'm all ears.









Repurposing a sentence from the 


draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03:







   "By engaging in a DNS tradeoff, they are attempting =
to


    shield users with impaired access from the sym=
ptoms of those


    impairments."







Web content providers use a DNS tradeoff to avoid losing quality and <=
/div>

money as most ISPs are reluctant to pour money into IPv6.  A=
t least 


Comcast has a plan to provide each of their users with 


18,446,744,073,709,551,616 IPv6 addresses.









[JL] What has become more apparent since the =9603 draft is that it is=
 not just about the impairment level. Even (or perhaps especially) if every=
 ISP was 100% dual stack, some large domains would still want or need a mec=
hanism to incrementally control the
 addition of IPv6 traffic to their domain. I have tried to add some new tex=
t to the =9604 update to better explain this on behalf of implementers or p=
otential implementers.









Given that draft-ietf-v6ops-v6-aaaa-whitelisting-implications has

been reviewed by DNSOP and v6ops, and that the intended status is 

Informational, it is difficult to give it a "DNP". &nbs=
p;RFC 3901 mentions 


"Policy Based Avoidance of Name Space Fragmentation". &=
nbsp;The DNS 


technique used in the draft (split-view) contributes to name space 

fragmentation.







If you wanted to argue for "DNP", you could have the followi=
ng text 


from the v6ops Charter at the bottom of the list:







  "IPv6 operational and deployment issues with specific=
 protocols or


   technologies (such as Applications, Transport Protocols, =
Routing


   Protocols, DNS or Sub-IP Protocols) are the primary respo=
nsibility of


   the groups or areas responsible for those protocols or te=
chnologies.


   However, the v6ops WG may provide input to those areas/gr=
oups, as


   needed, and cooperate with those areas/groups in reviewin=
g solutions


   to IPv6 operational and deployment problems."







If you want to argue against "DNP", you can always say that =
you are 


merely documenting the stupid things people have to do get IPv6 deploy=
ed.







I am stupid but I am not that stupid to go and argue about a draft 

that has been blessed by DNSOP and v6ops.  :-)  An=
drew Sullivan 


mentioned WCP [1].  That RFC sub-series does not exist yet.&=
nbsp; The best 


fit is FYI.









[JL] Yup.









As a comment that will not be considered as part of the Last Call, I <=
/div>

would have given the draft a DNP if I had to review it.  I d=
on't have 


to say that as the draft already got a five DISCUSS rating.  =
;That 


won't prevent a well-known search engine from deploying the mechanism =



described in this draft.  Someone might come to me and say t=
hat 


"well-known search does this, why can't you do it; it's even a 

RFC".  I'll read the Mathematical Principles of Natural=
 Philosophy to 


see whether I can find an answer to that. :-)





















--_000_CA080C7728976jasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Sun May 29 12:33: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 95D8AE06B2 for ; Sun, 29 May 2011 12:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.162
X-Spam-Level: 
X-Spam-Status: No, score=-108.162 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 NsR-Bf7MYVFl for ; Sun, 29 May 2011 12:33:50 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id AE5E0E0655 for ; Sun, 29 May 2011 12:33:49 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.127919714; Sun, 29 May 2011 15:33:43 -0400
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; Sun, 29 May 2011 15:33:42 -0400
From: "Livingood, Jason" 
To: Ray Hunter , "v6ops@ietf.org WG" 
Thread-Topic: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
Thread-Index: AQHMHjdMKlp71D5R1EmOJnIlkuW7DA==
Date: Sun, 29 May 2011 19:33:42 +0000
Message-ID: 
In-Reply-To: <4DC29A96.6020709@globis.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [69.141.126.196]
Content-Type: multipart/alternative; boundary="_000_CA0812AD289ABjasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 May 2011 19:33:54 -0000

--_000_CA0812AD289ABjasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks for your review and feedback, Ray. A revised =9604 will soon be publ=
ished. See some specific comments inline below in a few places.

Thank you!
JL

On 5/5/11 8:39 AM, "Ray Hunter" >=
 wrote:

I'm guessing comments are welcome again now for input to the revised ID
now that the status is "Revised ID Needed" (according to RFC6174) Or
should I be waiting for the revised ID first before commenting further?
I dunno. I still admit to getting confused by the status on the
http://tools.ietf.org/wg/v6ops tooling page even after having read the
finite state machine a couple of times. Maybe that should disqualify me
from taking part in the WG ;)

Anyway, firstly, I can imagine that the actions of a single aaaa
whitelisting provider can have far reaching consequences for many
parties on the Internet.

[JL] Quite so=85

Say "Content Provider G" adds your ISP's DNS resolvers and suddenly a
huge proportion of the ISP's traffic switches to IPv6. Vice versa is
also true if traffic is routed away from IPv6. It may even take a
different path through the transit providers' networks (if they are not
all offering dual native transport) and thus also have financial
consequences.

Meanwhile if you're in the ISP network, you really can't debug anything
meaningfully because you might be receiving a different response to
someone else who has a problem, and you have no idea why. Even if you do
debug the problem correctly, and correct your local issues, you have
very little control over full problem resolution (by getting the aaaa
whitelist contents changed).

That means my first conclusion is that I feel v6ops WG should attempt to
reach some consensus on a revised I-D, and at least comment on the
operational aspects, rather than just let the current draft lapse.

[JL] The current I-D will definitely not lapse. Your point above is a good =
one and I have added this to the section concerning the implications of de-=
whitelisting:
"One particular risk is that, especially when a high-traffic domain de-whit=
elists a large network, this may cause a sudden change to networks since a =
large volume of traffic will then switch from IPv6 to IPv4. This can have d=
ramatic effects on those being de-whitelisted as well as on other interconn=
ected networks."

Secondly, Is the scope and function of the document clear?

That seemed to confuse some members of the IESG if I read their feedback.

Is it too early to talk about Solutions?

Maybe the revised I-D should simply stick to the target defined in the
text already present on page 5:

"This document explores the reasons and motivations for DNS
whitelisting. It also explores the outlined concerns regarding this
practice. Readers will hopefully better understand what DNS whitelisting
is, why some parties are implementing it, and what   criticisms of the
practice exist." with the addition that "It is intended to address best
current practice and solutions in a follow up."

And then leave all discussion of "Solutions" to a BCP follow up RFC?

[JL] That section has been reworked in the upcoming revision and is now cal=
led "General Implementation Variations". If you think the re-worked section=
 is still out of place after the =9604, please feel free to say so.

I suspect it would probably be easier to reach consensus for an
informational "description and concerns of current practice" without
immediately taking the next step and marking that description as "best
current practice" or proposing "solutions" to the concerns. Yes I know
the first document won't change anything, but at least it is a clear
problem statement for people to tackle and to generate possibly many
alternative options for follow-up.

Thirdly, as has already been pointed out in the description of the
"current practice", the relationship between IPv6 name resolution and
IPv6 connectivity appears tenuous to me, although others have commented
that they have observed a causal link.

Is there any hard data on this?

Thinking off the top of my head:

There are off site / off net back up recursive resolvers just to mention
one basic level of obfuscation.

There are open recursive resolvers. Here's a survey of open recursive
resolvers that potentially serve people "outside" of their own network
http://dns.measurement-factory.com/surveys/openresolvers/ASN-reports/latest=
.html
10000 of them in the latest survey. These would almost certainly break a
link between resolver performance and network connectivity.

Looking closer to home, my own authoritative DNS is not located on my
ISP's DNS. I want to be able to change transport provider (big cost and
low hassle for me) in a smooth manner, without having to change DNS
provider (small cost, but big hassle for me). I also currently use a
different recursive resolver for outbound requests (IPv6 capable via a
tunnel) than my IPv4 transport provider (not IPv6 capable).

This aaaa whitelisting practice as described appears to create a direct
link between DNS recursive resolution services and IPv6 transport
provider services that has not existed up until now IMHO.

[JL] I don't disagree that the resolver is an imperfect proxy for the end h=
ost's capabilities. Implementers have said it may be their best or easiest =
available tool however.

That should probably be noted as an architectural concern of the WG. It
is hinted at within the existing text: "An additional concern is that
the IP address of a recursive resolver is not a precise indicator of the
IPv6 preparedness, or lack of IPv6-related impairments, of end user
hosts which query (use) a particular recursive resolver."

But that text does not address the concern at any architectural level
whether there should be _any_ link at all between an IPv6 transport
provider and DNS recursive resolver server address, never mind if it is
a reliable link.

[JL] I understand your concern but I'm not sure how to update the sentence =
/ section noted. If you have suggested text, please let me know.

RFC5358 suggest it was Best Current Practice in 2008 to avoid open
recursive resolvers to avoid reflector attacks, but it does not directly
link DNS resolution and transport service provision. It just says "The
generic recommendation to nameserver operators is to use the means
provided by the implementation of choice to provide recursive name
lookup service to only the intended clients." One suggested method was
IP filtering, another was DNS-tsig, which is certainly a real
possibility. But the intended clients for DNS were certainly not limited
to only those using a particular transport provider.

Has this concern therefore been properly documented?

Fourthly, moving on to possible suggestions for solutions and BCP, it is
very clear that there is a real issue with the lack of transparency on
the whole aaaa whitelisting process. As others have already commented,
it seems very opaque.

[JL] Yes, and this was one of my initial concerns with the practice. It see=
ms that the WG is not ready to work on recommended practices in this area. =
I'm working on some suggested steps an implementer can take in another grou=
p (the Broadband Internet Technical Advisory Group). That document covers e=
ach of the items you note below (and will become a public document in the n=
ext 2 =96 3 months).

In order to facilitate troubleshooting, and to give people a chance to
control their own destiny (regardless of the aaaa whitelisting
technology employed) can the v6ops WG take a view that DNS server
operators who employ aaaa whitelisting SHOULD:
1. publish their policy for maintaining the aaaa whitelist
2. provide details for how and where the aaaa whitelist is used
3. provide details of how to request the contents of the aaaa whitelist
(taking into account privacy concerns)
4. provide details of how to request being included in the aaaa whitelist
5. provide details of how to request being excluded from the aaaa whitelist
6. provide details of how to request a review, appeal, or enter an
arbitration process.
7. provide active feedback to the maintainers of DNS and IPv6 transport
providers to improve overall IPv6 DNS resolution and IPv6 connectivity,
in order to remove any underlying need for an aaaa whitelist, and to
facilitate its complete removal at the earliest possible opportunity.

I miss these operational issues being addressed at all in the previous
draft in the Solutions section. They're well covered in discussion
relating to other (similar) lists e.g. DNSBL

So does the v6ops WG deprecate/discourage/condone/tolerate/encourage DNS
whitelisting or blacklisting on the basis of "recursive resolver IP
address" reachability/ reliability being linked to IPv6 transport
reliability?

Doubt there'll be consensus here, but I think the question should be
asked again.

To it seems that broken IPv6 connectivity is the real problem, not
broken name resolution as far as I can see. Especially when it is
possible to resolve both IPv4 and IPv6 records over either IPv4 or IPv6
transport, I really fail to see the correlation. Perhaps someone can
correct my myopia with hard data.

[JL] Broken IPv6-related connectivity is without a doubt one of the root is=
sues. Another which I am trying to better address in the =9604 is a volumet=
ric concern held by high-traffic domains. This concerns leads them to searc=
h for a way to gradually add IPv6 traffic to their domain, so they can matu=
re their IPv6 routes to various networks, and so their and other networks c=
an mature their IPv6-related monitoring, policies, procedures, etc.

If someone has broken DNS recursive resolution for IPv6, it is going to
affect the majority of the IPv6 services they are using, and should
stand out like a sore thumb. They are therefore likely to be highly
motivated to point their local resolver libs at a better DNS server, and
which action is generally a fairly trivial act (altering one DHCP record
at best and rebooting machines).

[JL] It's less about the resolvers being broken or having IPv6 issues =97 i=
t's more the end hosts using a particular resolver.

If there are generally large numbers of broken IPv6 DNS resolvers out
there, then there's a much bigger problem, which is certainly not going
to be solved by a point solution deployed by a few content providers. In
fact aaaa whitelisting is more likely to mask the problem than solve it
IMHO.

Again I sense a lack of hard operational data as to the root causes of
the problem. Maybe that's also a basic concern to be noted: "lack of
operational data regarding the root causes of the problem."


Also IMHO the v6ops WG also shouldn't encourage people to mess around
with DNS unless it is absolutely necessary. Breaking DNS would break an
awful lot, to put it mildly.

[JL] This is a fair point =97 DNS is a foundational element.


The current document notes the current practice of only deploying aaaa
whitelisting on an authoritative server.

Should the v6ops WG clearly state in any recommendations or bcp that
1. aaaa whitelisting MUST NOT be deployed anywhere other than on an
authoritative DNS server for which the aaaa whitelist provider is
directly responsible.
2. aaaa whitleisting information SHOULD NOT be traded for use in aaaa
whitelisting on other authoritative DNS servers, unless the aaaa
whitelist policy of the two organisations is tightly coupled.
3. the adminisatrator of the authoritative DNS SHOULD ensure that all
authoritative DNS servers for a domain return a consistent set of
results, regardless of which server has been queried.
4. aaaa whitelisting is a transition mechanism that MAY be useful in
supporting a move towards a fully native IPv6 network, but which SHOULD
only be used where, and for as long, as is essential to maintain normal
operations.

A few questions and issues for your consideration thus.

[JL] Those are good questions for the WG. I think so far consensus seems to=
 be to proceed with the current I-D and that, over time, a BCP or other add=
itional documents may (or may not) be called for. That being said, on #4, t=
he upcoming I-D will address this somewhat more directly.

Thanks again!
Jason



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


--_000_CA0812AD289ABjasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <2C9D50D3EA46A74C8E7AE87E4879129B@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable









Thanks for your review and feedback, Ray. A revised =9604 will soon be=
 published. See some specific comments inline below in a few places.









Thank you!


JL







On 5/5/11 8:39 AM, "Ray Hunter" <v6ops@globis.net> wrote:









I'm guessing comments are welcome again now for input to the revised I=
D 


now that the status is "Revised ID Needed" (according to RFC=
6174) Or 


should I be waiting for the revised ID first before commenting further=
? 


I dunno. I still admit to getting confused by the status on the 


http://tools.ietf.org/wg/v6=
ops tooling page even after having read the



finite state machine a couple of times. Maybe that should disqualify m=
e 


from taking part in the WG ;)







Anyway, firstly, I can imagine that the actions of a single aaaa 

whitelisting provider can have far reaching consequences for many 

parties on the Internet.









[JL] Quite so=85









Say "Content Provider G" adds your ISP's DNS resolvers and s=
uddenly a 


huge proportion of the ISP's traffic switches to IPv6. Vice versa is <=
/div>

also true if traffic is routed away from IPv6. It may even take a 

different path through the transit providers' networks (if they are no=
t 


all offering dual native transport) and thus also have financial 

consequences.







Meanwhile if you're in the ISP network, you really can't debug anythin=
g 


meaningfully because you might be receiving a different response to 

someone else who has a problem, and you have no idea why. Even if you =
do 


debug the problem correctly, and correct your local issues, you have <=
/div>

very little control over full problem resolution (by getting the aaaa =



whitelist contents changed).







That means my first conclusion is that I feel v6ops WG should attempt =
to 


reach some consensus on a revised I-D, and at least comment on the 

operational aspects, rather than just let the current draft lapse.








[JL] The current I-D will definitely not lapse. Your point=
 above is a good one and I have added this to the section concerning the im=
plications of de-whitelisting:


"One particular risk is that, especially when a high-traffic d=
omain de-whitelists a large network, this may cause a sudden change to netw=
orks since a large volume of traffic will then switch from IPv6 to IPv4. Th=
is can have dramatic effects on those
 being de-whitelisted as well as on other interconnected networks."









Secondly, Is the scope and function of the document clear?







That seemed to confuse some members of the IESG if I read their feedba=
ck.







Is it too early to talk about Solutions?







Maybe the revised I-D should simply stick to the target defined in the=
 


text already present on page 5:







"This document explores the reasons and motivations for DNS 

whitelisting. It also explores the outlined concerns regarding this&nb=
sp;  


practice. Readers will hopefully better understand what DNS whitelisti=
ng 


is, why some parties are implementing it, and what   critici=
sms of the 


practice exist." with the addition that "It is intended to a=
ddress best 


current practice and solutions in a follow up."







And then leave all discussion of "Solutions" to a BCP follow=
 up RFC?









[JL] That section has been reworked in the upcoming revision and is no=
w called "General Implementation Variations". If you think the re=
-worked section is still out of place after the =9604, please feel free to =
say so.









I suspect it would probably be easier to reach consensus for an


informational "description and concerns of current practice"=
 without 


immediately taking the next step and marking that description as "=
;best 


current practice" or proposing "solutions" to the conce=
rns. Yes I know 


the first document won't change anything, but at least it is a clear <=
/div>

problem statement for people to tackle and to generate possibly many <=
/div>

alternative options for follow-up.







Thirdly, as has already been pointed out in the description of the 

"current practice", the relationship between IPv6 name resol=
ution and 


IPv6 connectivity appears tenuous to me, although others have commente=
d 


that they have observed a causal link.







Is there any hard data on this?







Thinking off the top of my head:







There are off site / off net back up recursive resolvers just to menti=
on 


one basic level of obfuscation.







There are open recursive resolvers. Here's a survey of open recursive =



resolvers that potentially serve people "outside" of their o=
wn network 



10000 of them in the latest survey. These would almost certainly break=
 a 


link between resolver performance and network connectivity.







Looking closer to home, my own authoritative DNS is not located on my =



ISP's DNS. I want to be able to change transport provider (big cost an=
d 


low hassle for me) in a smooth manner, without having to change DNS 

provider (small cost, but big hassle for me). I also currently use a <=
/div>

different recursive resolver for outbound requests (IPv6 capable via a=
 


tunnel) than my IPv4 transport provider (not IPv6 capable).







This aaaa whitelisting practice as described appears to create a direc=
t 


link between DNS recursive resolution services and IPv6 transport 

provider services that has not existed up until now IMHO.









[JL] I don't disagree that the resolver is an imperfect proxy for the =
end host's capabilities. Implementers have said it may be their best or eas=
iest available tool however. 









That should probably be noted as an architectural concern of the WG. I=
t 


is hinted at within the existing text: "An additional concern is =
that 


the IP address of a recursive resolver is not a precise indicator of t=
he 


IPv6 preparedness, or lack of IPv6-related impairments, of end user 

hosts which query (use) a particular recursive resolver."







But that text does not address the concern at any architectural level =



whether there should be _any_ link at all between an IPv6 transport 

provider and DNS recursive resolver server address, never mind if it i=
s 


a reliable link.









[JL] I understand your concern but I'm not sure how to update the sent=
ence / section noted. If you have suggested text, please let me know.









RFC5358 suggest it was Best Current Practice in 2008 to avoid open

recursive resolvers to avoid reflector attacks, but it does not direct=
ly 


link DNS resolution and transport service provision. It just says &quo=
t;The 


generic recommendation to nameserver operators is to use the means 

provided by the implementation of choice to provide recursive name 

lookup service to only the intended clients." One suggested metho=
d was 


IP filtering, another was DNS-tsig, which is certainly a real 


possibility. But the intended clients for DNS were certainly not limit=
ed 


to only those using a particular transport provider.







Has this concern therefore been properly documented?







Fourthly, moving on to possible suggestions for solutions and BCP, it =
is 


very clear that there is a real issue with the lack of transparency on=
 


the whole aaaa whitelisting process. As others have already commented,=
 


it seems very opaque.









[JL] Yes, and this was one of my initial concerns with the practice. I=
t seems that the WG is not ready to work on recommended practices in this a=
rea. I'm working on some suggested steps an implementer can take in another=
 group (the Broadband Internet Technical
 Advisory Group). That document covers each of the items you note below (an=
d will become a public document in the next 2 =96 3 months). 









In order to facilitate troubleshooting, and to give people a chance to=
 


control their own destiny (regardless of the aaaa whitelisting 


technology employed) can the v6ops WG take a view that DNS server 

operators who employ aaaa whitelisting SHOULD:


1. publish their policy for maintaining the aaaa whitelist


2. provide details for how and where the aaaa whitelist is used


3. provide details of how to request the contents of the aaaa whitelis=
t 


(taking into account privacy concerns)


4. provide details of how to request being included in the aaaa whitel=
ist


5. provide details of how to request being excluded from the aaaa whit=
elist


6. provide details of how to request a review, appeal, or enter an 

arbitration process.


7. provide active feedback to the maintainers of DNS and IPv6 transpor=
t 


providers to improve overall IPv6 DNS resolution and IPv6 connectivity=
, 


in order to remove any underlying need for an aaaa whitelist, and to <=
/div>

facilitate its complete removal at the earliest possible opportunity.<=
/div>






I miss these operational issues being addressed at all in the previous=
 


draft in the Solutions section. They're well covered in discussion 

relating to other (similar) lists e.g. DNSBL







So does the v6ops WG deprecate/discourage/condone/tolerate/encourage D=
NS 


whitelisting or blacklisting on the basis of "recursive resolver =
IP 


address" reachability/ reliability being linked to IPv6 transport=
 


reliability?







Doubt there'll be consensus here, but I think the question should be <=
/div>

asked again.







To it seems that broken IPv6 connectivity is the real problem, not 

broken name resolution as far as I can see. Especially when it is 

possible to resolve both IPv4 and IPv6 records over either IPv4 or IPv=
6 


transport, I really fail to see the correlation. Perhaps someone can <=
/div>

correct my myopia with hard data.









[JL] Broken IPv6-related connectivity is without a doubt one of the ro=
ot issues. Another which I am trying to better address in the =9604 is a vo=
lumetric concern held by high-traffic domains. This concerns leads them to =
search for a way to gradually add
 IPv6 traffic to their domain, so they can mature their IPv6 routes to vari=
ous networks, and so their and other networks can mature their IPv6-related=
 monitoring, policies, procedures, etc.









If someone has broken DNS recursive resolution for IPv6, it is going t=
o 


affect the majority of the IPv6 services they are using, and should 

stand out like a sore thumb. They are therefore likely to be highly 

motivated to point their local resolver libs at a better DNS server, a=
nd 


which action is generally a fairly trivial act (altering one DHCP reco=
rd 


at best and rebooting machines).









[JL] It's less about the resolvers being broken or having IPv6 issues =
=97 it's more the end hosts using a particular resolver. 









If there are generally large numbers of broken IPv6 DNS resolvers out =



there, then there's a much bigger problem, which is certainly not goin=
g 


to be solved by a point solution deployed by a few content providers. =
In 


fact aaaa whitelisting is more likely to mask the problem than solve i=
t 


IMHO.







Again I sense a lack of hard operational data as to the root causes of=
 


the problem. Maybe that's also a basic concern to be noted: "lack=
 of 


operational data regarding the root causes of the problem."












Also IMHO the v6ops WG also shouldn't encourage people to mess around =



with DNS unless it is absolutely necessary. Breaking DNS would break a=
n 


awful lot, to put it mildly.









[JL] This is a fair point =97 DNS is a foundational element.














The current document notes the current practice of only deploying aaaa=
 


whitelisting on an authoritative server.







Should the v6ops WG clearly state in any recommendations or bcp that

1. aaaa whitelisting MUST NOT be deployed anywhere other than on an 

authoritative DNS server for which the aaaa whitelist provider is 

directly responsible.


2. aaaa whitleisting information SHOULD NOT be traded for use in aaaa =



whitelisting on other authoritative DNS servers, unless the aaaa 

whitelist policy of the two organisations is tightly coupled.


3. the adminisatrator of the authoritative DNS SHOULD ensure that all =



authoritative DNS servers for a domain return a consistent set of 

results, regardless of which server has been queried.


4. aaaa whitelisting is a transition mechanism that MAY be useful in <=
/div>

supporting a move towards a fully native IPv6 network, but which SHOUL=
D 


only be used where, and for as long, as is essential to maintain norma=
l 


operations.







A few questions and issues for your consideration thus.









[JL] Those are good questions for the WG. I think so far consensus see=
ms to be to proceed with the current I-D and that, over time, a BCP or othe=
r additional documents may (or may not) be called for. That being said, on =
#4, the upcoming I-D will address
 this somewhat more directly.







Thanks again!


Jason



















regards,


RayH


_______________________________________________


v6ops mailing list













--_000_CA0812AD289ABjasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Sun May 29 12:46: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 3D32DE075E for ; Sun, 29 May 2011 12:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.17
X-Spam-Level: 
X-Spam-Status: No, score=-108.17 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 ssYcNj3cGI8l for ; Sun, 29 May 2011 12:46:16 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD57E0740 for ; Sun, 29 May 2011 12:46:15 -0700 (PDT)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.127923420; Sun, 29 May 2011 15:46:10 -0400
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Sun, 29 May 2011 15:46:10 -0400
From: "Livingood, Jason" 
To: "K.Fleischhauer@telekom.de" , "v6ops@ietf.org" 
Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 - traffic load considerations
Thread-Index: AQHMDmJcdMlTH64Ob0qwxzp9To93NJSkVU6A
Date: Sun, 29 May 2011 19:46:07 +0000
Message-ID: 
In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840C5B42E@HE111648.emea1.cds.t-internal.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [24.40.55.70]
Content-Type: multipart/alternative; boundary="_000_CA0817E9289CEjasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 - traffic load considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 May 2011 19:46:18 -0000

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

Thanks for your additional feedback, Karsten. See comments inline below.

Regards
JL

On 5/9/11 12:01 PM, "K.Fleischhauer@telekom.de" > wrote:

Dear Jason,

a more or less arbitrarily using of the AAAA whitelisting configuration
without coordination of all involved networks could lead IMHO to unexpected=
 traffic behaviour respectively traffic load in some segments of the intern=
et.
That should be valid as long as the internet is not complete Dual-Stack ena=
bled
or when no congruent IPv4/v6 network topology is available.
I would expect at least that the latter case will never occur.

Therefore I propose the following text in section 7.3.x of the draft.

"
7.3.x Unexpected changes and shifts in traffic load on links and network se=
gments

In the case when large content provider would using DNS whitelisting for DN=
S resolver of
access provider [is this now the right term?] to be whitelisted or not will=
 change significant
the traffic volume for IPv4 or IPv6 between both parties.
Also when the overall traffic is stable, in the case that there is not a co=
ngruent IPv4-IPv6 topology available whitelisting will lead to changes in t=
raffic load of individual links and network segments between the access and=
 the content provider.
In the case of creating a whitelist entry traffic will be shifted to IPv4 a=
nd the IPv4 capable links and network segments.
In the case of deleting a whitelist entry traffic will be shifted to IPv6 a=
nd the IPv6 capable links and network segments.
When the DNS whitelisting occur without coordination between the content an=
d the access provider this could cause challenges in the traffic engineerin=
g.
"

[JL] I received similar feedback from some other people recently. What I ha=
ve done is added this text to 7.3.1, De-Whitelisting May Occur. I'm hoping =
this sufficiently accounts for your concern, which I share. If not, let me =
know what you suggest and I will add that to an upcoming version.
"One particular risk is that, especially when a high-traffic domain de-whit=
elists a large network, this may cause a sudden and dramatic change to netw=
orks since a large volume of traffic will then switch from IPv6 to IPv4. Th=
is can have dramatic effects on those being de-whitelisted as well as on ot=
her interconnected networks. In some cases, IPv4 network links may rapidly =
become congested and users of affected networks will experience network acc=
ess impairments well beyond the domain which performed the de-whitelisting.=
 Thus, once "operational stability" has been achieved between a whitelistin=
g and whitelisted party, then de-whitelisting should generally not occur ex=
cept in cases of operational emergencies, and there should be opportunities=
 for joint troubleshooting or at least for advance warning to affected part=
ies."

Thanks!
Jason





Best

KARSTEN


--_000_CA0817E9289CEjasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <8DA359840DECB541837084C4221A54AE@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable









Thanks for your additional feedback, Karsten. See comments inline belo=
w.









Regards


JL















Dear Jason,







a more or less arbitrarily using of the AAAA whitelisting configuratio=
n


without coordination of all involved networks could lead IMHO to unexp=
ected traffic behaviour respectively traffic load in some segments of the i=
nternet.


That should be valid as long as the internet is not complete Dual-Stac=
k enabled


or when no congruent IPv4/v6 network topology is available.


I would expect at least that the latter case will never occur.







Therefore I propose the following text in section 7.3.x of the draft.<=
/div>






"


7.3.x Unexpected changes and shifts in traffic load on links and netwo=
rk segments







In the case when large content provider would using DNS whitelisting f=
or DNS resolver of


access provider [is this now the right term?] to be whitelisted or not=
 will change significant


the traffic volume for IPv4 or IPv6 between both parties.


Also when the overall traffic is stable, in the case that there is not=
 a congruent IPv4-IPv6 topology available whitelisting will lead to changes=
 in traffic load of individual links and network segments between the acces=
s and the content provider.


In the case of creating a whitelist entry traffic will be shifted to I=
Pv4 and the IPv4 capable links and network segments.


In the case of deleting a whitelist entry traffic will be shifted to I=
Pv6 and the IPv6 capable links and network segments.


When the DNS whitelisting occur without coordination between the conte=
nt and the access provider this could cause challenges in the traffic engin=
eering.


"









[JL] I received similar feedback from some other people recently. What=
 I have done is added this text to 7.3.1, De-Whitelisting May Occur. I'm ho=
ping this sufficiently accounts for your concern, which I share. If not, le=
t me know what you suggest and I
 will add that to an upcoming version.


"One particular risk is that, especially when a high-traffic d=
omain de-whitelists a large network, this may cause a sudden and dramatic c=
hange to networks since a large volume of traffic will then switch from IPv=
6 to IPv4. This can have dramatic effects
 on those being de-whitelisted as well as on other interconnected networks.=
 In some cases, IPv4 network links may rapidly become congested and users o=
f affected networks will experience network access impairments well beyond =
the domain which performed the de-whitelisting.
 Thus, once "operational stability" has been achieved between a w=
hitelisting and whitelisted party, then de-whitelisting should generally no=
t occur except in cases of operational emergencies, and there should be opp=
ortunities for joint troubleshooting or at
 least for advance warning to affected parties."







Thanks!


Jason





























Best







KARSTEN











--_000_CA0817E9289CEjasonlivingoodcablecomcastcom_--

From lorenzo@google.com  Sun May 29 19:16: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 C9BF3E0768 for ; Sun, 29 May 2011 19:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 c1TsvuyVmBeI for ; Sun, 29 May 2011 19:16:28 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2712CE0684 for ; Sun, 29 May 2011 19:16:27 -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 p4U2GR2c019111 for ; Sun, 29 May 2011 19:16:27 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306721787; bh=LlT61bN4BdtISw6U+FZ9qzPKuZ0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ywIh41W6oq8v15FeaJ8yrjEHfXOGe8GPqvIK+1ZhAD+45SOXlWckJeo1crrcv0kyu WR7Rwz5earjABDdi1vnnQ==
Received: from gwj20 (gwj20.prod.google.com [10.200.10.20]) by wpaz9.hot.corp.google.com with ESMTP id p4U2GQYP002441 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 29 May 2011 19:16:26 -0700
Received: by gwj20 with SMTP id 20so1774438gwj.26 for ; Sun, 29 May 2011 19:16:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sL7aOPMS8T3Z1jA+PcyzAyEwE5C13c+uX6YB6ON6Da0=; b=Rw1mLwkhRxyxo7JQTrqtc5x2Z8T+GpGfhMD0iLBe95nACt4VcQ0AE/bUL1QzeWqXO4 UhoZBMH2PyTgh9RC5vWg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=k9Nt/T+yBNEhEnKmAwo3HuuJ4rg+PQ6QXnVSrMzFnpXHo1wC36VWMNtW9Qwu3XM9xf 2bBD+yWBUWw/EdML5Bhg==
Received: by 10.150.113.20 with SMTP id l20mr3649528ybc.36.1306721786006; Sun, 29 May 2011 19:16:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Sun, 29 May 2011 19:16:03 -0700 (PDT)
In-Reply-To: 
References: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840C5B42E@HE111648.emea1.cds.t-internal.com> 
From: Lorenzo Colitti 
Date: Sun, 29 May 2011 19:16:03 -0700
Message-ID: 
To: "Livingood, Jason" 
Content-Type: multipart/alternative; boundary=000e0cd56830e00f9404a474dfac
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 - traffic load considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 30 May 2011 02:16:28 -0000

--000e0cd56830e00f9404a474dfac
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 29, 2011 at 12:46 PM, Livingood, Jason <
Jason_Livingood@cable.comcast.com> wrote:

>  *"One particular risk is that, especially when a high-traffic domain
> de-whitelists a large network, this may cause a sudden and dramatic change
> to networks since a large volume of traffic will then switch from IPv6 to
> IPv4.*
>

Why does the draft neglect to mention the equal but opposite "sudden and
dramatic change to networks" that can occur if a high-traffic domain
suddenly announces AAAA records for the whole world without whitelisting?

--000e0cd56830e00f9404a474dfac
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Sun, May 29, 2011 at 12:46 PM, Livingood, Jas=
on <Jason_Livingood@cable.comcast.com> wrote:











"One particular risk is that, especially when a high-traffic d=
omain de-whitelists a large network, this may cause a sudden and dramatic c=
hange to networks since a large volume of traffic will then switch from IPv=
6 to IPv4.




Why does the draft neglect to =
mention the equal but opposite "sudden and dramatic change to networks=
" that can occur if a high-traffic domain suddenly announces AAAA reco=
rds for the whole world without whitelisting?





--000e0cd56830e00f9404a474dfac--

From jason_livingood@cable.comcast.com  Sun May 29 19:54: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 A7E4CE0767; Sun, 29 May 2011 19:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.896
X-Spam-Level: 
X-Spam-Status: No, score=-107.896 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 0sWjjUkXL97z; Sun, 29 May 2011 19:54:33 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id C8A22E0657; Sun, 29 May 2011 19:54:31 -0700 (PDT)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128054652; Sun, 29 May 2011 22:54:22 -0400
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; Sun, 29 May 2011 22:54:21 -0400
From: "Livingood, Jason" 
To: Dave Crocker , IETF Discussion 
Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
Thread-Index: AQHMHnTaa+cb8O33f02hYGkDuWA7dQ==
Date: Mon, 30 May 2011 02:54:20 +0000
Message-ID: 
In-Reply-To: <4DC821FB.2050904@dcrocker.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [24.40.55.70]
Content-Type: multipart/alternative; boundary="_000_CA084387289FFjasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , Apps Review 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 30 May 2011 02:54:42 -0000

--_000_CA084387289FFjasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Dave =96 Thanks for this email as well. It is my last item in queue before =
posting an updated =9604 draft (whew!). See some specific responses inline =
below.

Thanks
JL

On 5/9/11 1:18 PM, "Dave CROCKER" > wrote:

(This is an "official" and significantly extended version of an informal an=
d
narrow review I posted earlier.  /d)

Howdy.

I have been selected as the Applications Area Review Team reviewer for this
draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you m=
ay
receive. Please wait for direction from your document shepherd or AD before
posting a new version of the draft.

Review (v2):

Title:  IPv6 AAAA DNS Whitelisting Implications
I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

By:     D. Crocker >
Date:   <>

Summary
=3D=3D=3D=3D=3D=3D=3D

This draft covers a a dual-stack problem in which a target host's DNS entry
contains records for IPv4 and IPv6, but returning IPv6 information to a DNS
client can cause problems. The paper discusses for resolving this through u=
se of
a a DNS-based mechanism that manually lists response preferences to select =
which
DNS records to return.  The paper describes the mechanism and explores vari=
ous
effects and possibilities of its use, including the difference between usin=
g it
selectively among a smaller number of sites, versus universally.

The draft is a serious effort to explore the use of such a mechanism and it
touches many different issues.  It is generally well-organized and clearly
written, although it very much needs the aid of a professional technical ed=
itor.
The writing often assumes too much knowledge by the reader.

The paper's exploration of universal adoption seems to vary between conside=
ring
that goal practical versus considering it only as a matter of completeness =
for
discussing the full range of possibilities.  That is, it is not clear wheth=
er
the paper views this alternative as practically possible and even preferred=
,
versus only a matter for academic thoroughness.

[JL] I consider it the latter =96 highly unlikely but included for complete=
ness (on the assumption that a failure to include it would lead to comments=
 that it was incomplete without it). However the =9604 update will make mor=
e clear the remoteness of the possibility of universal deployment.

The paper needs to take a basic
position about feasibility, explain it in terms of comparable adoption effo=
rts
at Internet-scale, and then make its treatment of universal adoption a bit =
more
consistent.

[JL] Good feedback - I've tried to do that in the =9604 version.

When introducing terms, mechanisms, configurations and scenarios, the paper
needs to be more careful to describe them adequately for a reader new to th=
e
topic.  This is not a matter of having a tutorial about the DNS, but rather=
 a
tutorial for this type of mechanism and when and how it can be used.

As a specific example, the document cites "domain-by-domain" use, but I am =
not
clear how that would work, in terms of configuration and cross-net informat=
ion
exchange.  One question is how the server knows the 'domain' of the client?

The document should careful to distinguish what is existing practice, versu=
s
what is being explored as added possibilities.  The difference in concreten=
ess
and certitude between the two is substantial.

The document's use of the term whitelisting appears to continue an existing=
,
recent use, for this type of mechanism.  Unfortunately it directly conflict=
s
with long-standing use of the term by the anti-abuse community for whitelis=
ting
in the DNS. Its use here also seems to be a mismatch with the word's dictio=
nary
semantics, which is most naturally used to distinguish yes/no choices, rath=
er
than either/or choices.  So there is no intuitive sense of "goodness" (whit=
elist
=3D yes) or "badness" (blacklist) for this use. The word "preferences" seem=
s more
in line with the meaning of the mechanism.

[JL] Duly noted in my previous emails. I'm keeping the naming as an open is=
sue in the =9604 and will be seeking WG and WG co-chair guidance one way or=
 the other. Your other notes have also suggested a simplification of the do=
cument in some respects so that is also noted as an open item as well (but =
I really do need to get an update out in the meantime).

Detailed Comments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Abstract

    The objective of this document is to describe what the whitelisting
    of DNS AAAA resource records is, hereafter referred to as DNS

RRs are whitelisted?  Isn't it the addresses and not the records that are
whitelisted?

Does this mean putting whitelisting records into the DNS or does it mean
something else?

Comcast's own considerable expertise notwithstanding, has this doc been vet=
ted
with a range of organizations that actually DO whitelisting?  Has it been
circulated through MAAWG and APWG?  Any comments from Spamhaus?  The
Acknowledgements list does not seem to indicate a range of whitelist ops fo=
lks
whose names I know.  (But then, I only know a few...)

[JL] Per my other note today, this will be fixed in the =9604.

    whitelisting, as well as the implications of this emerging practice
    and what alternatives may exist.  The audience for this document is
    the Internet community generally, including the IETF and IPv6
    implementers.

I suspect that product marketers won't have much interest in this.  I suspe=
ct
that the target for this is anti-abuse technical and operations staff. In a=
ny
event, the targetting statement should be more precise.

[JL] Addressed in my earlier response to your shorter review.

1.  Introduction

    This document describes the emerging practice of whitelisting of DNS

One natural, semantic problem with the term 'whitelist' is that it does not
really match the function being performed.  The white/black distinction imp=
lies
goodness -- or as Wikipedia says, "priviledge".  Instead, the use here is f=
or
preference or priority.  What would a "blacklist" be, here?  Also note it i=
s not
obvious what it means to be whitelisted, here?  Does it mean to choose the =
AAAA
records or the A records?

This is more like a 'Preference' or 'Configuration' list.

At the least, the name for this should be IPv6 Resolver Whitelisting.  It m=
akes
clear /what/ is being "whitelisted".

[JL] Ack. Carried in Open Items for =9604.

    AAAA resource records (RRs), which contain IPv6 addresses, hereafter
    referred to as DNS whitelisting.  The document explores the

This provides a name, but not a function.  That is, it does not say what th=
is
mechanisms actually /does/ or is /for/.

[JL] Addressed in my earlier response to your shorter review.

    implications of this emerging practice are and what alternatives may
    exist.

    The practice of DNS whitelisting appears to have first been used by
    major web content sites (sometimes described herein as "highly-

It's use for email anti-abuse dates back farther.

    

    



Specifically within the context of the DNS, the term whitelisting is theref=
ore
made ambiguous.

A google query for "whitelist dns" also demonstrates the history and curren=
t
ambiguity.

[JL] Addressed in my earlier response to your shorter review.

    trafficked domains" or "major domains").  These web site operators,
    or domain operators, observed that when they added AAAA resource
    records to their authoritative DNS servers in order to support IPv6
    access to their content that a small fraction of end users had slow
    or otherwise impaired access to a given web site with both AAAA and A
    resource records.  The fraction of users with such impaired access
    has been estimated to be roughly 0.078% of total Internet users
    [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
    Brokenness].  Thus, in an example Internet Service Provider (ISP)
    network of 10 million users, approximately 7,800 of those users may
    experience such impaired access.

At a minimum, these sorts of statistics need to be normalized across IPv6
users/traffic, given how small a percentage that is, in total users and tot=
al
traffic.  If that's what is meant it should be stated.  If it isn't, the
statistic should be recalculated and explained a bit more precisely.

[JL] Addressed in my earlier response to your shorter review.

    As a result of this impairment affecting end users of a given domain,
    a few major domains have either implemented DNS whitelisting or are
    considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].
    When implemented, DNS whitelisting in practice means that a domain's
    authoritative DNS will return a AAAA resource record to DNS recursive
    resolvers [RFC1035] on the whitelist, while returning no AAAA
    resource records to DNS resolvers which are not on the whitelist.  It

This explanation of the function should be offered sooner and should be
summarized in the Abstract.

[JL] Good suggestion =96 made some tweaks to the Abstract to try to address=
 this.

    is important to note that these major domains are motivated by a
    desire to maintain a high-quality user experience for all of their

Rather than being important to note, this sentence sounds oddly like market=
ing
hype, in a technical specification.  It is gratuitous because specified fea=
tures
are never added to /lower/ the quality of the user experience, for example.

In addition, the mechanism also affects client activity that has no user
directly involved.


    users.  By engaging in DNS whitelisting, they are attempting to
    shield users with impaired access from the symptoms of those
    impairments.

The /technical/ statement that should be here is that they are attempting t=
o
provide a work-around for problematic behaviors in dual-stack IPv4/IPv6
environments.

The paper should make more clear exactly where the problem lies and when. I=
f it
can occur for a number of reasons, explaining each of those scenarios would=
 be
useful.

[JL] I've attempted to do so in the =9604 update.

    Critics of the practice of DNS whitelisting have articulated several
    concerns.  Among these are that:

    o  DNS whitelisting is a very different behavior from the current
       practice concerning the publishing of IPv4 address resource
       records,

    o  that it may create a two-tiered Internet,

    o  that policies concerning whitelisting and de-whitelisting are
       opaque,

Livingood                Expires August 26, 2011                [Page 5]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    o  that DNS whitelisting reduces interest in the deployment of IPv6,

    o  that new operational and management burdens are created,

well, yeah... in fact it should be noted that the burdens are particularly
onerous at scale.

[JL] Ack =96 updated the text to reflect this



    o  and that the costs and negative implications of DNS whitelisting
       outweigh the perceived benefits, compared to fixing underlying
       impairments.

and it doesn't scale.

and it violates an extremely basic premise of cross-Internet interoperabili=
ty by
requiring prior arrangement.

[JL] Ack =96 added this

    This document explores the reasons and motivations for DNS
    whitelisting.  It also explores the outlined concerns regarding this
    practice.  Readers will hopefully better understand what DNS
    whitelisting is, why some parties are implementing it, and what
    criticisms of the practice exist.


2.  How DNS Whitelisting Works

How IPv6 AAAA DNS Whitelisting Works.

(Anti-spam DNS Whitelisting works rather differently...)


    DNS whitelisting is implemented in authoritative DNS servers.  These
    servers implement IP address-based restrictions on AAAA query
    responses.  So far, DNS whitelisting has been primarily implemented
    by web server operators deploying IPv6-enabled services.  For a given

Really?  This is web-specific?  The same restrictions are not applied for o=
ther
applications?

So if the same client-side hosts attempt to contact the server for email or
xmpp, they won't get the same handling?

[JL] Quite so =96 I updated the text to clarify this.

    operator of a website, such as www.example.com, the operator
    essentially applies an access control list (ACL) on the authoritative
    DNS servers for the domain example.com.  The ACL is populated with

An ACL usually is a yes/no mechanism.  Here, however, the mechanism is for
asserting a preference for IPv6 over IPv4.

That does not seem to match the definition of ACL that I'm used to, unless =
the
semantic is defined as denying IPv4 access to the listed clients.

The term ACL is particularly odd to use if the mechanism pertains to respon=
ses
rather than queries.

[JL] I am using 'ACL' in the most general possible sense and am open to alt=
ernative descriptors if you wish to suggest one. But most people seem to kn=
ow an ACL is a list that, if you are listed on it, grants you access to som=
e resource. In this case if the resolver is on the list then it gets AAAA R=
Rs.

    the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive

Either address type can be listed?  So this really is a pure 'preferences'
mechanism?

Which settings count as whitelisting?  Do any count as blacklisting?

[JL] A resolver can have both IPv6 and IPv4 addresses. Whether a resolver i=
s listed on the whitelist and is therefore able to receive AAAA RR response=
s is orthogonal to whether the resolver itself has an IPv4 or IPv6 address =
=97 since the whitelisting decision making tends to be based on some conclu=
sion about the hosts that query the resolver rather than the resolver.

    resolvers on the Internet, which have been authorized to receive AAAA
    resource record responses.  These DNS recursive resolvers are
    operated by third parties, such as ISPs, universities, governments,
    businesses, and individual end users.  If a DNS recursive resolver IS
    NOT matched in the ACL, then AAAA resource records will NOT be sent
    in response to a query for a hostname in the example.com domain.

This configuration appears to ensure the maximum barrier to adoption for IP=
v6,
since it means that IPv6 will not work automatically.  It will only work fo=
r
hosts that are manually configured to receive responses with v6 records.

That's a rather major implication.  It's a default that is probably meant t=
o
apply during the very early stages of adoption, when there are few users of=
 the
newer mechanism.

It's probably worth discussing it in more detail, including discussing when=
 to
change the default...

[JL] Correct on all 3 points. I've tried to address this better in the =960=
4 version.

    However, if a DNS recursive resolver IS matched in the ACL, then AAAA
    resource records will be sent in response to a query for a given
    hostname in the example.com domain.  While these are not network-
    layer access controls they are nonetheless access controls that are a
    factor for end users and other parties like network operators,
    especially as networks and hosts transition from one network address
    family to another (IPv4 to IPv6).

Also, all of this clarifies the function of this listing mechanism and sugg=
ests
a very different name, to be more precise and accurate in naming it:

     IPv6 DNS Response Preference List.

[JL] I've added all the various naming suggestions to the Open Issues secti=
on.

    In practice, DNS whitelisting generally means that a very small
    fraction of the DNS recursive resolvers on the Internet (those in the
    whitelist ACL) will receive AAAA responses.  The large majority of
    DNS resolvers on the Internet will therefore receive only A resource
    records containing IPv4 addresses.  Thus, quite simply, the
    authoritative server hands out different answers depending upon who
    is asking; with IPv4 and IPv6 resource records for some on the
    authorized whitelist, and only IPv4 resource records for everyone
    else.  See Section 2.1 and Figure 1 for a description of how this



Livingood                Expires August 26, 2011                [Page 6]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    works.

    Finally, DNS whitelisting can be deployed in two primary ways:
    universally on a global basis, or on an ad hoc basis.  Deployment on
    a universal deployment basis means that DNS whitelisting is
    implemented on all authoritative DNS servers, across the entire
    Internet.  In contrast, deployment on an ad hoc basis means that only
    some authoritative DNS servers, and perhaps even only a few,
    implement DNS whitelisting.  These two potential deployment models
    are described in Section 6.

2.1.  Description of the Operation of DNS Whitelisting

    The system logic of DNS whitelisting is as follows:

    1.  The authoritative DNS server for example.com receives DNS queries
        for the A (IPv4) and AAAA (IPv6) address resource records for the
        FQDN www.example.com, for which AAAA (IPv6) resource records
        exist.

This means that the mechanism is /only/ triggered when /both/ address recor=
ds
are queried?  A query for only one type of address record won't trigger the=
 list
lookup?  I think that doesn't match other statements in the document.

[JL] Updated to clarify / correct my text. (changed A and AAAA to and/or)



    2.  The authoritative DNS server examines the IP address of the DNS
        recursive resolver sending the AAAA (IPv6) query.

"examines"?  Examines it for what?  What does this step mean?

[JL] Examines as in looks at the IP address. I'll just simplify it and comb=
ine it with #3.

    3.  The authoritative DNS server checks this IP address against the
        access control list (ACL) that is the DNS whitelist.

    4.  If the DNS recursive resolver's IP address IS matched in the ACL,
        then the response to that specific DNS recursive resolver can
        contain AAAA (IPv6) address resource records.

Oh.  This is not about whether to send responses /over/ v6 vs. v4?  This is
whether to /include/ a particular type of RR in responses???

In that case an appropriate name for this mechanism is more like:

    DNS Response Content Preference List

[JL] Adding this suggested name to the Open Issues list as well.

And this seems even less like an ACL than it did before.  (I assume the
justification is that access is being prevented by virtue of not supplying =
the
address, but still...)


    5.  If the DNS recursive resolver's IP address IS NOT matched in the
        ACL, then the response to that specific DNS recursive resolver
        cannot contain AAAA (IPv6) address resource records.  In this
        case, the server should return a response with the response code
        (RCODE) being set to 0 (No Error) with an empty answer section
        for the AAAA record query.

Livingood                Expires August 26, 2011                [Page 7]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    ---------------------------------------------------------------------
    A query is sent from a DNS recursive resolver that IS NOT on the DNS
    whitelist:

                Request                      Request
            www.example.com                  www.example.com
                  AAAA    +-------------+     AAAA    +-----------------+
      ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
      ||  ||       A      | **IS NOT**  |      A      | IN A exists     |
    +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
    +--------+     A      | example.com |      A      |                 |
       Host    <--------- |  WHITELIST  |  <--------- |                 |
     Computer   A Record  +-------------+  A Record   +-----------------+
                Response   DNS Recursive   Response       example.com
               (only IPv4)   Resolver     (only IPv4)    Authoritative
                               #1                           Server
    ---------------------------------------------------------------------
    A query is sent from a DNS recursive resolver that IS on the DNS
    whitelist:

                Request                      Request
            www.example.com                  www.example.com
                 AAAA     +-------------+     AAAA    +-----------------+
      ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
      ||  ||       A      |   **IS**    |      A      | IN A exists     |
    +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
    +--------+   AAAA     | example.com |     AAAA    |                 |
       Host    <--------- |  WHITELIST  |  <--------- |                 |
     Computer      A      |             |      A      |                 |
               <--------- |             |  <--------- |                 |
               A and AAAA +-------------+ A and AAAA  +-----------------+
                Record     DNS Recursive   Record        example.com
               Responses     Resolver     Responses      Authoritative
               (IPv4+IPv6)      #2        (IPv4+IPv6)       Server
    ---------------------------------------------------------------------

               Figure 1: DNS Whitelisting - Functional Diagram

This diagram is confusing to me.  I suspect that a protocol exchange sequen=
ce
format, in the style of:

      Host             Resolver 1            Authoritative

           ---------->
                                  --------->
                                 <---------
          <----------

will be considerably more helpful.

[JL] I took a stab at a new diagram in =9604 =97 so take a look and let me =
know if it is what you are suggesting (I've left the original one in for no=
w).

3.  What Problems Are Implementers Trying To Solve?

This is a very useful section and it is probably worth moving it higher, to
precede the 'how it works' section.


    As noted in Section 1, domains which implement DNS whitelisting are
    attempting to protect a few users of their domain, who have impaired
    IPv6 access, from having a negative experience (poor performance).

By the way, what does 'impaired v6 access' mean?

I think there needs to be a simple, direct description of what occurs witho=
ut
this mechanism.

For example, perhaps you mean that a host can send DNS queries using IPv6 b=
ut
cannot receive DNS responses over IPv6? Perhaps you mean that the host can =
send
IPv6 but cannot receive it.  (That's a different scale and scope of problem=
 from
the first example I gave.)

This brief, summary problem statement should be included in the Abstract, t=
o
make /much/ more clear what this mechanism is for.

[JL] Done. Added text to the Abstract and Intro and added more to note that=
 this is about both impairment and (actual or perceived) immaturity of IPv6=
 network routing and practices.



    While it is outside the scope of this document to explore the various
    reasons why a particular user's system (host) may have impaired IPv6
    access, for the users who experience this impairment it is a very
    real performance impact.  It would affect access to all or most dual



Livingood                Expires August 26, 2011                [Page 8]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    stack services to which the user attempts to connect.  This negative
    end user experience can range from someone slower than usual (as
    compared to native IPv4-based access), to extremely slow, to no
    access to the domain whatsoever.

Rather than repeat that this is about end-users, it sounds more that this i=
s
about whether a service works or does not work, whether a user is directly
present or not.


    While one can debate whether DNS whitelisting is the optimal solution
    to the end user experience problem, it is quite clear that DNS
    whitelisting implementers are interested in maximizing the
    performance of their services for end users as a primary motivation
    for implementation.

You keep citing 'performance' but haven't described what sort of performanc=
e
degradation takes place. Is this really about relatively better or worse
performance -- and if so, how -- or is this about working or not working?

[JL] Good point =96 I added this text:
"In essence, whether the end user even has an IPv6 address or not (they pro=
bably only have an IPv4 address), merely by receiving a AAAA record respons=
e the user either cannot access a FQDN or it is so slow that the user gives=
 up and assumes the destination is unreachable."

Also rather than saying what implementers are interested in, it's probably =
more
helpful to note that the practice is now significantly established and ther=
efore
worth documenting, independent of its possible controversy.


    At least one highly-trafficked domain has noted that they have
    received requests to not send DNS responses with AAAA resource
    records to particular resolvers.  In this case, the operators of

"At least one" seems a rather tiny statistic.  Perhaps the actual statistic=
 is
significantly larger?

[JL] It does not seem to be. Other than this being passed along by Google, =
I've not heard of any similar stories. Nevertheless, it seemed interesting =
enough to include.

    those recursive resolvers have expressed a concern that their IPv6

I suspect that it's not resolvers that are doing the expressing, since thei=
r
vocabulary is usually too limited...

[JL] Quite. Updated:
"In this case, DNS recursive resolvers operators have expressed=85"

    network infrastructure is not yet ready to handle the large traffic
    volume which may be associated with the hosts in their network
    connecting to the websites of these domains.  This concern is clearly

So even though the site allows v6 DNS queries to go out from a host, it can=
't
really support having the host use v6?

[JL] A network isn't really in control of the end host's limitations w/r/t =
IPv6 impairment. A good summary of the issue of impairment is @ http://www.=
fud.no/ipv6/

Wow. I do understand why service providers often have to work around sillin=
ess
at the client side, but this problem at the client side seems particularly
egregious.


    a temporary consideration relating to the deployment of IPv6 network
    infrastructure on the part of networks with end user hosts, rather
    than a long-term concern.  These end user networks may also have

Again this goal of short-term usage is worth noting earlier, including in t=
he
Abstract.


    other tools at their disposal in order to address this concern,
    including applying rules to network equipment such as routers and
    firewalls (this will necessarily vary by the type of network, as well
    as the technologies used and the design of a given network), as well
    as configuration of their recursive resolvers (though modifying or
    suppressing AAAA resource records in a DNSSEC-signed domain on a
    Security-Aware Resolver will be problematic Section 10.1).

    Some implementers with highly-trafficked domains have explained that
    DNS whitelisting is a necessary, though temporary, risk reduction
    tactic intended to ease their transition to IPv6 and minimize any
    perceived risk in such a transition.  As a result, they perceive this
    as a tactic to enable them to incrementally enable IPv6 connectivity
    to their domains during the early phases of their transition to IPv6.

    Finally, some domains, have run IPv6 experiments whereby they added
    AAAA resource records and observed and measured errors [Heise Online
    Experiment], which should be important reading for any domain
    contemplating either the use of DNS whitelisting or simply adding
    IPv6 addressing to their site.


4.  Concerns Regarding DNS Whitelisting

    There are a number of potential implications relating to DNS
    whitelisting, which have been raised as concerns by some parts of the
    Internet community.  Many of those potential implications are further

I think the implications are not conditional; they exist rather than being
potential.  The 'potential' is that what is implicated will come to pass.

[JL] Fair point =96 removed 'potential' there and in another similar sectio=
n.


Livingood                Expires August 26, 2011                [Page 9]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    enumerated here and in Section 7.

Pro forma question:  Why are implications discussed in multiple places?

[JL] Some of them in are briefly noted in Section 4, but the exhaustive lis=
t in in Section 7.



    Some parties in the Internet community, including ISPs, are concerned

This style of text personalizes the issues unnecessarily (IMO).  It does no=
t
really matter who holds the concerns, or else they'd be described more prec=
isely.

[JL] I'll have to look at that after the =9604 update. In a previous draft =
I was asked to call out different parts of the community separately. (Alway=
s challenging to work through conflicting feedback.)


I suggest merely noting that there are concerns and then listing and discus=
sing
the concerns, rather than adding text to attribute the concerns to others, =
even
if the conclusion of your text is that a particular concern is not valid.

[JL] Duly noted. Let me get the =9604 update out, after which I will look a=
t generally simplifying the I-D and look at this issue specifically.



    that the practice of DNS whitelisting for IPv6 address resource
    records represents a departure from the generally accepted practices
    regarding IPv4 address resource records in the DNS on the Internet
    [Whitelisting Concerns].  These parties explain their belief that for

"These parties explain their belief" is an example of personalization that =
is
not needed.  This isn't about the believers.  It is about possible problems=
.

[JL] Ack.

    A resource records, containing IPv4 addresses, once an authoritative
    server operator adds the A record to the DNS, then any DNS recursive
    resolver on the Internet can receive that A record in response to a

This does not appear to be a grammatically valid sentence.  My guess is tha=
t
deleting "A resource... addresses" fixes this.

[JL] Change made.

And by the way, the document's reference to "recursive" resolvers is mostly
likely incorrect.  The problem is not restricted only to that very specific=
 type
of resolver, is it?

If in fact it /is/ specific to them -- and your following text describes an
indirect effects scenario where it might be -- I suggest calling out the
configuration at the beginning, along the lines of:

      One way the problem with returning AAAA records can be experienced is=
 when
recursive resolvers are used.  Although that resolver might support IPv6, i=
ts
client hosts might not.  So, returning an AAAA record will mean that these
limited hosts will be given an unusable address.

And this type of description belongs in the text describing the motivating
problem(s), rather than buried in the 'concerns' discussion.

(The text, here, pertains to A records, but the problem I've described uses=
 the
same configuration but for AAAA records with mixed v6 support.)


    query.  By extension, this means that any of the hosts connected to
    any of these DNS recursive resolvers can receive the IPv4 address
    resource records for a given FQDN.  This enables new server hosts
    which are connected to the Internet, and for which a fully qualified
    domain name (FQDN) such as www.example.com has been added to the DNS
    with an IPv4 address record, to be almost immediately reachable by
    any host on the Internet.  In this case, these new servers hosts
    become more and more widely accessible as new networks and new end
    user hosts connect to the Internet over time, capitalizing on and
    increasing so-called "network effects" (also called network
    externalities).  It also means that the new server hosts do not need
    to know about these new networks and new end user hosts in order to
    make their content and applications available to them, in essence
    that each end in this end-to-end model is responsible for connecting
    to the Internet and once they have done so they can connect to each
    other without additional impediments or middle networks or
    intervening networks or servers knowing about these end points and
    whether one is allowed to contact the other.

Hmmm.  This rather lengthy bit of prose appears merely to be explaining the
basic and long-standing DNS value proposition???

[JL] Ack =96 see previous comments about simplification. At the same time I=
'm trying to keep the document understandable to wide audience (and one of =
your other notes suggested I need to be somewhat less technical or more des=
criptive). You may be more familiar with the mechanics of DNS whereas someo=
ne else is less so. I'll think about this one=85

    In contrast, the concern is that DNS whitelisting may fundamentally
    change this model.  In the altered DNS whitelisting end-to-end model,
    one end (where the end user is located) cannot readily connect to the
    other end (where the content is located), without parts of the middle
    (recursive resolvers) used by one end (the client, or end user hosts)
    being known to an intermediary (authoritative nameservers) and
    approved for access to the resource at the end.  As new networks
    connect to the Internet over time, those networks need to contact any
    and all domains which have implemented DNS whitelisting in order to
    apply to be added to their DNS whitelist, in the hopes of making the
    content and applications residing on named server hosts in those
    domains accessible by the end user hosts on that new network.
    Furthermore, this same need to contact all domains implementing DNS
    whitelisting also applies to all pre-existing (but not whitelisted)
    networks connected to the Internet.

    In the current IPv4 Internet when a new server host is added to the
    Internet it is generally widely available to all end user hosts and
    networks, when DNS whitelisting of IPv6 resource records is used,

If it is available to the hosts, it is available to the network.

networks, when -> networks. When

[JL] Fixed






Livingood                Expires August 26, 2011               [Page 10]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    these new server hosts are not accessible to any end user hosts or
    networks until such time as the operator of the authoritative DNS

They are still accessible.  The IP-level mechanisms still work.

They are not reachable when using the domain name.

[JL] Fixed



    servers for those new server hosts expressly authorizes access to
    those new server hosts by adding DNS recursive resolvers around the
    Internet to the ACL.  This has the potential to be a significant

This is a good example of the reason the term ACL is inappropriate:  It imp=
lies
a security protection that does not actually exist.  The hosts are still ac=
cessible.

[JL] I still think the whitelist is comparable to an ACL insofar as it cont=
rols access to AAAA RR responses on the authoritative server, regardless of=
 access by IP address to some destination host.

    change in reachability of content and applications by end users and
    networks as these end user hosts and networks transition to IPv6,
    resulting in more (but different) breakage.  A concern expressed is
    that if much of the content that end users are most interested in is
    not accessible as a result, then end users and/or networks may resist
    adoption of IPv6 or actively seek alternatives to it, such as using
    multi-layer network address translation (NAT) techniques like NAT444
    [I-D.shirasaki-nat444] on a long-term basis.  There is also concern
    that this practice also could disrupt the continued increase in
    Internet adoption by end users if they cannot simply access new
    content and applications but must instead contact the operator of
    their DNS recursive resolver, such as their ISP or another third
    party, to have their DNS recursive resolver authorized for access to
    the content or applications that interests them.  Meanwhile, these
    parties say, over 99.9% of the other end users that are also using
    that same network or DNS recursive resolver are unable to access the
    IPv6-based content, despite their experience being a positive one.

    While in Section 1 the level of IPv6-related impairment has been
    estimated to be as high as 0.078% of Internet users, which is a

8 hundredths of one percent?

That's considered a high percentage?

[JL] It is. I joked at one of the v6ops WG meetings awhile ago that at that=
 rate, it'd be cheaper and easier for me (an ISP) to just buy new computers=
 for the affected "impaired" users than to have to navigate years of whitel=
isting with a variety of domains. In any case, one recent measurement estim=
ates it at 0.05% now and another at 0.015%. Despite this, this practice is =
still generating some interest. I'm hoping World IPv6 Day goes well and is =
informative for the community as to this percentage on a widespread basis, =
across a wide variety of web sites.


Even if it is 8%, is that considered high?

[JL] 8% of the Internet finding google.com or facebook.com inaccessible wou=
ld be bad for everyone. That could generate several hundred thousand suppor=
t calls per day to a big ISP.

5.2.  Similarities to DNS Load Balancing

    DNS whitelisting also has some similarities to DNS load balancing.
    There are of course many ways that DNS load balancing can be
    performed.  In one example, multiple IP address resource records (A
    and/or AAAA) can be added to the DNS for a given FQDN.  This approach
    is referred to as DNS round robin [RFC1794].  DNS round robin may
    also be employed where SRV resource records are used [RFC2782].

Right, but that's algorithmic rather than involving the manual method, desc=
ribed
here. So it does not seem comparable.

[JL] Whether I agree with you or not, the WG asked to include it in an earl=
ier draft. I tried to simply say that there are "some" similarities as a qu=
alifier.

6.  Likely Deployment Scenarios

    In considering how DNS whitelisting may emerge more widely, there are
    two likely deployment scenarios, which are explored below.

    In either of these deployment scenarios, it is possible that
    reputable third parties could create and maintain DNS whitelists, in
    much the same way that blacklists are used for reducing email spam.
    In the email context, a mail operator subscribes to one or more of
    these lists and as such the operational processes for additions and
    deletions to the list are managed by a third party.  A similar model
    could emerge for DNS whitelisting, whether deployment occurs
    universally or on an ad hoc basis.

The challenges of email whitelists and blacklists should be cited, since it
provides a rich base of experience for such an effort, at scale.


6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis

    The seemingly most likely deployment scenario is where some

Most likely?  This is not already established practice?

[JL] It is established at some large domains like google.com (which compris=
e a large % of global Internet traffic). But other domains are now on the c=
usp of their IPv6 transition and are pondering whether or not to use whitel=
isting. This document will hopefully be one of many data points in their de=
cision-making.

    authoritative DNS server operators implement DNS whitelisting but
    many or most others do not do so.  What can make this scenario
    challenging from the standpoint of a DNS recursive resolver operator
    is determining which domains implement DNS whitelisting, particularly
    since a domain may not do so as they initially transition to IPv6,
    and may instead do so later.  Thus, a DNS recursive resolver operator



Livingood                Expires August 26, 2011               [Page 13]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    may initially believe that they can receive AAAA responses as a
    domain adopts IPv6, but then notice via end user reports that they no
    longer receive AAAA responses due to that domain adopting DNS
    whitelisting.  Of course, a domain's IPv6 transition may be
    effectively invisible to recursive server operators due to the effect
    of DNS whitelisting.

This suggests that every listing at the server needs a contact record for
periodic checks whether to renew the listing.



    In contrast to a universal deployment of DNS whitelisting
    Section 6.2, deployment on an ad hoc basis is likely to be
    significantly more challenging from an operational, monitoring, and

Oh?  Use in small scale is more challenging than use of manual exceptions l=
ist
at large scale?  That's a very unexpected view.

[JL] I think it is in some regards but thinking it through more fully, I th=
ink you are correct and I have removed this.

    troubleshooting standpoint.  In this scenario, a DNS recursive
    resolver operator will have no way to systematically determine
    whether DNS whitelisting is or is not implemented for a domain, since
    the absence of AAAA resource records may simply be indicative that
    the domain has not yet added IPv6 addressing for the domain, rather
    than that they have done so but have restricted query access via DNS

The premise is that, in large scale use, servers /will/ have a way to
systematically determine whether it is implemented?  What are the existing
examples of having such a capability for other Internet protocols and servi=
ces?

[JL] Perhaps I'm overplaying this point, but you know someone has email ser=
vice if they have an MX record for example, or a website if the host answer=
s on TCP/80. But as I re-read this it is probably overkill and so I've dele=
ted it. I have however moved some of the text to a prior section, since det=
ermining whether or not domains are whitelisting is still a challenge at sc=
ale.

    whitelisting.  As a result, discovering which domains implement DNS
    whitelisting, in order to differentiate them from those that do not,
    is likely to be challenging.

    One benefit of DNS whitelisting being deployed on an ad hoc basis is
    that only the domains that are interested in doing so would have to
    upgrade their authoritative DNS servers in order to implement the
    ACLs necessary to perform DNS whitelisting.

    In this potential deployment scenario, it is also possible that a
    given domain will implement DNS whitelisting temporarily.  A domain,
    particularly a highly-trafficked domain, may choose to do so in order
    to ease their transition to IPv6 through a selective deployment and
    minimize any perceived risk in such a transition.

6.2.  Deploying DNS Whitelisting Universally

    The least likely deployment scenario is one where DNS whitelisting is
    implemented on all authoritative DNS servers, across the entire
    Internet.  While this scenario seems less likely than ad hoc
    deployment due to some parties not sharing the concerns that have so
    far motivated the use of DNS whitelisting, it is nonetheless
    conceivable that it could be one of the ways in which DNS
    whitelisting is deployed.

Significantly, the partial-deployment model casts this mechanism as a trans=
ition
expedient -- as the document reasonably describes it -- whereas universal
deployment casts it as a fundamental change to the architecture.

Given that it would take decades to achieve relatively full deployment of t=
his
'across the entire Internet', what is the benefit of discussing this highly
unlikely scenario?  Is it really "conceivable"?  I doubt it. If you think
otherwise, the paper needs to explore the deployment and adoption issues in=
 much
more detail, because I don't see how it could work.

[JL] Per my previous email responses this has been extensively reworked. I =
feel I should probably leave the universal deployment scenario in there for=
 completeness, but it's been cut down and minimized. I'm open to reconsider=
ing the question later.

   In order for this deployment scenario to occur, it is likely that DNS
    whitelisting functionality would need to be built into all
    authoritative DNS server software, and that all operators of
    authoritative DNS servers would have to upgrade their software and
    enable this functionality.  It is likely that new Internet Draft
    documents would need to be developed which describe how to properly
    configure, deploy, and maintain DNS whitelisting.  As a result, it is

Livingood                Expires August 26, 2011               [Page 14]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011

    unlikely that DNS whitelisting would, at least in the next several
    years, become universally deployed.  Furthermore, these DNS
    whitelists are likely to vary on a domain-by-domain basis, depending
    upon a variety of factors.  Such factors may include the motivation
    of each domain owner, the location of the DNS recursive resolvers in
    relation to the source content, as well as various other parameters
    that may be transitory in nature, or unique to a specific end user
    host type.  It is probably unlikely that a single clearinghouse for
    managing whitelisting is possible; it will more likely be unique to
    the source content owners and/or domains which implement DNS
    whitelists.

    While this scenario may be unlikely, it may carry some benefits.
    First, parties performing troubleshooting would not have to determine
    whether or not DNS whitelisting was being used, as it always would be
    in use.  In addition, if universally deployed, it is possible that
    the criteria for being added to or removed from a DNS whitelist could
    be standardized across the entire Internet.  Nevertheless, even if
    uniform DNS whitelisting policies were not standardized, is also
    possible that a central registry of these policies could be developed
    and deployed in order to make it easier to discover them, a key part
    of achieving transparency regarding DNS whitelisting.

Is any of this paragraph realistic?  Obviously my asking means I don't it i=
s.
These seem to be of theoretical rather than pragmatic interest.  ("If every=
one
refuses to shoot, there will be no wars.")

It's true that this is an "implications" paper rather than a BCP, but still=
...

[JL] Good point. Paragraph removed.


7.  Implications of DNS Whitelisting

    There are many potential implications of DNS whitelisting.  The key
    potential implications are detailed below.

7.1.  Architectural Implications

    DNS whitelisting could be perceived as modifying the end-to-end model
    and/or the general notion of the architecture that prevails on the

I'll suggest that perception is not a major issue about a technical topic l=
ike
this.  (It's not entirely irrelevant, of course, but I suspect it is quite =
minor.)

The major issue is whether it /actually/ modifies the end-to-end nature of =
the
DNS.  And I think it does, as well as modifying the "spontaneous
interoperability" expectation for most Internet mechanism, since it require=
s
prior registration.

[JL] Removed the perception stuff=85



7.2.  Public IPv6 Address Reachability Implications

    The predominant experience of end user hosts and servers on the IPv4-
    addressed Internet today is that when a new server with a public IPv4
    address is added to the DNS, that it is then globally accessible by

This sentence is not quite correct, in strict technical terms.  Since this =
is a
technical discussion, we need to be precise:  the host is reachable when th=
e
routing tables make it reachable.  That's strictly a mapper of IP Address
handling, not name-to-address mapping.

What you mean is that its domain name is immediately useful for reaching it=
.

[JL] Correction made.



    IPv4-addressed hosts.  This is a generalization and in Section 5
    there are examples of common cases where this may not necessarily be
    the case.  For the purposes of this argument, that concept of
    accessibility can be considered "pervasive reachability".  It has so
    far been assumed that the same expectations of pervasive reachability
    would exist in the IPv6-addressed Internet.  However, if DNS
    whitelisting is deployed, this will not be the case since only end
    user hosts using DNS recursive resolvers which are included in the

again, you mean /name-based/ reachability.

[JL] Fixed. In a way I was grasping at the "spontaneous interoperability" n=
otion you mentioned.


Livingood                Expires August 26, 2011               [Page 16]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    ACL of a given domain using DNS whitelisting would be able to reach
    new servers in that given domain via IPv6 addresses.  The expectation
    of any end user host being able to connect to any server (essentially
    both hosts, just at either end of the network), defined here as
    "pervasive reachability", will change to "restricted reachability"
    with IPv6.

    Establishing DNS whitelisting as an accepted practice in the early
    phases of mass IPv6 deployment could well establish it as an integral
    part of how IPv6 DNS resource records are deployed globally.  As a
    result, it is then possible that DNS whitelisting could live on for
    decades on the Internet as a key foundational element of domain name
    management that we will all live with for a long time.

(that last sentence could benefit from some editing.)

[JL] Ack =96 fixed.

    It is a critical to understand that the concept of reachability
    described above depends upon a knowledge or awareness of an address
    in the DNS.  Thus, in order to establish reachability to an end
    point, a host is dependent upon looking up an IP address in the DNS

If this section were started with a sentence like this, then there would no=
t be
a problem with the other references' being confused with address-based rout=
ing
reachability.

[JL] Great point! I've actually moved the last paragraph to the start of th=
at section and it makes much more sense.

    when a FQDN is used.  When DNS whitelisting is used, it is quite
    likely the case that an IPv6-enabled end user host could ping or
    connect to an example server host, even though the FQDN associated
    with that server host is restricted via a DNS whitelist.  Since most

First, I suspect that "example" doesn't add meaning to the sentence.  Secon=
d,
pinging and connecting might happen with or without the whitelist entry.  S=
o I
do not understand what import there is in this sentence.

[JL] I removed pinging but left connecting. What I'm saying you may still b=
e able to connect to the host via an IP if you cannot use the FQDN (it won'=
t always be the case, such as on a virtual web server sharing one IP across=
 several sites). I'll reword it a bit though since I see your point.

    Internet applications and hosts such as web servers depend upon the
    DNS, and as end users connect to FQDNs such as www.example.com and do
    not remember or wish to type in an IP address, the notion of
    reachability described here should be understood to include knowledge
    how to associate a name with a network address.

Again, this 'premise' statement should introduce the sub-section, not end i=
t.

[JL] Done (as noted above)


7.3.  Operational Implications

    This section explores some of the operational implications which may
    occur as a result of, are related to, or become necessary when
    engaging in the practice of DNS whitelisting.

7.3.1.  De-Whitelisting May Occur

The more general version of this issue is 'synchronization'.  Entries in th=
e
whitelist need to be synchronized with host status and capabilities.


    It is possible for a DNS recursive resolver added to a whitelist to
    then be removed from the whitelist, also known as de-whitelisting.
    Since de-whitelisting can occur, through a decision by the
    authoritative server operator, the domain owner, or even due to a
    technical error, an operator of a DNS recursive resolver will have
    new operational and monitoring requirements and/or needs as noted in
    Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5.

7.3.2.  Authoritative DNS Server Operational Implications

    Operators of authoritative servers may need to maintain an ACL a

a -> on a (?)

[JL] fixed



    server-wide basis affecting all domains, on a domain-by-domain basis,


Livingood                Expires August 26, 2011               [Page 17]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    as well as on a combination of the two.  As a result, operational

I'm not really understanding the first sentence.  One problem might be that=
 its
discussing an implication of some configuration or usage options that have =
not
been previously specified, so that the reference here might be overly crypt=
ic.

For example, I don't know what "affecting all domains" actually means.  It
almost sounds as if it could mean "everyone gets AAAA records" or "no one g=
ets
AAAA records" yet I'm reaonably certain that is /not/ what is meant.

[JL] Yes, that sentence was unclear. It is now:
"Operators of authoritative servers (which are frequently authoritative for=
 multiple domain names) will need to maintain an ACL on a server-wide basis=
 affecting all domains, or on a domain-by-domain basis."

    practices and software capabilities may need to be developed in order
    to support such functionality.  In addition, processes may need to be
    put in place to protect against inadvertently adding or removing IP
    addresses, as well as systems and/or processes to respond to such
    incidents if and when they occur.  For example, a system may be
    needed to record DNS whitelisting requests, report on their status
    along a workflow, add IP addresses when whitelisting has been
    approved, remove IP addresses when they have been de-whitelisted, log
    the personnel involved and timing of changes, schedule changes to
    occur in the future, and to roll back any inadvertent changes.

Might be worth starting with a simple, broad summary statement, possibly al=
ong
the lines of:

    An AAAA DNS Whitelist serves as a critical infrastructure service; to b=
e
useful it needs careful and extensive administration, monitoring and operat=
ion.
  Each new and essential mechanism creates substantial follow-on support co=
sts.

[JL] Thanks =96 added that text.



    Operators may also need implement new forms of monitoring in order to
    apply change control, as noted briefly in Section 7.3.4.

7.3.3.  DNS Recursive Resolver Server Operational Implications

    Operators of DNS recursive resolvers, which may include ISPs,
    enterprises, universities, governments, individual end users, and
    many other parties, are likely to need to implement new forms of
    monitoring, as noted briefly in Section 7.3.4.  But more critically,
    such operators may need to add people, processes, and systems in
    order to manage large numbers of DNS whitelisting applications as
    part of their own IPv6 transition, for all domains that the end users
    of such servers are interested in now or in which they may be

I think the summary observation is simple and should be stated directly:  T=
his
is a manual mechanism that becomes expensive in time and personnel effort a=
s it
scales up.

[JL] Added that



    interested in the future.  As anticipation of interesting domains is
    likely infeasible, it is more likely that operators may either choose
    to only apply to be whitelisted for a domain based upon one or more
    end user requests, or that they will attempt to do so for all domains
    that they can ascertain to be engaging in DNS whitelisting.

"attempt to do so for all domain that they can ascertain to be engaging in =
DNS
whitelisting"  appears to be saying to do whitelisting for domains that do
whitelisting.  I don't understand.

[JL] I was going to great effort to badly make a point that you can't antic=
ipate all domains users will want to access and so will need a way for user=
s to request whitelisting instead. I've reworded as:
"But more critically, such operators will need to add people, processes, an=
d systems in order to manage large numbers of DNS Whitelisting applications=
. Since there is no common method for determining whether or not a domain i=
s engaged in DNS Whitelisting, operators will have to apply to be whitelist=
ed for a domain based upon one or more end user requests, which means syste=
ms, processes, and personnel for handling and responding to those requests =
will also be necessary."


    When operators apply for DNS whitelisting for all domains, that may

"apply for DNS whitelisting for all domains" -- again I'm not understanding=
 what
this means.

[JL] See above

7.3.5.  Implications of Operational Momentum

    It seems plausible that once DNS whitelisting is implemented it will
    be very difficult to deprecate such technical and operational
    practices.  This assumption is based in an understanding of human

in -> on

[JL] Fixed

    nature, not to mention physics.  For example, as Sir Issac Newton
    noted, "Every object in a state of uniform motion tends to remain in
    that state of motion unless an external force is applied to it" [Laws

Code does not have momenum.  Neither do configurations or lists.  This real=
ly
isn't about physics.

[JL] But people and processes do have (operational) momentum=85

It is entirely about group psychology, as you note, and the administrative
challenges in the logistics of large-scale operational changes (which proba=
bly
/does/ have something to with physics, but it seems a stretch to credit New=
ton.
How about Heisenberg?...)

[JL] Hmmm=85 I don't think it is Heisenberg-related. But it's such an inter=
esting citation I feel it's almost a personal challenge to figure out a way=
 to keep it in there. ;-) The way I think about it is that in 5 or 10 years=
 none of the people working on the details of the IPv6 transition now will =
still be involved in the day-to-day operational work. But DNS Whitelisting =
could still be in place =96 and once something gets a momentum to it (peopl=
e, processes, and organizations) it is really, really hard to change that. =
This seems very much like the physics principle to which I refer but I'm op=
en to other citations. I envision this possibility:
Q (from new trainee): Why are we doing this DNS Whitelisting thing?
A: Because that's what we have to do for IPv6 access to every new domain.
Q: Why?
A: Because we've been doing it for years and it says to do it here in this =
operations manual we have to follow.
Q: Then I guess we should keep doing it?
A: Yes, we should. It'd be hard to change the standard process, and we'd ha=
ve to escalate it to someone, etc.

    of Motion].  Thus, once DNS whitelisting is implemented it is quite
    likely that it would take considerable effort to deprecate the
    practice and remove it everywhere on the Internet - it will otherwise
    simply remain in place in perpetuity.  To better illustrate this
    point, one could consider one example (of many) that there are many
    email servers continuing to attempt to query or otherwise check anti-



Livingood                Expires August 26, 2011               [Page 19]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    spam DNS blocklists which have long ago ceased to exist.

7.3.6.  Troubleshooting Implications

    The implications of DNS whitelisted present many challenges, which
    have been detailed in Section 7.  These challenges may negatively

But this is /still/ section 7.  Can you be more specific?  Or perhaps say
"throughout this section".

[JL] fixed



    affect the end users' ability to troubleshoot, as well as that of DNS
    recursive resolver operators, ISPs, content providers, domain owners
    (where they may be different from the operator of the authoritative
    DNS server for their domain), and other third parties.  This may make
    the process of determining why a server is not reachable
    significantly more complex.

7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis

    Additional implications, should this be deployed on an ad hoc basis,
    could include scalability problems relating to operational processes,

I'm pretty sure that scaling problems for this exist in all scenarios, not =
just
ad hoc usage.

[JL] True. Simplified to:
"As more domains choose to implement DNS Whitelisting, and more networks be=
come IPv6-capable and request to be whitelisted, scaling up operational pro=
cesses, monitoring, and ACL updates will become more difficult. The increas=
ed rate of change and increased size of whitelists will increase the likeli=
hood of configuration and other operational errors."

    monitoring, and ACL updates.  In particular, it seems likely that as
    the number of domains that are using DNS whitelisting increases, as
    well as the number of IPv6-capable networks requesting to be
    whitelisted, that there is an increased likelihood of configuration
    and other operational errors, especially with respect to the ACLs
    themselves.

    It is unclear when and if it would be appropriate to change from
    whitelisting to blacklisting, and whether or how this could feasibly
    be coordinated across the Internet, which may be proposed or

Actually the question of coordination is quite clear and rather fundamental=
:

      No.

Anyone believing otherwise needs to cite a successful example, at Internet =
scale
and diversity, more recently than the 1983 switch to IP (which didn't go al=
l
that well anyhow...)

Simple, unambiguous showstoppers should be stated in a simple and direct ma=
nner.
  When there is room for debate, softer language makes sense.  Again, if th=
e
question of coordination really is subject to debate, then the basis needs =
to be
stated.  (Good luck!)

[JL] That's not encouraging=85 Changed to:
"It is unclear when and if it would be appropriate to change from whitelist=
ing to blacklisting. It is clear that trying to coordinate this across the =
Internet is likely be be impossible, so such a change to blacklisting would=
 happen on a domain-by-domain basis (if at all)."

    implemented on an ad hoc basis when a majority of networks (or
    allocated IPv6 address blocks) have been whitelisted.  Finally, some
    parties implementing DNS whitelisting consider this to be a temporary
    measure.  As such, it is not clear how these parties will judge the
    network conditions to have changed sufficiently to justify disabling
    DNS whitelisting and/or what the process and timing will be in order
    to discontinue this practice.

    One further potential implication is that an end user with only an
    IPv4 address, using a DNS resolver which has not been whitelisted by
    any domains, would not be able to get any AAAA resource records.  In
    such a case, this could give that end user the incorrect impression
    that there is no IPv6-based content on the Internet since they are
    unable to discover any IPv6 addresses via the DNS.

7.4.  Homogeneity May Be Encouraged

    A broad trend which has existed on the Internet appears to be a move
    towards increasing levels of heterogeneity.  One manifestation of

increasing levels of heterogeneity -> more heterogeneity

[JL] fixed


(I think heterogeneity does not have 'levels'.)

Substantively:  say the nature of the heterogeneity within the initial clai=
m.
For example, there is /less/ heterogeneity of ISPs, given industry
consolidation.  There is less heterogeneity of infrastructure equipment suc=
h as
routers.  Etc.

[JL] I have gotten lots and lots of questions related to this section, whic=
h led me to conclude that I've done a poor job stating the issue. I was dan=
cing around it but here it is more directly in an updated section (the new =
2nd  and final paragraph of this section):
"Some forms of so-called "network neutrality" principles around the world i=
nclude the notion that any IP-capable device should be able to connect to a=
 network, which seems to encourage heterogeneity. These principles are ofte=
n explicitly encouraged by application providers given the reasons noted ab=
ove, though some of these same providers may also be implementing DNS White=
listing. This is ironic, as one implication of the adoption of DNS Whitelis=
ting is that it encourages a move back towards homogeneity. This is because=
 some implementers have expressed a preference for greater levels of contro=
l by networks over end user hosts in order to attempt to enforce technical =
requirements intended to reduce IPv6-related impairments. This return to an=
 environment of more homogenous and/or controlled end user hosts could have=
 unintended side effects on and counter-productive implications for future =
innovation at the edges of the network."

    this is in an increasing number, variety, and customization of end
    user hosts, including home network, operating systems, client



Livingood                Expires August 26, 2011               [Page 20]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


    software, home network devices, and personal computing devices.  This
    trend appears to have had a positive effect on the development and
    growth of the Internet.  A key facet of this that has evolved is the
    ability of the end user to connect any technically compliant device
    or use any technically compatible software to connect to the
    Internet.  Not only does this trend towards greater heterogeneity
    reduce the control which is exerted in the middle of the network,
    described in positive terms in [Tussle in Cyberspace], [Rethinking
    the Internet], and [RFC3724], but it can also help to enable greater
    and more rapid innovation at the edges.

    An unfortunate implication of the adoption of DNS whitelisting may be
    the encouragement of a reversal of this trend, which would be a move

the encouragement of -> to encourage

[JL] totally changed this, as noted above.



8.1.  Implement DNS Whitelisting Universally

    One obvious solution is to implement DNS whitelisted universally, and
    to do so using some sort of centralized registry of DNS whitelisting
    policies, contracts, processes, or other information.  This potential
    solution seems unlikely at the current time.

I'm pretty sure that the only thing that is obvious about a premise of univ=
ersal
adoption is that it's not practical.  Seriously.

At the least, this section needs to be less cavalier about putting this
alternative forward as a "solution", especially given the rather serious
drawbacks/problems with it.

[JL] Fixed




8.2.  Implement DNS Whitelisting On An Ad Hoc Basis

    If DNS whitelisting is to be adopted, it is likely to be adopted on

"is to be"?  I thought it already had a significant installed base.

[JL] Fixed.

    this ad hoc, or domain-by-domain basis.  Therefore, only those
    domains interested in DNS whitelisting would need to adopt the
    practice, though as noted herein discovering that they a given domain
    has done so may be problematic.  Also in this scenario, ad hoc use by
    a particular domain may be a temporary measure that has been adopted
    to ease the transition of the domain to IPv6 over some short-term
    timeframe.

8.3.  Do Not Implement DNS Whitelisting

    As an alternative to adopting DNS whitelisting, the Internet
    community generally can choose to take no action whatsoever,
    perpetuating the current predominant authoritative DNS operational
    model on the Internet, and leave it up to end users with IPv6-related
    impairments to discover and fix those impairments.


That is, place the burden of fixing a problem on those creating it?

[JL] In a way. It gets back to the question you asked about what level of i=
mpairment justifies this practice. One obvious option is to let end users s=
ort it out (presumably by consulting with their ISPs / network operators). =
This may be simpler and it's the way solutions to non-IPv6 problems tend to=
 work today.





Livingood                Expires August 26, 2011               [Page 23]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011


8.3.1.  Solving Current End User IPv6 Impairments

    A further extension of not implementing DNS whitelisting, is to also
    endeavor to actually fix the underlying technical problems that have
    prompted the consideration of DNS whitelisting in the first place, as
    an alternative to trying to apply temporary workarounds to avoid the
    symptoms of underlying end user IPv6 impairments.  A first step is
    obviously to identify which users have such impairments, which would
    appear to be possible, and then to communicate this information to
    end users.  Such end user communication is likely to be most helpful
    if the end user is not only alerted to a potential problem but is
    given careful and detailed advice on how to resolve this on their
    own, or where they can seek help in doing so.  Section 11 may also be
    relevant in this case.

    One challenge with this option is the potential difficulty of
    motivating members of the Internet community to work collectively
    towards this goal, sharing the labor, time, and costs related to such
    an effort.  Of course, since just such a community effort is now
    underway for IPv6, it is possible that this would call for only a
    moderate amount of additional work.

This 'challenge' is at the core of /all/ adoption efforts for Internet prot=
ocols
and services that entail distributed adoption.


    Despite any potential challenges, many in the Internet community are
    already working towards this goal and/or have expressed a general
    preference for this approach.

If this is not already an organized effort with a website, sponsoring
consortium, or the like, it should be.  If it is, then cite it in this doc!

[JL] Fixed. It is World IPv6 Day and the many efforts related to that.



8.3.2.  Gain Experience Using IPv6 Transition Names

    Another alternative is for domains to gain experience using an FQDN
    which has become common for domains beginning the transition to IPv6;
    ipv6.example.com and www.ipv6.example.com.  This can be a way for a
    domain to gain IPv6 experience and increase IPv6 use on a relatively
    controlled basis, and to inform any plans for DNS whitelisting with
    experience.

I do not understand what this means.

What is it for?  What are the results?  How are theyused?

[JL] Ack. This has been clarified in the =9604.



9.  Is DNS Whitelisting a Recommended Practice?

    Opinions in the Internet community concerning whether or not DNS
    whitelisting is a recommended practice are understandably quite
    varied.  However, there is clear consensus that DNS whitelisting is
    at best a useful temporary measure which a domain may choose to

If that is a clear consensus, then it makes even less sense to promote the =
idea
of universal adoption, given the timescale needed to achieve it.


10.  Security Considerations

    There are no particular security considerations if DNS whitelisting
    is not adopted, as this is how the public Internet works today with A
    resource records.

Or rather, failure to adopt a mechanism like this or repair the underlying
problem, for those sites experiencing that problem, will result in a denial=
 of
service, albeit not an intentional one.  Still, that's a pretty basic secur=
ity
issue.


d/
--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


--_000_CA084387289FFjasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable









Dave =96 Thanks for this email as well. It is my last item in queue be=
fore posting an updated =9604 draft (whew!). See some specific responses in=
line below.







Thanks


JL









On 5/9/11 1:18 PM, "Dave CROCKER" <dhc@dcrocker.net> wrote:









(This is an "official" and significantly extended version of=
 an informal and



narrow review I posted earlier.  /d)







Howdy.







I have been selected as the Applications Area Review Team reviewer for=
 this 


draft (for background on apps-review, please see 


http://www.apps.ietf.org/content/applications-area-review-team).






Please resolve these comments along with any other Last Call comments =
you may



receive. Please wait for direction from your document shepherd or AD b=
efore 


posting a new version of the draft.







Review (v2):







Title:  IPv6 AAAA DNS Whitelisting Implications


I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-impl=
ications-03







By:     D. Crocker <dcrocker@bbiw.net>


Date:   <>







Summary


=3D=3D=3D=3D=3D=3D=3D







This draft covers a a dual-stack problem in which a target host's DNS =
entry 


contains records for IPv4 and IPv6, but returning IPv6 information to =
a DNS 


client can cause problems. The paper discusses for resolving this thro=
ugh use of



a a DNS-based mechanism that manually lists response preferences to se=
lect which



DNS records to return.  The paper describes the mechanism an=
d explores various



effects and possibilities of its use, including the difference between=
 using it



selectively among a smaller number of sites, versus universally.







The draft is a serious effort to explore the use of such a mechanism a=
nd it 


touches many different issues.  It is generally well-organiz=
ed and clearly 


written, although it very much needs the aid of a professional technic=
al editor.



The writing often assumes too much knowledge by the reader.







The paper's exploration of universal adoption seems to vary between co=
nsidering



that goal practical versus considering it only as a matter of complete=
ness for



discussing the full range of possibilities.  That is, it is =
not clear whether



the paper views this alternative as practically possible and even pref=
erred,



versus only a matter for academic thoroughness. 









[JL] I consider it the latter =96 highly unlikely but included for com=
pleteness (on the assumption that a failure to include it would lead to com=
ments that it was incomplete without it). However the =9604 update will mak=
e more clear the remoteness of the possibility
 of universal deployment. 









The paper needs to take a basic 


position about feasibility, explain it in terms of comparable adoption=
 efforts



at Internet-scale, and then make its treatment of universal adoption a=
 bit more



consistent.









[JL] Good feedback - I've tried to do that in the =9604 version.









When introducing terms, mechanisms, configurations and scenarios, the =
paper 


needs to be more careful to describe them adequately for a reader new =
to the



topic.  This is not a matter of having a tutorial about the =
DNS, but rather a



tutorial for this type of mechanism and when and how it can be used.






As a specific example, the document cites "domain-by-domain"=
 use, but I am not



clear how that would work, in terms of configuration and cross-net inf=
ormation



exchange.  One question is how the server knows the 'domain'=
 of the client?







The document should careful to distinguish what is existing practice, =
versus



what is being explored as added possibilities.  The differen=
ce in concreteness



and certitude between the two is substantial.







The document's use of the term whitelisting appears to continue an exi=
sting,



recent use, for this type of mechanism.  Unfortunately it di=
rectly conflicts



with long-standing use of the term by the anti-abuse community for whi=
telisting



in the DNS. Its use here also seems to be a mismatch with the word's d=
ictionary



semantics, which is most naturally used to distinguish yes/no choices,=
 rather



than either/or choices.  So there is no intuitive sense of &=
quot;goodness" (whitelist



=3D yes) or "badness" (blacklist) for this use. The word &qu=
ot;preferences" seems more



in line with the meaning of the mechanism.









[JL] Duly noted in my previous emails. I'm keeping the naming as an op=
en issue in the =9604 and will be seeking WG and WG co-chair guidance one w=
ay or the other. Your other notes have also suggested a simplification of t=
he document in some respects so that
 is also noted as an open item as well (but I really do need to get an upda=
te out in the meantime).









Detailed Comments


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D









Abstract







    The objective of this document is to describe =
what the whitelisting


    of DNS AAAA resource records is, hereafter ref=
erred to as DNS









RRs are whitelisted?  Isn't it the addresses and not the rec=
ords that are 


whitelisted?







Does this mean putting whitelisting records into the DNS or does it me=
an 


something else?







Comcast's own considerable expertise notwithstanding, has this doc bee=
n vetted



with a range of organizations that actually DO whitelisting? &nbs=
p;Has it been 


circulated through MAAWG and APWG?  Any comments from Spamha=
us?  The 


Acknowledgements list does not seem to indicate a range of whitelist o=
ps folks



whose names I know.  (But then, I only know a few...)









[JL] Per my other note today, this will be fixed in the =9604.











    whitelisting, as well as the implications of t=
his emerging practice


    and what alternatives may exist.  Th=
e audience for this document is


    the Internet community generally, including th=
e IETF and IPv6


    implementers.









I suspect that product marketers won't have much interest in this.&nbs=
p; I suspect



that the target for this is anti-abuse technical and operations staff.=
 In any



event, the targetting statement should be more precise.









[JL] Addressed in my earlier response to your shorter review.











1.  Introduction







    This document describes the emerging practice =
of whitelisting of DNS









One natural, semantic problem with the term 'whitelist' is that it doe=
s not 


really match the function being performed.  The white/black =
distinction implies



goodness -- or as Wikipedia says, "priviledge".  I=
nstead, the use here is for



preference or priority.  What would a "blacklist" =
be, here?  Also note it is not



obvious what it means to be whitelisted, here?  Does it mean=
 to choose the AAAA



records or the A records?







This is more like a 'Preference' or 'Configuration' list.







At the least, the name for this should be IPv6 Resolver Whitelisting.&=
nbsp; It makes



clear /what/ is being "whitelisted".









[JL] Ack. Carried in Open Items for =9604.











    AAAA resource records (RRs), which contain IPv=
6 addresses, hereafter


    referred to as DNS whitelisting.  Th=
e document explores the









This provides a name, but not a function.  That is, it does =
not say what this



mechanisms actually /does/ or is /for/.









[JL] Addressed in my earlier response to your shorter review.











    implications of this emerging practice are and=
 what alternatives may


    exist.







    The practice of DNS whitelisting appears to ha=
ve first been used by


    major web content sites (sometimes described h=
erein as "highly-









It's use for email anti-abuse dates back farther.



























Specifically within the context of the DNS, the term whitelisting is t=
herefore



made ambiguous.







A google query for "whitelist dns" also demonstrates the his=
tory and current



ambiguity.









[JL] Addressed in my earlier response to your shorter review.











    trafficked domains" or "major domain=
s").  These web site operators,


    or domain operators, observed that when they a=
dded AAAA resource


    records to their authoritative DNS servers in =
order to support IPv6


    access to their content that a small fraction =
of end users had slow


    or otherwise impaired access to a given web si=
te with both AAAA and A


    resource records.  The fraction of u=
sers with such impaired access


    has been estimated to be roughly 0.078% of tot=
al Internet users


    [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating=
 IPv6 Adoption] [IPv6


    Brokenness].  Thus, in an example In=
ternet Service Provider (ISP)


    network of 10 million users, approximately 7,8=
00 of those users may


    experience such impaired access.









At a minimum, these sorts of statistics need to be normalized across I=
Pv6 


users/traffic, given how small a percentage that is, in total users an=
d total



traffic.  If that's what is meant it should be stated. =
 If it isn't, the 


statistic should be recalculated and explained a bit more precisely.








[JL] Addressed in my earlier response to your shorter review.











    As a result of this impairment affecting end u=
sers of a given domain,


    a few major domains have either implemented DN=
S whitelisting or are


    considering doing so [NW-Article-DNS-WL] [IPv6=
 Whitelist Operations].


    When implemented, DNS whitelisting in practice=
 means that a domain's


    authoritative DNS will return a AAAA resource =
record to DNS recursive


    resolvers [RFC1035] on the whitelist, while re=
turning no AAAA


    resource records to DNS resolvers which are no=
t on the whitelist.  It









This explanation of the function should be offered sooner and should b=
e 


summarized in the Abstract.









[JL] Good suggestion =96 made some tweaks to the Abstract to try to ad=
dress this.











    is important to note that these major domains =
are motivated by a


    desire to maintain a high-quality user experie=
nce for all of their









Rather than being important to note, this sentence sounds oddly like m=
arketing



hype, in a technical specification.  It is gratuitous becaus=
e specified features



are never added to /lower/ the quality of the user experience, for exa=
mple.







In addition, the mechanism also affects client activity that has no us=
er 


directly involved.














    users.  By engaging in DNS whitelist=
ing, they are attempting to


    shield users with impaired access from the sym=
ptoms of those


    impairments.









The /technical/ statement that should be here is that they are attempt=
ing to



provide a work-around for problematic behaviors in dual-stack IPv4/IPv=
6 


environments.







The paper should make more clear exactly where the problem lies and wh=
en. If it



can occur for a number of reasons, explaining each of those scenarios =
would be



useful.









[JL] I've attempted to do so in the =9604 update.











    Critics of the practice of DNS whitelisting ha=
ve articulated several


    concerns.  Among these are that:






    o  DNS whitelisting is a very differ=
ent behavior from the current


       practice concerning the publishin=
g of IPv4 address resource


       records,







    o  that it may create a two-tiered I=
nternet,







    o  that policies concerning whitelis=
ting and de-whitelisting are


       opaque,







Livingood          &=
nbsp;     Expires August 26, 2011   =
;            &n=
bsp;[Page 5]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












    o  that DNS whitelisting reduces int=
erest in the deployment of IPv6,







    o  that new operational and manageme=
nt burdens are created,









well, yeah... in fact it should be noted that the burdens are particul=
arly 


onerous at scale.









[JL] Ack =96 updated the text to reflect this





















    o  and that the costs and negative i=
mplications of DNS whitelisting


       outweigh the perceived benefits, =
compared to fixing underlying


       impairments.









and it doesn't scale.







and it violates an extremely basic premise of cross-Internet interoper=
ability by



requiring prior arrangement.









[JL] Ack =96 added this











    This document explores the reasons and motivat=
ions for DNS


    whitelisting.  It also explores the =
outlined concerns regarding this


    practice.  Readers will hopefully be=
tter understand what DNS


    whitelisting is, why some parties are implemen=
ting it, and what


    criticisms of the practice exist.












2.  How DNS Whitelisting Works









How IPv6 AAAA DNS Whitelisting Works.







(Anti-spam DNS Whitelisting works rather differently...)














    DNS whitelisting is implemented in authoritati=
ve DNS servers.  These


    servers implement IP address-based restriction=
s on AAAA query


    responses.  So far, DNS whitelisting=
 has been primarily implemented


    by web server operators deploying IPv6-enabled=
 services.  For a given









Really?  This is web-specific?  The same restricti=
ons are not applied for other



applications?







So if the same client-side hosts attempt to contact the server for ema=
il or 


xmpp, they won't get the same handling?









[JL] Quite so =96 I updated the text to clarify this.











    operator of a website, such as www.example.com=
, the operator


    essentially applies an access control list (AC=
L) on the authoritative


    DNS servers for the domain example.com. &=
nbsp;The ACL is populated with









An ACL usually is a yes/no mechanism.  Here, however, the me=
chanism is for 


asserting a preference for IPv6 over IPv4.







That does not seem to match the definition of ACL that I'm used to, un=
less the



semantic is defined as denying IPv4 access to the listed clients.






The term ACL is particularly odd to use if the mechanism pertains to r=
esponses



rather than queries.









[JL] I am using 'ACL' in the most general possible sense and am open t=
o alternative descriptors if you wish to suggest one. But most people seem =
to know an ACL is a list that, if you are listed on it, grants you access t=
o some resource. In this case if
 the resolver is on the list then it gets AAAA RRs.











    the IPv4 and/or IPv6 addresses or prefix range=
s of DNS recursive









Either address type can be listed?  So this really is a pure=
 'preferences' 


mechanism?







Which settings count as whitelisting?  Do any count as black=
listing?









[JL] A resolver can have both IPv6 and IPv4 addresses. Whether a resol=
ver is listed on the whitelist and is therefore able to receive AAAA RR res=
ponses is orthogonal to whether the resolver itself has an IPv4 or IPv6 add=
ress =97 since the whitelisting decision
 making tends to be based on some conclusion about the hosts that query the=
 resolver rather than the resolver.











    resolvers on the Internet, which have been aut=
horized to receive AAAA


    resource record responses.  These DN=
S recursive resolvers are


    operated by third parties, such as ISPs, unive=
rsities, governments,


    businesses, and individual end users. &nb=
sp;If a DNS recursive resolver IS


    NOT matched in the ACL, then AAAA resource rec=
ords will NOT be sent


    in response to a query for a hostname in the e=
xample.com domain.









This configuration appears to ensure the maximum barrier to adoption f=
or IPv6,



since it means that IPv6 will not work automatically.  It wi=
ll only work for



hosts that are manually configured to receive responses with v6 record=
s.







That's a rather major implication.  It's a default that is p=
robably meant to



apply during the very early stages of adoption, when there are few use=
rs of the



newer mechanism.







It's probably worth discussing it in more detail, including discussing=
 when to



change the default...









[JL] Correct on all 3 points. I've tried to address this better in the=
 =9604 version.











    However, if a DNS recursive resolver IS matche=
d in the ACL, then AAAA


    resource records will be sent in response to a=
 query for a given


    hostname in the example.com domain.  =
;While these are not network-


    layer access controls they are nonetheless acc=
ess controls that are a


    factor for end users and other parties like ne=
twork operators,


    especially as networks and hosts transition fr=
om one network address


    family to another (IPv4 to IPv6).









Also, all of this clarifies the function of this listing mechanism and=
 suggests



a very different name, to be more precise and accurate in naming it:






     IPv6 DNS Response Preference List.









[JL] I've added all the various naming suggestions to the Open Issues =
section.











    In practice, DNS whitelisting generally means =
that a very small


    fraction of the DNS recursive resolvers on the=
 Internet (those in the


    whitelist ACL) will receive AAAA responses.&nb=
sp; The large majority of


    DNS resolvers on the Internet will therefore r=
eceive only A resource


    records containing IPv4 addresses.  =
Thus, quite simply, the


    authoritative server hands out different answe=
rs depending upon who


    is asking; with IPv4 and IPv6 resource records=
 for some on the


    authorized whitelist, and only IPv4 resource r=
ecords for everyone


    else.  See Section 2.1 and Figure 1 =
for a description of how this

















Livingood          &=
nbsp;     Expires August 26, 2011   =
;            &n=
bsp;[Page 6]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












    works.







    Finally, DNS whitelisting can be deployed in t=
wo primary ways:


    universally on a global basis, or on an ad hoc=
 basis.  Deployment on


    a universal deployment basis means that DNS wh=
itelisting is


    implemented on all authoritative DNS servers, =
across the entire


    Internet.  In contrast, deployment o=
n an ad hoc basis means that only


    some authoritative DNS servers, and perhaps ev=
en only a few,


    implement DNS whitelisting.  These t=
wo potential deployment models


    are described in Section 6.







2.1.  Description of the Operation of DNS Whitelisting







    The system logic of DNS whitelisting is as fol=
lows:







    1.  The authoritative DNS server for=
 example.com receives DNS queries


        for the A (IPv4) and A=
AAA (IPv6) address resource records for the


        FQDN www.example.com, =
for which AAAA (IPv6) resource records


        exist.









This means that the mechanism is /only/ triggered when /both/ address =
records



are queried?  A query for only one type of address record wo=
n't trigger the list



lookup?  I think that doesn't match other statements in the =
document.









[JL] Updated to clarify / correct my text. (changed A and AAAA to and/=
or)





















    2.  The authoritative DNS server exa=
mines the IP address of the DNS


        recursive resolver sen=
ding the AAAA (IPv6) query.









"examines"?  Examines it for what?  What=
 does this step mean?









[JL] Examines as in looks at the IP address. I'll just simplify it and=
 combine it with #3.











    3.  The authoritative DNS server che=
cks this IP address against the


        access control list (A=
CL) that is the DNS whitelist.







    4.  If the DNS recursive resolver's =
IP address IS matched in the ACL,


        then the response to t=
hat specific DNS recursive resolver can


        contain AAAA (IPv6) ad=
dress resource records.









Oh.  This is not about whether to send responses /over/ v6 v=
s. v4?  This is 


whether to /include/ a particular type of RR in responses???







In that case an appropriate name for this mechanism is more like:






    DNS Response Content Preference List









[JL] Adding this suggested name to the Open Issues list as well.









And this seems even less like an ACL than it did before.  (I=
 assume the 


justification is that access is being prevented by virtue of not suppl=
ying the



address, but still...)














    5.  If the DNS recursive resolver's =
IP address IS NOT matched in the


        ACL, then the response=
 to that specific DNS recursive resolver


        cannot contain AAAA (I=
Pv6) address resource records.  In this


        case, the server shoul=
d return a response with the response code


        (RCODE) being set to 0=
 (No Error) with an empty answer section


        for the AAAA record qu=
ery.







Livingood          &=
nbsp;     Expires August 26, 2011   =
;            &n=
bsp;[Page 7]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












    ----------------------------------------------=
-----------------------


    A query is sent from a DNS recursive resolver =
that IS NOT on the DNS


    whitelist:







           &nbs=
p;    Request       =
            &nb=
sp;  Request


           &nbs=
p;www.example.com         &nbs=
p;        www.example.com


           &nbs=
p;      AAAA    +----=
---------+     AAAA    +---=
--------------+


      ++--++  =
 ---------> |  RESOLVER   |  --------->=
 | www.example.com |


      ||  ||   =
    A      | **IS NOT** &=
nbsp;|      A     &n=
bsp;| IN A exists     |


    +-++--++-+ ---------&g=
t; |     ON      | &=
nbsp;---------> | IN AAAA exists  |


    +--------+     A&n=
bsp;     | example.com |    &n=
bsp; A      |    &nb=
sp;            |

       Host    <-=
-------- |  WHITELIST  |  <--------- |&nbs=
p;            &=
nbsp;   |


     Computer   A Record  +=
;-------------+  A Record   +-----------------&=
#43;


           &nbs=
p;    Response   DNS Recursive   Re=
sponse       example.com


           &nbs=
p;   (only IPv4)   Resolver     (on=
ly IPv4)    Authoritative


           &nbs=
p;            &=
nbsp;      #1      &=
nbsp;           &nbs=
p;        Server


    ----------------------------------------------=
-----------------------


    A query is sent from a DNS recursive resolver =
that IS on the DNS


    whitelist:







           &nbs=
p;    Request       =
            &nb=
sp;  Request


           &nbs=
p;www.example.com         &nbs=
p;        www.example.com


           &nbs=
p;     AAAA     +-------------&=
#43;     AAAA    +-------------=
----+


      ++--++  =
 ---------> |  RESOLVER   |  --------->=
 | www.example.com |


      ||  ||   =
    A      |   **IS*=
*    |      A  =
    | IN A exists     |


    +-++--++-+ ---------&g=
t; |     ON      | &=
nbsp;---------> | IN AAAA exists  |


    +--------+   AAAA  =
;   | example.com |     AAAA   =
; |           &=
nbsp;     |


       Host    <-=
-------- |  WHITELIST  |  <--------- |&nbs=
p;            &=
nbsp;   |


     Computer      A=
      |      &n=
bsp;      |      A&n=
bsp;     |      &nbs=
p;          |


           &nbs=
p;   <--------- |       &nb=
sp;     |  <--------- |   &=
nbsp;           &nbs=
p; |


           &nbs=
p;   A and AAAA +-------------+ A and AAAA  =
3;-----------------+


           &nbs=
p;    Record     DNS Recursive =
;  Record        example.com

           &nbs=
p;   Responses     Resolver   =
  Responses      Authoritative


           &nbs=
p;   (IPv4+IPv6)      #2 &=
nbsp;      (IPv4+IPv6)   &=
nbsp;   Server


    ----------------------------------------------=
-----------------------







           &nbs=
p;   Figure 1: DNS Whitelisting - Functional Diagram









This diagram is confusing to me.  I suspect that a protocol =
exchange sequence



format, in the style of:







      Host     =
        Resolver 1   &nbs=
p;        Authoritative







           ---------=
->


           &nbs=
p;            &=
nbsp;         --------->

           &nbs=
p;            &=
nbsp;        <---------


          <------=
----







will be considerably more helpful.









[JL] I took a stab at a new diagram in =9604 =97 so take a look and le=
t me know if it is what you are suggesting (I've left the original one in f=
or now).











3.  What Problems Are Implementers Trying To Solve?









This is a very useful section and it is probably worth moving it highe=
r, to 


precede the 'how it works' section.














    As noted in Section 1, domains which implement=
 DNS whitelisting are


    attempting to protect a few users of their dom=
ain, who have impaired


    IPv6 access, from having a negative experience=
 (poor performance).









By the way, what does 'impaired v6 access' mean?







I think there needs to be a simple, direct description of what occurs =
without



this mechanism.







For example, perhaps you mean that a host can send DNS queries using I=
Pv6 but



cannot receive DNS responses over IPv6? Perhaps you mean that the host=
 can send



IPv6 but cannot receive it.  (That's a different scale and s=
cope of problem from



the first example I gave.)







This brief, summary problem statement should be included in the Abstra=
ct, to



make /much/ more clear what this mechanism is for.









[JL] Done. Added text to the Abstract and Intro and added more to note=
 that this is about both impairment and (actual or perceived) immaturity of=
 IPv6 network routing and practices.





















    While it is outside the scope of this document=
 to explore the various


    reasons why a particular user's system (host) =
may have impaired IPv6


    access, for the users who experience this impa=
irment it is a very


    real performance impact.  It would a=
ffect access to all or most dual

















Livingood          &=
nbsp;     Expires August 26, 2011   =
;            &n=
bsp;[Page 8]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












    stack services to which the user attempts to c=
onnect.  This negative


    end user experience can range from someone slo=
wer than usual (as


    compared to native IPv4-based access), to extr=
emely slow, to no


    access to the domain whatsoever.









Rather than repeat that this is about end-users, it sounds more that t=
his is



about whether a service works or does not work, whether a user is dire=
ctly 


present or not.














    While one can debate whether DNS whitelisting =
is the optimal solution


    to the end user experience problem, it is quit=
e clear that DNS


    whitelisting implementers are interested in ma=
ximizing the


    performance of their services for end users as=
 a primary motivation


    for implementation.









You keep citing 'performance' but haven't described what sort of perfo=
rmance



degradation takes place. Is this really about relatively better or wor=
se 


performance -- and if so, how -- or is this about working or not worki=
ng?









[JL] Good point =96 I added this text: 


"In essence, whether the end user even has an IPv6 address or =
not (they probably only have an IPv4 address), merely by receiving a AAAA r=
ecord response the user either cannot access a FQDN or it is so slow that t=
he user gives up and assumes the destination
 is unreachable."









Also rather than saying what implementers are interested in, it's prob=
ably more



helpful to note that the practice is now significantly established and=
 therefore



worth documenting, independent of its possible controversy.














    At least one highly-trafficked domain has note=
d that they have


    received requests to not send DNS responses wi=
th AAAA resource


    records to particular resolvers.  In=
 this case, the operators of









"At least one" seems a rather tiny statistic.  Per=
haps the actual statistic is



significantly larger?









[JL] It does not seem to be. Other than this being passed along by Goo=
gle, I've not heard of any similar stories. Nevertheless, it seemed interes=
ting enough to include.











    those recursive resolvers have expressed a con=
cern that their IPv6









I suspect that it's not resolvers that are doing the expressing, since=
 their



vocabulary is usually too limited...









[JL] Quite. Updated:


"In this case, DNS recursive resolvers operators have expresse=
d=85"











    network infrastructure is not yet ready to han=
dle the large traffic


    volume which may be associated with the hosts =
in their network


    connecting to the websites of these domains.&n=
bsp; This concern is clearly









So even though the site allows v6 DNS queries to go out from a host, i=
t can't



really support having the host use v6?









[JL] A network isn't really in control of the end host's limitations w=
/r/t IPv6 impairment. A good summary of the issue of impairment is @ <=
a href=3D"http://www.fud.no/ipv6/">http://www.fud.no/ipv6/









Wow. I do understand why service providers often have to work around s=
illiness



at the client side, but this problem at the client side seems particul=
arly 


egregious.














    a temporary consideration relating to the depl=
oyment of IPv6 network


    infrastructure on the part of networks with en=
d user hosts, rather


    than a long-term concern.  These end=
 user networks may also have









Again this goal of short-term usage is worth noting earlier, including=
 in the



Abstract.














    other tools at their disposal in order to addr=
ess this concern,


    including applying rules to network equipment =
such as routers and


    firewalls (this will necessarily vary by the t=
ype of network, as well


    as the technologies used and the design of a g=
iven network), as well


    as configuration of their recursive resolvers =
(though modifying or


    suppressing AAAA resource records in a DNSSEC-=
signed domain on a


    Security-Aware Resolver will be problematic Se=
ction 10.1).







    Some implementers with highly-trafficked domai=
ns have explained that


    DNS whitelisting is a necessary, though tempor=
ary, risk reduction


    tactic intended to ease their transition to IP=
v6 and minimize any


    perceived risk in such a transition. &nbs=
p;As a result, they perceive this


    as a tactic to enable them to incrementally en=
able IPv6 connectivity


    to their domains during the early phases of th=
eir transition to IPv6.







    Finally, some domains, have run IPv6 experimen=
ts whereby they added


    AAAA resource records and observed and measure=
d errors [Heise Online


    Experiment], which should be important reading=
 for any domain


    contemplating either the use of DNS whitelisti=
ng or simply adding


    IPv6 addressing to their site.












4.  Concerns Regarding DNS Whitelisting







    There are a number of potential implications r=
elating to DNS


    whitelisting, which have been raised as concer=
ns by some parts of the


    Internet community.  Many of those p=
otential implications are further









I think the implications are not conditional; they exist rather than b=
eing 


potential.  The 'potential' is that what is implicated will =
come to pass.









[JL] Fair point =96 removed 'potential' there and in another similar s=
ection.
















Livingood          &=
nbsp;     Expires August 26, 2011   =
;            &n=
bsp;[Page 9]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












    enumerated here and in Section 7.









Pro forma question:  Why are implications discussed in multi=
ple places?









[JL] Some of them in are briefly noted in Section 4, but the exhaustiv=
e list in in Section 7. 





















    Some parties in the Internet community, includ=
ing ISPs, are concerned









This style of text personalizes the issues unnecessarily (IMO). &=
nbsp;It does not



really matter who holds the concerns, or else they'd be described more=
 precisely.









[JL] I'll have to look at that after the =9604 update. In a previous d=
raft I was asked to call out different parts of the community separately. (=
Always challenging to work through conflicting feedback.)














I suggest merely noting that there are concerns and then listing and d=
iscussing



the concerns, rather than adding text to attribute the concerns to oth=
ers, even



if the conclusion of your text is that a particular concern is not val=
id.









[JL] Duly noted. Let me get the =9604 update out, after which I will l=
ook at generally simplifying the I-D and look at this issue specifically.




















    that the practice of DNS whitelisting for IPv6=
 address resource


    records represents a departure from the genera=
lly accepted practices


    regarding IPv4 address resource records in the=
 DNS on the Internet


    [Whitelisting Concerns].  These part=
ies explain their belief that for









"These parties explain their belief" is an example of person=
alization that is



not needed.  This isn't about the believers.  It i=
s about possible problems.









[JL] Ack.











    A resource records, containing IPv4 addresses,=
 once an authoritative


    server operator adds the A record to the DNS, =
then any DNS recursive


    resolver on the Internet can receive that A re=
cord in response to a









This does not appear to be a grammatically valid sentence.  =
My guess is that



deleting "A resource... addresses" fixes this.









[JL] Change made.









And by the way, the document's reference to "recursive" reso=
lvers is mostly


likely incorrect.  The problem is not restricted only to tha=
t very specific type



of resolver, is it?







If in fact it /is/ specific to them -- and your following text describ=
es an 


indirect effects scenario where it might be -- I suggest calling out t=
he 


configuration at the beginning, along the lines of:







      One way the problem with returning=
 AAAA records can be experienced is when



recursive resolvers are used.  Although that resolver might =
support IPv6, its



client hosts might not.  So, returning an AAAA record will m=
ean that these 


limited hosts will be given an unusable address.







And this type of description belongs in the text describing the motiva=
ting 


problem(s), rather than buried in the 'concerns' discussion.







(The text, here, pertains to A records, but the problem I've described=
 uses the



same configuration but for AAAA records with mixed v6 support.)














    query.  By extension, this means tha=
t any of the hosts connected to


    any of these DNS recursive resolvers can recei=
ve the IPv4 address


    resource records for a given FQDN.  =
This enables new server hosts


    which are connected to the Internet, and for w=
hich a fully qualified


    domain name (FQDN) such as www.example.com has=
 been added to the DNS


    with an IPv4 address record, to be almost imme=
diately reachable by


    any host on the Internet.  In this c=
ase, these new servers hosts


    become more and more widely accessible as new =
networks and new end


    user hosts connect to the Internet over time, =
capitalizing on and


    increasing so-called "network effects&quo=
t; (also called network


    externalities).  It also means that =
the new server hosts do not need


    to know about these new networks and new end u=
ser hosts in order to


    make their content and applications available =
to them, in essence


    that each end in this end-to-end model is resp=
onsible for connecting


    to the Internet and once they have done so the=
y can connect to each


    other without additional impediments or middle=
 networks or


    intervening networks or servers knowing about =
these end points and


    whether one is allowed to contact the other.








Hmmm.  This rather lengthy bit of prose appears merely to be=
 explaining the 


basic and long-standing DNS value proposition???









[JL] Ack =96 see previous comments about simplification. At the same t=
ime I'm trying to keep the document understandable to wide audience (and on=
e of your other notes suggested I need to be somewhat less technical or mor=
e descriptive). You may be more familiar
 with the mechanics of DNS whereas someone else is less so. I'll think abou=
t this one=85











    In contrast, the concern is that DNS whitelist=
ing may fundamentally


    change this model.  In the altered D=
NS whitelisting end-to-end model,


    one end (where the end user is located) cannot=
 readily connect to the


    other end (where the content is located), with=
out parts of the middle


    (recursive resolvers) used by one end (the cli=
ent, or end user hosts)


    being known to an intermediary (authoritative =
nameservers) and


    approved for access to the resource at the end=
.  As new networks


    connect to the Internet over time, those netwo=
rks need to contact any


    and all domains which have implemented DNS whi=
telisting in order to


    apply to be added to their DNS whitelist, in t=
he hopes of making the


    content and applications residing on named ser=
ver hosts in those


    domains accessible by the end user hosts on th=
at new network.


    Furthermore, this same need to contact all dom=
ains implementing DNS


    whitelisting also applies to all pre-existing =
(but not whitelisted)


    networks connected to the Internet.







    In the current IPv4 Internet when a new server=
 host is added to the


    Internet it is generally widely available to a=
ll end user hosts and


    networks, when DNS whitelisting of IPv6 resour=
ce records is used,









If it is available to the hosts, it is available to the network.







networks, when -> networks. When









[JL] Fixed




































Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 1=
0]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












    these new server hosts are not accessible to a=
ny end user hosts or


    networks until such time as the operator of th=
e authoritative DNS









They are still accessible.  The IP-level mechanisms still wo=
rk.







They are not reachable when using the domain name.









[JL] Fixed





















    servers for those new server hosts expressly a=
uthorizes access to


    those new server hosts by adding DNS recursive=
 resolvers around the


    Internet to the ACL.  This has the p=
otential to be a significant









This is a good example of the reason the term ACL is inappropriate:&nb=
sp; It implies



a security protection that does not actually exist.  The hos=
ts are still accessible.









[JL] I still think the whitelist is comparable to an ACL insofar as it=
 controls access to AAAA RR responses on the authoritative server, regardle=
ss of access by IP address to some destination host.











    change in reachability of content and applicat=
ions by end users and


    networks as these end user hosts and networks =
transition to IPv6,


    resulting in more (but different) breakage.&nb=
sp; A concern expressed is


    that if much of the content that end users are=
 most interested in is


    not accessible as a result, then end users and=
/or networks may resist


    adoption of IPv6 or actively seek alternatives=
 to it, such as using


    multi-layer network address translation (NAT) =
techniques like NAT444


    [I-D.shirasaki-nat444] on a long-term basis.&n=
bsp; There is also concern


    that this practice also could disrupt the cont=
inued increase in


    Internet adoption by end users if they cannot =
simply access new


    content and applications but must instead cont=
act the operator of


    their DNS recursive resolver, such as their IS=
P or another third


    party, to have their DNS recursive resolver au=
thorized for access to


    the content or applications that interests the=
m.  Meanwhile, these


    parties say, over 99.9% of the other end users=
 that are also using


    that same network or DNS recursive resolver ar=
e unable to access the


    IPv6-based content, despite their experience b=
eing a positive one.







    While in Section 1 the level of IPv6-related i=
mpairment has been


    estimated to be as high as 0.078% of Internet =
users, which is a









8 hundredths of one percent?







That's considered a high percentage?









[JL] It is. I joked at one of the v6ops WG meetings awhile ago that at=
 that rate, it'd be cheaper and easier for me (an ISP) to just buy new comp=
uters for the affected "impaired" users than to have to navigate =
years of whitelisting with a variety of domains.
 In any case, one recent measurement estimates it at 0.05% now and another =
at 0.015%. Despite this, this practice is still generating some interest. I=
'm hoping World IPv6 Day goes well and is informative for the community as =
to this percentage on a widespread
 basis, across a wide variety of web sites. 














Even if it is 8%, is that considered high?









[JL] 8% of the Internet finding google.com or facebook.com inaccessibl=
e would be bad for everyone. That could generate several hundred thousand s=
upport calls per day to a big ISP.











5.2.  Similarities to DNS Load Balancing







    DNS whitelisting also has some similarities to=
 DNS load balancing.


    There are of course many ways that DNS load ba=
lancing can be


    performed.  In one example, multiple=
 IP address resource records (A


    and/or AAAA) can be added to the DNS for a giv=
en FQDN.  This approach


    is referred to as DNS round robin [RFC1794].&n=
bsp; DNS round robin may


    also be employed where SRV resource records ar=
e used [RFC2782].









Right, but that's algorithmic rather than involving the manual method,=
 described



here. So it does not seem comparable.









[JL] Whether I agree with you or not, the WG asked to include it in an=
 earlier draft. I tried to simply say that there are "some" simil=
arities as a qualifier. 











6.  Likely Deployment Scenarios







    In considering how DNS whitelisting may emerge=
 more widely, there are


    two likely deployment scenarios, which are exp=
lored below.







    In either of these deployment scenarios, it is=
 possible that


    reputable third parties could create and maint=
ain DNS whitelists, in


    much the same way that blacklists are used for=
 reducing email spam.


    In the email context, a mail operator subscrib=
es to one or more of


    these lists and as such the operational proces=
ses for additions and


    deletions to the list are managed by a third p=
arty.  A similar model


    could emerge for DNS whitelisting, whether dep=
loyment occurs


    universally or on an ad hoc basis.









The challenges of email whitelists and blacklists should be cited, sin=
ce it 


provides a rich base of experience for such an effort, at scale.














6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis







    The seemingly most likely deployment scenario =
is where some









Most likely?  This is not already established practice?








[JL] It is established at some large domains like google.com (which co=
mprise a large % of global Internet traffic). But other domains are now on =
the cusp of their IPv6 transition and are pondering whether or not to use w=
hitelisting. This document will
 hopefully be one of many data points in their decision-making.











    authoritative DNS server operators implement D=
NS whitelisting but


    many or most others do not do so.  W=
hat can make this scenario


    challenging from the standpoint of a DNS recur=
sive resolver operator


    is determining which domains implement DNS whi=
telisting, particularly


    since a domain may not do so as they initially=
 transition to IPv6,


    and may instead do so later.  Thus, =
a DNS recursive resolver operator

















Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 1=
3]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












    may initially believe that they can receive AA=
AA responses as a


    domain adopts IPv6, but then notice via end us=
er reports that they no


    longer receive AAAA responses due to that doma=
in adopting DNS


    whitelisting.  Of course, a domain's=
 IPv6 transition may be


    effectively invisible to recursive server oper=
ators due to the effect


    of DNS whitelisting.









This suggests that every listing at the server needs a contact record =
for 


periodic checks whether to renew the listing.



















    In contrast to a universal deployment of DNS w=
hitelisting


    Section 6.2, deployment on an ad hoc basis is =
likely to be


    significantly more challenging from an operati=
onal, monitoring, and









Oh?  Use in small scale is more challenging than use of manu=
al exceptions list



at large scale?  That's a very unexpected view.









[JL] I think it is in some regards but thinking it through more fully,=
 I think you are correct and I have removed this. 











    troubleshooting standpoint.  In this=
 scenario, a DNS recursive


    resolver operator will have no way to systemat=
ically determine


    whether DNS whitelisting is or is not implemen=
ted for a domain, since


    the absence of AAAA resource records may simpl=
y be indicative that


    the domain has not yet added IPv6 addressing f=
or the domain, rather


    than that they have done so but have restricte=
d query access via DNS









The premise is that, in large scale use, servers /will/ have a way to =



systematically determine whether it is implemented?  What ar=
e the existing 


examples of having such a capability for other Internet protocols and =
services?









[JL] Perhaps I'm overplaying this point, but you know someone has emai=
l service if they have an MX record for example, or a website if the host a=
nswers on TCP/80. But as I re-read this it is probably overkill and so I've=
 deleted it. I have however moved
 some of the text to a prior section, since determining whether or not doma=
ins are whitelisting is still a challenge at scale. 











    whitelisting.  As a result, discover=
ing which domains implement DNS


    whitelisting, in order to differentiate them f=
rom those that do not,


    is likely to be challenging.







    One benefit of DNS whitelisting being deployed=
 on an ad hoc basis is


    that only the domains that are interested in d=
oing so would have to


    upgrade their authoritative DNS servers in ord=
er to implement the


    ACLs necessary to perform DNS whitelisting.






    In this potential deployment scenario, it is a=
lso possible that a


    given domain will implement DNS whitelisting t=
emporarily.  A domain,


    particularly a highly-trafficked domain, may c=
hoose to do so in order


    to ease their transition to IPv6 through a sel=
ective deployment and


    minimize any perceived risk in such a transiti=
on.







6.2.  Deploying DNS Whitelisting Universally







    The least likely deployment scenario is one wh=
ere DNS whitelisting is


    implemented on all authoritative DNS servers, =
across the entire


    Internet.  While this scenario seems=
 less likely than ad hoc


    deployment due to some parties not sharing the=
 concerns that have so


    far motivated the use of DNS whitelisting, it =
is nonetheless


    conceivable that it could be one of the ways i=
n which DNS


    whitelisting is deployed.









Significantly, the partial-deployment model casts this mechanism as a =
transition



expedient -- as the document reasonably describes it -- whereas univer=
sal 


deployment casts it as a fundamental change to the architecture.







Given that it would take decades to achieve relatively full deployment=
 of this



'across the entire Internet', what is the benefit of discussing this h=
ighly 


unlikely scenario?  Is it really "conceivable"?&nb=
sp; I doubt it. If you think 


otherwise, the paper needs to explore the deployment and adoption issu=
es in much



more detail, because I don't see how it could work.









[JL] Per my previous email responses this has been extensively reworke=
d. I feel I should probably leave the universal deployment scenario in ther=
e for completeness, but it's been cut down and minimized. I'm open to recon=
sidering the question later.











   In order for this deployment scenario to occur, it is lik=
ely that DNS


    whitelisting functionality would need to be bu=
ilt into all


    authoritative DNS server software, and that al=
l operators of


    authoritative DNS servers would have to upgrad=
e their software and


    enable this functionality.  It is li=
kely that new Internet Draft


    documents would need to be developed which des=
cribe how to properly


    configure, deploy, and maintain DNS whitelisti=
ng.  As a result, it is







Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 1=
4]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011







    unlikely that DNS whitelisting would, at least=
 in the next several


    years, become universally deployed.  =
;Furthermore, these DNS


    whitelists are likely to vary on a domain-by-d=
omain basis, depending


    upon a variety of factors.  Such fac=
tors may include the motivation


    of each domain owner, the location of the DNS =
recursive resolvers in


    relation to the source content, as well as var=
ious other parameters


    that may be transitory in nature, or unique to=
 a specific end user


    host type.  It is probably unlikely =
that a single clearinghouse for


    managing whitelisting is possible; it will mor=
e likely be unique to


    the source content owners and/or domains which=
 implement DNS


    whitelists.







    While this scenario may be unlikely, it may ca=
rry some benefits.


    First, parties performing troubleshooting woul=
d not have to determine


    whether or not DNS whitelisting was being used=
, as it always would be


    in use.  In addition, if universally=
 deployed, it is possible that


    the criteria for being added to or removed fro=
m a DNS whitelist could


    be standardized across the entire Internet.&nb=
sp; Nevertheless, even if


    uniform DNS whitelisting policies were not sta=
ndardized, is also


    possible that a central registry of these poli=
cies could be developed


    and deployed in order to make it easier to dis=
cover them, a key part


    of achieving transparency regarding DNS whitel=
isting.









Is any of this paragraph realistic?  Obviously my asking mea=
ns I don't it is.



These seem to be of theoretical rather than pragmatic interest. &=
nbsp;("If everyone



refuses to shoot, there will be no wars.")







It's true that this is an "implications" paper rather than a=
 BCP, but still...









[JL] Good point. Paragraph removed.
















7.  Implications of DNS Whitelisting







    There are many potential implications of DNS w=
hitelisting.  The key


    potential implications are detailed below.






7.1.  Architectural Implications







    DNS whitelisting could be perceived as modifyi=
ng the end-to-end model


    and/or the general notion of the architecture =
that prevails on the









I'll suggest that perception is not a major issue about a technical to=
pic like



this.  (It's not entirely irrelevant, of course, but I suspe=
ct it is quite minor.)







The major issue is whether it /actually/ modifies the end-to-end natur=
e of the



DNS.  And I think it does, as well as modifying the "sp=
ontaneous 


interoperability" expectation for most Internet mechanism, since =
it requires



prior registration.









[JL] Removed the perception stuff=85





















7.2.  Public IPv6 Address Reachability Implications







    The predominant experience of end user hosts a=
nd servers on the IPv4-


    addressed Internet today is that when a new se=
rver with a public IPv4


    address is added to the DNS, that it is then g=
lobally accessible by









This sentence is not quite correct, in strict technical terms. &n=
bsp;Since this is a



technical discussion, we need to be precise:  the host is re=
achable when the



routing tables make it reachable.  That's strictly a mapper =
of IP Address 


handling, not name-to-address mapping.







What you mean is that its domain name is immediately useful for reachi=
ng it.









[JL] Correction made. 





















    IPv4-addressed hosts.  This is a gen=
eralization and in Section 5


    there are examples of common cases where this =
may not necessarily be


    the case.  For the purposes of this =
argument, that concept of


    accessibility can be considered "pervasiv=
e reachability".  It has so


    far been assumed that the same expectations of=
 pervasive reachability


    would exist in the IPv6-addressed Internet.&nb=
sp; However, if DNS


    whitelisting is deployed, this will not be the=
 case since only end


    user hosts using DNS recursive resolvers which=
 are included in the









again, you mean /name-based/ reachability.









[JL] Fixed. In a way I was grasping at the "spontaneous inte=
roperability" notion you mentioned.
















Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 1=
6]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












    ACL of a given domain using DNS whitelisting w=
ould be able to reach


    new servers in that given domain via IPv6 addr=
esses.  The expectation


    of any end user host being able to connect to =
any server (essentially


    both hosts, just at either end of the network)=
, defined here as


    "pervasive reachability", will chang=
e to "restricted reachability"


    with IPv6.







    Establishing DNS whitelisting as an accepted p=
ractice in the early


    phases of mass IPv6 deployment could well esta=
blish it as an integral


    part of how IPv6 DNS resource records are depl=
oyed globally.  As a


    result, it is then possible that DNS whitelist=
ing could live on for


    decades on the Internet as a key foundational =
element of domain name


    management that we will all live with for a lo=
ng time.









(that last sentence could benefit from some editing.)









[JL] Ack =96 fixed.











    It is a critical to understand that the concep=
t of reachability


    described above depends upon a knowledge or aw=
areness of an address


    in the DNS.  Thus, in order to estab=
lish reachability to an end


    point, a host is dependent upon looking up an =
IP address in the DNS









If this section were started with a sentence like this, then there wou=
ld not be



a problem with the other references' being confused with address-based=
 routing



reachability.









[JL] Great point! I've actually moved the last paragraph to the start =
of that section and it makes much more sense. 











    when a FQDN is used.  When DNS white=
listing is used, it is quite


    likely the case that an IPv6-enabled end user =
host could ping or


    connect to an example server host, even though=
 the FQDN associated


    with that server host is restricted via a DNS =
whitelist.  Since most









First, I suspect that "example" doesn't add meaning to the s=
entence.  Second,



pinging and connecting might happen with or without the whitelist entr=
y.  So I



do not understand what import there is in this sentence.









[JL] I removed pinging but left connecting. What I'm saying you may st=
ill be able to connect to the host via an IP if you cannot use the FQDN (it=
 won't always be the case, such as on a virtual web server sharing one IP a=
cross several sites). I'll reword
 it a bit though since I see your point.











    Internet applications and hosts such as web se=
rvers depend upon the


    DNS, and as end users connect to FQDNs such as=
 www.example.com and do


    not remember or wish to type in an IP address,=
 the notion of


    reachability described here should be understo=
od to include knowledge


    how to associate a name with a network address=
.









Again, this 'premise' statement should introduce the sub-section, not =
end it.









[JL] Done (as noted above)
















7.3.  Operational Implications







    This section explores some of the operational =
implications which may


    occur as a result of, are related to, or becom=
e necessary when


    engaging in the practice of DNS whitelisting.<=
/div>






7.3.1.  De-Whitelisting May Occur









The more general version of this issue is 'synchronization'. &nbs=
p;Entries in the



whitelist need to be synchronized with host status and capabilities.













    It is possible for a DNS recursive resolver ad=
ded to a whitelist to


    then be removed from the whitelist, also known=
 as de-whitelisting.


    Since de-whitelisting can occur, through a dec=
ision by the


    authoritative server operator, the domain owne=
r, or even due to a


    technical error, an operator of a DNS recursiv=
e resolver will have


    new operational and monitoring requirements an=
d/or needs as noted in


    Section 7.3.3, Section 7.3.4, Section 7.3.6, a=
nd Section 7.5.







7.3.2.  Authoritative DNS Server Operational Implications






    Operators of authoritative servers may need to=
 maintain an ACL a









a -> on a (?)









[JL] fixed





















    server-wide basis affecting all domains, on a =
domain-by-domain basis,












Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 1=
7]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












    as well as on a combination of the two. &=
nbsp;As a result, operational









I'm not really understanding the first sentence.  One proble=
m might be that its



discussing an implication of some configuration or usage options that =
have not



been previously specified, so that the reference here might be overly =
cryptic.







For example, I don't know what "affecting all domains" actua=
lly means.  It 


almost sounds as if it could mean "everyone gets AAAA records&quo=
t; or "no one gets



AAAA records" yet I'm reaonably certain that is /not/ what is mea=
nt.









[JL] Yes, that sentence was unclear. It is now:


"Operators of authoritative servers (which are frequent=
ly authoritative for multiple domain names) will need to maintain an ACL on=
 a server-wide basis affecting all domains, or on a domain-by-domain basis.=
"











    practices and software capabilities may need to be =
developed in order


    to support such functionality.  In a=
ddition, processes may need to be


    put in place to protect against inadvertently =
adding or removing IP


    addresses, as well as systems and/or processes=
 to respond to such


    incidents if and when they occur.  F=
or example, a system may be


    needed to record DNS whitelisting requests, re=
port on their status


    along a workflow, add IP addresses when whitel=
isting has been


    approved, remove IP addresses when they have b=
een de-whitelisted, log


    the personnel involved and timing of changes, =
schedule changes to


    occur in the future, and to roll back any inad=
vertent changes.









Might be worth starting with a simple, broad summary statement, possib=
ly along



the lines of:







    An AAAA DNS Whitelist serves as a critical inf=
rastructure service; to be



useful it needs careful and extensive administration, monitoring and o=
peration.



  Each new and essential mechanism creates substantial follo=
w-on support costs.









[JL] Thanks =96 added that text.





















    Operators may also need implement new forms of=
 monitoring in order to


    apply change control, as noted briefly in Sect=
ion 7.3.4.







7.3.3.  DNS Recursive Resolver Server Operational Implicatio=
ns







    Operators of DNS recursive resolvers, which ma=
y include ISPs,


    enterprises, universities, governments, indivi=
dual end users, and


    many other parties, are likely to need to impl=
ement new forms of


    monitoring, as noted briefly in Section 7.3.4.=
  But more critically,


    such operators may need to add people, process=
es, and systems in


    order to manage large numbers of DNS whitelist=
ing applications as


    part of their own IPv6 transition, for all dom=
ains that the end users


    of such servers are interested in now or in wh=
ich they may be









I think the summary observation is simple and should be stated directl=
y:  This



is a manual mechanism that becomes expensive in time and personnel eff=
ort as it



scales up.









[JL] Added that





















    interested in the future.  As antici=
pation of interesting domains is


    likely infeasible, it is more likely that oper=
ators may either choose


    to only apply to be whitelisted for a domain b=
ased upon one or more


    end user requests, or that they will attempt t=
o do so for all domains


    that they can ascertain to be engaging in DNS =
whitelisting.









"attempt to do so for all domain that they can ascertain to be en=
gaging in DNS



whitelisting"  appears to be saying to do whitelisting =
for domains that do 


whitelisting.  I don't understand.









[JL] I was going to great effort to badly make a point that you can't =
anticipate all domains users will want to access and so will need a way for=
 users to request whitelisting instead. I've reworded as:


"But more critically, such operators will need to add people, =
processes, and systems in order to manage large numbers of DNS Whitelisting=
 applications. Since there is no common method for determining whether or n=
ot a domain is engaged in DNS Whitelisting,
 operators will have to apply to be whitelisted for a domain based upon one=
 or more end user requests, which means systems, processes, and personnel f=
or handling and responding to those requests will also be necessary."<=
/i>
















    When operators apply for DNS whitelisting for =
all domains, that may









"apply for DNS whitelisting for all domains" -- again I'm no=
t understanding what



this means.









[JL] See above











7.3.5.  Implications of Operational Momentum







    It seems plausible that once DNS whitelisting =
is implemented it will


    be very difficult to deprecate such technical =
and operational


    practices.  This assumption is based=
 in an understanding of human









in -> on









[JL] Fixed











    nature, not to mention physics.  For=
 example, as Sir Issac Newton


    noted, "Every object in a state of unifor=
m motion tends to remain in


    that state of motion unless an external force =
is applied to it" [Laws









Code does not have momenum.  Neither do configurations or li=
sts.  This really



isn't about physics.









[JL] But people and processes do have (operational) momentum=85









It is entirely about group psychology, as you note, and the administra=
tive 


challenges in the logistics of large-scale operational changes (which =
probably



/does/ have something to with physics, but it seems a stretch to credi=
t Newton.



How about Heisenberg?...)









[JL] Hmmm=85 I don't think it is Heisenberg-related. But it's such an =
interesting citation I feel it's almost a personal challenge to figure out =
a way to keep it in there. ;-) The way I think about it is that in 5 or 10 =
years none of the people working on
 the details of the IPv6 transition now will still be involved in the day-t=
o-day operational work. But DNS Whitelisting could still be in place =96 an=
d once something gets a momentum to it (people, processes, and organization=
s) it is really, really hard to change
 that. This seems very much like the physics principle to which I refer but=
 I'm open to other citations. I envision this possibility:


Q (from new trainee): Why are we doing this DNS Whitelisting thing?

A: Because that's what we have to do for IPv6 access to every new doma=
in.


Q: Why? 


A: Because we've been doing it for years and it says to do it here in =
this operations manual we have to follow.


Q: Then I guess we should keep doing it? 


A: Yes, we should. It'd be hard to change the standard process, and we=
'd have to escalate it to someone, etc.  











    of Motion].  Thus, once DNS whitelis=
ting is implemented it is quite


    likely that it would take considerable effort =
to deprecate the


    practice and remove it everywhere on the Inter=
net - it will otherwise


    simply remain in place in perpetuity. &nb=
sp;To better illustrate this


    point, one could consider one example (of many=
) that there are many


    email servers continuing to attempt to query o=
r otherwise check anti-

















Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 1=
9]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












    spam DNS blocklists which have long ago ceased=
 to exist.







7.3.6.  Troubleshooting Implications







    The implications of DNS whitelisted present ma=
ny challenges, which


    have been detailed in Section 7.  Th=
ese challenges may negatively









But this is /still/ section 7.  Can you be more specific?&nb=
sp; Or perhaps say 


"throughout this section".









[JL] fixed





















    affect the end users' ability to troubleshoot,=
 as well as that of DNS


    recursive resolver operators, ISPs, content pr=
oviders, domain owners


    (where they may be different from the operator=
 of the authoritative


    DNS server for their domain), and other third =
parties.  This may make


    the process of determining why a server is not=
 reachable


    significantly more complex.







7.3.7.  Additional Implications If Deployed On An Ad Hoc Bas=
is







    Additional implications, should this be deploy=
ed on an ad hoc basis,


    could include scalability problems relating to=
 operational processes,









I'm pretty sure that scaling problems for this exist in all scenarios,=
 not just



ad hoc usage.









[JL] True. Simplified to:


"As more domains choose to implement DNS Whitelisting, and mor=
e networks become IPv6-capable and request to be whitelisted, scaling up op=
erational processes, monitoring, and ACL updates will become more difficult=
. The increased rate of change and increased
 size of whitelists will increase the likelihood of configuration and other=
 operational errors."











    monitoring, and ACL updates.  In par=
ticular, it seems likely that as


    the number of domains that are using DNS white=
listing increases, as


    well as the number of IPv6-capable networks re=
questing to be


    whitelisted, that there is an increased likeli=
hood of configuration


    and other operational errors, especially with =
respect to the ACLs


    themselves.







    It is unclear when and if it would be appropri=
ate to change from


    whitelisting to blacklisting, and whether or h=
ow this could feasibly


    be coordinated across the Internet, which may =
be proposed or









Actually the question of coordination is quite clear and rather fundam=
ental:







      No.







Anyone believing otherwise needs to cite a successful example, at Inte=
rnet scale



and diversity, more recently than the 1983 switch to IP (which didn't =
go all



that well anyhow...)







Simple, unambiguous showstoppers should be stated in a simple and dire=
ct manner.



  When there is room for debate, softer language makes sense=
.  Again, if the



question of coordination really is subject to debate, then the basis n=
eeds to be



stated.  (Good luck!)









[JL] That's not encouraging=85 Changed to: 


"It is unclear when and if it would be appropriate to change f=
rom whitelisting to blacklisting. It is clear that trying to coordinate thi=
s across the Internet is likely be be impossible, so such a change to black=
listing would happen on a domain-by-domain
 basis (if at all)."











    implemented on an ad hoc basis when a majority=
 of networks (or


    allocated IPv6 address blocks) have been white=
listed.  Finally, some


    parties implementing DNS whitelisting consider=
 this to be a temporary


    measure.  As such, it is not clear h=
ow these parties will judge the


    network conditions to have changed sufficientl=
y to justify disabling


    DNS whitelisting and/or what the process and t=
iming will be in order


    to discontinue this practice.







    One further potential implication is that an e=
nd user with only an


    IPv4 address, using a DNS resolver which has n=
ot been whitelisted by


    any domains, would not be able to get any AAAA=
 resource records.  In


    such a case, this could give that end user the=
 incorrect impression


    that there is no IPv6-based content on the Int=
ernet since they are


    unable to discover any IPv6 addresses via the =
DNS.







7.4.  Homogeneity May Be Encouraged







    A broad trend which has existed on the Interne=
t appears to be a move


    towards increasing levels of heterogeneity.&nb=
sp; One manifestation of









increasing levels of heterogeneity -> more heterogeneity









[JL] fixed














(I think heterogeneity does not have 'levels'.)







Substantively:  say the nature of the heterogeneity within t=
he initial claim.



For example, there is /less/ heterogeneity of ISPs, given industry 

consolidation.  There is less heterogeneity of infrastructur=
e equipment such as



routers.  Etc.









[JL] I have gotten lots and lots of questions related to this section,=
 which led me to conclude that I've done a poor job stating the issue. I wa=
s dancing around it but here it is more directly in an updated section (the=
 new 2nd  and final paragraph of
 this section):


"Some forms of so-called "network neutrality" princi=
ples around the world include the notion that any IP-capable device should =
be able to connect to a network, which seems to encourage heterogeneity. Th=
ese principles are often explicitly encouraged
 by application providers given the reasons noted above,=
 though some of these same providers may also be implementing DNS Whitelist=
ing. This is ironic, as one implication of the adoption of DNS Whitelisting=
 is that it encourages a move back towards
 homogeneity. This is because some implementers have expressed a preference=
 for greater levels of control by networks over end user hosts in order to =
attempt to enforce technical requirements intended to reduce IPv6-related i=
mpairments. This return to an environment
 of more homogenous and/or controlled end user hosts could have unintended =
side effects on and counter-productive implications for future innovation a=
t the edges of the network."











    this is in an increasing number, variety, and =
customization of end


    user hosts, including home network, operating =
systems, client

















Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 2=
0]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












    software, home network devices, and personal c=
omputing devices.  This


    trend appears to have had a positive effect on=
 the development and


    growth of the Internet.  A key facet=
 of this that has evolved is the


    ability of the end user to connect any technic=
ally compliant device


    or use any technically compatible software to =
connect to the


    Internet.  Not only does this trend =
towards greater heterogeneity


    reduce the control which is exerted in the mid=
dle of the network,


    described in positive terms in [Tussle in Cybe=
rspace], [Rethinking


    the Internet], and [RFC3724], but it can also =
help to enable greater


    and more rapid innovation at the edges.







    An unfortunate implication of the adoption of =
DNS whitelisting may be


    the encouragement of a reversal of this trend,=
 which would be a move









the encouragement of -> to encourage









[JL] totally changed this, as noted above.





















8.1.  Implement DNS Whitelisting Universally







    One obvious solution is to implement DNS white=
listed universally, and


    to do so using some sort of centralized regist=
ry of DNS whitelisting


    policies, contracts, processes, or other infor=
mation.  This potential


    solution seems unlikely at the current time.








I'm pretty sure that the only thing that is obvious about a premise of=
 universal



adoption is that it's not practical.  Seriously.







At the least, this section needs to be less cavalier about putting thi=
s 


alternative forward as a "solution", especially given the ra=
ther serious 


drawbacks/problems with it.









[JL] Fixed


























8.2.  Implement DNS Whitelisting On An Ad Hoc Basis







    If DNS whitelisting is to be adopted, it is li=
kely to be adopted on









"is to be"?  I thought it already had a significan=
t installed base.









[JL] Fixed. 











    this ad hoc, or domain-by-domain basis. &=
nbsp;Therefore, only those


    domains interested in DNS whitelisting would n=
eed to adopt the


    practice, though as noted herein discovering t=
hat they a given domain


    has done so may be problematic.  Als=
o in this scenario, ad hoc use by


    a particular domain may be a temporary measure=
 that has been adopted


    to ease the transition of the domain to IPv6 o=
ver some short-term


    timeframe.







8.3.  Do Not Implement DNS Whitelisting







    As an alternative to adopting DNS whitelisting=
, the Internet


    community generally can choose to take no acti=
on whatsoever,


    perpetuating the current predominant authorita=
tive DNS operational


    model on the Internet, and leave it up to end =
users with IPv6-related


    impairments to discover and fix those impairme=
nts.














That is, place the burden of fixing a problem on those creating it?








[JL] In a way. It gets back to the question you asked about what level=
 of impairment justifies this practice. One obvious option is to let end us=
ers sort it out (presumably by consulting with their ISPs / network operato=
rs). This may be simpler and it's
 the way solutions to non-IPv6 problems tend to work today.































Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 2=
3]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011












8.3.1.  Solving Current End User IPv6 Impairments







    A further extension of not implementing DNS wh=
itelisting, is to also


    endeavor to actually fix the underlying techni=
cal problems that have


    prompted the consideration of DNS whitelisting=
 in the first place, as


    an alternative to trying to apply temporary wo=
rkarounds to avoid the


    symptoms of underlying end user IPv6 impairmen=
ts.  A first step is


    obviously to identify which users have such im=
pairments, which would


    appear to be possible, and then to communicate=
 this information to


    end users.  Such end user communicat=
ion is likely to be most helpful


    if the end user is not only alerted to a poten=
tial problem but is


    given careful and detailed advice on how to re=
solve this on their


    own, or where they can seek help in doing so.&=
nbsp; Section 11 may also be


    relevant in this case.







    One challenge with this option is the potentia=
l difficulty of


    motivating members of the Internet community t=
o work collectively


    towards this goal, sharing the labor, time, an=
d costs related to such


    an effort.  Of course, since just su=
ch a community effort is now


    underway for IPv6, it is possible that this wo=
uld call for only a


    moderate amount of additional work.









This 'challenge' is at the core of /all/ adoption efforts for Internet=
 protocols



and services that entail distributed adoption.














    Despite any potential challenges, many in the =
Internet community are


    already working towards this goal and/or have =
expressed a general


    preference for this approach.









If this is not already an organized effort with a website, sponsoring =



consortium, or the like, it should be.  If it is, then cite =
it in this doc!









[JL] Fixed. It is World IPv6 Day and the many efforts related to that.=
 





















8.3.2.  Gain Experience Using IPv6 Transition Names







    Another alternative is for domains to gain exp=
erience using an FQDN


    which has become common for domains beginning =
the transition to IPv6;


    ipv6.example.com and www.ipv6.example.com.&nbs=
p; This can be a way for a


    domain to gain IPv6 experience and increase IP=
v6 use on a relatively


    controlled basis, and to inform any plans for =
DNS whitelisting with


    experience.









I do not understand what this means.







What is it for?  What are the results?  How are th=
eyused?









[JL] Ack. This has been clarified in the =9604.





















9.  Is DNS Whitelisting a Recommended Practice?







    Opinions in the Internet community concerning =
whether or not DNS


    whitelisting is a recommended practice are und=
erstandably quite


    varied.  However, there is clear con=
sensus that DNS whitelisting is


    at best a useful temporary measure which a dom=
ain may choose to









If that is a clear consensus, then it makes even less sense to promote=
 the idea



of universal adoption, given the timescale needed to achieve it.














10.  Security Considerations







    There are no particular security consideration=
s if DNS whitelisting


    is not adopted, as this is how the public Inte=
rnet works today with A


    resource records.









Or rather, failure to adopt a mechanism like this or repair the underl=
ying 


problem, for those sites experiencing that problem, will result in a d=
enial of



service, albeit not an intentional one.  Still, that's a pre=
tty basic security



issue.












d/


-- 







   Dave Crocker


   Brandenburg InternetWorking


   bbiw.net











--_000_CA084387289FFjasonlivingoodcablecomcastcom_--

From internet-drafts@ietf.org  Sun May 29 20:15: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 7C525E077B; Sun, 29 May 2011 20:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level: 
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 PlGypdxldJE9; Sun, 29 May 2011 20:15:00 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C5EE0657; Sun, 29 May 2011 20:15:00 -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: <20110530031500.28213.21399.idtracker@ietfa.amsl.com>
Date: Sun, 29 May 2011 20:15:00 -0700
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-04.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, 30 May 2011 03:15:00 -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 AAAA DNS Whitelisting Implications
	Author(s)       : Jason Livingood
	Filename        : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-04.txt
	Pages           : 39
	Date            : 2011-05-29

   The objective of this document is to describe the practice of
   whitelisting of DNS recursive resolvers in order to limit AAAA
   resource records responses, which contain IPv6 addresses, hereafter
   referred to as DNS Whitelisting, as well as the implications of this
   emerging practice and what alternatives or variations may exist.
   This practice is a type of IPv6 transition mechanism used by domains,
   as a method for incrementally transitioning inbound traffic to a
   domain from IPv4 to IPv6 transport.  The audience for this document
   is the Internet community generally, particularly IPv6 implementers.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-i=
mplications-04.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-v6-aaaa-whitelisting-im=
plications-04.txt

From jason_livingood@cable.comcast.com  Sun May 29 20: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 23FAEE078E for ; Sun, 29 May 2011 20:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.194
X-Spam-Level: 
X-Spam-Status: No, score=-108.194 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 gWSWepP7WJo9 for ; Sun, 29 May 2011 20:25: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 E9CA0E0787 for ; Sun, 29 May 2011 20:25:55 -0700 (PDT)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128063421; Sun, 29 May 2011 23:25:52 -0400
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; Sun, 29 May 2011 23:25:52 -0400
From: "Livingood, Jason" 
To: Lorenzo Colitti 
Thread-Topic: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 - traffic load considerations
Thread-Index: AQHMDmJcdMlTH64Ob0qwxzp9To93NJSkVU6AgACwB4D//9BvAA==
Date: Mon, 30 May 2011 03:25:52 +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.10.0.110310
x-originating-ip: [24.40.55.70]
Content-Type: multipart/alternative; boundary="_000_CA0884A928ADFjasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: Erik Kline , "v6ops@ietf.org" 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 - traffic load considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 30 May 2011 03:25:57 -0000

--_000_CA0884A928ADFjasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

On 5/29/11 10:16 PM, "Lorenzo Colitti" > wrote:

On Sun, May 29, 2011 at 12:46 PM, Livingood, Jason > wrote:
"One particular risk is that, especially when a high-traffic domain de-whit=
elists a large network, this may cause a sudden and dramatic change to netw=
orks since a large volume of traffic will then switch from IPv6 to IPv4.

Why does the draft neglect to mention the equal but opposite "sudden and dr=
amatic change to networks" that can occur if a high-traffic domain suddenly=
 announces AAAA records for the whole world without whitelisting?

[JL] Well, actually the draft *does* mention this. Please note the followin=
g instances with specific and/or relation mentions of this. I am open to an=
y suggestions you may have on these or on additional mentions of course. :-=
)

Section 3: "=85 Therefore there are two concerns which relate to this pract=
ice; one of which relates to IPv6-related impairment and the other which re=
lates to the maturity or stability of IPv6 transport for high-traffic domai=
ns=85."

Section 3.2, Volume-Based Concerns:
"Some implementers are trying to gradually add IPv6 traffic to their domain=
 since they may find that network operations, tools, processes and procedur=
es are less mature for IPv6 as compared to IPv4. While for domains with sma=
ll to moderate traffic volumes, whether by the count of end users or count =
of bytes transferred, high-traffic domains receive such a level of usage th=
at it is prudent to undertake any network changes gradually or in a manner =
which minimizes any risk of disruption. For example, one can imagine for on=
e of the top ten sites globally that the idea of suddenly turning on a sign=
ificant amount of IPv6 traffic might be quite daunting. DNS Whitelisting ma=
y therefore offer such high-traffic domains one potential method for increm=
entally enabling IPv6. Thus, some implementers with high-traffic domains pl=
an to use DNS Whitelisting is a necessary, though temporary, risk reduction=
 tactic intended to ease their transition to IPv6 and minimize any perceive=
d risk in such a transition."

Section 3.3.  Free Versus Subscription Services
"It is also worth noting the differences between domains containing primari=
ly subscription-based services compared to those containing primarily free =
services. In the case of free services, such as search engines, end users h=
ave no direct billing relationship with the domain and can switch sites sim=
ply by changing the address they enter into their browser (ignoring other v=
alue added services which may tie a user's preference to a given domain or =
otherwise create switching costs). As a result, such domains explain that t=
hey believe they are more sensitive to the quality of the services within t=
heir domain since if the user has issues when they turn on IPv6, then that =
user could switch to another domain that is not using IPv6."

Section 7.6: "...At the same time, as noted in Section 3, some high-traffic=
 domains may find the prospect of transitioning to IPv6 daunting without ha=
ving some short-term ability to incrementally control the amount and source=
 of IPv6 traffic to their domains. Lacking such controls, some domains may =
choose to substantially delay their transition to IPv6..."

Section 8.3.2: "...Another alternative is for domains to gain experience us=
ing an FQDN which has become common for domains beginning the transition to=
 IPv6; ipv6.example.com and www.ipv6.example.com. This can be a way for a d=
omain to gain IPv6 experience and increase IPv6 use on a relatively control=
led basis, and to inform any plans for DNS Whitelisting with experience. Wh=
ile this is a good first step to functionally test and prepare a domain for=
 IPv6, the utility of the tactic is limited since users must know the trans=
ition name, the traffic volume will be low, and the traffic is unlikely to =
be representative of the general population of end users, among other reaso=
ns..."

Section 9: "...In particular, some high-traffic domains view DNS Whitelisti=
ng as one of the few practical and low-risk approaches enabling them to tra=
nsition to IPv6, without which their transition may not take place for some=
 time..."


-- JL

--_000_CA0884A928ADFjasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable











On 5/29/11 10:16 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:














On Sun, May 29, 2011 at 12:46 PM, Livingood, Jas=
on 
<Jason_Livingood@ca=
ble.comcast.com> wrote:








"One particular risk is that, especially when a high-traffic d=
omain de-whitelists a large network, this may cause a sudden and dramatic c=
hange to networks since a large volume of traffic will then switch from IPv=
6 to IPv4.













Why does the draft neglect to mention the equal but opposite "sud=
den and dramatic change to networks" that can occur if a high-traffic =
domain suddenly announces AAAA records for the whole world without whitelis=
ting?












[JL] Well, actually the draft *does* mention this. Please note the fol=
lowing instances with specific and/or relation mentions of this. I am open =
to any suggestions you may have on these or on additional mentions of cours=
e. :-)









Section 3: "=85 Therefore there are two concerns which relate to =
this practice; one of which relates to IPv6-related impairment and the othe=
r which relates to the maturity or stability of IPv6 transport for high-tra=
ffic domains=85."







Section 3.2, Volume-Based Concerns: 


"Some implementers are trying to gradually add IPv6 traffic to th=
eir domain since they may find that network operations, tools, processes an=
d procedures are less mature for IPv6 as compared to IPv4. While for domain=
s with small to moderate traffic volumes,
 whether by the count of end users or count of bytes transferred, high-traf=
fic domains receive such a level of usage that it is prudent to undertake a=
ny network changes gradually or in a manner which minimizes any risk of dis=
ruption. For example, one can imagine
 for one of the top ten sites globally that the idea of suddenly turning on=
 a significant amount of IPv6 traffic might be quite daunting. DNS Whitelis=
ting may therefore offer such high-traffic domains one potential method for=
 incrementally enabling IPv6. Thus,
 some implementers with high-traffic domains plan to use DNS Whitelisting i=
s a necessary, though temporary, risk reduction tactic intended to ease the=
ir transition to IPv6 and minimize any perceived risk in such a transition.=
"







Section 3.3.  Free Versus Subscription Services


"It is also worth noting the differences between domains containi=
ng primarily subscription-based services compared to those containing prima=
rily free services. In the case of free services, such as search engines, e=
nd users have no direct billing relationship
 with the domain and can switch sites simply by changing the address they e=
nter into their browser (ignoring other value added services which may tie =
a user's preference to a given domain or otherwise create switching costs).=
 As a result, such domains explain
 that they believe they are more sensitive to the quality of the services w=
ithin their domain since if the user has issues when they turn on IPv6, the=
n that user could switch to another domain that is not using IPv6."






Section 7.6: "...At the same time, as noted in Section 3, some hi=
gh-traffic domains may find the prospect of transitioning to IPv6 daunting =
without having some short-term ability to incrementally control the amount =
and source of IPv6 traffic to their domains.
 Lacking such controls, some domains may choose to substantially delay thei=
r transition to IPv6..."







Section 8.3.2: "...Another alternative is for domains to gain exp=
erience using an FQDN which has become common for domains beginning the tra=
nsition to IPv6; ipv6.example.com and www.ipv6.example.com. This can be a w=
ay for a domain to gain IPv6 experience
 and increase IPv6 use on a relatively controlled basis, and to inform any =
plans for DNS Whitelisting with experience. While this is a good first step=
 to functionally test and prepare a domain for IPv6, the utility of the tac=
tic is limited since users must
 know the transition name, the traffic volume will be low, and the traffic =
is unlikely to be representative of the general population of end users, am=
ong other reasons..."







Section 9: "...In particular, some high-traffic domains view DNS =
Whitelisting as one of the few practical and low-risk approaches enabling t=
hem to transition to IPv6, without which their transition may not take plac=
e for some time..."














-- JL




--_000_CA0884A928ADFjasonlivingoodcablecomcastcom_--

From joelja@bogus.com  Sun May 29 22:22: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 E3B7BE06AA; Sun, 29 May 2011 22:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.3
X-Spam-Level: 
X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300,  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 4W+TZXtke+E8; Sun, 29 May 2011 22:22:15 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5738FE0674; Sun, 29 May 2011 22:22:10 -0700 (PDT)
Received: from [IPv6:2001:43f8:220:216:129a:ddff:feb1:e750] ([IPv6:2001:43f8:220:216:129a:ddff:feb1:e750]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p4U5Lp1l083599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 May 2011 05:21:55 GMT (envelope-from joelja@bogus.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Joel Jaeggli 
In-Reply-To: <4DE27946.7000704@dcrocker.net>
Date: Sun, 29 May 2011 22:21:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <91AE1B6C-02F8-4023-8FAC-FD19EBB646A9@bogus.com>
References: <4DE27946.7000704@dcrocker.net>
To: dcrocker@bbiw.net
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]); Mon, 30 May 2011 05:22:00 +0000 (UTC)
Cc: "v6ops@ietf.org" , IETF Discussion 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 30 May 2011 05:22:20 -0000

With respect to the discussion of the whitelist/blacklist terminology I =
believe it can be stipulated that the authors, the document shepherd, =
the working group chairs disagree with your conclusions as to the =
appropriateness of the term whitelist.

thanks
joel

On May 29, 2011, at 9:50 AM, Dave CROCKER wrote:

>=20
> On 5/29/2011 7:46 AM, Livingood, Jason wrote:
> > Hi Bernard =96 I've finally found the time to close out the last =
bits of
> > feedback > in this version of the draft.
>=20
>=20
> Jason,
>=20
> Perhaps my filters misfiled your followup to the "formal" review I was =
asked to do, or perhaps my earlier, informal, and vary narrow review =
muddied the waters, but I am not finding your response to the Apps Area =
review.
>=20
> For convenience, here it is again.
>=20
> d/
>=20
> -------- Original Message --------
> Subject: Review of:  =
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03=09
>         *(formal for apps area)*
> Date: Mon, 09 May 2011 10:18:51 -0700
> From: Dave CROCKER 
> Reply-To: dcrocker@bbiw.net
> Organization: Brandenburg InternetWorking
> To: IETF Discussion 
> CC: v6ops@ietf.org , Apps Review =

>=20
> (This is an "official" and significantly extended version of an =
informal and
> narrow review I posted earlier.  /d)
>=20
>=20
>=20
> Howdy.
>=20
> I have been selected as the Applications Area Review Team reviewer for =
this
> draft (for background on apps-review, please see
> http://www.apps.ietf.org/content/applications-area-review-team).
>=20
> Please resolve these comments along with any other Last Call comments =
you may
> receive. Please wait for direction from your document shepherd or AD =
before
> posting a new version of the draft.
>=20
>=20
>=20
> Review (v2):
>=20
> Title:  IPv6 AAAA DNS Whitelisting Implications
> I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
>=20
> By:     D. Crocker 
> Date:   <>
>=20
>=20
>=20
> Summary
> =3D=3D=3D=3D=3D=3D=3D
>=20
> This draft covers a a dual-stack problem in which a target host's DNS =
entry
> contains records for IPv4 and IPv6, but returning IPv6 information to =
a DNS
> client can cause problems. The paper discusses for resolving this =
through use of
> a a DNS-based mechanism that manually lists response preferences to =
select which
> DNS records to return.  The paper describes the mechanism and explores =
various
> effects and possibilities of its use, including the difference between =
using it
> selectively among a smaller number of sites, versus universally.
>=20
> The draft is a serious effort to explore the use of such a mechanism =
and it
> touches many different issues.  It is generally well-organized and =
clearly
> written, although it very much needs the aid of a professional =
technical editor.
> The writing often assumes too much knowledge by the reader.
>=20
> The paper's exploration of universal adoption seems to vary between =
considering
> that goal practical versus considering it only as a matter of =
completeness for
> discussing the full range of possibilities.  That is, it is not clear =
whether
> the paper views this alternative as practically possible and even =
preferred,
> versus only a matter for academic thoroughness. The paper needs to =
take a basic
> position about feasibility, explain it in terms of comparable adoption =
efforts
> at Internet-scale, and then make its treatment of universal adoption a =
bit more
> consistent.
>=20
> When introducing terms, mechanisms, configurations and scenarios, the =
paper
> needs to be more careful to describe them adequately for a reader new =
to the
> topic.  This is not a matter of having a tutorial about the DNS, but =
rather a
> tutorial for this type of mechanism and when and how it can be used.
>=20
> As a specific example, the document cites "domain-by-domain" use, but =
I am not
> clear how that would work, in terms of configuration and cross-net =
information
> exchange.  One question is how the server knows the 'domain' of the =
client?
>=20
> The document should careful to distinguish what is existing practice, =
versus
> what is being explored as added possibilities.  The difference in =
concreteness
> and certitude between the two is substantial.
>=20
> The document's use of the term whitelisting appears to continue an =
existing,
> recent use, for this type of mechanism.  Unfortunately it directly =
conflicts
> with long-standing use of the term by the anti-abuse community for =
whitelisting
> in the DNS. Its use here also seems to be a mismatch with the word's =
dictionary
> semantics, which is most naturally used to distinguish yes/no choices, =
rather
> than either/or choices.  So there is no intuitive sense of "goodness" =
(whitelist
> =3D yes) or "badness" (blacklist) for this use. The word "preferences" =
seems more
> in line with the meaning of the mechanism.
>=20
>=20
>=20
> Detailed Comments
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
>=20
>> Abstract
>>=20
>>   The objective of this document is to describe what the whitelisting
>>   of DNS AAAA resource records is, hereafter referred to as DNS
>=20
> RRs are whitelisted?  Isn't it the addresses and not the records that =
are
> whitelisted?
>=20
> Does this mean putting whitelisting records into the DNS or does it =
mean
> something else?
>=20
> Comcast's own considerable expertise notwithstanding, has this doc =
been vetted
> with a range of organizations that actually DO whitelisting?  Has it =
been
> circulated through MAAWG and APWG?  Any comments from Spamhaus?  The
> Acknowledgements list does not seem to indicate a range of whitelist =
ops folks
> whose names I know.  (But then, I only know a few...)
>=20
>=20
>>   whitelisting, as well as the implications of this emerging practice
>>   and what alternatives may exist.  The audience for this document is
>>   the Internet community generally, including the IETF and IPv6
>>   implementers.
>=20
> I suspect that product marketers won't have much interest in this.  I =
suspect
> that the target for this is anti-abuse technical and operations staff. =
In any
> event, the targetting statement should be more precise.
>=20
>=20
>> 1.  Introduction
>>=20
>>   This document describes the emerging practice of whitelisting of =
DNS
>=20
> One natural, semantic problem with the term 'whitelist' is that it =
does not
> really match the function being performed.  The white/black =
distinction implies
> goodness -- or as Wikipedia says, "priviledge".  Instead, the use here =
is for
> preference or priority.  What would a "blacklist" be, here?  Also note =
it is not
> obvious what it means to be whitelisted, here?  Does it mean to choose =
the AAAA
> records or the A records?
>=20
> This is more like a 'Preference' or 'Configuration' list.
>=20
> At the least, the name for this should be IPv6 Resolver Whitelisting.  =
It makes
> clear /what/ is being "whitelisted".
>=20
>=20
>>   AAAA resource records (RRs), which contain IPv6 addresses, =
hereafter
>>   referred to as DNS whitelisting.  The document explores the
>=20
> This provides a name, but not a function.  That is, it does not say =
what this
> mechanisms actually /does/ or is /for/.
>=20
>=20
>>   implications of this emerging practice are and what alternatives =
may
>>   exist.
>>=20
>>   The practice of DNS whitelisting appears to have first been used by
>>   major web content sites (sometimes described herein as "highly-
>=20
> It's use for email anti-abuse dates back farther.
>=20
>   
>=20
>   
>=20
>=20
> =

>=20
> Specifically within the context of the DNS, the term whitelisting is =
therefore
> made ambiguous.
>=20
> A google query for "whitelist dns" also demonstrates the history and =
current
> ambiguity.
>=20
>=20
>>   trafficked domains" or "major domains").  These web site operators,
>>   or domain operators, observed that when they added AAAA resource
>>   records to their authoritative DNS servers in order to support IPv6
>>   access to their content that a small fraction of end users had slow
>>   or otherwise impaired access to a given web site with both AAAA and =
A
>>   resource records.  The fraction of users with such impaired access
>>   has been estimated to be roughly 0.078% of total Internet users
>>   [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
>>   Brokenness].  Thus, in an example Internet Service Provider (ISP)
>>   network of 10 million users, approximately 7,800 of those users may
>>   experience such impaired access.
>=20
> At a minimum, these sorts of statistics need to be normalized across =
IPv6
> users/traffic, given how small a percentage that is, in total users =
and total
> traffic.  If that's what is meant it should be stated.  If it isn't, =
the
> statistic should be recalculated and explained a bit more precisely.
>=20
>=20
>>   As a result of this impairment affecting end users of a given =
domain,
>>   a few major domains have either implemented DNS whitelisting or are
>>   considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist =
Operations].
>>   When implemented, DNS whitelisting in practice means that a =
domain's
>>   authoritative DNS will return a AAAA resource record to DNS =
recursive
>>   resolvers [RFC1035] on the whitelist, while returning no AAAA
>>   resource records to DNS resolvers which are not on the whitelist.  =
It
>=20
> This explanation of the function should be offered sooner and should =
be
> summarized in the Abstract.
>=20
>=20
>>   is important to note that these major domains are motivated by a
>>   desire to maintain a high-quality user experience for all of their
>=20
> Rather than being important to note, this sentence sounds oddly like =
marketing
> hype, in a technical specification.  It is gratuitous because =
specified features
> are never added to /lower/ the quality of the user experience, for =
example.
>=20
> In addition, the mechanism also affects client activity that has no =
user
> directly involved.
>=20
>=20
>>   users.  By engaging in DNS whitelisting, they are attempting to
>>   shield users with impaired access from the symptoms of those
>>   impairments.
>=20
> The /technical/ statement that should be here is that they are =
attempting to
> provide a work-around for problematic behaviors in dual-stack =
IPv4/IPv6
> environments.
>=20
> The paper should make more clear exactly where the problem lies and =
when. If it
> can occur for a number of reasons, explaining each of those scenarios =
would be
> useful.
>=20
>=20
>>   Critics of the practice of DNS whitelisting have articulated =
several
>>   concerns.  Among these are that:
>>=20
>>   o  DNS whitelisting is a very different behavior from the current
>>      practice concerning the publishing of IPv4 address resource
>>      records,
>>=20
>>   o  that it may create a two-tiered Internet,
>>=20
>>   o  that policies concerning whitelisting and de-whitelisting are
>>      opaque,
>>=20
>>=20
>>=20
>>=20
>>=20
>> Livingood                Expires August 26, 2011                [Page =
5]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>>   o  that DNS whitelisting reduces interest in the deployment of =
IPv6,
>>=20
>>   o  that new operational and management burdens are created,
>=20
> well, yeah... in fact it should be noted that the burdens are =
particularly
> onerous at scale.
>=20
>=20
>>   o  and that the costs and negative implications of DNS whitelisting
>>      outweigh the perceived benefits, compared to fixing underlying
>>      impairments.
>=20
> and it doesn't scale.
>=20
> and it violates an extremely basic premise of cross-Internet =
interoperability by
> requiring prior arrangement.
>=20
>=20
>>   This document explores the reasons and motivations for DNS
>>   whitelisting.  It also explores the outlined concerns regarding =
this
>>   practice.  Readers will hopefully better understand what DNS
>>   whitelisting is, why some parties are implementing it, and what
>>   criticisms of the practice exist.
>>=20
>>=20
>> 2.  How DNS Whitelisting Works
>=20
> How IPv6 AAAA DNS Whitelisting Works.
>=20
> (Anti-spam DNS Whitelisting works rather differently...)
>=20
>=20
>>   DNS whitelisting is implemented in authoritative DNS servers.  =
These
>>   servers implement IP address-based restrictions on AAAA query
>>   responses.  So far, DNS whitelisting has been primarily implemented
>>   by web server operators deploying IPv6-enabled services.  For a =
given
>=20
> Really?  This is web-specific?  The same restrictions are not applied =
for other
> applications?
>=20
> So if the same client-side hosts attempt to contact the server for =
email or
> xmpp, they won't get the same handling?
>=20
>=20
>>   operator of a website, such as www.example.com, the operator
>>   essentially applies an access control list (ACL) on the =
authoritative
>>   DNS servers for the domain example.com.  The ACL is populated with
>=20
> An ACL usually is a yes/no mechanism.  Here, however, the mechanism is =
for
> asserting a preference for IPv6 over IPv4.
>=20
> That does not seem to match the definition of ACL that I'm used to, =
unless the
> semantic is defined as denying IPv4 access to the listed clients.
>=20
> The term ACL is particularly odd to use if the mechanism pertains to =
responses
> rather than queries.
>=20
>=20
>>   the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive
>=20
> Either address type can be listed?  So this really is a pure =
'preferences'
> mechanism?
>=20
> Which settings count as whitelisting?  Do any count as blacklisting?
>=20
>=20
>=20
>>   resolvers on the Internet, which have been authorized to receive =
AAAA
>>   resource record responses.  These DNS recursive resolvers are
>>   operated by third parties, such as ISPs, universities, governments,
>>   businesses, and individual end users.  If a DNS recursive resolver =
IS
>>   NOT matched in the ACL, then AAAA resource records will NOT be sent
>>   in response to a query for a hostname in the example.com domain.
>=20
> This configuration appears to ensure the maximum barrier to adoption =
for IPv6,
> since it means that IPv6 will not work automatically.  It will only =
work for
> hosts that are manually configured to receive responses with v6 =
records.
>=20
> That's a rather major implication.  It's a default that is probably =
meant to
> apply during the very early stages of adoption, when there are few =
users of the
> newer mechanism.
>=20
> It's probably worth discussing it in more detail, including discussing =
when to
> change the default...
>=20
>=20
>>   However, if a DNS recursive resolver IS matched in the ACL, then =
AAAA
>>   resource records will be sent in response to a query for a given
>>   hostname in the example.com domain.  While these are not network-
>>   layer access controls they are nonetheless access controls that are =
a
>>   factor for end users and other parties like network operators,
>>   especially as networks and hosts transition from one network =
address
>>   family to another (IPv4 to IPv6).
>=20
>=20
> Also, all of this clarifies the function of this listing mechanism and =
suggests
> a very different name, to be more precise and accurate in naming it:
>=20
>    IPv6 DNS Response Preference List.
>=20
>=20
>>   In practice, DNS whitelisting generally means that a very small
>>   fraction of the DNS recursive resolvers on the Internet (those in =
the
>>   whitelist ACL) will receive AAAA responses.  The large majority of
>>   DNS resolvers on the Internet will therefore receive only A =
resource
>>   records containing IPv4 addresses.  Thus, quite simply, the
>>   authoritative server hands out different answers depending upon who
>>   is asking; with IPv4 and IPv6 resource records for some on the
>>   authorized whitelist, and only IPv4 resource records for everyone
>>   else.  See Section 2.1 and Figure 1 for a description of how this
>>=20
>>=20
>>=20
>> Livingood                Expires August 26, 2011                [Page =
6]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>>   works.
>>=20
>>   Finally, DNS whitelisting can be deployed in two primary ways:
>>   universally on a global basis, or on an ad hoc basis.  Deployment =
on
>>   a universal deployment basis means that DNS whitelisting is
>>   implemented on all authoritative DNS servers, across the entire
>>   Internet.  In contrast, deployment on an ad hoc basis means that =
only
>>   some authoritative DNS servers, and perhaps even only a few,
>>   implement DNS whitelisting.  These two potential deployment models
>>   are described in Section 6.
>>=20
>> 2.1.  Description of the Operation of DNS Whitelisting
>>=20
>>   The system logic of DNS whitelisting is as follows:
>>=20
>>   1.  The authoritative DNS server for example.com receives DNS =
queries
>>       for the A (IPv4) and AAAA (IPv6) address resource records for =
the
>>       FQDN www.example.com, for which AAAA (IPv6) resource records
>>       exist.
>=20
> This means that the mechanism is /only/ triggered when /both/ address =
records
> are queried?  A query for only one type of address record won't =
trigger the list
> lookup?  I think that doesn't match other statements in the document.
>=20
>=20
>>   2.  The authoritative DNS server examines the IP address of the DNS
>>       recursive resolver sending the AAAA (IPv6) query.
>=20
> "examines"?  Examines it for what?  What does this step mean?
>=20
>=20
>>   3.  The authoritative DNS server checks this IP address against the
>>       access control list (ACL) that is the DNS whitelist.
>>=20
>>   4.  If the DNS recursive resolver's IP address IS matched in the =
ACL,
>>       then the response to that specific DNS recursive resolver can
>>       contain AAAA (IPv6) address resource records.
>=20
> Oh.  This is not about whether to send responses /over/ v6 vs. v4?  =
This is
> whether to /include/ a particular type of RR in responses???
>=20
> In that case an appropriate name for this mechanism is more like:
>=20
>   DNS Response Content Preference List
>=20
> And this seems even less like an ACL than it did before.  (I assume =
the
> justification is that access is being prevented by virtue of not =
supplying the
> address, but still...)
>=20
>=20
>>   5.  If the DNS recursive resolver's IP address IS NOT matched in =
the
>>       ACL, then the response to that specific DNS recursive resolver
>>       cannot contain AAAA (IPv6) address resource records.  In this
>>       case, the server should return a response with the response =
code
>>       (RCODE) being set to 0 (No Error) with an empty answer section
>>       for the AAAA record query.
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> Livingood                Expires August 26, 2011                [Page =
7]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>>   =
---------------------------------------------------------------------
>>   A query is sent from a DNS recursive resolver that IS NOT on the =
DNS
>>   whitelist:
>>=20
>>               Request                      Request
>>           www.example.com                  www.example.com
>>                 AAAA    +-------------+     AAAA    =
+-----------------+
>>     ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com =
|
>>     ||  ||       A      | **IS NOT**  |      A      | IN A exists     =
|
>>   +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  =
|
>>   +--------+     A      | example.com |      A      |                 =
|
>>      Host    <--------- |  WHITELIST  |  <--------- |                 =
|
>>    Computer   A Record  +-------------+  A Record   =
+-----------------+
>>               Response   DNS Recursive   Response       example.com
>>              (only IPv4)   Resolver     (only IPv4)    Authoritative
>>                              #1                           Server
>>   =
---------------------------------------------------------------------
>>   A query is sent from a DNS recursive resolver that IS on the DNS
>>   whitelist:
>>=20
>>               Request                      Request
>>           www.example.com                  www.example.com
>>                AAAA     +-------------+     AAAA    =
+-----------------+
>>     ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com =
|
>>     ||  ||       A      |   **IS**    |      A      | IN A exists     =
|
>>   +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  =
|
>>   +--------+   AAAA     | example.com |     AAAA    |                 =
|
>>      Host    <--------- |  WHITELIST  |  <--------- |                 =
|
>>    Computer      A      |             |      A      |                 =
|
>>              <--------- |             |  <--------- |                 =
|
>>              A and AAAA +-------------+ A and AAAA  =
+-----------------+
>>               Record     DNS Recursive   Record        example.com
>>              Responses     Resolver     Responses      Authoritative
>>              (IPv4+IPv6)      #2        (IPv4+IPv6)       Server
>>   =
---------------------------------------------------------------------
>>=20
>>              Figure 1: DNS Whitelisting - Functional Diagram
>=20
> This diagram is confusing to me.  I suspect that a protocol exchange =
sequence
> format, in the style of:
>=20
>     Host             Resolver 1            Authoritative
>=20
>          ---------->
>                                 --------->
>                                <---------
>         <----------
>=20
> will be considerably more helpful.
>=20
>=20
>> 3.  What Problems Are Implementers Trying To Solve?
>=20
> This is a very useful section and it is probably worth moving it =
higher, to
> precede the 'how it works' section.
>=20
>=20
>>   As noted in Section 1, domains which implement DNS whitelisting are
>>   attempting to protect a few users of their domain, who have =
impaired
>>   IPv6 access, from having a negative experience (poor performance).
>=20
> By the way, what does 'impaired v6 access' mean?
>=20
> I think there needs to be a simple, direct description of what occurs =
without
> this mechanism.
>=20
> For example, perhaps you mean that a host can send DNS queries using =
IPv6 but
> cannot receive DNS responses over IPv6? Perhaps you mean that the host =
can send
> IPv6 but cannot receive it.  (That's a different scale and scope of =
problem from
> the first example I gave.)
>=20
> This brief, summary problem statement should be included in the =
Abstract, to
> make /much/ more clear what this mechanism is for.
>=20
>=20
>>   While it is outside the scope of this document to explore the =
various
>>   reasons why a particular user's system (host) may have impaired =
IPv6
>>   access, for the users who experience this impairment it is a very
>>   real performance impact.  It would affect access to all or most =
dual
>>=20
>>=20
>>=20
>> Livingood                Expires August 26, 2011                [Page =
8]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>>   stack services to which the user attempts to connect.  This =
negative
>>   end user experience can range from someone slower than usual (as
>>   compared to native IPv4-based access), to extremely slow, to no
>>   access to the domain whatsoever.
>=20
> Rather than repeat that this is about end-users, it sounds more that =
this is
> about whether a service works or does not work, whether a user is =
directly
> present or not.
>=20
>=20
>>   While one can debate whether DNS whitelisting is the optimal =
solution
>>   to the end user experience problem, it is quite clear that DNS
>>   whitelisting implementers are interested in maximizing the
>>   performance of their services for end users as a primary motivation
>>   for implementation.
>=20
> You keep citing 'performance' but haven't described what sort of =
performance
> degradation takes place. Is this really about relatively better or =
worse
> performance -- and if so, how -- or is this about working or not =
working?
>=20
> Also rather than saying what implementers are interested in, it's =
probably more
> helpful to note that the practice is now significantly established and =
therefore
> worth documenting, independent of its possible controversy.
>=20
>=20
>>   At least one highly-trafficked domain has noted that they have
>>   received requests to not send DNS responses with AAAA resource
>>   records to particular resolvers.  In this case, the operators of
>=20
> "At least one" seems a rather tiny statistic.  Perhaps the actual =
statistic is
> significantly larger?
>=20
>=20
>>   those recursive resolvers have expressed a concern that their IPv6
>=20
> I suspect that it's not resolvers that are doing the expressing, since =
their
> vocabulary is usually too limited...
>=20
>=20
>>   network infrastructure is not yet ready to handle the large traffic
>>   volume which may be associated with the hosts in their network
>>   connecting to the websites of these domains.  This concern is =
clearly
>=20
> So even though the site allows v6 DNS queries to go out from a host, =
it can't
> really support having the host use v6?
>=20
> Wow. I do understand why service providers often have to work around =
silliness
> at the client side, but this problem at the client side seems =
particularly
> egregious.
>=20
>=20
>>   a temporary consideration relating to the deployment of IPv6 =
network
>>   infrastructure on the part of networks with end user hosts, rather
>>   than a long-term concern.  These end user networks may also have
>=20
> Again this goal of short-term usage is worth noting earlier, including =
in the
> Abstract.
>=20
>=20
>>   other tools at their disposal in order to address this concern,
>>   including applying rules to network equipment such as routers and
>>   firewalls (this will necessarily vary by the type of network, as =
well
>>   as the technologies used and the design of a given network), as =
well
>>   as configuration of their recursive resolvers (though modifying or
>>   suppressing AAAA resource records in a DNSSEC-signed domain on a
>>   Security-Aware Resolver will be problematic Section 10.1).
>>=20
>>   Some implementers with highly-trafficked domains have explained =
that
>>   DNS whitelisting is a necessary, though temporary, risk reduction
>>   tactic intended to ease their transition to IPv6 and minimize any
>>   perceived risk in such a transition.  As a result, they perceive =
this
>>   as a tactic to enable them to incrementally enable IPv6 =
connectivity
>>   to their domains during the early phases of their transition to =
IPv6.
>>=20
>>   Finally, some domains, have run IPv6 experiments whereby they added
>>   AAAA resource records and observed and measured errors [Heise =
Online
>>   Experiment], which should be important reading for any domain
>>   contemplating either the use of DNS whitelisting or simply adding
>>   IPv6 addressing to their site.
>>=20
>>=20
>> 4.  Concerns Regarding DNS Whitelisting
>>=20
>>   There are a number of potential implications relating to DNS
>>   whitelisting, which have been raised as concerns by some parts of =
the
>>   Internet community.  Many of those potential implications are =
further
>=20
> I think the implications are not conditional; they exist rather than =
being
> potential.  The 'potential' is that what is implicated will come to =
pass.
>=20
>=20
>=20
>>=20
>> Livingood                Expires August 26, 2011                [Page =
9]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>>   enumerated here and in Section 7.
>=20
> Pro forma question:  Why are implications discussed in multiple =
places?
>=20
>=20
>>   Some parties in the Internet community, including ISPs, are =
concerned
>=20
> This style of text personalizes the issues unnecessarily (IMO).  It =
does not
> really matter who holds the concerns, or else they'd be described more =
precisely.
>=20
> I suggest merely noting that there are concerns and then listing and =
discussing
> the concerns, rather than adding text to attribute the concerns to =
others, even
> if the conclusion of your text is that a particular concern is not =
valid.
>=20
>=20
>>   that the practice of DNS whitelisting for IPv6 address resource
>>   records represents a departure from the generally accepted =
practices
>>   regarding IPv4 address resource records in the DNS on the Internet
>>   [Whitelisting Concerns].  These parties explain their belief that =
for
>=20
> "These parties explain their belief" is an example of personalization =
that is
> not needed.  This isn't about the believers.  It is about possible =
problems.
>=20
>=20
>>   A resource records, containing IPv4 addresses, once an =
authoritative
>>   server operator adds the A record to the DNS, then any DNS =
recursive
>>   resolver on the Internet can receive that A record in response to a
>=20
> This does not appear to be a grammatically valid sentence.  My guess =
is that
> deleting "A resource... addresses" fixes this.
>=20
> And by the way, the document's reference to "recursive" resolvers is =
mostly
> likely incorrect.  The problem is not restricted only to that very =
specific type
> of resolver, is it?
>=20
> If in fact it /is/ specific to them -- and your following text =
describes an
> indirect effects scenario where it might be -- I suggest calling out =
the
> configuration at the beginning, along the lines of:
>=20
>     One way the problem with returning AAAA records can be experienced =
is when
> recursive resolvers are used.  Although that resolver might support =
IPv6, its
> client hosts might not.  So, returning an AAAA record will mean that =
these
> limited hosts will be given an unusable address.
>=20
> And this type of description belongs in the text describing the =
motivating
> problem(s), rather than buried in the 'concerns' discussion.
>=20
> (The text, here, pertains to A records, but the problem I've described =
uses the
> same configuration but for AAAA records with mixed v6 support.)
>=20
>=20
>>   query.  By extension, this means that any of the hosts connected to
>>   any of these DNS recursive resolvers can receive the IPv4 address
>>   resource records for a given FQDN.  This enables new server hosts
>>   which are connected to the Internet, and for which a fully =
qualified
>>   domain name (FQDN) such as www.example.com has been added to the =
DNS
>>   with an IPv4 address record, to be almost immediately reachable by
>>   any host on the Internet.  In this case, these new servers hosts
>>   become more and more widely accessible as new networks and new end
>>   user hosts connect to the Internet over time, capitalizing on and
>>   increasing so-called "network effects" (also called network
>>   externalities).  It also means that the new server hosts do not =
need
>>   to know about these new networks and new end user hosts in order to
>>   make their content and applications available to them, in essence
>>   that each end in this end-to-end model is responsible for =
connecting
>>   to the Internet and once they have done so they can connect to each
>>   other without additional impediments or middle networks or
>>   intervening networks or servers knowing about these end points and
>>   whether one is allowed to contact the other.
>=20
> Hmmm.  This rather lengthy bit of prose appears merely to be =
explaining the
> basic and long-standing DNS value proposition???
>=20
>=20
>>   In contrast, the concern is that DNS whitelisting may fundamentally
>>   change this model.  In the altered DNS whitelisting end-to-end =
model,
>>   one end (where the end user is located) cannot readily connect to =
the
>>   other end (where the content is located), without parts of the =
middle
>>   (recursive resolvers) used by one end (the client, or end user =
hosts)
>>   being known to an intermediary (authoritative nameservers) and
>>   approved for access to the resource at the end.  As new networks
>>   connect to the Internet over time, those networks need to contact =
any
>>   and all domains which have implemented DNS whitelisting in order to
>>   apply to be added to their DNS whitelist, in the hopes of making =
the
>>   content and applications residing on named server hosts in those
>>   domains accessible by the end user hosts on that new network.
>>   Furthermore, this same need to contact all domains implementing DNS
>>   whitelisting also applies to all pre-existing (but not whitelisted)
>>   networks connected to the Internet.
>>=20
>>   In the current IPv4 Internet when a new server host is added to the
>>   Internet it is generally widely available to all end user hosts and
>>   networks, when DNS whitelisting of IPv6 resource records is used,
>=20
> If it is available to the hosts, it is available to the network.
>=20
> networks, when -> networks. When
>=20
>=20
>>=20
>>=20
>>=20
>> Livingood                Expires August 26, 2011               [Page =
10]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>>   these new server hosts are not accessible to any end user hosts or
>>   networks until such time as the operator of the authoritative DNS
>=20
> They are still accessible.  The IP-level mechanisms still work.
>=20
> They are not reachable when using the domain name.
>=20
>=20
>>   servers for those new server hosts expressly authorizes access to
>>   those new server hosts by adding DNS recursive resolvers around the
>>   Internet to the ACL.  This has the potential to be a significant
>=20
> This is a good example of the reason the term ACL is inappropriate:  =
It implies
> a security protection that does not actually exist.  The hosts are =
still accessible.
>=20
>=20
>>   change in reachability of content and applications by end users and
>>   networks as these end user hosts and networks transition to IPv6,
>>   resulting in more (but different) breakage.  A concern expressed is
>>   that if much of the content that end users are most interested in =
is
>>   not accessible as a result, then end users and/or networks may =
resist
>>   adoption of IPv6 or actively seek alternatives to it, such as using
>>   multi-layer network address translation (NAT) techniques like =
NAT444
>>   [I-D.shirasaki-nat444] on a long-term basis.  There is also concern
>>   that this practice also could disrupt the continued increase in
>>   Internet adoption by end users if they cannot simply access new
>>   content and applications but must instead contact the operator of
>>   their DNS recursive resolver, such as their ISP or another third
>>   party, to have their DNS recursive resolver authorized for access =
to
>>   the content or applications that interests them.  Meanwhile, these
>>   parties say, over 99.9% of the other end users that are also using
>>   that same network or DNS recursive resolver are unable to access =
the
>>   IPv6-based content, despite their experience being a positive one.
>>=20
>>   While in Section 1 the level of IPv6-related impairment has been
>>   estimated to be as high as 0.078% of Internet users, which is a
>=20
> 8 hundredths of one percent?
>=20
> That's considered a high percentage?
>=20
> Even if it is 8%, is that considered high?
>=20
>=20
>> 5.2.  Similarities to DNS Load Balancing
>>=20
>>   DNS whitelisting also has some similarities to DNS load balancing.
>>   There are of course many ways that DNS load balancing can be
>>   performed.  In one example, multiple IP address resource records (A
>>   and/or AAAA) can be added to the DNS for a given FQDN.  This =
approach
>>   is referred to as DNS round robin [RFC1794].  DNS round robin may
>>   also be employed where SRV resource records are used [RFC2782].
>=20
> Right, but that's algorithmic rather than involving the manual method, =
described
> here. So it does not seem comparable.
>=20
>=20
>> 6.  Likely Deployment Scenarios
>>=20
>>   In considering how DNS whitelisting may emerge more widely, there =
are
>>   two likely deployment scenarios, which are explored below.
>>=20
>>   In either of these deployment scenarios, it is possible that
>>   reputable third parties could create and maintain DNS whitelists, =
in
>>   much the same way that blacklists are used for reducing email spam.
>>   In the email context, a mail operator subscribes to one or more of
>>   these lists and as such the operational processes for additions and
>>   deletions to the list are managed by a third party.  A similar =
model
>>   could emerge for DNS whitelisting, whether deployment occurs
>>   universally or on an ad hoc basis.
>=20
> The challenges of email whitelists and blacklists should be cited, =
since it
> provides a rich base of experience for such an effort, at scale.
>=20
>=20
>> 6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis
>>=20
>>   The seemingly most likely deployment scenario is where some
>=20
> Most likely?  This is not already established practice?
>=20
>=20
>>   authoritative DNS server operators implement DNS whitelisting but
>>   many or most others do not do so.  What can make this scenario
>>   challenging from the standpoint of a DNS recursive resolver =
operator
>>   is determining which domains implement DNS whitelisting, =
particularly
>>   since a domain may not do so as they initially transition to IPv6,
>>   and may instead do so later.  Thus, a DNS recursive resolver =
operator
>>=20
>>=20
>>=20
>> Livingood                Expires August 26, 2011               [Page =
13]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>>   may initially believe that they can receive AAAA responses as a
>>   domain adopts IPv6, but then notice via end user reports that they =
no
>>   longer receive AAAA responses due to that domain adopting DNS
>>   whitelisting.  Of course, a domain's IPv6 transition may be
>>   effectively invisible to recursive server operators due to the =
effect
>>   of DNS whitelisting.
>=20
> This suggests that every listing at the server needs a contact record =
for
> periodic checks whether to renew the listing.
>=20
>=20
>>=20
>>   In contrast to a universal deployment of DNS whitelisting
>>   Section 6.2, deployment on an ad hoc basis is likely to be
>>   significantly more challenging from an operational, monitoring, and
>=20
> Oh?  Use in small scale is more challenging than use of manual =
exceptions list
> at large scale?  That's a very unexpected view.
>=20
>=20
>>   troubleshooting standpoint.  In this scenario, a DNS recursive
>>   resolver operator will have no way to systematically determine
>>   whether DNS whitelisting is or is not implemented for a domain, =
since
>>   the absence of AAAA resource records may simply be indicative that
>>   the domain has not yet added IPv6 addressing for the domain, rather
>>   than that they have done so but have restricted query access via =
DNS
>=20
> The premise is that, in large scale use, servers /will/ have a way to
> systematically determine whether it is implemented?  What are the =
existing
> examples of having such a capability for other Internet protocols and =
services?
>=20
>=20
>>   whitelisting.  As a result, discovering which domains implement DNS
>>   whitelisting, in order to differentiate them from those that do =
not,
>>   is likely to be challenging.
>>=20
>>   One benefit of DNS whitelisting being deployed on an ad hoc basis =
is
>>   that only the domains that are interested in doing so would have to
>>   upgrade their authoritative DNS servers in order to implement the
>>   ACLs necessary to perform DNS whitelisting.
>>=20
>>   In this potential deployment scenario, it is also possible that a
>>   given domain will implement DNS whitelisting temporarily.  A =
domain,
>>   particularly a highly-trafficked domain, may choose to do so in =
order
>>   to ease their transition to IPv6 through a selective deployment and
>>   minimize any perceived risk in such a transition.
>>=20
>> 6.2.  Deploying DNS Whitelisting Universally
>>=20
>>   The least likely deployment scenario is one where DNS whitelisting =
is
>>   implemented on all authoritative DNS servers, across the entire
>>   Internet.  While this scenario seems less likely than ad hoc
>>   deployment due to some parties not sharing the concerns that have =
so
>>   far motivated the use of DNS whitelisting, it is nonetheless
>>   conceivable that it could be one of the ways in which DNS
>>   whitelisting is deployed.
>=20
> Significantly, the partial-deployment model casts this mechanism as a =
transition
> expedient -- as the document reasonably describes it -- whereas =
universal
> deployment casts it as a fundamental change to the architecture.
>=20
> Given that it would take decades to achieve relatively full deployment =
of this
> 'across the entire Internet', what is the benefit of discussing this =
highly
> unlikely scenario?  Is it really "conceivable"?  I doubt it. If you =
think
> otherwise, the paper needs to explore the deployment and adoption =
issues in much
> more detail, because I don't see how it could work.
>=20
>=20
>>   In order for this deployment scenario to occur, it is likely that =
DNS
>>   whitelisting functionality would need to be built into all
>>   authoritative DNS server software, and that all operators of
>>   authoritative DNS servers would have to upgrade their software and
>>   enable this functionality.  It is likely that new Internet Draft
>>   documents would need to be developed which describe how to properly
>>   configure, deploy, and maintain DNS whitelisting.  As a result, it =
is
>>=20
>>=20
>>=20
>> Livingood                Expires August 26, 2011               [Page =
14]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>>   unlikely that DNS whitelisting would, at least in the next several
>>   years, become universally deployed.  Furthermore, these DNS
>>   whitelists are likely to vary on a domain-by-domain basis, =
depending
>>   upon a variety of factors.  Such factors may include the motivation
>>   of each domain owner, the location of the DNS recursive resolvers =
in
>>   relation to the source content, as well as various other parameters
>>   that may be transitory in nature, or unique to a specific end user
>>   host type.  It is probably unlikely that a single clearinghouse for
>>   managing whitelisting is possible; it will more likely be unique to
>>   the source content owners and/or domains which implement DNS
>>   whitelists.
>>=20
>>   While this scenario may be unlikely, it may carry some benefits.
>>   First, parties performing troubleshooting would not have to =
determine
>>   whether or not DNS whitelisting was being used, as it always would =
be
>>   in use.  In addition, if universally deployed, it is possible that
>>   the criteria for being added to or removed from a DNS whitelist =
could
>>   be standardized across the entire Internet.  Nevertheless, even if
>>   uniform DNS whitelisting policies were not standardized, is also
>>   possible that a central registry of these policies could be =
developed
>>   and deployed in order to make it easier to discover them, a key =
part
>>   of achieving transparency regarding DNS whitelisting.
>=20
> Is any of this paragraph realistic?  Obviously my asking means I don't =
it is.
> These seem to be of theoretical rather than pragmatic interest.  ("If =
everyone
> refuses to shoot, there will be no wars.")
>=20
> It's true that this is an "implications" paper rather than a BCP, but =
still...
>=20
>=20
>>=20
>> 7.  Implications of DNS Whitelisting
>>=20
>>   There are many potential implications of DNS whitelisting.  The key
>>   potential implications are detailed below.
>>=20
>> 7.1.  Architectural Implications
>>=20
>>   DNS whitelisting could be perceived as modifying the end-to-end =
model
>>   and/or the general notion of the architecture that prevails on the
>=20
> I'll suggest that perception is not a major issue about a technical =
topic like
> this.  (It's not entirely irrelevant, of course, but I suspect it is =
quite minor.)
>=20
> The major issue is whether it /actually/ modifies the end-to-end =
nature of the
> DNS.  And I think it does, as well as modifying the "spontaneous
> interoperability" expectation for most Internet mechanism, since it =
requires
> prior registration.
>=20
>=20
>> 7.2.  Public IPv6 Address Reachability Implications
>>=20
>>   The predominant experience of end user hosts and servers on the =
IPv4-
>>   addressed Internet today is that when a new server with a public =
IPv4
>>   address is added to the DNS, that it is then globally accessible by
>=20
> This sentence is not quite correct, in strict technical terms.  Since =
this is a
> technical discussion, we need to be precise:  the host is reachable =
when the
> routing tables make it reachable.  That's strictly a mapper of IP =
Address
> handling, not name-to-address mapping.
>=20
> What you mean is that its domain name is immediately useful for =
reaching it.
>=20
>=20
>>   IPv4-addressed hosts.  This is a generalization and in Section 5
>>   there are examples of common cases where this may not necessarily =
be
>>   the case.  For the purposes of this argument, that concept of
>>   accessibility can be considered "pervasive reachability".  It has =
so
>>   far been assumed that the same expectations of pervasive =
reachability
>>   would exist in the IPv6-addressed Internet.  However, if DNS
>>   whitelisting is deployed, this will not be the case since only end
>>   user hosts using DNS recursive resolvers which are included in the
>=20
> again, you mean /name-based/ reachability.
>=20
>=20
>>=20
>>=20
>>=20
>> Livingood                Expires August 26, 2011               [Page =
16]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>>   ACL of a given domain using DNS whitelisting would be able to reach
>>   new servers in that given domain via IPv6 addresses.  The =
expectation
>>   of any end user host being able to connect to any server =
(essentially
>>   both hosts, just at either end of the network), defined here as
>>   "pervasive reachability", will change to "restricted reachability"
>>   with IPv6.
>>=20
>>   Establishing DNS whitelisting as an accepted practice in the early
>>   phases of mass IPv6 deployment could well establish it as an =
integral
>>   part of how IPv6 DNS resource records are deployed globally.  As a
>>   result, it is then possible that DNS whitelisting could live on for
>>   decades on the Internet as a key foundational element of domain =
name
>>   management that we will all live with for a long time.
>=20
> (that last sentence could benefit from some editing.)
>=20
>=20
>>   It is a critical to understand that the concept of reachability
>>   described above depends upon a knowledge or awareness of an address
>>   in the DNS.  Thus, in order to establish reachability to an end
>>   point, a host is dependent upon looking up an IP address in the DNS
>=20
> If this section were started with a sentence like this, then there =
would not be
> a problem with the other references' being confused with address-based =
routing
> reachability.
>=20
>=20
>>   when a FQDN is used.  When DNS whitelisting is used, it is quite
>>   likely the case that an IPv6-enabled end user host could ping or
>>   connect to an example server host, even though the FQDN associated
>>   with that server host is restricted via a DNS whitelist.  Since =
most
>=20
> First, I suspect that "example" doesn't add meaning to the sentence.  =
Second,
> pinging and connecting might happen with or without the whitelist =
entry.  So I
> do not understand what import there is in this sentence.
>=20
>=20
>>   Internet applications and hosts such as web servers depend upon the
>>   DNS, and as end users connect to FQDNs such as www.example.com and =
do
>>   not remember or wish to type in an IP address, the notion of
>>   reachability described here should be understood to include =
knowledge
>>   how to associate a name with a network address.
>=20
> Again, this 'premise' statement should introduce the sub-section, not =
end it.
>=20
>=20
>>=20
>> 7.3.  Operational Implications
>>=20
>>   This section explores some of the operational implications which =
may
>>   occur as a result of, are related to, or become necessary when
>>   engaging in the practice of DNS whitelisting.
>>=20
>> 7.3.1.  De-Whitelisting May Occur
>=20
> The more general version of this issue is 'synchronization'.  Entries =
in the
> whitelist need to be synchronized with host status and capabilities.
>=20
>=20
>>   It is possible for a DNS recursive resolver added to a whitelist to
>>   then be removed from the whitelist, also known as de-whitelisting.
>>   Since de-whitelisting can occur, through a decision by the
>>   authoritative server operator, the domain owner, or even due to a
>>   technical error, an operator of a DNS recursive resolver will have
>>   new operational and monitoring requirements and/or needs as noted =
in
>>   Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5.
>>=20
>> 7.3.2.  Authoritative DNS Server Operational Implications
>>=20
>>   Operators of authoritative servers may need to maintain an ACL a
>=20
> a -> on a (?)
>=20
>=20
>>   server-wide basis affecting all domains, on a domain-by-domain =
basis,
>>=20
>>=20
>> Livingood                Expires August 26, 2011               [Page =
17]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>>   as well as on a combination of the two.  As a result, operational
>=20
> I'm not really understanding the first sentence.  One problem might be =
that its
> discussing an implication of some configuration or usage options that =
have not
> been previously specified, so that the reference here might be overly =
cryptic.
>=20
> For example, I don't know what "affecting all domains" actually means. =
 It
> almost sounds as if it could mean "everyone gets AAAA records" or "no =
one gets
> AAAA records" yet I'm reaonably certain that is /not/ what is meant.
>=20
>=20
>>   practices and software capabilities may need to be developed in =
order
>>   to support such functionality.  In addition, processes may need to =
be
>>   put in place to protect against inadvertently adding or removing IP
>>   addresses, as well as systems and/or processes to respond to such
>>   incidents if and when they occur.  For example, a system may be
>>   needed to record DNS whitelisting requests, report on their status
>>   along a workflow, add IP addresses when whitelisting has been
>>   approved, remove IP addresses when they have been de-whitelisted, =
log
>>   the personnel involved and timing of changes, schedule changes to
>>   occur in the future, and to roll back any inadvertent changes.
>=20
> Might be worth starting with a simple, broad summary statement, =
possibly along
> the lines of:
>=20
>   An AAAA DNS Whitelist serves as a critical infrastructure service; =
to be
> useful it needs careful and extensive administration, monitoring and =
operation.
> Each new and essential mechanism creates substantial follow-on support =
costs.
>=20
>=20
>>   Operators may also need implement new forms of monitoring in order =
to
>>   apply change control, as noted briefly in Section 7.3.4.
>>=20
>> 7.3.3.  DNS Recursive Resolver Server Operational Implications
>>=20
>>   Operators of DNS recursive resolvers, which may include ISPs,
>>   enterprises, universities, governments, individual end users, and
>>   many other parties, are likely to need to implement new forms of
>>   monitoring, as noted briefly in Section 7.3.4.  But more =
critically,
>>   such operators may need to add people, processes, and systems in
>>   order to manage large numbers of DNS whitelisting applications as
>>   part of their own IPv6 transition, for all domains that the end =
users
>>   of such servers are interested in now or in which they may be
>=20
> I think the summary observation is simple and should be stated =
directly:  This
> is a manual mechanism that becomes expensive in time and personnel =
effort as it
> scales up.
>=20
>=20
>>   interested in the future.  As anticipation of interesting domains =
is
>>   likely infeasible, it is more likely that operators may either =
choose
>>   to only apply to be whitelisted for a domain based upon one or more
>>   end user requests, or that they will attempt to do so for all =
domains
>>   that they can ascertain to be engaging in DNS whitelisting.
>=20
> "attempt to do so for all domain that they can ascertain to be =
engaging in DNS
> whitelisting"  appears to be saying to do whitelisting for domains =
that do
> whitelisting.  I don't understand.
>=20
>=20
>>=20
>>   When operators apply for DNS whitelisting for all domains, that may
>=20
> "apply for DNS whitelisting for all domains" -- again I'm not =
understanding what
> this means.
>=20
>=20
>> 7.3.5.  Implications of Operational Momentum
>>=20
>>   It seems plausible that once DNS whitelisting is implemented it =
will
>>   be very difficult to deprecate such technical and operational
>>   practices.  This assumption is based in an understanding of human
>=20
> in -> on
>=20
>=20
>>   nature, not to mention physics.  For example, as Sir Issac Newton
>>   noted, "Every object in a state of uniform motion tends to remain =
in
>>   that state of motion unless an external force is applied to it" =
[Laws
>=20
> Code does not have momenum.  Neither do configurations or lists.  This =
really
> isn't about physics.
>=20
> It is entirely about group psychology, as you note, and the =
administrative
> challenges in the logistics of large-scale operational changes (which =
probably
> /does/ have something to with physics, but it seems a stretch to =
credit Newton.
> How about Heisenberg?...)
>=20
>=20
>>   of Motion].  Thus, once DNS whitelisting is implemented it is quite
>>   likely that it would take considerable effort to deprecate the
>>   practice and remove it everywhere on the Internet - it will =
otherwise
>>   simply remain in place in perpetuity.  To better illustrate this
>>   point, one could consider one example (of many) that there are many
>>   email servers continuing to attempt to query or otherwise check =
anti-
>>=20
>>=20
>>=20
>> Livingood                Expires August 26, 2011               [Page =
19]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>>   spam DNS blocklists which have long ago ceased to exist.
>>=20
>> 7.3.6.  Troubleshooting Implications
>>=20
>>   The implications of DNS whitelisted present many challenges, which
>>   have been detailed in Section 7.  These challenges may negatively
>=20
> But this is /still/ section 7.  Can you be more specific?  Or perhaps =
say
> "throughout this section".
>=20
>=20
>>   affect the end users' ability to troubleshoot, as well as that of =
DNS
>>   recursive resolver operators, ISPs, content providers, domain =
owners
>>   (where they may be different from the operator of the authoritative
>>   DNS server for their domain), and other third parties.  This may =
make
>>   the process of determining why a server is not reachable
>>   significantly more complex.
>>=20
>> 7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis
>>=20
>>   Additional implications, should this be deployed on an ad hoc =
basis,
>>   could include scalability problems relating to operational =
processes,
>=20
> I'm pretty sure that scaling problems for this exist in all scenarios, =
not just
> ad hoc usage.
>=20
>=20
>>   monitoring, and ACL updates.  In particular, it seems likely that =
as
>>   the number of domains that are using DNS whitelisting increases, as
>>   well as the number of IPv6-capable networks requesting to be
>>   whitelisted, that there is an increased likelihood of configuration
>>   and other operational errors, especially with respect to the ACLs
>>   themselves.
>>=20
>>   It is unclear when and if it would be appropriate to change from
>>   whitelisting to blacklisting, and whether or how this could =
feasibly
>>   be coordinated across the Internet, which may be proposed or
>=20
> Actually the question of coordination is quite clear and rather =
fundamental:
>=20
>     No.
>=20
> Anyone believing otherwise needs to cite a successful example, at =
Internet scale
> and diversity, more recently than the 1983 switch to IP (which didn't =
go all
> that well anyhow...)
>=20
> Simple, unambiguous showstoppers should be stated in a simple and =
direct manner.
> When there is room for debate, softer language makes sense.  Again, if =
the
> question of coordination really is subject to debate, then the basis =
needs to be
> stated.  (Good luck!)
>=20
>=20
>>   implemented on an ad hoc basis when a majority of networks (or
>>   allocated IPv6 address blocks) have been whitelisted.  Finally, =
some
>>   parties implementing DNS whitelisting consider this to be a =
temporary
>>   measure.  As such, it is not clear how these parties will judge the
>>   network conditions to have changed sufficiently to justify =
disabling
>>   DNS whitelisting and/or what the process and timing will be in =
order
>>   to discontinue this practice.
>>=20
>>   One further potential implication is that an end user with only an
>>   IPv4 address, using a DNS resolver which has not been whitelisted =
by
>>   any domains, would not be able to get any AAAA resource records.  =
In
>>   such a case, this could give that end user the incorrect impression
>>   that there is no IPv6-based content on the Internet since they are
>>   unable to discover any IPv6 addresses via the DNS.
>>=20
>> 7.4.  Homogeneity May Be Encouraged
>>=20
>>   A broad trend which has existed on the Internet appears to be a =
move
>>   towards increasing levels of heterogeneity.  One manifestation of
>=20
> increasing levels of heterogeneity -> more heterogeneity
>=20
> (I think heterogeneity does not have 'levels'.)
>=20
> Substantively:  say the nature of the heterogeneity within the initial =
claim.
> For example, there is /less/ heterogeneity of ISPs, given industry
> consolidation.  There is less heterogeneity of infrastructure =
equipment such as
> routers.  Etc.
>=20
>=20
>>   this is in an increasing number, variety, and customization of end
>>   user hosts, including home network, operating systems, client
>>=20
>>=20
>>=20
>> Livingood                Expires August 26, 2011               [Page =
20]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>>   software, home network devices, and personal computing devices.  =
This
>>   trend appears to have had a positive effect on the development and
>>   growth of the Internet.  A key facet of this that has evolved is =
the
>>   ability of the end user to connect any technically compliant device
>>   or use any technically compatible software to connect to the
>>   Internet.  Not only does this trend towards greater heterogeneity
>>   reduce the control which is exerted in the middle of the network,
>>   described in positive terms in [Tussle in Cyberspace], [Rethinking
>>   the Internet], and [RFC3724], but it can also help to enable =
greater
>>   and more rapid innovation at the edges.
>>=20
>>   An unfortunate implication of the adoption of DNS whitelisting may =
be
>>   the encouragement of a reversal of this trend, which would be a =
move
>=20
> the encouragement of -> to encourage
>=20
>=20
>> 8.1.  Implement DNS Whitelisting Universally
>>=20
>>   One obvious solution is to implement DNS whitelisted universally, =
and
>>   to do so using some sort of centralized registry of DNS =
whitelisting
>>   policies, contracts, processes, or other information.  This =
potential
>>   solution seems unlikely at the current time.
>=20
> I'm pretty sure that the only thing that is obvious about a premise of =
universal
> adoption is that it's not practical.  Seriously.
>=20
> At the least, this section needs to be less cavalier about putting =
this
> alternative forward as a "solution", especially given the rather =
serious
> drawbacks/problems with it.
>=20
>=20
>> 8.2.  Implement DNS Whitelisting On An Ad Hoc Basis
>>=20
>>   If DNS whitelisting is to be adopted, it is likely to be adopted on
>=20
> "is to be"?  I thought it already had a significant installed base.
>=20
>=20
>>   this ad hoc, or domain-by-domain basis.  Therefore, only those
>>   domains interested in DNS whitelisting would need to adopt the
>>   practice, though as noted herein discovering that they a given =
domain
>>   has done so may be problematic.  Also in this scenario, ad hoc use =
by
>>   a particular domain may be a temporary measure that has been =
adopted
>>   to ease the transition of the domain to IPv6 over some short-term
>>   timeframe.
>>=20
>> 8.3.  Do Not Implement DNS Whitelisting
>>=20
>>   As an alternative to adopting DNS whitelisting, the Internet
>>   community generally can choose to take no action whatsoever,
>>   perpetuating the current predominant authoritative DNS operational
>>   model on the Internet, and leave it up to end users with =
IPv6-related
>>   impairments to discover and fix those impairments.
>>=20
>=20
> That is, place the burden of fixing a problem on those creating it?
>=20
>=20
>>=20
>>=20
>>=20
>>=20
>> Livingood                Expires August 26, 2011               [Page =
23]
>>=20
>> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February =
2011
>>=20
>>=20
>> 8.3.1.  Solving Current End User IPv6 Impairments
>>=20
>>   A further extension of not implementing DNS whitelisting, is to =
also
>>   endeavor to actually fix the underlying technical problems that =
have
>>   prompted the consideration of DNS whitelisting in the first place, =
as
>>   an alternative to trying to apply temporary workarounds to avoid =
the
>>   symptoms of underlying end user IPv6 impairments.  A first step is
>>   obviously to identify which users have such impairments, which =
would
>>   appear to be possible, and then to communicate this information to
>>   end users.  Such end user communication is likely to be most =
helpful
>>   if the end user is not only alerted to a potential problem but is
>>   given careful and detailed advice on how to resolve this on their
>>   own, or where they can seek help in doing so.  Section 11 may also =
be
>>   relevant in this case.
>>=20
>>   One challenge with this option is the potential difficulty of
>>   motivating members of the Internet community to work collectively
>>   towards this goal, sharing the labor, time, and costs related to =
such
>>   an effort.  Of course, since just such a community effort is now
>>   underway for IPv6, it is possible that this would call for only a
>>   moderate amount of additional work.
>=20
> This 'challenge' is at the core of /all/ adoption efforts for Internet =
protocols
> and services that entail distributed adoption.
>=20
>=20
>>   Despite any potential challenges, many in the Internet community =
are
>>   already working towards this goal and/or have expressed a general
>>   preference for this approach.
>=20
> If this is not already an organized effort with a website, sponsoring
> consortium, or the like, it should be.  If it is, then cite it in this =
doc!
>=20
>>=20
>> 8.3.2.  Gain Experience Using IPv6 Transition Names
>>=20
>>   Another alternative is for domains to gain experience using an FQDN
>>   which has become common for domains beginning the transition to =
IPv6;
>>   ipv6.example.com and www.ipv6.example.com.  This can be a way for a
>>   domain to gain IPv6 experience and increase IPv6 use on a =
relatively
>>   controlled basis, and to inform any plans for DNS whitelisting with
>>   experience.
>=20
> I do not understand what this means.
>=20
> What is it for?  What are the results?  How are theyused?
>=20
>=20
>> 9.  Is DNS Whitelisting a Recommended Practice?
>>=20
>>   Opinions in the Internet community concerning whether or not DNS
>>   whitelisting is a recommended practice are understandably quite
>>   varied.  However, there is clear consensus that DNS whitelisting is
>>   at best a useful temporary measure which a domain may choose to
>=20
> If that is a clear consensus, then it makes even less sense to promote =
the idea
> of universal adoption, given the timescale needed to achieve it.
>=20
>=20
>> 10.  Security Considerations
>>=20
>>   There are no particular security considerations if DNS whitelisting
>>   is not adopted, as this is how the public Internet works today with =
A
>>   resource records.
>=20
> Or rather, failure to adopt a mechanism like this or repair the =
underlying
> problem, for those sites experiencing that problem, will result in a =
denial of
> service, albeit not an intentional one.  Still, that's a pretty basic =
security
> issue.
>=20
>=20
> d/
> --=20
>=20
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>=20
>=20
> --=20
>=20
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>=20


From lorenzo@google.com  Mon May 30 02: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 95E5BE0759 for ; Mon, 30 May 2011 02:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 GO0kLWQn0j8D for ; Mon, 30 May 2011 02:06:57 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D0C5AE0707 for ; Mon, 30 May 2011 02:06:56 -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 p4U96sqv026130 for ; Mon, 30 May 2011 02:06:55 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306746415; bh=ZrVDYmu1WfU0eN4BIYMt6IY1hSk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=DVxgur7ysn723W0wagwYbMOEa9fsLwPMt9qQX4PqunBBUAUdpLWs322IpWe9IePJ/ hdEBNdgqzy4AP18seaJYQ==
Received: from gwb19 (gwb19.prod.google.com [10.200.2.19]) by wpaz21.hot.corp.google.com with ESMTP id p4U96rfL005597 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 30 May 2011 02:06:53 -0700
Received: by gwb19 with SMTP id 19so1830200gwb.32 for ; Mon, 30 May 2011 02:06:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nEw3h1R6gWipC37aMlJbrYbp62YPknGjP5wVGWSOTO4=; b=vjXYSR+25UPMEFc510+hfhwUrRjUJtFtLXB88xJYOx0qzvLXeNlMPVEDD1oq3nhP/w KlA7DZRu/wWU7yGIB4iA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=jP3dlNe0ts8cL+mIlVyC/IDz+Hg+SgEK/POAajP+CDfYjcDtYwund24x6E+htu7be6 PWnkH0r7JLefbiRQv+VQ==
Received: by 10.151.24.10 with SMTP id b10mr3842618ybj.93.1306746413353; Mon, 30 May 2011 02:06:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Mon, 30 May 2011 02:06:33 -0700 (PDT)
In-Reply-To: 
References:  
From: Lorenzo Colitti 
Date: Mon, 30 May 2011 02:06:33 -0700
Message-ID: 
To: "Livingood, Jason" 
Content-Type: multipart/alternative; boundary=000e0cd23ef6c789b404a47a9b57
X-System-Of-Record: true
Cc: Erik Kline , "v6ops@ietf.org" 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 - traffic load considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 30 May 2011 09:06:57 -0000

--000e0cd23ef6c789b404a47a9b57
Content-Type: text/plain; charset=ISO-8859-1

On Sun, May 29, 2011 at 8:25 PM, Livingood, Jason <
Jason_Livingood@cable.comcast.com> wrote:

>  Why does the draft neglect to mention the equal but opposite "sudden and
> dramatic change to networks" that can occur if a high-traffic domain
> suddenly announces AAAA records for the whole world without whitelisting?
>
>
>  [JL] Well, actually the draft *does* mention this. Please note the
> following instances with specific and/or relation mentions of this. I am
> open to any suggestions you may have on these or on additional mentions of
> course. :-)
>

None of those snippets mention changes to other networks, let alone "sudden
and dramatic" changes.

--000e0cd23ef6c789b404a47a9b57
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Sun, May 29, 2011 at 8:25 PM, Livingood, =
Jason <Jason_Livingood@cable.comcast.com> wr=
ote:











Why does the draft neglect to m=
ention the equal but opposite "sudden and dramatic change to networks&=
quot; that can occur if a high-traffic domain suddenly announces AAAA recor=
ds for the whole world without whitelisting?















[JL] Well, actually the draft *does* mention this. Please =
note the following instances with specific and/or relation mentions of this=
. I am open to any suggestions you may have on these or on additional menti=
ons of course. :-)





None of those snippets mention chang=
es to other networks, let alone "sudden and dramatic" changes.


--000e0cd23ef6c789b404a47a9b57--

From jason_livingood@cable.comcast.com  Mon May 30 06:02: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 DA1F8E07C9 for ; Mon, 30 May 2011 06:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.214
X-Spam-Level: 
X-Spam-Status: No, score=-108.214 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 IR2C8bRU6u6b for ; Mon, 30 May 2011 06:02:12 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 02393E07BE for ; Mon, 30 May 2011 06:02:11 -0700 (PDT)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128208426; Mon, 30 May 2011 08:59:03 -0400
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, 30 May 2011 08:59:03 -0400
From: "Livingood, Jason" 
To: Lorenzo Colitti 
Thread-Topic: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 - traffic load considerations
Thread-Index: AQHMDmJcdMlTH64Ob0qwxzp9To93NJSkVU6AgACwB4D//9BvAIAAokOA///95AA=
Date: Mon, 30 May 2011 12:59:02 +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.10.0.110310
x-originating-ip: [24.40.55.71]
Content-Type: multipart/alternative; boundary="_000_CA090C3628B1Ejasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: Erik Kline , "v6ops@ietf.org" 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 - traffic load considerations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 30 May 2011 13:02:13 -0000

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


On Sun, May 29, 2011 at 8:25 PM, Livingood, Jason > wrote:
Why does the draft neglect to mention the equal but opposite "sudden and dr=
amatic change to networks" that can occur if a high-traffic domain suddenly=
 announces AAAA records for the whole world without whitelisting?

[JL] Well, actually the draft *does* mention this. Please note the followin=
g instances with specific and/or relation mentions of this. I am open to an=
y suggestions you may have on these or on additional mentions of course. :-=
)

None of those snippets mention changes to other networks, let alone "sudden=
 and dramatic" changes.

[JL] Then perhaps I am misunderstanding what you are asking for. For exampl=
e, 3.2 does say sudden:
"For example, one can imagine for one of the top ten sites globally that th=
e idea of suddenly turning on a significant amount of IPv6 traffic might be=
 quite daunting. DNS Whitelisting may therefore offer such high-traffic dom=
ains one potential method for incrementally enabling IPv6. Thus, some imple=
menters with high-traffic domains plan to use DNS Whitelisting is a necessa=
ry, though temporary, risk reduction tactic intended to ease their transiti=
on to IPv6 and minimize any perceived risk in such a transition."

Can you explain exactly what you mean / are asking for? I can keep guessing=
 but it'd be far easier if you could explain it. ;-)

Jason

--_000_CA090C3628B1Ejasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <34F0D2B13AE6934C8FF2A05447A3DB7D@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable












On Sun, May 29, 2011 at 8:25 PM, Livingood, Jaso=
n 
<=
Jason_Livingood@cable.comcast.com> wrote:
















Why does the draft neglect to mention the equal but opposite "sud=
den and dramatic change to networks" that can occur if a high-traffic =
domain suddenly announces AAAA records for the whole world without whitelis=
ting?
















[JL] Well, actually the draft *does* mention this. Please note the fol=
lowing instances with specific and/or relation mentions of this. I am open =
to any suggestions you may have on these or on additional mentions of cours=
e. :-)











None of those snippets mention changes to other networks, let alone &q=
uot;sudden and dramatic" changes.












[JL] Then perhaps I am misunderstanding what you are asking for. For e=
xample, 3.2 does say sudden: 


"For example, one can imagine for one of the top ten sites glo=
bally that the idea of suddenly turning on a significant amount of IPv6 tra=
ffic might be quite daunting. DNS Whitelisting may therefore offer such hig=
h-traffic domains one potential method
 for incrementally enabling IPv6. Thus, some implementers with high-traffic=
 domains plan to use DNS Whitelisting is a necessary, though temporary, ris=
k reduction tactic intended to ease their transition to IPv6 and minimize a=
ny perceived risk in such a transition."







Can you explain exactly what you mean / are asking for? I can keep gue=
ssing but it'd be far easier if you could explain it. ;-)







Jason




--_000_CA090C3628B1Ejasonlivingoodcablecomcastcom_--

From internet-drafts@ietf.org  Mon May 30 06:36: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 E88E0E07D2; Mon, 30 May 2011 06:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.54
X-Spam-Level: 
X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 BlngObc7bGSo; Mon, 30 May 2011 06:36:31 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11217E07C9; Mon, 30 May 2011 06:36:31 -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: <20110530133631.13554.94278.idtracker@ietfa.amsl.com>
Date: Mon, 30 May 2011 06:36:31 -0700
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05.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, 30 May 2011 13:36:32 -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 AAAA DNS Whitelisting Implications
	Author(s)       : Jason Livingood
	Filename        : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05.txt
	Pages           : 39
	Date            : 2011-05-30

   The objective of this document is to describe the practice of
   whitelisting of DNS recursive resolvers in order to limit AAAA
   resource records responses, which contain IPv6 addresses, hereafter
   referred to as DNS Whitelisting, as well as the implications of this
   emerging practice and what alternatives or variations may exist.
   This practice is a type of IPv6 transition mechanism used by domains,
   as a method for incrementally transitioning inbound traffic to a
   domain from IPv4 to IPv6 transport.  The audience for this document
   is the Internet community generally, particularly IPv6 implementers.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-i=
mplications-05.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-v6-aaaa-whitelisting-im=
plications-05.txt

From jason_livingood@cable.comcast.com  Mon May 30 06: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 C9A60E07C9 for ; Mon, 30 May 2011 06:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.947
X-Spam-Level: 
X-Spam-Status: No, score=-107.947 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 jvvbXYP-EESM for ; Mon, 30 May 2011 06:40:33 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 74E37E06FD for ; Mon, 30 May 2011 06:40:33 -0700 (PDT)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128219802; Mon, 30 May 2011 09:40:31 -0400
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, 30 May 2011 09:40:30 -0400
From: "Livingood, Jason" 
To: "v6ops@ietf.org" 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05.txt
Thread-Index: AQHMHs8dweq7/Mu7EUGLH1T/Jm2hfA==
Date: Mon, 30 May 2011 13:40:29 +0000
Message-ID: 
In-Reply-To: <20110530133631.13554.94278.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [24.40.55.71]
Content-Type: multipart/alternative; boundary="_000_CA0915D228B51jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05.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, 30 May 2011 13:40:34 -0000

--_000_CA0915D228B51jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

This update was specifically to clear one of the open Discuss positions by =
the IESG. I suspect it is likely you will see a few more of those targeted =
updates as I close each one of those out. I also will be working on the cur=
rent list of Open Issues in Appendix B. I've certainly taken note of Lorenz=
o's ongoing questions, and think this is related to an Open Issue I am carr=
ying for Jari Arkko. I hope to receive sufficient feedback from Lorenzo or =
others soon to help me close that one out =96 as it is important to fully a=
ccount for all of the concerns/motivations he and other implementers have.

Thanks
Jason


On 5/30/11 9:36 AM, "internet-drafts@ietf.org" > wrote:

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 AAAA DNS Whitelisting Implications
Author(s)       : Jason Livingood
Filename        : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-05.txt
Pages           : 39
Date            : 2011-05-30

   The objective of this document is to describe the practice of
   whitelisting of DNS recursive resolvers in order to limit AAAA
   resource records responses, which contain IPv6 addresses, hereafter
   referred to as DNS Whitelisting, as well as the implications of this
   emerging practice and what alternatives or variations may exist.
   This practice is a type of IPv6 transition mechanism used by domains,
   as a method for incrementally transitioning inbound traffic to a
   domain from IPv4 to IPv6 transport.  The audience for this document
   is the Internet community generally, particularly IPv6 implementers.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-i=
mplications-05.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-v6-aaaa-whitelisting-im=
plications-05.txt
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--_000_CA0915D228B51jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <8FD136F147088440A0B015C46F8405CD@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable









This update was specifically to clear one of the open Discuss position=
s by the IESG. I suspect it is likely you will see a few more of those targ=
eted updates as I close each one of those out. I also will be working on th=
e current list of Open Issues in
 Appendix B. I've certainly taken note of Lorenzo's ongoing questions, and =
think this is related to an Open Issue I am carrying for Jari Arkko. I hope=
 to receive sufficient feedback from Lorenzo or others soon to help me clos=
e that one out =96 as it is important
 to fully account for all of the concerns/motivations he and other implemen=
ters have. 







Thanks


Jason






















A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories. This draft is a work item of the IPv6 Operations Working Group of=
 the IETF.







Title&=
nbsp;          : IPv6 AAAA DNS=
 Whitelisting Implications


Author=
(s)       : Jason Livingood


Filena=
me        : draft-ietf-v6ops-v6-aaa=
a-whitelisting-implications-05.txt


Pages&=
nbsp;          : 39


Date&n=
bsp;           : 201=
1-05-30







   The objective of this document is to describe the practic=
e of


   whitelisting of DNS recursive resolvers in order to limit=
 AAAA


   resource records responses, which contain IPv6 addresses,=
 hereafter


   referred to as DNS Whitelisting, as well as the implicati=
ons of this


   emerging practice and what alternatives or variations may=
 exist.


   This practice is a type of IPv6 transition mechanism used=
 by domains,


   as a method for incrementally transitioning inbound traff=
ic to a


   domain from IPv4 to IPv6 transport.  The audien=
ce for this document


   is the Internet community generally, particularly IPv6 im=
plementers.












A URL for this Internet-Draft is:








Internet-Drafts are also available by anonymous FTP at:








This Internet-Draft can be retrieved at:



_______________________________________________


v6ops mailing list













--_000_CA0915D228B51jasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Mon May 30 06:42: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 53938E07D0; Mon, 30 May 2011 06:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.312
X-Spam-Level: 
X-Spam-Status: No, score=-108.312 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 Uzfjejphv6ea; Mon, 30 May 2011 06:42:17 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 963E7E07C9; Mon, 30 May 2011 06:42:16 -0700 (PDT)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128220274; Mon, 30 May 2011 09:42:03 -0400
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Mon, 30 May 2011 09:42:03 -0400
From: "Livingood, Jason" 
To: Joel Jaeggli , Dave Crocker 
Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
Thread-Index: AQHMHomIY0ACKjuDkUKxgWUUluzLgpSlYZyA
Date: Mon, 30 May 2011 13:42:02 +0000
Message-ID: 
In-Reply-To: <91AE1B6C-02F8-4023-8FAC-FD19EBB646A9@bogus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [69.141.126.196]
Content-Type: multipart/alternative; boundary="_000_CA09169928B58jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , IETF Discussion 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 30 May 2011 13:42:25 -0000

--_000_CA09169928B58jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks Joel. In that case, I plan to remove the following Open Issue from t=
he next revision:


#8 - Per Dave Crocker - do we need to change the name from
       whitelisting to an alternate term?  Dave suggests "IPv6 Resolver
       Whitelisting" or "IPv6 DNS Response Preference List" or "DNS
       Response Content Preference List".  Tony Finch suggests: So I
       suggest retitling the document "IPv6 DNS resolver whitelisting"
       and revising the terminology throughout to match.  Mark Andrews
       also suggests "DNS resolver whitelisting for AAAA resolution".
       John Leslie suggests "AAAA-blocking".

Thanks
Jason

On 5/30/11 1:21 AM, "Joel Jaeggli" > wrote:

With respect to the discussion of the whitelist/blacklist terminology I bel=
ieve it can be stipulated that the authors, the document shepherd, the work=
ing group chairs disagree with your conclusions as to the appropriateness o=
f the term whitelist.

thanks
joel

On May 29, 2011, at 9:50 AM, Dave CROCKER wrote:

On 5/29/2011 7:46 AM, Livingood, Jason wrote:
> Hi Bernard =96 I've finally found the time to close out the last bits of
> feedback > in this version of the draft.
Jason,
Perhaps my filters misfiled your followup to the "formal" review I was aske=
d to do, or perhaps my earlier, informal, and vary narrow review muddied th=
e waters, but I am not finding your response to the Apps Area review.
For convenience, here it is again.
d/
-------- Original Message --------
Subject: Review of:  draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
         *(formal for apps area)*
Date: Mon, 09 May 2011 10:18:51 -0700
From: Dave CROCKER >
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
To: IETF Discussion >
CC: v6ops@ietf.org >, Apps Review >
(This is an "official" and significantly extended version of an informal an=
d
narrow review I posted earlier.  /d)
Howdy.
I have been selected as the Applications Area Review Team reviewer for this
draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).
Please resolve these comments along with any other Last Call comments you m=
ay
receive. Please wait for direction from your document shepherd or AD before
posting a new version of the draft.
Review (v2):
Title:  IPv6 AAAA DNS Whitelisting Implications
I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03
By:     D. Crocker >
Date:   <>
Summary
=3D=3D=3D=3D=3D=3D=3D
This draft covers a a dual-stack problem in which a target host's DNS entry
contains records for IPv4 and IPv6, but returning IPv6 information to a DNS
client can cause problems. The paper discusses for resolving this through u=
se of
a a DNS-based mechanism that manually lists response preferences to select =
which
DNS records to return.  The paper describes the mechanism and explores vari=
ous
effects and possibilities of its use, including the difference between usin=
g it
selectively among a smaller number of sites, versus universally.
The draft is a serious effort to explore the use of such a mechanism and it
touches many different issues.  It is generally well-organized and clearly
written, although it very much needs the aid of a professional technical ed=
itor.
The writing often assumes too much knowledge by the reader.
The paper's exploration of universal adoption seems to vary between conside=
ring
that goal practical versus considering it only as a matter of completeness =
for
discussing the full range of possibilities.  That is, it is not clear wheth=
er
the paper views this alternative as practically possible and even preferred=
,
versus only a matter for academic thoroughness. The paper needs to take a b=
asic
position about feasibility, explain it in terms of comparable adoption effo=
rts
at Internet-scale, and then make its treatment of universal adoption a bit =
more
consistent.
When introducing terms, mechanisms, configurations and scenarios, the paper
needs to be more careful to describe them adequately for a reader new to th=
e
topic.  This is not a matter of having a tutorial about the DNS, but rather=
 a
tutorial for this type of mechanism and when and how it can be used.
As a specific example, the document cites "domain-by-domain" use, but I am =
not
clear how that would work, in terms of configuration and cross-net informat=
ion
exchange.  One question is how the server knows the 'domain' of the client?
The document should careful to distinguish what is existing practice, versu=
s
what is being explored as added possibilities.  The difference in concreten=
ess
and certitude between the two is substantial.
The document's use of the term whitelisting appears to continue an existing=
,
recent use, for this type of mechanism.  Unfortunately it directly conflict=
s
with long-standing use of the term by the anti-abuse community for whitelis=
ting
in the DNS. Its use here also seems to be a mismatch with the word's dictio=
nary
semantics, which is most naturally used to distinguish yes/no choices, rath=
er
than either/or choices.  So there is no intuitive sense of "goodness" (whit=
elist
=3D yes) or "badness" (blacklist) for this use. The word "preferences" seem=
s more
in line with the meaning of the mechanism.
Detailed Comments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Abstract
   The objective of this document is to describe what the whitelisting
   of DNS AAAA resource records is, hereafter referred to as DNS
RRs are whitelisted?  Isn't it the addresses and not the records that are
whitelisted?
Does this mean putting whitelisting records into the DNS or does it mean
something else?
Comcast's own considerable expertise notwithstanding, has this doc been vet=
ted
with a range of organizations that actually DO whitelisting?  Has it been
circulated through MAAWG and APWG?  Any comments from Spamhaus?  The
Acknowledgements list does not seem to indicate a range of whitelist ops fo=
lks
whose names I know.  (But then, I only know a few...)
   whitelisting, as well as the implications of this emerging practice
   and what alternatives may exist.  The audience for this document is
   the Internet community generally, including the IETF and IPv6
   implementers.
I suspect that product marketers won't have much interest in this.  I suspe=
ct
that the target for this is anti-abuse technical and operations staff. In a=
ny
event, the targetting statement should be more precise.
1.  Introduction
   This document describes the emerging practice of whitelisting of DNS
One natural, semantic problem with the term 'whitelist' is that it does not
really match the function being performed.  The white/black distinction imp=
lies
goodness -- or as Wikipedia says, "priviledge".  Instead, the use here is f=
or
preference or priority.  What would a "blacklist" be, here?  Also note it i=
s not
obvious what it means to be whitelisted, here?  Does it mean to choose the =
AAAA
records or the A records?
This is more like a 'Preference' or 'Configuration' list.
At the least, the name for this should be IPv6 Resolver Whitelisting.  It m=
akes
clear /what/ is being "whitelisted".
   AAAA resource records (RRs), which contain IPv6 addresses, hereafter
   referred to as DNS whitelisting.  The document explores the
This provides a name, but not a function.  That is, it does not say what th=
is
mechanisms actually /does/ or is /for/.
   implications of this emerging practice are and what alternatives may
   exist.
   The practice of DNS whitelisting appears to have first been used by
   major web content sites (sometimes described herein as "highly-
It's use for email anti-abuse dates back farther.
   
   

Specifically within the context of the DNS, the term whitelisting is theref=
ore
made ambiguous.
A google query for "whitelist dns" also demonstrates the history and curren=
t
ambiguity.
   trafficked domains" or "major domains").  These web site operators,
   or domain operators, observed that when they added AAAA resource
   records to their authoritative DNS servers in order to support IPv6
   access to their content that a small fraction of end users had slow
   or otherwise impaired access to a given web site with both AAAA and A
   resource records.  The fraction of users with such impaired access
   has been estimated to be roughly 0.078% of total Internet users
   [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
   Brokenness].  Thus, in an example Internet Service Provider (ISP)
   network of 10 million users, approximately 7,800 of those users may
   experience such impaired access.
At a minimum, these sorts of statistics need to be normalized across IPv6
users/traffic, given how small a percentage that is, in total users and tot=
al
traffic.  If that's what is meant it should be stated.  If it isn't, the
statistic should be recalculated and explained a bit more precisely.
   As a result of this impairment affecting end users of a given domain,
   a few major domains have either implemented DNS whitelisting or are
   considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].
   When implemented, DNS whitelisting in practice means that a domain's
   authoritative DNS will return a AAAA resource record to DNS recursive
   resolvers [RFC1035] on the whitelist, while returning no AAAA
   resource records to DNS resolvers which are not on the whitelist.  It
This explanation of the function should be offered sooner and should be
summarized in the Abstract.
   is important to note that these major domains are motivated by a
   desire to maintain a high-quality user experience for all of their
Rather than being important to note, this sentence sounds oddly like market=
ing
hype, in a technical specification.  It is gratuitous because specified fea=
tures
are never added to /lower/ the quality of the user experience, for example.
In addition, the mechanism also affects client activity that has no user
directly involved.
   users.  By engaging in DNS whitelisting, they are attempting to
   shield users with impaired access from the symptoms of those
   impairments.
The /technical/ statement that should be here is that they are attempting t=
o
provide a work-around for problematic behaviors in dual-stack IPv4/IPv6
environments.
The paper should make more clear exactly where the problem lies and when. I=
f it
can occur for a number of reasons, explaining each of those scenarios would=
 be
useful.
   Critics of the practice of DNS whitelisting have articulated several
   concerns.  Among these are that:
   o  DNS whitelisting is a very different behavior from the current
      practice concerning the publishing of IPv4 address resource
      records,
   o  that it may create a two-tiered Internet,
   o  that policies concerning whitelisting and de-whitelisting are
      opaque,
Livingood                Expires August 26, 2011                [Page 5]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
   o  that DNS whitelisting reduces interest in the deployment of IPv6,
   o  that new operational and management burdens are created,
well, yeah... in fact it should be noted that the burdens are particularly
onerous at scale.
   o  and that the costs and negative implications of DNS whitelisting
      outweigh the perceived benefits, compared to fixing underlying
      impairments.
and it doesn't scale.
and it violates an extremely basic premise of cross-Internet interoperabili=
ty by
requiring prior arrangement.
   This document explores the reasons and motivations for DNS
   whitelisting.  It also explores the outlined concerns regarding this
   practice.  Readers will hopefully better understand what DNS
   whitelisting is, why some parties are implementing it, and what
   criticisms of the practice exist.
2.  How DNS Whitelisting Works
How IPv6 AAAA DNS Whitelisting Works.
(Anti-spam DNS Whitelisting works rather differently...)
   DNS whitelisting is implemented in authoritative DNS servers.  These
   servers implement IP address-based restrictions on AAAA query
   responses.  So far, DNS whitelisting has been primarily implemented
   by web server operators deploying IPv6-enabled services.  For a given
Really?  This is web-specific?  The same restrictions are not applied for o=
ther
applications?
So if the same client-side hosts attempt to contact the server for email or
xmpp, they won't get the same handling?
   operator of a website, such as www.example.com, the operator
   essentially applies an access control list (ACL) on the authoritative
   DNS servers for the domain example.com.  The ACL is populated with
An ACL usually is a yes/no mechanism.  Here, however, the mechanism is for
asserting a preference for IPv6 over IPv4.
That does not seem to match the definition of ACL that I'm used to, unless =
the
semantic is defined as denying IPv4 access to the listed clients.
The term ACL is particularly odd to use if the mechanism pertains to respon=
ses
rather than queries.
   the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive
Either address type can be listed?  So this really is a pure 'preferences'
mechanism?
Which settings count as whitelisting?  Do any count as blacklisting?
   resolvers on the Internet, which have been authorized to receive AAAA
   resource record responses.  These DNS recursive resolvers are
   operated by third parties, such as ISPs, universities, governments,
   businesses, and individual end users.  If a DNS recursive resolver IS
   NOT matched in the ACL, then AAAA resource records will NOT be sent
   in response to a query for a hostname in the example.com domain.
This configuration appears to ensure the maximum barrier to adoption for IP=
v6,
since it means that IPv6 will not work automatically.  It will only work fo=
r
hosts that are manually configured to receive responses with v6 records.
That's a rather major implication.  It's a default that is probably meant t=
o
apply during the very early stages of adoption, when there are few users of=
 the
newer mechanism.
It's probably worth discussing it in more detail, including discussing when=
 to
change the default...
   However, if a DNS recursive resolver IS matched in the ACL, then AAAA
   resource records will be sent in response to a query for a given
   hostname in the example.com domain.  While these are not network-
   layer access controls they are nonetheless access controls that are a
   factor for end users and other parties like network operators,
   especially as networks and hosts transition from one network address
   family to another (IPv4 to IPv6).
Also, all of this clarifies the function of this listing mechanism and sugg=
ests
a very different name, to be more precise and accurate in naming it:
    IPv6 DNS Response Preference List.
   In practice, DNS whitelisting generally means that a very small
   fraction of the DNS recursive resolvers on the Internet (those in the
   whitelist ACL) will receive AAAA responses.  The large majority of
   DNS resolvers on the Internet will therefore receive only A resource
   records containing IPv4 addresses.  Thus, quite simply, the
   authoritative server hands out different answers depending upon who
   is asking; with IPv4 and IPv6 resource records for some on the
   authorized whitelist, and only IPv4 resource records for everyone
   else.  See Section 2.1 and Figure 1 for a description of how this
Livingood                Expires August 26, 2011                [Page 6]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
   works.
   Finally, DNS whitelisting can be deployed in two primary ways:
   universally on a global basis, or on an ad hoc basis.  Deployment on
   a universal deployment basis means that DNS whitelisting is
   implemented on all authoritative DNS servers, across the entire
   Internet.  In contrast, deployment on an ad hoc basis means that only
   some authoritative DNS servers, and perhaps even only a few,
   implement DNS whitelisting.  These two potential deployment models
   are described in Section 6.
2.1.  Description of the Operation of DNS Whitelisting
   The system logic of DNS whitelisting is as follows:
   1.  The authoritative DNS server for example.com receives DNS queries
       for the A (IPv4) and AAAA (IPv6) address resource records for the
       FQDN www.example.com, for which AAAA (IPv6) resource records
       exist.
This means that the mechanism is /only/ triggered when /both/ address recor=
ds
are queried?  A query for only one type of address record won't trigger the=
 list
lookup?  I think that doesn't match other statements in the document.
   2.  The authoritative DNS server examines the IP address of the DNS
       recursive resolver sending the AAAA (IPv6) query.
"examines"?  Examines it for what?  What does this step mean?
   3.  The authoritative DNS server checks this IP address against the
       access control list (ACL) that is the DNS whitelist.
   4.  If the DNS recursive resolver's IP address IS matched in the ACL,
       then the response to that specific DNS recursive resolver can
       contain AAAA (IPv6) address resource records.
Oh.  This is not about whether to send responses /over/ v6 vs. v4?  This is
whether to /include/ a particular type of RR in responses???
In that case an appropriate name for this mechanism is more like:
   DNS Response Content Preference List
And this seems even less like an ACL than it did before.  (I assume the
justification is that access is being prevented by virtue of not supplying =
the
address, but still...)
   5.  If the DNS recursive resolver's IP address IS NOT matched in the
       ACL, then the response to that specific DNS recursive resolver
       cannot contain AAAA (IPv6) address resource records.  In this
       case, the server should return a response with the response code
       (RCODE) being set to 0 (No Error) with an empty answer section
       for the AAAA record query.
Livingood                Expires August 26, 2011                [Page 7]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
   ---------------------------------------------------------------------
   A query is sent from a DNS recursive resolver that IS NOT on the DNS
   whitelist:
               Request                      Request
           www.example.com                  www.example.com
                 AAAA    +-------------+     AAAA    +-----------------+
     ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
     ||  ||       A      | **IS NOT**  |      A      | IN A exists     |
   +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
   +--------+     A      | example.com |      A      |                 |
      Host    <--------- |  WHITELIST  |  <--------- |                 |
    Computer   A Record  +-------------+  A Record   +-----------------+
               Response   DNS Recursive   Response       example.com
              (only IPv4)   Resolver     (only IPv4)    Authoritative
                              #1                           Server
   ---------------------------------------------------------------------
   A query is sent from a DNS recursive resolver that IS on the DNS
   whitelist:
               Request                      Request
           www.example.com                  www.example.com
                AAAA     +-------------+     AAAA    +-----------------+
     ++--++   ---------> |  RESOLVER   |  ---------> | www.example.com |
     ||  ||       A      |   **IS**    |      A      | IN A exists     |
   +-++--++-+ ---------> |     ON      |  ---------> | IN AAAA exists  |
   +--------+   AAAA     | example.com |     AAAA    |                 |
      Host    <--------- |  WHITELIST  |  <--------- |                 |
    Computer      A      |             |      A      |                 |
              <--------- |             |  <--------- |                 |
              A and AAAA +-------------+ A and AAAA  +-----------------+
               Record     DNS Recursive   Record        example.com
              Responses     Resolver     Responses      Authoritative
              (IPv4+IPv6)      #2        (IPv4+IPv6)       Server
   ---------------------------------------------------------------------
              Figure 1: DNS Whitelisting - Functional Diagram
This diagram is confusing to me.  I suspect that a protocol exchange sequen=
ce
format, in the style of:
     Host             Resolver 1            Authoritative
          ---------->
                                 --------->
                                <---------
         <----------
will be considerably more helpful.
3.  What Problems Are Implementers Trying To Solve?
This is a very useful section and it is probably worth moving it higher, to
precede the 'how it works' section.
   As noted in Section 1, domains which implement DNS whitelisting are
   attempting to protect a few users of their domain, who have impaired
   IPv6 access, from having a negative experience (poor performance).
By the way, what does 'impaired v6 access' mean?
I think there needs to be a simple, direct description of what occurs witho=
ut
this mechanism.
For example, perhaps you mean that a host can send DNS queries using IPv6 b=
ut
cannot receive DNS responses over IPv6? Perhaps you mean that the host can =
send
IPv6 but cannot receive it.  (That's a different scale and scope of problem=
 from
the first example I gave.)
This brief, summary problem statement should be included in the Abstract, t=
o
make /much/ more clear what this mechanism is for.
   While it is outside the scope of this document to explore the various
   reasons why a particular user's system (host) may have impaired IPv6
   access, for the users who experience this impairment it is a very
   real performance impact.  It would affect access to all or most dual
Livingood                Expires August 26, 2011                [Page 8]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
   stack services to which the user attempts to connect.  This negative
   end user experience can range from someone slower than usual (as
   compared to native IPv4-based access), to extremely slow, to no
   access to the domain whatsoever.
Rather than repeat that this is about end-users, it sounds more that this i=
s
about whether a service works or does not work, whether a user is directly
present or not.
   While one can debate whether DNS whitelisting is the optimal solution
   to the end user experience problem, it is quite clear that DNS
   whitelisting implementers are interested in maximizing the
   performance of their services for end users as a primary motivation
   for implementation.
You keep citing 'performance' but haven't described what sort of performanc=
e
degradation takes place. Is this really about relatively better or worse
performance -- and if so, how -- or is this about working or not working?
Also rather than saying what implementers are interested in, it's probably =
more
helpful to note that the practice is now significantly established and ther=
efore
worth documenting, independent of its possible controversy.
   At least one highly-trafficked domain has noted that they have
   received requests to not send DNS responses with AAAA resource
   records to particular resolvers.  In this case, the operators of
"At least one" seems a rather tiny statistic.  Perhaps the actual statistic=
 is
significantly larger?
   those recursive resolvers have expressed a concern that their IPv6
I suspect that it's not resolvers that are doing the expressing, since thei=
r
vocabulary is usually too limited...
   network infrastructure is not yet ready to handle the large traffic
   volume which may be associated with the hosts in their network
   connecting to the websites of these domains.  This concern is clearly
So even though the site allows v6 DNS queries to go out from a host, it can=
't
really support having the host use v6?
Wow. I do understand why service providers often have to work around sillin=
ess
at the client side, but this problem at the client side seems particularly
egregious.
   a temporary consideration relating to the deployment of IPv6 network
   infrastructure on the part of networks with end user hosts, rather
   than a long-term concern.  These end user networks may also have
Again this goal of short-term usage is worth noting earlier, including in t=
he
Abstract.
   other tools at their disposal in order to address this concern,
   including applying rules to network equipment such as routers and
   firewalls (this will necessarily vary by the type of network, as well
   as the technologies used and the design of a given network), as well
   as configuration of their recursive resolvers (though modifying or
   suppressing AAAA resource records in a DNSSEC-signed domain on a
   Security-Aware Resolver will be problematic Section 10.1).
   Some implementers with highly-trafficked domains have explained that
   DNS whitelisting is a necessary, though temporary, risk reduction
   tactic intended to ease their transition to IPv6 and minimize any
   perceived risk in such a transition.  As a result, they perceive this
   as a tactic to enable them to incrementally enable IPv6 connectivity
   to their domains during the early phases of their transition to IPv6.
   Finally, some domains, have run IPv6 experiments whereby they added
   AAAA resource records and observed and measured errors [Heise Online
   Experiment], which should be important reading for any domain
   contemplating either the use of DNS whitelisting or simply adding
   IPv6 addressing to their site.
4.  Concerns Regarding DNS Whitelisting
   There are a number of potential implications relating to DNS
   whitelisting, which have been raised as concerns by some parts of the
   Internet community.  Many of those potential implications are further
I think the implications are not conditional; they exist rather than being
potential.  The 'potential' is that what is implicated will come to pass.
Livingood                Expires August 26, 2011                [Page 9]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
   enumerated here and in Section 7.
Pro forma question:  Why are implications discussed in multiple places?
   Some parties in the Internet community, including ISPs, are concerned
This style of text personalizes the issues unnecessarily (IMO).  It does no=
t
really matter who holds the concerns, or else they'd be described more prec=
isely.
I suggest merely noting that there are concerns and then listing and discus=
sing
the concerns, rather than adding text to attribute the concerns to others, =
even
if the conclusion of your text is that a particular concern is not valid.
   that the practice of DNS whitelisting for IPv6 address resource
   records represents a departure from the generally accepted practices
   regarding IPv4 address resource records in the DNS on the Internet
   [Whitelisting Concerns].  These parties explain their belief that for
"These parties explain their belief" is an example of personalization that =
is
not needed.  This isn't about the believers.  It is about possible problems=
.
   A resource records, containing IPv4 addresses, once an authoritative
   server operator adds the A record to the DNS, then any DNS recursive
   resolver on the Internet can receive that A record in response to a
This does not appear to be a grammatically valid sentence.  My guess is tha=
t
deleting "A resource... addresses" fixes this.
And by the way, the document's reference to "recursive" resolvers is mostly
likely incorrect.  The problem is not restricted only to that very specific=
 type
of resolver, is it?
If in fact it /is/ specific to them -- and your following text describes an
indirect effects scenario where it might be -- I suggest calling out the
configuration at the beginning, along the lines of:
     One way the problem with returning AAAA records can be experienced is =
when
recursive resolvers are used.  Although that resolver might support IPv6, i=
ts
client hosts might not.  So, returning an AAAA record will mean that these
limited hosts will be given an unusable address.
And this type of description belongs in the text describing the motivating
problem(s), rather than buried in the 'concerns' discussion.
(The text, here, pertains to A records, but the problem I've described uses=
 the
same configuration but for AAAA records with mixed v6 support.)
   query.  By extension, this means that any of the hosts connected to
   any of these DNS recursive resolvers can receive the IPv4 address
   resource records for a given FQDN.  This enables new server hosts
   which are connected to the Internet, and for which a fully qualified
   domain name (FQDN) such as www.example.com has been added to the DNS
   with an IPv4 address record, to be almost immediately reachable by
   any host on the Internet.  In this case, these new servers hosts
   become more and more widely accessible as new networks and new end
   user hosts connect to the Internet over time, capitalizing on and
   increasing so-called "network effects" (also called network
   externalities).  It also means that the new server hosts do not need
   to know about these new networks and new end user hosts in order to
   make their content and applications available to them, in essence
   that each end in this end-to-end model is responsible for connecting
   to the Internet and once they have done so they can connect to each
   other without additional impediments or middle networks or
   intervening networks or servers knowing about these end points and
   whether one is allowed to contact the other.
Hmmm.  This rather lengthy bit of prose appears merely to be explaining the
basic and long-standing DNS value proposition???
   In contrast, the concern is that DNS whitelisting may fundamentally
   change this model.  In the altered DNS whitelisting end-to-end model,
   one end (where the end user is located) cannot readily connect to the
   other end (where the content is located), without parts of the middle
   (recursive resolvers) used by one end (the client, or end user hosts)
   being known to an intermediary (authoritative nameservers) and
   approved for access to the resource at the end.  As new networks
   connect to the Internet over time, those networks need to contact any
   and all domains which have implemented DNS whitelisting in order to
   apply to be added to their DNS whitelist, in the hopes of making the
   content and applications residing on named server hosts in those
   domains accessible by the end user hosts on that new network.
   Furthermore, this same need to contact all domains implementing DNS
   whitelisting also applies to all pre-existing (but not whitelisted)
   networks connected to the Internet.
   In the current IPv4 Internet when a new server host is added to the
   Internet it is generally widely available to all end user hosts and
   networks, when DNS whitelisting of IPv6 resource records is used,
If it is available to the hosts, it is available to the network.
networks, when -> networks. When
Livingood                Expires August 26, 2011               [Page 10]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
   these new server hosts are not accessible to any end user hosts or
   networks until such time as the operator of the authoritative DNS
They are still accessible.  The IP-level mechanisms still work.
They are not reachable when using the domain name.
   servers for those new server hosts expressly authorizes access to
   those new server hosts by adding DNS recursive resolvers around the
   Internet to the ACL.  This has the potential to be a significant
This is a good example of the reason the term ACL is inappropriate:  It imp=
lies
a security protection that does not actually exist.  The hosts are still ac=
cessible.
   change in reachability of content and applications by end users and
   networks as these end user hosts and networks transition to IPv6,
   resulting in more (but different) breakage.  A concern expressed is
   that if much of the content that end users are most interested in is
   not accessible as a result, then end users and/or networks may resist
   adoption of IPv6 or actively seek alternatives to it, such as using
   multi-layer network address translation (NAT) techniques like NAT444
   [I-D.shirasaki-nat444] on a long-term basis.  There is also concern
   that this practice also could disrupt the continued increase in
   Internet adoption by end users if they cannot simply access new
   content and applications but must instead contact the operator of
   their DNS recursive resolver, such as their ISP or another third
   party, to have their DNS recursive resolver authorized for access to
   the content or applications that interests them.  Meanwhile, these
   parties say, over 99.9% of the other end users that are also using
   that same network or DNS recursive resolver are unable to access the
   IPv6-based content, despite their experience being a positive one.
   While in Section 1 the level of IPv6-related impairment has been
   estimated to be as high as 0.078% of Internet users, which is a
8 hundredths of one percent?
That's considered a high percentage?
Even if it is 8%, is that considered high?
5.2.  Similarities to DNS Load Balancing
   DNS whitelisting also has some similarities to DNS load balancing.
   There are of course many ways that DNS load balancing can be
   performed.  In one example, multiple IP address resource records (A
   and/or AAAA) can be added to the DNS for a given FQDN.  This approach
   is referred to as DNS round robin [RFC1794].  DNS round robin may
   also be employed where SRV resource records are used [RFC2782].
Right, but that's algorithmic rather than involving the manual method, desc=
ribed
here. So it does not seem comparable.
6.  Likely Deployment Scenarios
   In considering how DNS whitelisting may emerge more widely, there are
   two likely deployment scenarios, which are explored below.
   In either of these deployment scenarios, it is possible that
   reputable third parties could create and maintain DNS whitelists, in
   much the same way that blacklists are used for reducing email spam.
   In the email context, a mail operator subscribes to one or more of
   these lists and as such the operational processes for additions and
   deletions to the list are managed by a third party.  A similar model
   could emerge for DNS whitelisting, whether deployment occurs
   universally or on an ad hoc basis.
The challenges of email whitelists and blacklists should be cited, since it
provides a rich base of experience for such an effort, at scale.
6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis
   The seemingly most likely deployment scenario is where some
Most likely?  This is not already established practice?
   authoritative DNS server operators implement DNS whitelisting but
   many or most others do not do so.  What can make this scenario
   challenging from the standpoint of a DNS recursive resolver operator
   is determining which domains implement DNS whitelisting, particularly
   since a domain may not do so as they initially transition to IPv6,
   and may instead do so later.  Thus, a DNS recursive resolver operator
Livingood                Expires August 26, 2011               [Page 13]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
   may initially believe that they can receive AAAA responses as a
   domain adopts IPv6, but then notice via end user reports that they no
   longer receive AAAA responses due to that domain adopting DNS
   whitelisting.  Of course, a domain's IPv6 transition may be
   effectively invisible to recursive server operators due to the effect
   of DNS whitelisting.
This suggests that every listing at the server needs a contact record for
periodic checks whether to renew the listing.
   In contrast to a universal deployment of DNS whitelisting
   Section 6.2, deployment on an ad hoc basis is likely to be
   significantly more challenging from an operational, monitoring, and
Oh?  Use in small scale is more challenging than use of manual exceptions l=
ist
at large scale?  That's a very unexpected view.
   troubleshooting standpoint.  In this scenario, a DNS recursive
   resolver operator will have no way to systematically determine
   whether DNS whitelisting is or is not implemented for a domain, since
   the absence of AAAA resource records may simply be indicative that
   the domain has not yet added IPv6 addressing for the domain, rather
   than that they have done so but have restricted query access via DNS
The premise is that, in large scale use, servers /will/ have a way to
systematically determine whether it is implemented?  What are the existing
examples of having such a capability for other Internet protocols and servi=
ces?
   whitelisting.  As a result, discovering which domains implement DNS
   whitelisting, in order to differentiate them from those that do not,
   is likely to be challenging.
   One benefit of DNS whitelisting being deployed on an ad hoc basis is
   that only the domains that are interested in doing so would have to
   upgrade their authoritative DNS servers in order to implement the
   ACLs necessary to perform DNS whitelisting.
   In this potential deployment scenario, it is also possible that a
   given domain will implement DNS whitelisting temporarily.  A domain,
   particularly a highly-trafficked domain, may choose to do so in order
   to ease their transition to IPv6 through a selective deployment and
   minimize any perceived risk in such a transition.
6.2.  Deploying DNS Whitelisting Universally
   The least likely deployment scenario is one where DNS whitelisting is
   implemented on all authoritative DNS servers, across the entire
   Internet.  While this scenario seems less likely than ad hoc
   deployment due to some parties not sharing the concerns that have so
   far motivated the use of DNS whitelisting, it is nonetheless
   conceivable that it could be one of the ways in which DNS
   whitelisting is deployed.
Significantly, the partial-deployment model casts this mechanism as a trans=
ition
expedient -- as the document reasonably describes it -- whereas universal
deployment casts it as a fundamental change to the architecture.
Given that it would take decades to achieve relatively full deployment of t=
his
'across the entire Internet', what is the benefit of discussing this highly
unlikely scenario?  Is it really "conceivable"?  I doubt it. If you think
otherwise, the paper needs to explore the deployment and adoption issues in=
 much
more detail, because I don't see how it could work.
   In order for this deployment scenario to occur, it is likely that DNS
   whitelisting functionality would need to be built into all
   authoritative DNS server software, and that all operators of
   authoritative DNS servers would have to upgrade their software and
   enable this functionality.  It is likely that new Internet Draft
   documents would need to be developed which describe how to properly
   configure, deploy, and maintain DNS whitelisting.  As a result, it is
Livingood                Expires August 26, 2011               [Page 14]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
   unlikely that DNS whitelisting would, at least in the next several
   years, become universally deployed.  Furthermore, these DNS
   whitelists are likely to vary on a domain-by-domain basis, depending
   upon a variety of factors.  Such factors may include the motivation
   of each domain owner, the location of the DNS recursive resolvers in
   relation to the source content, as well as various other parameters
   that may be transitory in nature, or unique to a specific end user
   host type.  It is probably unlikely that a single clearinghouse for
   managing whitelisting is possible; it will more likely be unique to
   the source content owners and/or domains which implement DNS
   whitelists.
   While this scenario may be unlikely, it may carry some benefits.
   First, parties performing troubleshooting would not have to determine
   whether or not DNS whitelisting was being used, as it always would be
   in use.  In addition, if universally deployed, it is possible that
   the criteria for being added to or removed from a DNS whitelist could
   be standardized across the entire Internet.  Nevertheless, even if
   uniform DNS whitelisting policies were not standardized, is also
   possible that a central registry of these policies could be developed
   and deployed in order to make it easier to discover them, a key part
   of achieving transparency regarding DNS whitelisting.
Is any of this paragraph realistic?  Obviously my asking means I don't it i=
s.
These seem to be of theoretical rather than pragmatic interest.  ("If every=
one
refuses to shoot, there will be no wars.")
It's true that this is an "implications" paper rather than a BCP, but still=
...
7.  Implications of DNS Whitelisting
   There are many potential implications of DNS whitelisting.  The key
   potential implications are detailed below.
7.1.  Architectural Implications
   DNS whitelisting could be perceived as modifying the end-to-end model
   and/or the general notion of the architecture that prevails on the
I'll suggest that perception is not a major issue about a technical topic l=
ike
this.  (It's not entirely irrelevant, of course, but I suspect it is quite =
minor.)
The major issue is whether it /actually/ modifies the end-to-end nature of =
the
DNS.  And I think it does, as well as modifying the "spontaneous
interoperability" expectation for most Internet mechanism, since it require=
s
prior registration.
7.2.  Public IPv6 Address Reachability Implications
   The predominant experience of end user hosts and servers on the IPv4-
   addressed Internet today is that when a new server with a public IPv4
   address is added to the DNS, that it is then globally accessible by
This sentence is not quite correct, in strict technical terms.  Since this =
is a
technical discussion, we need to be precise:  the host is reachable when th=
e
routing tables make it reachable.  That's strictly a mapper of IP Address
handling, not name-to-address mapping.
What you mean is that its domain name is immediately useful for reaching it=
.
   IPv4-addressed hosts.  This is a generalization and in Section 5
   there are examples of common cases where this may not necessarily be
   the case.  For the purposes of this argument, that concept of
   accessibility can be considered "pervasive reachability".  It has so
   far been assumed that the same expectations of pervasive reachability
   would exist in the IPv6-addressed Internet.  However, if DNS
   whitelisting is deployed, this will not be the case since only end
   user hosts using DNS recursive resolvers which are included in the
again, you mean /name-based/ reachability.
Livingood                Expires August 26, 2011               [Page 16]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
   ACL of a given domain using DNS whitelisting would be able to reach
   new servers in that given domain via IPv6 addresses.  The expectation
   of any end user host being able to connect to any server (essentially
   both hosts, just at either end of the network), defined here as
   "pervasive reachability", will change to "restricted reachability"
   with IPv6.
   Establishing DNS whitelisting as an accepted practice in the early
   phases of mass IPv6 deployment could well establish it as an integral
   part of how IPv6 DNS resource records are deployed globally.  As a
   result, it is then possible that DNS whitelisting could live on for
   decades on the Internet as a key foundational element of domain name
   management that we will all live with for a long time.
(that last sentence could benefit from some editing.)
   It is a critical to understand that the concept of reachability
   described above depends upon a knowledge or awareness of an address
   in the DNS.  Thus, in order to establish reachability to an end
   point, a host is dependent upon looking up an IP address in the DNS
If this section were started with a sentence like this, then there would no=
t be
a problem with the other references' being confused with address-based rout=
ing
reachability.
   when a FQDN is used.  When DNS whitelisting is used, it is quite
   likely the case that an IPv6-enabled end user host could ping or
   connect to an example server host, even though the FQDN associated
   with that server host is restricted via a DNS whitelist.  Since most
First, I suspect that "example" doesn't add meaning to the sentence.  Secon=
d,
pinging and connecting might happen with or without the whitelist entry.  S=
o I
do not understand what import there is in this sentence.
   Internet applications and hosts such as web servers depend upon the
   DNS, and as end users connect to FQDNs such as www.example.com and do
   not remember or wish to type in an IP address, the notion of
   reachability described here should be understood to include knowledge
   how to associate a name with a network address.
Again, this 'premise' statement should introduce the sub-section, not end i=
t.
7.3.  Operational Implications
   This section explores some of the operational implications which may
   occur as a result of, are related to, or become necessary when
   engaging in the practice of DNS whitelisting.
7.3.1.  De-Whitelisting May Occur
The more general version of this issue is 'synchronization'.  Entries in th=
e
whitelist need to be synchronized with host status and capabilities.
   It is possible for a DNS recursive resolver added to a whitelist to
   then be removed from the whitelist, also known as de-whitelisting.
   Since de-whitelisting can occur, through a decision by the
   authoritative server operator, the domain owner, or even due to a
   technical error, an operator of a DNS recursive resolver will have
   new operational and monitoring requirements and/or needs as noted in
   Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5.
7.3.2.  Authoritative DNS Server Operational Implications
   Operators of authoritative servers may need to maintain an ACL a
a -> on a (?)
   server-wide basis affecting all domains, on a domain-by-domain basis,
Livingood                Expires August 26, 2011               [Page 17]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
   as well as on a combination of the two.  As a result, operational
I'm not really understanding the first sentence.  One problem might be that=
 its
discussing an implication of some configuration or usage options that have =
not
been previously specified, so that the reference here might be overly crypt=
ic.
For example, I don't know what "affecting all domains" actually means.  It
almost sounds as if it could mean "everyone gets AAAA records" or "no one g=
ets
AAAA records" yet I'm reaonably certain that is /not/ what is meant.
   practices and software capabilities may need to be developed in order
   to support such functionality.  In addition, processes may need to be
   put in place to protect against inadvertently adding or removing IP
   addresses, as well as systems and/or processes to respond to such
   incidents if and when they occur.  For example, a system may be
   needed to record DNS whitelisting requests, report on their status
   along a workflow, add IP addresses when whitelisting has been
   approved, remove IP addresses when they have been de-whitelisted, log
   the personnel involved and timing of changes, schedule changes to
   occur in the future, and to roll back any inadvertent changes.
Might be worth starting with a simple, broad summary statement, possibly al=
ong
the lines of:
   An AAAA DNS Whitelist serves as a critical infrastructure service; to be
useful it needs careful and extensive administration, monitoring and operat=
ion.
Each new and essential mechanism creates substantial follow-on support cost=
s.
   Operators may also need implement new forms of monitoring in order to
   apply change control, as noted briefly in Section 7.3.4.
7.3.3.  DNS Recursive Resolver Server Operational Implications
   Operators of DNS recursive resolvers, which may include ISPs,
   enterprises, universities, governments, individual end users, and
   many other parties, are likely to need to implement new forms of
   monitoring, as noted briefly in Section 7.3.4.  But more critically,
   such operators may need to add people, processes, and systems in
   order to manage large numbers of DNS whitelisting applications as
   part of their own IPv6 transition, for all domains that the end users
   of such servers are interested in now or in which they may be
I think the summary observation is simple and should be stated directly:  T=
his
is a manual mechanism that becomes expensive in time and personnel effort a=
s it
scales up.
   interested in the future.  As anticipation of interesting domains is
   likely infeasible, it is more likely that operators may either choose
   to only apply to be whitelisted for a domain based upon one or more
   end user requests, or that they will attempt to do so for all domains
   that they can ascertain to be engaging in DNS whitelisting.
"attempt to do so for all domain that they can ascertain to be engaging in =
DNS
whitelisting"  appears to be saying to do whitelisting for domains that do
whitelisting.  I don't understand.
   When operators apply for DNS whitelisting for all domains, that may
"apply for DNS whitelisting for all domains" -- again I'm not understanding=
 what
this means.
7.3.5.  Implications of Operational Momentum
   It seems plausible that once DNS whitelisting is implemented it will
   be very difficult to deprecate such technical and operational
   practices.  This assumption is based in an understanding of human
in -> on
   nature, not to mention physics.  For example, as Sir Issac Newton
   noted, "Every object in a state of uniform motion tends to remain in
   that state of motion unless an external force is applied to it" [Laws
Code does not have momenum.  Neither do configurations or lists.  This real=
ly
isn't about physics.
It is entirely about group psychology, as you note, and the administrative
challenges in the logistics of large-scale operational changes (which proba=
bly
/does/ have something to with physics, but it seems a stretch to credit New=
ton.
How about Heisenberg?...)
   of Motion].  Thus, once DNS whitelisting is implemented it is quite
   likely that it would take considerable effort to deprecate the
   practice and remove it everywhere on the Internet - it will otherwise
   simply remain in place in perpetuity.  To better illustrate this
   point, one could consider one example (of many) that there are many
   email servers continuing to attempt to query or otherwise check anti-
Livingood                Expires August 26, 2011               [Page 19]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
   spam DNS blocklists which have long ago ceased to exist.
7.3.6.  Troubleshooting Implications
   The implications of DNS whitelisted present many challenges, which
   have been detailed in Section 7.  These challenges may negatively
But this is /still/ section 7.  Can you be more specific?  Or perhaps say
"throughout this section".
   affect the end users' ability to troubleshoot, as well as that of DNS
   recursive resolver operators, ISPs, content providers, domain owners
   (where they may be different from the operator of the authoritative
   DNS server for their domain), and other third parties.  This may make
   the process of determining why a server is not reachable
   significantly more complex.
7.3.7.  Additional Implications If Deployed On An Ad Hoc Basis
   Additional implications, should this be deployed on an ad hoc basis,
   could include scalability problems relating to operational processes,
I'm pretty sure that scaling problems for this exist in all scenarios, not =
just
ad hoc usage.
   monitoring, and ACL updates.  In particular, it seems likely that as
   the number of domains that are using DNS whitelisting increases, as
   well as the number of IPv6-capable networks requesting to be
   whitelisted, that there is an increased likelihood of configuration
   and other operational errors, especially with respect to the ACLs
   themselves.
   It is unclear when and if it would be appropriate to change from
   whitelisting to blacklisting, and whether or how this could feasibly
   be coordinated across the Internet, which may be proposed or
Actually the question of coordination is quite clear and rather fundamental=
:
     No.
Anyone believing otherwise needs to cite a successful example, at Internet =
scale
and diversity, more recently than the 1983 switch to IP (which didn't go al=
l
that well anyhow...)
Simple, unambiguous showstoppers should be stated in a simple and direct ma=
nner.
When there is room for debate, softer language makes sense.  Again, if the
question of coordination really is subject to debate, then the basis needs =
to be
stated.  (Good luck!)
   implemented on an ad hoc basis when a majority of networks (or
   allocated IPv6 address blocks) have been whitelisted.  Finally, some
   parties implementing DNS whitelisting consider this to be a temporary
   measure.  As such, it is not clear how these parties will judge the
   network conditions to have changed sufficiently to justify disabling
   DNS whitelisting and/or what the process and timing will be in order
   to discontinue this practice.
   One further potential implication is that an end user with only an
   IPv4 address, using a DNS resolver which has not been whitelisted by
   any domains, would not be able to get any AAAA resource records.  In
   such a case, this could give that end user the incorrect impression
   that there is no IPv6-based content on the Internet since they are
   unable to discover any IPv6 addresses via the DNS.
7.4.  Homogeneity May Be Encouraged
   A broad trend which has existed on the Internet appears to be a move
   towards increasing levels of heterogeneity.  One manifestation of
increasing levels of heterogeneity -> more heterogeneity
(I think heterogeneity does not have 'levels'.)
Substantively:  say the nature of the heterogeneity within the initial clai=
m.
For example, there is /less/ heterogeneity of ISPs, given industry
consolidation.  There is less heterogeneity of infrastructure equipment suc=
h as
routers.  Etc.
   this is in an increasing number, variety, and customization of end
   user hosts, including home network, operating systems, client
Livingood                Expires August 26, 2011               [Page 20]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
   software, home network devices, and personal computing devices.  This
   trend appears to have had a positive effect on the development and
   growth of the Internet.  A key facet of this that has evolved is the
   ability of the end user to connect any technically compliant device
   or use any technically compatible software to connect to the
   Internet.  Not only does this trend towards greater heterogeneity
   reduce the control which is exerted in the middle of the network,
   described in positive terms in [Tussle in Cyberspace], [Rethinking
   the Internet], and [RFC3724], but it can also help to enable greater
   and more rapid innovation at the edges.
   An unfortunate implication of the adoption of DNS whitelisting may be
   the encouragement of a reversal of this trend, which would be a move
the encouragement of -> to encourage
8.1.  Implement DNS Whitelisting Universally
   One obvious solution is to implement DNS whitelisted universally, and
   to do so using some sort of centralized registry of DNS whitelisting
   policies, contracts, processes, or other information.  This potential
   solution seems unlikely at the current time.
I'm pretty sure that the only thing that is obvious about a premise of univ=
ersal
adoption is that it's not practical.  Seriously.
At the least, this section needs to be less cavalier about putting this
alternative forward as a "solution", especially given the rather serious
drawbacks/problems with it.
8.2.  Implement DNS Whitelisting On An Ad Hoc Basis
   If DNS whitelisting is to be adopted, it is likely to be adopted on
"is to be"?  I thought it already had a significant installed base.
   this ad hoc, or domain-by-domain basis.  Therefore, only those
   domains interested in DNS whitelisting would need to adopt the
   practice, though as noted herein discovering that they a given domain
   has done so may be problematic.  Also in this scenario, ad hoc use by
   a particular domain may be a temporary measure that has been adopted
   to ease the transition of the domain to IPv6 over some short-term
   timeframe.
8.3.  Do Not Implement DNS Whitelisting
   As an alternative to adopting DNS whitelisting, the Internet
   community generally can choose to take no action whatsoever,
   perpetuating the current predominant authoritative DNS operational
   model on the Internet, and leave it up to end users with IPv6-related
   impairments to discover and fix those impairments.
That is, place the burden of fixing a problem on those creating it?
Livingood                Expires August 26, 2011               [Page 23]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
8.3.1.  Solving Current End User IPv6 Impairments
   A further extension of not implementing DNS whitelisting, is to also
   endeavor to actually fix the underlying technical problems that have
   prompted the consideration of DNS whitelisting in the first place, as
   an alternative to trying to apply temporary workarounds to avoid the
   symptoms of underlying end user IPv6 impairments.  A first step is
   obviously to identify which users have such impairments, which would
   appear to be possible, and then to communicate this information to
   end users.  Such end user communication is likely to be most helpful
   if the end user is not only alerted to a potential problem but is
   given careful and detailed advice on how to resolve this on their
   own, or where they can seek help in doing so.  Section 11 may also be
   relevant in this case.
   One challenge with this option is the potential difficulty of
   motivating members of the Internet community to work collectively
   towards this goal, sharing the labor, time, and costs related to such
   an effort.  Of course, since just such a community effort is now
   underway for IPv6, it is possible that this would call for only a
   moderate amount of additional work.
This 'challenge' is at the core of /all/ adoption efforts for Internet prot=
ocols
and services that entail distributed adoption.
   Despite any potential challenges, many in the Internet community are
   already working towards this goal and/or have expressed a general
   preference for this approach.
If this is not already an organized effort with a website, sponsoring
consortium, or the like, it should be.  If it is, then cite it in this doc!
8.3.2.  Gain Experience Using IPv6 Transition Names
   Another alternative is for domains to gain experience using an FQDN
   which has become common for domains beginning the transition to IPv6;
   ipv6.example.com and www.ipv6.example.com.  This can be a way for a
   domain to gain IPv6 experience and increase IPv6 use on a relatively
   controlled basis, and to inform any plans for DNS whitelisting with
   experience.
I do not understand what this means.
What is it for?  What are the results?  How are theyused?
9.  Is DNS Whitelisting a Recommended Practice?
   Opinions in the Internet community concerning whether or not DNS
   whitelisting is a recommended practice are understandably quite
   varied.  However, there is clear consensus that DNS whitelisting is
   at best a useful temporary measure which a domain may choose to
If that is a clear consensus, then it makes even less sense to promote the =
idea
of universal adoption, given the timescale needed to achieve it.
10.  Security Considerations
   There are no particular security considerations if DNS whitelisting
   is not adopted, as this is how the public Internet works today with A
   resource records.
Or rather, failure to adopt a mechanism like this or repair the underlying
problem, for those sites experiencing that problem, will result in a denial=
 of
service, albeit not an intentional one.  Still, that's a pretty basic secur=
ity
issue.
d/
--
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
--
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



--_000_CA09169928B58jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <916AD15B8B46D1448E63887F156CC459@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable









Thanks Joel. In that case, I plan to remove the following Open Issue f=
rom the next revision:











#8 - Per Dave=
 Crocker - do we need to change the name from
       whitelisting to an alternate term?  Dave suggests "IPv6 Resolve=
r
       Whitelisting" or "IPv6 DNS Response Preference List" =
or "DNS
       Response Content Preference List".  Tony Finch suggests: So I
       suggest retitling the document "IPv6 DNS resolver whitelisting&=
quot;
       and revising the terminology throughout to match.  Mark Andrews
       also suggests "DNS resolver whitelisting for AAAA resolution&qu=
ot;.
       John Leslie suggests "AAAA-blocking".









Thanks


Jason







On 5/30/11 1:21 AM, "Joel Jaeggli" <joelja@bogus.com> wrote:









With respect to the discussion of the whitelist/blacklist terminology =
I believe it can be stipulated that the authors, the document shepherd, the=
 working group chairs disagree with your conclusions as to the appropriaten=
ess of the term whitelist.







thanks


joel







On May 29, 2011, at 9:50 AM, Dave CROCKER wrote:











On 5/29/2011 7:46 AM, Livingood, Jason wrote:


> Hi Bernard =96 I've finally found the time to close out the last =
bits of


> feedback > in this version of the draft.






Jason,




Perhaps my filters misfiled your followup to the "formal" re=
view I was asked to do, or perhaps my earlier, informal, and vary narrow re=
view muddied the waters, but I am not finding your response to the Apps Are=
a review.




For convenience, here it is again.




d/




-------- Original Message --------


Subject: Review of:  draft-ietf-v6ops-v6-aaaa-whitelisting-i=
mplications-03



         *(formal for apps are=
a)*


Date: Mon, 09 May 2011 10:18:51 -0700


From: Dave CROCKER <dhc@dcrocke=
r.net>


Reply-To: dcrocker@bbiw.net

Organization: Brandenburg InternetWorking


To: IETF Discussion <ietf@ietf.org=
>





(This is an "official" and significantly extended version of=
 an informal and


narrow review I posted earlier.  /d)








Howdy.




I have been selected as the Applications Area Review Team reviewer for=
 this


draft (for background on apps-review, please see


http://www.apps.ietf.org/content/applications-area-review-team).



Please resolve these comments along with any other Last Call comments =
you may


receive. Please wait for direction from your document shepherd or AD b=
efore


posting a new version of the draft.








Review (v2):




Title:  IPv6 AAAA DNS Whitelisting Implications


I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-impl=
ications-03




By:     D. Crocker <dcrocker@bbiw.net>


Date:   <>








Summary


=3D=3D=3D=3D=3D=3D=3D




This draft covers a a dual-stack problem in which a target host's DNS =
entry


contains records for IPv4 and IPv6, but returning IPv6 information to =
a DNS


client can cause problems. The paper discusses for resolving this thro=
ugh use of


a a DNS-based mechanism that manually lists response preferences to se=
lect which


DNS records to return.  The paper describes the mechanism an=
d explores various


effects and possibilities of its use, including the difference between=
 using it


selectively among a smaller number of sites, versus universally.




The draft is a serious effort to explore the use of such a mechanism a=
nd it


touches many different issues.  It is generally well-organiz=
ed and clearly


written, although it very much needs the aid of a professional technic=
al editor.


The writing often assumes too much knowledge by the reader.




The paper's exploration of universal adoption seems to vary between co=
nsidering


that goal practical versus considering it only as a matter of complete=
ness for


discussing the full range of possibilities.  That is, it is =
not clear whether


the paper views this alternative as practically possible and even pref=
erred,


versus only a matter for academic thoroughness. The paper needs to tak=
e a basic


position about feasibility, explain it in terms of comparable adoption=
 efforts


at Internet-scale, and then make its treatment of universal adoption a=
 bit more


consistent.




When introducing terms, mechanisms, configurations and scenarios, the =
paper


needs to be more careful to describe them adequately for a reader new =
to the


topic.  This is not a matter of having a tutorial about the =
DNS, but rather a


tutorial for this type of mechanism and when and how it can be used.



As a specific example, the document cites "domain-by-domain"=
 use, but I am not


clear how that would work, in terms of configuration and cross-net inf=
ormation


exchange.  One question is how the server knows the 'domain'=
 of the client?




The document should careful to distinguish what is existing practice, =
versus


what is being explored as added possibilities.  The differen=
ce in concreteness


and certitude between the two is substantial.




The document's use of the term whitelisting appears to continue an exi=
sting,


recent use, for this type of mechanism.  Unfortunately it di=
rectly conflicts


with long-standing use of the term by the anti-abuse community for whi=
telisting


in the DNS. Its use here also seems to be a mismatch with the word's d=
ictionary


semantics, which is most naturally used to distinguish yes/no choices,=
 rather


than either/or choices.  So there is no intuitive sense of &=
quot;goodness" (whitelist


=3D yes) or "badness" (blacklist) for this use. The word &qu=
ot;preferences" seems more


in line with the meaning of the mechanism.








Detailed Comments


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D








Abstract




   The objective of this document is to describe what the wh=
itelisting


   of DNS AAAA resource records is, hereafter referred to as=
 DNS






RRs are whitelisted?  Isn't it the addresses and not the rec=
ords that are


whitelisted?




Does this mean putting whitelisting records into the DNS or does it me=
an


something else?




Comcast's own considerable expertise notwithstanding, has this doc bee=
n vetted


with a range of organizations that actually DO whitelisting? &nbs=
p;Has it been


circulated through MAAWG and APWG?  Any comments from Spamha=
us?  The


Acknowledgements list does not seem to indicate a range of whitelist o=
ps folks


whose names I know.  (But then, I only know a few...)








   whitelisting, as well as the implications of this emergin=
g practice


   and what alternatives may exist.  The audience =
for this document is


   the Internet community generally, including the IETF and =
IPv6


   implementers.






I suspect that product marketers won't have much interest in this.&nbs=
p; I suspect


that the target for this is anti-abuse technical and operations staff.=
 In any


event, the targetting statement should be more precise.








1.  Introduction




   This document describes the emerging practice of whitelis=
ting of DNS






One natural, semantic problem with the term 'whitelist' is that it doe=
s not


really match the function being performed.  The white/black =
distinction implies


goodness -- or as Wikipedia says, "priviledge".  I=
nstead, the use here is for


preference or priority.  What would a "blacklist" =
be, here?  Also note it is not


obvious what it means to be whitelisted, here?  Does it mean=
 to choose the AAAA


records or the A records?




This is more like a 'Preference' or 'Configuration' list.




At the least, the name for this should be IPv6 Resolver Whitelisting.&=
nbsp; It makes


clear /what/ is being "whitelisted".








   AAAA resource records (RRs), which contain IPv6 addresses=
, hereafter


   referred to as DNS whitelisting.  The document =
explores the






This provides a name, but not a function.  That is, it does =
not say what this


mechanisms actually /does/ or is /for/.








   implications of this emerging practice are and what alter=
natives may


   exist.




   The practice of DNS whitelisting appears to have first be=
en used by


   major web content sites (sometimes described herein as &q=
uot;highly-






It's use for email anti-abuse dates back farther.















Specifically within the context of the DNS, the term whitelisting is t=
herefore


made ambiguous.




A google query for "whitelist dns" also demonstrates the his=
tory and current


ambiguity.








   trafficked domains" or "major domains").&n=
bsp; These web site operators,


   or domain operators, observed that when they added AAAA r=
esource


   records to their authoritative DNS servers in order to su=
pport IPv6


   access to their content that a small fraction of end user=
s had slow


   or otherwise impaired access to a given web site with bot=
h AAAA and A


   resource records.  The fraction of users with s=
uch impaired access


   has been estimated to be roughly 0.078% of total Internet=
 users


   [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adopt=
ion] [IPv6


   Brokenness].  Thus, in an example Internet Serv=
ice Provider (ISP)


   network of 10 million users, approximately 7,800 of those=
 users may


   experience such impaired access.






At a minimum, these sorts of statistics need to be normalized across I=
Pv6


users/traffic, given how small a percentage that is, in total users an=
d total


traffic.  If that's what is meant it should be stated. =
 If it isn't, the


statistic should be recalculated and explained a bit more precisely.







   As a result of this impairment affecting end users of a g=
iven domain,


   a few major domains have either implemented DNS whitelist=
ing or are


   considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist =
Operations].


   When implemented, DNS whitelisting in practice means that=
 a domain's


   authoritative DNS will return a AAAA resource record to D=
NS recursive


   resolvers [RFC1035] on the whitelist, while returning no =
AAAA


   resource records to DNS resolvers which are not on the wh=
itelist.  It






This explanation of the function should be offered sooner and should b=
e


summarized in the Abstract.








   is important to note that these major domains are motivat=
ed by a


   desire to maintain a high-quality user experience for all=
 of their






Rather than being important to note, this sentence sounds oddly like m=
arketing


hype, in a technical specification.  It is gratuitous becaus=
e specified features


are never added to /lower/ the quality of the user experience, for exa=
mple.




In addition, the mechanism also affects client activity that has no us=
er


directly involved.








   users.  By engaging in DNS whitelisting, they a=
re attempting to


   shield users with impaired access from the symptoms of th=
ose


   impairments.






The /technical/ statement that should be here is that they are attempt=
ing to


provide a work-around for problematic behaviors in dual-stack IPv4/IPv=
6


environments.




The paper should make more clear exactly where the problem lies and wh=
en. If it


can occur for a number of reasons, explaining each of those scenarios =
would be


useful.








   Critics of the practice of DNS whitelisting have articula=
ted several


   concerns.  Among these are that:




   o  DNS whitelisting is a very different behavio=
r from the current


      practice concerning the publishing=
 of IPv4 address resource


      records,




   o  that it may create a two-tiered Internet,



   o  that policies concerning whitelisting and de=
-whitelisting are


      opaque,












Livingood          &=
nbsp;     Expires August 26, 2011   =
;            &n=
bsp;[Page 5]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






   o  that DNS whitelisting reduces interest in th=
e deployment of IPv6,




   o  that new operational and management burdens =
are created,






well, yeah... in fact it should be noted that the burdens are particul=
arly


onerous at scale.








   o  and that the costs and negative implications=
 of DNS whitelisting


      outweigh the perceived benefits, c=
ompared to fixing underlying


      impairments.






and it doesn't scale.




and it violates an extremely basic premise of cross-Internet interoper=
ability by


requiring prior arrangement.








   This document explores the reasons and motivations for DN=
S


   whitelisting.  It also explores the outlined co=
ncerns regarding this


   practice.  Readers will hopefully better unders=
tand what DNS


   whitelisting is, why some parties are implementing it, an=
d what


   criticisms of the practice exist.






2.  How DNS Whitelisting Works






How IPv6 AAAA DNS Whitelisting Works.




(Anti-spam DNS Whitelisting works rather differently...)








   DNS whitelisting is implemented in authoritative DNS serv=
ers.  These


   servers implement IP address-based restrictions on AAAA q=
uery


   responses.  So far, DNS whitelisting has been p=
rimarily implemented


   by web server operators deploying IPv6-enabled services.&=
nbsp; For a given






Really?  This is web-specific?  The same restricti=
ons are not applied for other


applications?




So if the same client-side hosts attempt to contact the server for ema=
il or


xmpp, they won't get the same handling?








   operator of a website, such as www.example.com, the opera=
tor


   essentially applies an access control list (ACL) on the a=
uthoritative


   DNS servers for the domain example.com.  The AC=
L is populated with






An ACL usually is a yes/no mechanism.  Here, however, the me=
chanism is for


asserting a preference for IPv6 over IPv4.




That does not seem to match the definition of ACL that I'm used to, un=
less the


semantic is defined as denying IPv4 access to the listed clients.



The term ACL is particularly odd to use if the mechanism pertains to r=
esponses


rather than queries.








   the IPv4 and/or IPv6 addresses or prefix ranges of DNS re=
cursive






Either address type can be listed?  So this really is a pure=
 'preferences'


mechanism?




Which settings count as whitelisting?  Do any count as black=
listing?










   resolvers on the Internet, which have been authorized to =
receive AAAA


   resource record responses.  These DNS recursive=
 resolvers are


   operated by third parties, such as ISPs, universities, go=
vernments,


   businesses, and individual end users.  If a DNS=
 recursive resolver IS


   NOT matched in the ACL, then AAAA resource records will N=
OT be sent


   in response to a query for a hostname in the example.com =
domain.






This configuration appears to ensure the maximum barrier to adoption f=
or IPv6,


since it means that IPv6 will not work automatically.  It wi=
ll only work for


hosts that are manually configured to receive responses with v6 record=
s.




That's a rather major implication.  It's a default that is p=
robably meant to


apply during the very early stages of adoption, when there are few use=
rs of the


newer mechanism.




It's probably worth discussing it in more detail, including discussing=
 when to


change the default...








   However, if a DNS recursive resolver IS matched in the AC=
L, then AAAA


   resource records will be sent in response to a query for =
a given


   hostname in the example.com domain.  While thes=
e are not network-


   layer access controls they are nonetheless access control=
s that are a


   factor for end users and other parties like network opera=
tors,


   especially as networks and hosts transition from one netw=
ork address


   family to another (IPv4 to IPv6).








Also, all of this clarifies the function of this listing mechanism and=
 suggests


a very different name, to be more precise and accurate in naming it:



    IPv6 DNS Response Preference List.








   In practice, DNS whitelisting generally means that a very=
 small


   fraction of the DNS recursive resolvers on the Internet (=
those in the


   whitelist ACL) will receive AAAA responses.  Th=
e large majority of


   DNS resolvers on the Internet will therefore receive only=
 A resource


   records containing IPv4 addresses.  Thus, quite=
 simply, the


   authoritative server hands out different answers dependin=
g upon who


   is asking; with IPv4 and IPv6 resource records for some o=
n the


   authorized whitelist, and only IPv4 resource records for =
everyone


   else.  See Section 2.1 and Figure 1 for a descr=
iption of how this








Livingood          &=
nbsp;     Expires August 26, 2011   =
;            &n=
bsp;[Page 6]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






   works.




   Finally, DNS whitelisting can be deployed in two primary =
ways:


   universally on a global basis, or on an ad hoc basis.&nbs=
p; Deployment on


   a universal deployment basis means that DNS whitelisting =
is


   implemented on all authoritative DNS servers, across the =
entire


   Internet.  In contrast, deployment on an ad hoc=
 basis means that only


   some authoritative DNS servers, and perhaps even only a f=
ew,


   implement DNS whitelisting.  These two potentia=
l deployment models


   are described in Section 6.




2.1.  Description of the Operation of DNS Whitelisting




   The system logic of DNS whitelisting is as follows:




   1.  The authoritative DNS server for example.co=
m receives DNS queries


       for the A (IPv4) and AAAA (IPv6) =
address resource records for the


       FQDN www.example.com, for which A=
AAA (IPv6) resource records


       exist.






This means that the mechanism is /only/ triggered when /both/ address =
records


are queried?  A query for only one type of address record wo=
n't trigger the list


lookup?  I think that doesn't match other statements in the =
document.








   2.  The authoritative DNS server examines the I=
P address of the DNS


       recursive resolver sending the AA=
AA (IPv6) query.






"examines"?  Examines it for what?  What=
 does this step mean?








   3.  The authoritative DNS server checks this IP=
 address against the


       access control list (ACL) that is=
 the DNS whitelist.




   4.  If the DNS recursive resolver's IP address =
IS matched in the ACL,


       then the response to that specifi=
c DNS recursive resolver can


       contain AAAA (IPv6) address resou=
rce records.






Oh.  This is not about whether to send responses /over/ v6 v=
s. v4?  This is


whether to /include/ a particular type of RR in responses???




In that case an appropriate name for this mechanism is more like:



   DNS Response Content Preference List




And this seems even less like an ACL than it did before.  (I=
 assume the


justification is that access is being prevented by virtue of not suppl=
ying the


address, but still...)








   5.  If the DNS recursive resolver's IP address =
IS NOT matched in the


       ACL, then the response to that sp=
ecific DNS recursive resolver


       cannot contain AAAA (IPv6) addres=
s resource records.  In this


       case, the server should return a =
response with the response code


       (RCODE) being set to 0 (No Error)=
 with an empty answer section


       for the AAAA record query.
































Livingood          &=
nbsp;     Expires August 26, 2011   =
;            &n=
bsp;[Page 7]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






   ---------------------------------------------------------=
------------


   A query is sent from a DNS recursive resolver that IS NOT=
 on the DNS


   whitelist:




           &nbs=
p;   Request         =
;            &n=
bsp;Request


           www.examp=
le.com           &nb=
sp;      www.example.com


           &nbs=
p;     AAAA    +-------------&#=
43;     AAAA    +--------------=
---+


     ++--++   ---------&=
gt; |  RESOLVER   |  ---------> | www.exam=
ple.com |


     ||  ||     =
;  A      | **IS NOT**  | =
;     A      | IN A =
exists     |


   +-++--++-+ ---------> | &=
nbsp;   ON      |  ------=
---> | IN AAAA exists  |


   +--------+     A  &=
nbsp;   | example.com |      A=
      |      &n=
bsp;          |


      Host    <--=
------- |  WHITELIST  |  <--------- | =
;            &n=
bsp;   |


    Computer   A Record  +=
-------------+  A Record   +-----------------&#=
43;


           &nbs=
p;   Response   DNS Recursive   Response =
;      example.com


           &nbs=
p;  (only IPv4)   Resolver     (onl=
y IPv4)    Authoritative


           &nbs=
p;            &=
nbsp;     #1      &n=
bsp;            =
;        Server


   ---------------------------------------------------------=
------------


   A query is sent from a DNS recursive resolver that IS on =
the DNS


   whitelist:




           &nbs=
p;   Request         =
;            &n=
bsp;Request


           www.examp=
le.com           &nb=
sp;      www.example.com


           &nbs=
p;    AAAA     +-------------&#=
43;     AAAA    +--------------=
---+


     ++--++   ---------&=
gt; |  RESOLVER   |  ---------> | www.exam=
ple.com |


     ||  ||     =
;  A      |   **IS** &nbs=
p;  |      A    =
;  | IN A exists     |


   +-++--++-+ ---------> | &=
nbsp;   ON      |  ------=
---> | IN AAAA exists  |


   +--------+   AAAA   &nbs=
p; | example.com |     AAAA    |&nb=
sp;            =
    |


      Host    <--=
------- |  WHITELIST  |  <--------- | =
;            &n=
bsp;   |


    Computer      A&=
nbsp;     |      &nb=
sp;      |      A&nb=
sp;     |       =
;          |


           &nbs=
p;  <--------- |       &nbs=
p;     |  <--------- |   &n=
bsp;            =
; |


           &nbs=
p;  A and AAAA +-------------+ A and AAAA  +=
;-----------------+


           &nbs=
p;   Record     DNS Recursive   Rec=
ord        example.com


           &nbs=
p;  Responses     Resolver   &=
nbsp; Responses      Authoritative


           &nbs=
p;  (IPv4+IPv6)      #2 &n=
bsp;      (IPv4+IPv6)   &n=
bsp;   Server


   ---------------------------------------------------------=
------------




           &nbs=
p;  Figure 1: DNS Whitelisting - Functional Diagram






This diagram is confusing to me.  I suspect that a protocol =
exchange sequence


format, in the style of:




     Host       =
;      Resolver 1     &nb=
sp;      Authoritative




          ----------=
>


           &nbs=
p;            &=
nbsp;        --------->


           &nbs=
p;            &=
nbsp;       <---------


         <----------




will be considerably more helpful.








3.  What Problems Are Implementers Trying To Solve?






This is a very useful section and it is probably worth moving it highe=
r, to


precede the 'how it works' section.








   As noted in Section 1, domains which implement DNS whitel=
isting are


   attempting to protect a few users of their domain, who ha=
ve impaired


   IPv6 access, from having a negative experience (poor perf=
ormance).






By the way, what does 'impaired v6 access' mean?




I think there needs to be a simple, direct description of what occurs =
without


this mechanism.




For example, perhaps you mean that a host can send DNS queries using I=
Pv6 but


cannot receive DNS responses over IPv6? Perhaps you mean that the host=
 can send


IPv6 but cannot receive it.  (That's a different scale and s=
cope of problem from


the first example I gave.)




This brief, summary problem statement should be included in the Abstra=
ct, to


make /much/ more clear what this mechanism is for.








   While it is outside the scope of this document to explore=
 the various


   reasons why a particular user's system (host) may have im=
paired IPv6


   access, for the users who experience this impairment it i=
s a very


   real performance impact.  It would affect acces=
s to all or most dual








Livingood          &=
nbsp;     Expires August 26, 2011   =
;            &n=
bsp;[Page 8]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






   stack services to which the user attempts to connect.&nbs=
p; This negative


   end user experience can range from someone slower than us=
ual (as


   compared to native IPv4-based access), to extremely slow,=
 to no


   access to the domain whatsoever.






Rather than repeat that this is about end-users, it sounds more that t=
his is


about whether a service works or does not work, whether a user is dire=
ctly


present or not.








   While one can debate whether DNS whitelisting is the opti=
mal solution


   to the end user experience problem, it is quite clear tha=
t DNS


   whitelisting implementers are interested in maximizing th=
e


   performance of their services for end users as a primary =
motivation


   for implementation.






You keep citing 'performance' but haven't described what sort of perfo=
rmance


degradation takes place. Is this really about relatively better or wor=
se


performance -- and if so, how -- or is this about working or not worki=
ng?




Also rather than saying what implementers are interested in, it's prob=
ably more


helpful to note that the practice is now significantly established and=
 therefore


worth documenting, independent of its possible controversy.








   At least one highly-trafficked domain has noted that they=
 have


   received requests to not send DNS responses with AAAA res=
ource


   records to particular resolvers.  In this case,=
 the operators of






"At least one" seems a rather tiny statistic.  Per=
haps the actual statistic is


significantly larger?








   those recursive resolvers have expressed a concern that t=
heir IPv6






I suspect that it's not resolvers that are doing the expressing, since=
 their


vocabulary is usually too limited...








   network infrastructure is not yet ready to handle the lar=
ge traffic


   volume which may be associated with the hosts in their ne=
twork


   connecting to the websites of these domains.  T=
his concern is clearly






So even though the site allows v6 DNS queries to go out from a host, i=
t can't


really support having the host use v6?




Wow. I do understand why service providers often have to work around s=
illiness


at the client side, but this problem at the client side seems particul=
arly


egregious.








   a temporary consideration relating to the deployment of I=
Pv6 network


   infrastructure on the part of networks with end user host=
s, rather


   than a long-term concern.  These end user netwo=
rks may also have






Again this goal of short-term usage is worth noting earlier, including=
 in the


Abstract.








   other tools at their disposal in order to address this co=
ncern,


   including applying rules to network equipment such as rou=
ters and


   firewalls (this will necessarily vary by the type of netw=
ork, as well


   as the technologies used and the design of a given networ=
k), as well


   as configuration of their recursive resolvers (though mod=
ifying or


   suppressing AAAA resource records in a DNSSEC-signed doma=
in on a


   Security-Aware Resolver will be problematic Section 10.1)=
.




   Some implementers with highly-trafficked domains have exp=
lained that


   DNS whitelisting is a necessary, though temporary, risk r=
eduction


   tactic intended to ease their transition to IPv6 and mini=
mize any


   perceived risk in such a transition.  As a resu=
lt, they perceive this


   as a tactic to enable them to incrementally enable IPv6 c=
onnectivity


   to their domains during the early phases of their transit=
ion to IPv6.




   Finally, some domains, have run IPv6 experiments whereby =
they added


   AAAA resource records and observed and measured errors [H=
eise Online


   Experiment], which should be important reading for any do=
main


   contemplating either the use of DNS whitelisting or simpl=
y adding


   IPv6 addressing to their site.






4.  Concerns Regarding DNS Whitelisting




   There are a number of potential implications relating to =
DNS


   whitelisting, which have been raised as concerns by some =
parts of the


   Internet community.  Many of those potential im=
plications are further






I think the implications are not conditional; they exist rather than b=
eing


potential.  The 'potential' is that what is implicated will =
come to pass.












Livingood          &=
nbsp;     Expires August 26, 2011   =
;            &n=
bsp;[Page 9]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






   enumerated here and in Section 7.






Pro forma question:  Why are implications discussed in multi=
ple places?








   Some parties in the Internet community, including ISPs, a=
re concerned






This style of text personalizes the issues unnecessarily (IMO). &=
nbsp;It does not


really matter who holds the concerns, or else they'd be described more=
 precisely.




I suggest merely noting that there are concerns and then listing and d=
iscussing


the concerns, rather than adding text to attribute the concerns to oth=
ers, even


if the conclusion of your text is that a particular concern is not val=
id.








   that the practice of DNS whitelisting for IPv6 address re=
source


   records represents a departure from the generally accepte=
d practices


   regarding IPv4 address resource records in the DNS on the=
 Internet


   [Whitelisting Concerns].  These parties explain=
 their belief that for






"These parties explain their belief" is an example of person=
alization that is


not needed.  This isn't about the believers.  It i=
s about possible problems.








   A resource records, containing IPv4 addresses, once an au=
thoritative


   server operator adds the A record to the DNS, then any DN=
S recursive


   resolver on the Internet can receive that A record in res=
ponse to a






This does not appear to be a grammatically valid sentence.  =
My guess is that


deleting "A resource... addresses" fixes this.




And by the way, the document's reference to "recursive" reso=
lvers is mostly


likely incorrect.  The problem is not restricted only to tha=
t very specific type


of resolver, is it?




If in fact it /is/ specific to them -- and your following text describ=
es an


indirect effects scenario where it might be -- I suggest calling out t=
he


configuration at the beginning, along the lines of:




     One way the problem with returning AAAA recor=
ds can be experienced is when


recursive resolvers are used.  Although that resolver might =
support IPv6, its


client hosts might not.  So, returning an AAAA record will m=
ean that these


limited hosts will be given an unusable address.




And this type of description belongs in the text describing the motiva=
ting


problem(s), rather than buried in the 'concerns' discussion.




(The text, here, pertains to A records, but the problem I've described=
 uses the


same configuration but for AAAA records with mixed v6 support.)








   query.  By extension, this means that any of th=
e hosts connected to


   any of these DNS recursive resolvers can receive the IPv4=
 address


   resource records for a given FQDN.  This enable=
s new server hosts


   which are connected to the Internet, and for which a full=
y qualified


   domain name (FQDN) such as www.example.com has been added=
 to the DNS


   with an IPv4 address record, to be almost immediately rea=
chable by


   any host on the Internet.  In this case, these =
new servers hosts


   become more and more widely accessible as new networks an=
d new end


   user hosts connect to the Internet over time, capitalizin=
g on and


   increasing so-called "network effects" (also ca=
lled network


   externalities).  It also means that the new ser=
ver hosts do not need


   to know about these new networks and new end user hosts i=
n order to


   make their content and applications available to them, in=
 essence


   that each end in this end-to-end model is responsible for=
 connecting


   to the Internet and once they have done so they can conne=
ct to each


   other without additional impediments or middle networks o=
r


   intervening networks or servers knowing about these end p=
oints and


   whether one is allowed to contact the other.






Hmmm.  This rather lengthy bit of prose appears merely to be=
 explaining the


basic and long-standing DNS value proposition???








   In contrast, the concern is that DNS whitelisting may fun=
damentally


   change this model.  In the altered DNS whitelis=
ting end-to-end model,


   one end (where the end user is located) cannot readily co=
nnect to the


   other end (where the content is located), without parts o=
f the middle


   (recursive resolvers) used by one end (the client, or end=
 user hosts)


   being known to an intermediary (authoritative nameservers=
) and


   approved for access to the resource at the end. &nbs=
p;As new networks


   connect to the Internet over time, those networks need to=
 contact any


   and all domains which have implemented DNS whitelisting i=
n order to


   apply to be added to their DNS whitelist, in the hopes of=
 making the


   content and applications residing on named server hosts i=
n those


   domains accessible by the end user hosts on that new netw=
ork.


   Furthermore, this same need to contact all domains implem=
enting DNS


   whitelisting also applies to all pre-existing (but not wh=
itelisted)


   networks connected to the Internet.




   In the current IPv4 Internet when a new server host is ad=
ded to the


   Internet it is generally widely available to all end user=
 hosts and


   networks, when DNS whitelisting of IPv6 resource records =
is used,






If it is available to the hosts, it is available to the network.




networks, when -> networks. When














Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 1=
0]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






   these new server hosts are not accessible to any end user=
 hosts or


   networks until such time as the operator of the authorita=
tive DNS






They are still accessible.  The IP-level mechanisms still wo=
rk.




They are not reachable when using the domain name.








   servers for those new server hosts expressly authorizes a=
ccess to


   those new server hosts by adding DNS recursive resolvers =
around the


   Internet to the ACL.  This has the potential to=
 be a significant






This is a good example of the reason the term ACL is inappropriate:&nb=
sp; It implies


a security protection that does not actually exist.  The hos=
ts are still accessible.








   change in reachability of content and applications by end=
 users and


   networks as these end user hosts and networks transition =
to IPv6,


   resulting in more (but different) breakage.  A =
concern expressed is


   that if much of the content that end users are most inter=
ested in is


   not accessible as a result, then end users and/or network=
s may resist


   adoption of IPv6 or actively seek alternatives to it, suc=
h as using


   multi-layer network address translation (NAT) techniques =
like NAT444


   [I-D.shirasaki-nat444] on a long-term basis.  T=
here is also concern


   that this practice also could disrupt the continued incre=
ase in


   Internet adoption by end users if they cannot simply acce=
ss new


   content and applications but must instead contact the ope=
rator of


   their DNS recursive resolver, such as their ISP or anothe=
r third


   party, to have their DNS recursive resolver authorized fo=
r access to


   the content or applications that interests them. &nb=
sp;Meanwhile, these


   parties say, over 99.9% of the other end users that are a=
lso using


   that same network or DNS recursive resolver are unable to=
 access the


   IPv6-based content, despite their experience being a posi=
tive one.




   While in Section 1 the level of IPv6-related impairment h=
as been


   estimated to be as high as 0.078% of Internet users, whic=
h is a






8 hundredths of one percent?




That's considered a high percentage?




Even if it is 8%, is that considered high?








5.2.  Similarities to DNS Load Balancing




   DNS whitelisting also has some similarities to DNS load b=
alancing.


   There are of course many ways that DNS load balancing can=
 be


   performed.  In one example, multiple IP address=
 resource records (A


   and/or AAAA) can be added to the DNS for a given FQDN.&nb=
sp; This approach


   is referred to as DNS round robin [RFC1794].  D=
NS round robin may


   also be employed where SRV resource records are used [RFC=
2782].






Right, but that's algorithmic rather than involving the manual method,=
 described


here. So it does not seem comparable.








6.  Likely Deployment Scenarios




   In considering how DNS whitelisting may emerge more widel=
y, there are


   two likely deployment scenarios, which are explored below=
.




   In either of these deployment scenarios, it is possible t=
hat


   reputable third parties could create and maintain DNS whi=
telists, in


   much the same way that blacklists are used for reducing e=
mail spam.


   In the email context, a mail operator subscribes to one o=
r more of


   these lists and as such the operational processes for add=
itions and


   deletions to the list are managed by a third party. =
 A similar model


   could emerge for DNS whitelisting, whether deployment occ=
urs


   universally or on an ad hoc basis.






The challenges of email whitelists and blacklists should be cited, sin=
ce it


provides a rich base of experience for such an effort, at scale.








6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis




   The seemingly most likely deployment scenario is where so=
me






Most likely?  This is not already established practice?







   authoritative DNS server operators implement DNS whitelis=
ting but


   many or most others do not do so.  What can mak=
e this scenario


   challenging from the standpoint of a DNS recursive resolv=
er operator


   is determining which domains implement DNS whitelisting, =
particularly


   since a domain may not do so as they initially transition=
 to IPv6,


   and may instead do so later.  Thus, a DNS recur=
sive resolver operator








Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 1=
3]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






   may initially believe that they can receive AAAA response=
s as a


   domain adopts IPv6, but then notice via end user reports =
that they no


   longer receive AAAA responses due to that domain adopting=
 DNS


   whitelisting.  Of course, a domain's IPv6 trans=
ition may be


   effectively invisible to recursive server operators due t=
o the effect


   of DNS whitelisting.






This suggests that every listing at the server needs a contact record =
for


periodic checks whether to renew the listing.










   In contrast to a universal deployment of DNS whitelisting=



   Section 6.2, deployment on an ad hoc basis is likely to b=
e


   significantly more challenging from an operational, monit=
oring, and






Oh?  Use in small scale is more challenging than use of manu=
al exceptions list


at large scale?  That's a very unexpected view.








   troubleshooting standpoint.  In this scenario, =
a DNS recursive


   resolver operator will have no way to systematically dete=
rmine


   whether DNS whitelisting is or is not implemented for a d=
omain, since


   the absence of AAAA resource records may simply be indica=
tive that


   the domain has not yet added IPv6 addressing for the doma=
in, rather


   than that they have done so but have restricted query acc=
ess via DNS






The premise is that, in large scale use, servers /will/ have a way to<=
/div>

systematically determine whether it is implemented?  What ar=
e the existing


examples of having such a capability for other Internet protocols and =
services?








   whitelisting.  As a result, discovering which d=
omains implement DNS


   whitelisting, in order to differentiate them from those t=
hat do not,


   is likely to be challenging.




   One benefit of DNS whitelisting being deployed on an ad h=
oc basis is


   that only the domains that are interested in doing so wou=
ld have to


   upgrade their authoritative DNS servers in order to imple=
ment the


   ACLs necessary to perform DNS whitelisting.




   In this potential deployment scenario, it is also possibl=
e that a


   given domain will implement DNS whitelisting temporarily.=
  A domain,


   particularly a highly-trafficked domain, may choose to do=
 so in order


   to ease their transition to IPv6 through a selective depl=
oyment and


   minimize any perceived risk in such a transition.




6.2.  Deploying DNS Whitelisting Universally




   The least likely deployment scenario is one where DNS whi=
telisting is


   implemented on all authoritative DNS servers, across the =
entire


   Internet.  While this scenario seems less likel=
y than ad hoc


   deployment due to some parties not sharing the concerns t=
hat have so


   far motivated the use of DNS whitelisting, it is nonethel=
ess


   conceivable that it could be one of the ways in which DNS=



   whitelisting is deployed.






Significantly, the partial-deployment model casts this mechanism as a =
transition


expedient -- as the document reasonably describes it -- whereas univer=
sal


deployment casts it as a fundamental change to the architecture.




Given that it would take decades to achieve relatively full deployment=
 of this


'across the entire Internet', what is the benefit of discussing this h=
ighly


unlikely scenario?  Is it really "conceivable"?&nb=
sp; I doubt it. If you think


otherwise, the paper needs to explore the deployment and adoption issu=
es in much


more detail, because I don't see how it could work.








   In order for this deployment scenario to occur, it is lik=
ely that DNS


   whitelisting functionality would need to be built into al=
l


   authoritative DNS server software, and that all operators=
 of


   authoritative DNS servers would have to upgrade their sof=
tware and


   enable this functionality.  It is likely that n=
ew Internet Draft


   documents would need to be developed which describe how t=
o properly


   configure, deploy, and maintain DNS whitelisting. &n=
bsp;As a result, it is








Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 1=
4]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






   unlikely that DNS whitelisting would, at least in the nex=
t several


   years, become universally deployed.  Furthermor=
e, these DNS


   whitelists are likely to vary on a domain-by-domain basis=
, depending


   upon a variety of factors.  Such factors may in=
clude the motivation


   of each domain owner, the location of the DNS recursive r=
esolvers in


   relation to the source content, as well as various other =
parameters


   that may be transitory in nature, or unique to a specific=
 end user


   host type.  It is probably unlikely that a sing=
le clearinghouse for


   managing whitelisting is possible; it will more likely be=
 unique to


   the source content owners and/or domains which implement =
DNS


   whitelists.




   While this scenario may be unlikely, it may carry some be=
nefits.


   First, parties performing troubleshooting would not have =
to determine


   whether or not DNS whitelisting was being used, as it alw=
ays would be


   in use.  In addition, if universally deployed, =
it is possible that


   the criteria for being added to or removed from a DNS whi=
telist could


   be standardized across the entire Internet.  Ne=
vertheless, even if


   uniform DNS whitelisting policies were not standardized, =
is also


   possible that a central registry of these policies could =
be developed


   and deployed in order to make it easier to discover them,=
 a key part


   of achieving transparency regarding DNS whitelisting.





Is any of this paragraph realistic?  Obviously my asking mea=
ns I don't it is.


These seem to be of theoretical rather than pragmatic interest. &=
nbsp;("If everyone


refuses to shoot, there will be no wars.")




It's true that this is an "implications" paper rather than a=
 BCP, but still...










7.  Implications of DNS Whitelisting




   There are many potential implications of DNS whitelisting=
.  The key


   potential implications are detailed below.




7.1.  Architectural Implications




   DNS whitelisting could be perceived as modifying the end-=
to-end model


   and/or the general notion of the architecture that prevai=
ls on the






I'll suggest that perception is not a major issue about a technical to=
pic like


this.  (It's not entirely irrelevant, of course, but I suspe=
ct it is quite minor.)




The major issue is whether it /actually/ modifies the end-to-end natur=
e of the


DNS.  And I think it does, as well as modifying the "sp=
ontaneous


interoperability" expectation for most Internet mechanism, since =
it requires


prior registration.








7.2.  Public IPv6 Address Reachability Implications




   The predominant experience of end user hosts and servers =
on the IPv4-


   addressed Internet today is that when a new server with a=
 public IPv4


   address is added to the DNS, that it is then globally acc=
essible by






This sentence is not quite correct, in strict technical terms. &n=
bsp;Since this is a


technical discussion, we need to be precise:  the host is re=
achable when the


routing tables make it reachable.  That's strictly a mapper =
of IP Address


handling, not name-to-address mapping.




What you mean is that its domain name is immediately useful for reachi=
ng it.








   IPv4-addressed hosts.  This is a generalization=
 and in Section 5


   there are examples of common cases where this may not nec=
essarily be


   the case.  For the purposes of this argument, t=
hat concept of


   accessibility can be considered "pervasive reachabil=
ity".  It has so


   far been assumed that the same expectations of pervasive =
reachability


   would exist in the IPv6-addressed Internet.  Ho=
wever, if DNS


   whitelisting is deployed, this will not be the case since=
 only end


   user hosts using DNS recursive resolvers which are includ=
ed in the






again, you mean /name-based/ reachability.














Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 1=
6]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






   ACL of a given domain using DNS whitelisting would be abl=
e to reach


   new servers in that given domain via IPv6 addresses. =
; The expectation


   of any end user host being able to connect to any server =
(essentially


   both hosts, just at either end of the network), defined h=
ere as


   "pervasive reachability", will change to "=
restricted reachability"


   with IPv6.




   Establishing DNS whitelisting as an accepted practice in =
the early


   phases of mass IPv6 deployment could well establish it as=
 an integral


   part of how IPv6 DNS resource records are deployed global=
ly.  As a


   result, it is then possible that DNS whitelisting could l=
ive on for


   decades on the Internet as a key foundational element of =
domain name


   management that we will all live with for a long time.





(that last sentence could benefit from some editing.)








   It is a critical to understand that the concept of reacha=
bility


   described above depends upon a knowledge or awareness of =
an address


   in the DNS.  Thus, in order to establish reacha=
bility to an end


   point, a host is dependent upon looking up an IP address =
in the DNS






If this section were started with a sentence like this, then there wou=
ld not be


a problem with the other references' being confused with address-based=
 routing


reachability.








   when a FQDN is used.  When DNS whitelisting is =
used, it is quite


   likely the case that an IPv6-enabled end user host could =
ping or


   connect to an example server host, even though the FQDN a=
ssociated


   with that server host is restricted via a DNS whitelist.&=
nbsp; Since most






First, I suspect that "example" doesn't add meaning to the s=
entence.  Second,


pinging and connecting might happen with or without the whitelist entr=
y.  So I


do not understand what import there is in this sentence.








   Internet applications and hosts such as web servers depen=
d upon the


   DNS, and as end users connect to FQDNs such as www.exampl=
e.com and do


   not remember or wish to type in an IP address, the notion=
 of


   reachability described here should be understood to inclu=
de knowledge


   how to associate a name with a network address.






Again, this 'premise' statement should introduce the sub-section, not =
end it.










7.3.  Operational Implications




   This section explores some of the operational implication=
s which may


   occur as a result of, are related to, or become necessary=
 when


   engaging in the practice of DNS whitelisting.




7.3.1.  De-Whitelisting May Occur






The more general version of this issue is 'synchronization'. &nbs=
p;Entries in the


whitelist need to be synchronized with host status and capabilities.







   It is possible for a DNS recursive resolver added to a wh=
itelist to


   then be removed from the whitelist, also known as de-whit=
elisting.


   Since de-whitelisting can occur, through a decision by th=
e


   authoritative server operator, the domain owner, or even =
due to a


   technical error, an operator of a DNS recursive resolver =
will have


   new operational and monitoring requirements and/or needs =
as noted in


   Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section =
7.5.




7.3.2.  Authoritative DNS Server Operational Implications



   Operators of authoritative servers may need to maintain a=
n ACL a






a -> on a (?)








   server-wide basis affecting all domains, on a domain-by-d=
omain basis,






Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 1=
7]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






   as well as on a combination of the two.  As a r=
esult, operational






I'm not really understanding the first sentence.  One proble=
m might be that its


discussing an implication of some configuration or usage options that =
have not


been previously specified, so that the reference here might be overly =
cryptic.




For example, I don't know what "affecting all domains" actua=
lly means.  It


almost sounds as if it could mean "everyone gets AAAA records&quo=
t; or "no one gets


AAAA records" yet I'm reaonably certain that is /not/ what is mea=
nt.








   practices and software capabilities may need to be develo=
ped in order


   to support such functionality.  In addition, pr=
ocesses may need to be


   put in place to protect against inadvertently adding or r=
emoving IP


   addresses, as well as systems and/or processes to respond=
 to such


   incidents if and when they occur.  For example,=
 a system may be


   needed to record DNS whitelisting requests, report on the=
ir status


   along a workflow, add IP addresses when whitelisting has =
been


   approved, remove IP addresses when they have been de-whit=
elisted, log


   the personnel involved and timing of changes, schedule ch=
anges to


   occur in the future, and to roll back any inadvertent cha=
nges.






Might be worth starting with a simple, broad summary statement, possib=
ly along


the lines of:




   An AAAA DNS Whitelist serves as a critical infrastructure=
 service; to be


useful it needs careful and extensive administration, monitoring and o=
peration.


Each new and essential mechanism creates substantial follow-on support=
 costs.








   Operators may also need implement new forms of monitoring=
 in order to


   apply change control, as noted briefly in Section 7.3.4.<=
/div>



7.3.3.  DNS Recursive Resolver Server Operational Implicatio=
ns




   Operators of DNS recursive resolvers, which may include I=
SPs,


   enterprises, universities, governments, individual end us=
ers, and


   many other parties, are likely to need to implement new f=
orms of


   monitoring, as noted briefly in Section 7.3.4.  =
;But more critically,


   such operators may need to add people, processes, and sys=
tems in


   order to manage large numbers of DNS whitelisting applica=
tions as


   part of their own IPv6 transition, for all domains that t=
he end users


   of such servers are interested in now or in which they ma=
y be






I think the summary observation is simple and should be stated directl=
y:  This


is a manual mechanism that becomes expensive in time and personnel eff=
ort as it


scales up.








   interested in the future.  As anticipation of i=
nteresting domains is


   likely infeasible, it is more likely that operators may e=
ither choose


   to only apply to be whitelisted for a domain based upon o=
ne or more


   end user requests, or that they will attempt to do so for=
 all domains


   that they can ascertain to be engaging in DNS whitelistin=
g.






"attempt to do so for all domain that they can ascertain to be en=
gaging in DNS


whitelisting"  appears to be saying to do whitelisting =
for domains that do


whitelisting.  I don't understand.










   When operators apply for DNS whitelisting for all domains=
, that may






"apply for DNS whitelisting for all domains" -- again I'm no=
t understanding what


this means.








7.3.5.  Implications of Operational Momentum




   It seems plausible that once DNS whitelisting is implemen=
ted it will


   be very difficult to deprecate such technical and operati=
onal


   practices.  This assumption is based in an unde=
rstanding of human






in -> on








   nature, not to mention physics.  For example, a=
s Sir Issac Newton


   noted, "Every object in a state of uniform motion te=
nds to remain in


   that state of motion unless an external force is applied =
to it" [Laws






Code does not have momenum.  Neither do configurations or li=
sts.  This really


isn't about physics.




It is entirely about group psychology, as you note, and the administra=
tive


challenges in the logistics of large-scale operational changes (which =
probably


/does/ have something to with physics, but it seems a stretch to credi=
t Newton.


How about Heisenberg?...)








   of Motion].  Thus, once DNS whitelisting is imp=
lemented it is quite


   likely that it would take considerable effort to deprecat=
e the


   practice and remove it everywhere on the Internet - it wi=
ll otherwise


   simply remain in place in perpetuity.  To bette=
r illustrate this


   point, one could consider one example (of many) that ther=
e are many


   email servers continuing to attempt to query or otherwise=
 check anti-








Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 1=
9]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






   spam DNS blocklists which have long ago ceased to exist.<=
/div>



7.3.6.  Troubleshooting Implications




   The implications of DNS whitelisted present many challeng=
es, which


   have been detailed in Section 7.  These challen=
ges may negatively






But this is /still/ section 7.  Can you be more specific?&nb=
sp; Or perhaps say


"throughout this section".








   affect the end users' ability to troubleshoot, as well as=
 that of DNS


   recursive resolver operators, ISPs, content providers, do=
main owners


   (where they may be different from the operator of the aut=
horitative


   DNS server for their domain), and other third parties.&nb=
sp; This may make


   the process of determining why a server is not reachable<=
/div>

   significantly more complex.




7.3.7.  Additional Implications If Deployed On An Ad Hoc Bas=
is




   Additional implications, should this be deployed on an ad=
 hoc basis,


   could include scalability problems relating to operationa=
l processes,






I'm pretty sure that scaling problems for this exist in all scenarios,=
 not just


ad hoc usage.








   monitoring, and ACL updates.  In particular, it=
 seems likely that as


   the number of domains that are using DNS whitelisting inc=
reases, as


   well as the number of IPv6-capable networks requesting to=
 be


   whitelisted, that there is an increased likelihood of con=
figuration


   and other operational errors, especially with respect to =
the ACLs


   themselves.




   It is unclear when and if it would be appropriate to chan=
ge from


   whitelisting to blacklisting, and whether or how this cou=
ld feasibly


   be coordinated across the Internet, which may be proposed=
 or






Actually the question of coordination is quite clear and rather fundam=
ental:




     No.




Anyone believing otherwise needs to cite a successful example, at Inte=
rnet scale


and diversity, more recently than the 1983 switch to IP (which didn't =
go all


that well anyhow...)




Simple, unambiguous showstoppers should be stated in a simple and dire=
ct manner.


When there is room for debate, softer language makes sense.  =
;Again, if the


question of coordination really is subject to debate, then the basis n=
eeds to be


stated.  (Good luck!)








   implemented on an ad hoc basis when a majority of network=
s (or


   allocated IPv6 address blocks) have been whitelisted.&nbs=
p; Finally, some


   parties implementing DNS whitelisting consider this to be=
 a temporary


   measure.  As such, it is not clear how these pa=
rties will judge the


   network conditions to have changed sufficiently to justif=
y disabling


   DNS whitelisting and/or what the process and timing will =
be in order


   to discontinue this practice.




   One further potential implication is that an end user wit=
h only an


   IPv4 address, using a DNS resolver which has not been whi=
telisted by


   any domains, would not be able to get any AAAA resource r=
ecords.  In


   such a case, this could give that end user the incorrect =
impression


   that there is no IPv6-based content on the Internet since=
 they are


   unable to discover any IPv6 addresses via the DNS.




7.4.  Homogeneity May Be Encouraged




   A broad trend which has existed on the Internet appears t=
o be a move


   towards increasing levels of heterogeneity.  On=
e manifestation of






increasing levels of heterogeneity -> more heterogeneity




(I think heterogeneity does not have 'levels'.)




Substantively:  say the nature of the heterogeneity within t=
he initial claim.


For example, there is /less/ heterogeneity of ISPs, given industry

consolidation.  There is less heterogeneity of infrastructur=
e equipment such as


routers.  Etc.








   this is in an increasing number, variety, and customizati=
on of end


   user hosts, including home network, operating systems, cl=
ient








Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 2=
0]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






   software, home network devices, and personal computing de=
vices.  This


   trend appears to have had a positive effect on the develo=
pment and


   growth of the Internet.  A key facet of this th=
at has evolved is the


   ability of the end user to connect any technically compli=
ant device


   or use any technically compatible software to connect to =
the


   Internet.  Not only does this trend towards gre=
ater heterogeneity


   reduce the control which is exerted in the middle of the =
network,


   described in positive terms in [Tussle in Cyberspace], [R=
ethinking


   the Internet], and [RFC3724], but it can also help to ena=
ble greater


   and more rapid innovation at the edges.




   An unfortunate implication of the adoption of DNS whiteli=
sting may be


   the encouragement of a reversal of this trend, which woul=
d be a move






the encouragement of -> to encourage








8.1.  Implement DNS Whitelisting Universally




   One obvious solution is to implement DNS whitelisted univ=
ersally, and


   to do so using some sort of centralized registry of DNS w=
hitelisting


   policies, contracts, processes, or other information.&nbs=
p; This potential


   solution seems unlikely at the current time.






I'm pretty sure that the only thing that is obvious about a premise of=
 universal


adoption is that it's not practical.  Seriously.




At the least, this section needs to be less cavalier about putting thi=
s


alternative forward as a "solution", especially given the ra=
ther serious


drawbacks/problems with it.








8.2.  Implement DNS Whitelisting On An Ad Hoc Basis




   If DNS whitelisting is to be adopted, it is likely to be =
adopted on






"is to be"?  I thought it already had a significan=
t installed base.








   this ad hoc, or domain-by-domain basis.  Theref=
ore, only those


   domains interested in DNS whitelisting would need to adop=
t the


   practice, though as noted herein discovering that they a =
given domain


   has done so may be problematic.  Also in this s=
cenario, ad hoc use by


   a particular domain may be a temporary measure that has b=
een adopted


   to ease the transition of the domain to IPv6 over some sh=
ort-term


   timeframe.




8.3.  Do Not Implement DNS Whitelisting




   As an alternative to adopting DNS whitelisting, the Inter=
net


   community generally can choose to take no action whatsoev=
er,


   perpetuating the current predominant authoritative DNS op=
erational


   model on the Internet, and leave it up to end users with =
IPv6-related


   impairments to discover and fix those impairments.








That is, place the burden of fixing a problem on those creating it?















Livingood          &=
nbsp;     Expires August 26, 2011   =
;            [Page 2=
3]




Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs=
p;  February 2011






8.3.1.  Solving Current End User IPv6 Impairments




   A further extension of not implementing DNS whitelisting,=
 is to also


   endeavor to actually fix the underlying technical problem=
s that have


   prompted the consideration of DNS whitelisting in the fir=
st place, as


   an alternative to trying to apply temporary workarounds t=
o avoid the


   symptoms of underlying end user IPv6 impairments. &n=
bsp;A first step is


   obviously to identify which users have such impairments, =
which would


   appear to be possible, and then to communicate this infor=
mation to


   end users.  Such end user communication is like=
ly to be most helpful


   if the end user is not only alerted to a potential proble=
m but is


   given careful and detailed advice on how to resolve this =
on their


   own, or where they can seek help in doing so.  =
Section 11 may also be


   relevant in this case.




   One challenge with this option is the potential difficult=
y of


   motivating members of the Internet community to work coll=
ectively


   towards this goal, sharing the labor, time, and costs rel=
ated to such


   an effort.  Of course, since just such a commun=
ity effort is now


   underway for IPv6, it is possible that this would call fo=
r only a


   moderate amount of additional work.






This 'challenge' is at the core of /all/ adoption efforts for Internet=
 protocols


and services that entail distributed adoption.








   Despite any potential challenges, many in the Internet co=
mmunity are


   already working towards this goal and/or have expressed a=
 general


   preference for this approach.






If this is not already an organized effort with a website, sponsoring<=
/div>

consortium, or the like, it should be.  If it is, then cite =
it in this doc!








8.3.2.  Gain Experience Using IPv6 Transition Names




   Another alternative is for domains to gain experience usi=
ng an FQDN


   which has become common for domains beginning the transit=
ion to IPv6;


   ipv6.example.com and www.ipv6.example.com.  Thi=
s can be a way for a


   domain to gain IPv6 experience and increase IPv6 use on a=
 relatively


   controlled basis, and to inform any plans for DNS whiteli=
sting with


   experience.






I do not understand what this means.




What is it for?  What are the results?  How are th=
eyused?








9.  Is DNS Whitelisting a Recommended Practice?




   Opinions in the Internet community concerning whether or =
not DNS


   whitelisting is a recommended practice are understandably=
 quite


   varied.  However, there is clear consensus that=
 DNS whitelisting is


   at best a useful temporary measure which a domain may cho=
ose to






If that is a clear consensus, then it makes even less sense to promote=
 the idea


of universal adoption, given the timescale needed to achieve it.








10.  Security Considerations




   There are no particular security considerations if DNS wh=
itelisting


   is not adopted, as this is how the public Internet works =
today with A


   resource records.






Or rather, failure to adopt a mechanism like this or repair the underl=
ying


problem, for those sites experiencing that problem, will result in a d=
enial of


service, albeit not an intentional one.  Still, that's a pre=
tty basic security


issue.






d/


-- 




  Dave Crocker


  Brandenburg InternetWorking


  bbiw.net


_______________________________________________


Ietf mailing list








-- 




  Dave Crocker


  Brandenburg InternetWorking


  bbiw.net


_______________________________________________


Ietf mailing list






















--_000_CA09169928B58jasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Mon May 30 06:59: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 11EFEE06FD for ; Mon, 30 May 2011 06:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.348
X-Spam-Level: 
X-Spam-Status: No, score=-108.348 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 lN48dMdDR5zs for ; Mon, 30 May 2011 06:59:16 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 27DA0E068F for ; Mon, 30 May 2011 06:59:16 -0700 (PDT)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128225028; Mon, 30 May 2011 09:59:05 -0400
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, 30 May 2011 09:59:05 -0400
From: "Livingood, Jason" 
To: "v6ops@ietf.org" 
Thread-Topic: Issue 2: draft-ietf-v6ops-v6-aaaa-whitelisting-implications
Thread-Index: AQHMHtG2XThjNX/iLESe1IpUZQ+nhw==
Date: Mon, 30 May 2011 13:59:04 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [69.141.126.196]
Content-Type: multipart/alternative; boundary="_000_CA091AE428B91jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "J.D. Falk" 
Subject: [v6ops] Issue 2: draft-ietf-v6ops-v6-aaaa-whitelisting-implications
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 30 May 2011 13:59:17 -0000

--_000_CA091AE428B91jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Seeking WG guidance to close open issues.

>From Appendix B:
2. JD Falk question - should I add a sub-section to 9 to explain how best t=
o implement if you did it? (transparent/published policies, SLA on decision=
 making,etc.)

Proposed direction (please comment if you disagree):
This is sort of 'best practices' or 'recommended practices' for Whitelistin=
g. I think this was raised in a WG meeting two IETFs ago and the direction =
was to not include that as it could be an entirely separate document later =
on =97 and once the practice had more time in deployment. I'd like to close=
 this out and not include these new sections. The WG can always decide such=
 a new document is useful later.

Jason


--_000_CA091AE428B91jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Seeking WG guidance to close open issues.







From Appendix B:


2. JD Falk question - should I add a sub-section to 9 to explain how b=
est to implement if you did it? (transparent/published policies, SLA on dec=
ision making,etc.)







Proposed direction (please comment if you disagree): 


This is sort of 'best practices' or 'recommended practices' for Whitel=
isting. I think this was raised in a WG meeting two IETFs ago and the direc=
tion was to not include that as it could be an entirely separate document l=
ater on =97 and once the practice
 had more time in deployment. I'd like to close this out and not include th=
ese new sections. The WG can always decide such a new document is useful la=
ter.







Jason









--_000_CA091AE428B91jasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Mon May 30 07:06: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 9623BE07C9 for ; Mon, 30 May 2011 07:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.986
X-Spam-Level: 
X-Spam-Status: No, score=-107.986 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 5+oSNdKpgFPM for ; Mon, 30 May 2011 07:06:10 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 75211E07C8 for ; Mon, 30 May 2011 07:06:10 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128227041; Mon, 30 May 2011 10:06:01 -0400
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; Mon, 30 May 2011 10:06:01 -0400
From: "Livingood, Jason" 
To: Ray Hunter , "v6ops@ietf.org" 
Thread-Topic: Issue 3: draft-ietf-v6ops-v6-aaaa-whitelisting-implications
Thread-Index: AQHMHtKu8THOrmwg9UuNjZj99k0U9Q==
Date: Mon, 30 May 2011 14:06:00 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [24.40.55.71]
Content-Type: multipart/alternative; boundary="_000_CA091C8728B9Fjasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Subject: [v6ops] Issue 3: draft-ietf-v6ops-v6-aaaa-whitelisting-implications
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 30 May 2011 14:06:11 -0000

--_000_CA091C8728B9Fjasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Seeking WG guidance to close open issues.

>From Appendix B:
3. Per Ray Hunter - "Which is why my original posting suggested that the WG=
 might wish to express a concern about anyone making assumptions about any =
undocumented architectural links between DNS and transport, and also sugges=
t that operators of aaaa whitelists (party X) should disclose their aaaa me=
thodology and data, and that they should not share whitelist data with othe=
r aaaa operators in an uncontrolled manner, so that at least Party Y could =
see what was happening and why, and also have a chance of correcting it."

Proposed direction (please comment if you disagree):
Some of this should now be addressed in Section 7.3.1 (De-Whitelisting May =
Occur). Other aspects of this are similar to the feedback from J.D. Falk. A=
s such, this relates to 'recommended practices' for Whitelisting. I think t=
his was raised in a WG meeting two IETFs ago and the direction was to not i=
nclude that as it could be an entirely separate document later on =97 and o=
nce the practice had more time in deployment. I'd like to close this out an=
d not include these new sections (also noting some of the question is addre=
ssed in 7.3.1). The WG can always decide such a new document is useful late=
r.

Jason

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

--_000_CA091C8728B9Fjasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <1B325823EB45124096FB64DE1A8938F2@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable













Seeking WG guidance to close open issues.







From Appendix B:


3. Per Ray Hunter - "Which is why my original posting suggested t=
hat the WG might wish to express a concern about anyone making assumptions =
about any undocumented architectural links between DNS and transport, and a=
lso suggest that operators of aaaa whitelists
 (party X) should disclose their aaaa methodology and data, and that they s=
hould not share whitelist data with other aaaa operators in an uncontrolled=
 manner, so that at least Party Y could see what was happening and why, and=
 also have a chance of correcting
 it."







Proposed direction (please comment if you disagree): 


Some of this should now be addressed in Section 7.3.1 (De-Whitelisting=
 May Occur). Other aspects of this are similar to the feedback from J.D. Fa=
lk. As such, this relates to 'recommended practices' for Whitelisting. I th=
ink this was raised in a WG meeting
 two IETFs ago and the direction was to not include that as it could be an =
entirely separate document later on =97 and once the practice had more time=
 in deployment. I'd like to close this out and not include these new sectio=
ns (also noting some of the question
 is addressed in 7.3.1). The WG can always decide such a new document is us=
eful later. 







Jason






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








--_000_CA091C8728B9Fjasonlivingoodcablecomcastcom_--

From dhc@dcrocker.net  Mon May 30 08: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 7DAA7E07E5; Mon, 30 May 2011 08:34:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.289
X-Spam-Level: 
X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=-0.290, 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 NwgKd0n+VEQO; Mon, 30 May 2011 08:34:34 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 71AA1E07AB; Mon, 30 May 2011 08:34:34 -0700 (PDT)
Received: from [192.168.1.5] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4UFYP23012039 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 30 May 2011 08:34:31 -0700
Message-ID: <4DE3B8FD.7040209@dcrocker.net>
Date: Mon, 30 May 2011 08:34:21 -0700
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Livingood, Jason" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 30 May 2011 08:34:31 -0700 (PDT)
Cc: "v6ops@ietf.org" , IETF Discussion , Apps Review 
Subject: Re: [v6ops] Review of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps	area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 May 2011 15:34:36 -0000

(I see that you've posted -05.  This response is for completeness.)


On 5/29/2011 7:54 PM, Livingood, Jason wrote:
> [JL] Duly noted in my previous emails. I'm keeping the naming as an open issue
> in the –04 and will be seeking WG and WG co-chair guidance one way or the other.

One of the reasons for cross-area review is to look for cross-area problems.

Separate from the legal formalities, the purpose of 'trademark' is to try to 
avoid market confusion.  Market confusion was exactly the reason that I raised 
concern about the naming and I wasn't the only one who noticed the problem.  (My 
original, informal posting was directly result of that confusion...)

So I'm sorry to see that the naming conflict is felt to be irrelevant by those 
running the working group.  (I was also a little surprised to see that that core 
of folk constitute working group rough consensus, for removing open items.)

As for the actual term "whitelisting" I suppose we should admire the boldness of 
the view that access to v6 is a priviledge -- note that that's the denotational 
perspective of the word whitelisting...


>         operator of a website, such as www.example.com, the operator
>         essentially applies an access control list (ACL) on the authoritative
>         DNS servers for the domain example.com. The ACL is populated with
>
>     An ACL usually is a yes/no mechanism. Here, however, the mechanism is for
>     asserting a preference for IPv6 over IPv4.
>
>     That does not seem to match the definition of ACL that I'm used to, unless the
>     semantic is defined as denying IPv4 access to the listed clients.
>
>     The term ACL is particularly odd to use if the mechanism pertains to responses
>     rather than queries.
>
>
> [JL] I am using 'ACL' in the most general possible sense and am open to
> alternative descriptors if you wish to suggest one. But most people seem to know
> an ACL is a list that, if you are listed on it, grants you access to some
> resource. In this case if the resolver is on the list then it gets AAAA RRs.

On reflection, the term is growing on me for this use.

"AAAA ACL" or "V6 DNS ACL" or "V6 resolver ACL" now seem to me quite good 
labels.  They provide useful, direct and precise meaning, while avoiding the 
various referential and denotational problems of a loaded term like whitelist.



> [JL] I took a stab at a new diagram in –04 — so take a look and let me know if
> it is what you are suggesting (I've left the original one in for now).

Took a quick look at the added diagram in the new draft.  The thing about a 
protocol timeline diagram is that it uses verticality to provide ordering.  So a 
response is lower down than a request. I don't get that from your Figure 2.

(By the way, your first sub-scenario, with Resolver 1, shows only a v4 response, 
without indicating whether the resolver sent a v6 or v4 query.  For the review, 
I think this distinction between transport and data -- "how is the 
query/response transported" vs. "what RRs are returned" -- was a continuing 
point of confusion for me. )


>         At least one highly-trafficked domain has noted that they have
>         received requests to not send DNS responses with AAAA resource
>         records to particular resolvers. In this case, the operators of
>
>
>     "At least one" seems a rather tiny statistic. Perhaps the actual statistic is
>     significantly larger?
>
>
> [JL] It does not seem to be. Other than this being passed along by Google, I've
> not heard of any similar stories. Nevertheless, it seemed interesting enough to
> include.

As an anecdote, it is perhaps interesting.  As a basis for promoting the entire 
effort, not so much.  I couldn't tell which role it was serving, but it felt 
like the latter.


>         network infrastructure is not yet ready to handle the large traffic
>         volume which may be associated with the hosts in their network
>         connecting to the websites of these domains. This concern is clearly
>
>
>     So even though the site allows v6 DNS queries to go out from a host, it can't
>     really support having the host use v6?
>
>
> [JL] A network isn't really in control of the end host's limitations w/r/t IPv6
> impairment. A good summary of the issue of impairment is @ http://www.fud.no/ipv6/

That sort of commentary, along with the citation, might be good to include, for 
clarification.


>         While in Section 1 the level of IPv6-related impairment has been
>         estimated to be as high as 0.078% of Internet users, which is a
>
>
>     8 hundredths of one percent?

I think that that's 8 of every 10,000 Internet users?


>     That's considered a high percentage?
>
>
> [JL] It is. I joked at one of the v6ops WG meetings awhile ago that at that
> rate, it'd be cheaper and easier for me (an ISP) to just buy new computers for
> the affected "impaired" users than to have to navigate years of whitelisting
> with a variety of domains. In any case, one recent measurement estimates it at
> 0.05% now and another at 0.015%. Despite this, this practice is still generating
> some interest. I'm hoping World IPv6 Day goes well and is informative for the
> community as to this percentage on a widespread basis, across a wide variety of
> web sites.
>
>
>     Even if it is 8%, is that considered high?
>
>
> [JL] 8% of the Internet finding google.com or facebook.com inaccessible would be
> bad for everyone. That could generate several hundred thousand support calls per
> day to a big ISP.

On reflection, I'm surprised to hear that IPv6 usage is up as high as 8 out of 
every 10,000 users, nevermind a large multiple of that.  (Although it does carry 
a backhanded note of encouragement about v6 adoption, I'm a bit suspicious of 
the statistic.)


>         troubleshooting standpoint. In this scenario, a DNS recursive
>         resolver operator will have no way to systematically determine
>         whether DNS whitelisting is or is not implemented for a domain, since
>         the absence of AAAA resource records may simply be indicative that
>         the domain has not yet added IPv6 addressing for the domain, rather
>         than that they have done so but have restricted query access via DNS
>
>
>     The premise is that, in large scale use, servers /will/ have a way to
>     systematically determine whether it is implemented? What are the existing
>     examples of having such a capability for other Internet protocols and services?
>
>
> [JL] Perhaps I'm overplaying this point, but you know someone has email service
> if they have an MX record for example, or a website if the host answers on
> TCP/80. But as I re-read this it is probably overkill and so I've deleted it. I
> have however moved some of the text to a prior section, since determining
> whether or not domains are whitelisting is still a challenge at scale.

Note that a site can have email service without an MX and that TCP:80 is not 
merely an "indicator" of web service, but actually /is/ the web service.

My point is that this idea of signaling/registering support of a service, as 
separate from actually providing the service, is not part of typical Internet 
service requirements and the simplification this provides is significant.  We 
need to be careful that we do not inadvertently teach folks that "signaling 
support" is an expected feature.

(And with this response, given that you already deleted the text, it's my turn 
to overplay a point...)



>         nature, not to mention physics. For example, as Sir Issac Newton
>         noted, "Every object in a state of uniform motion tends to remain in
>         that state of motion unless an external force is applied to it" [Laws
>
>
>     Code does not have momenum. Neither do configurations or lists. This really
>     isn't about physics.
>
>
> [JL] But people and processes do have (operational) momentum…

Indeed, and the process of dealing with the naming issue for this does seem to 
show that...


>     It is entirely about group psychology, as you note, and the administrative
>     challenges in the logistics of large-scale operational changes (which probably
>     /does/ have something to with physics, but it seems a stretch to credit Newton.
>     How about Heisenberg?...)
>
>
> [JL] Hmmm… I don't think it is Heisenberg-related. But it's such an interesting
> citation I feel it's almost a personal challenge to figure out a way to keep it
> in there. ;-)

How certain of it's being a challenge are you?  Does your certainty change as 
you think about it?


  The way I think about it is that in 5 or 10 years none of the
> people working on the details of the IPv6 transition now will still be involved
> in the day-to-day operational work. But DNS Whitelisting could still be in place
> – and once something gets a momentum to it (people, processes, and
> organizations) it is really, really hard to change that.

Well, I seriously applaud that concern, especially since its validity is proven 
every day (including in the IETF...)

On the average, I tend to believe that the best way to instruct folks later is 
by imparting information about tradeoffs and, especially, cost vs. benefit.

In the current case, the near-term cost/benefit makes some sense.

In the long term, the scaling cost of maintenance and the architectural cost of 
losing spontaneous interoperability strike me as pretty f'ing expensive.


>         8.3. Do Not Implement DNS Whitelisting
>
>         As an alternative to adopting DNS whitelisting, the Internet
>         community generally can choose to take no action whatsoever,
>         perpetuating the current predominant authoritative DNS operational
>         model on the Internet, and leave it up to end users with IPv6-related
>         impairments to discover and fix those impairments.
>
>
>     That is, place the burden of fixing a problem on those creating it?
>
>
> [JL] In a way. It gets back to the question you asked about what level of
> impairment justifies this practice. One obvious option is to let end users sort
> it out (presumably by consulting with their ISPs / network operators). This may
> be simpler and it's the way solutions to non-IPv6 problems tend to work today.

On the average, demanding that an end-user make an explicit decision about an 
operational tuning issue does not work very well.


d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From gert@space.net  Mon May 30 08:48: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 6A27CE07F4 for ; Mon, 30 May 2011 08:48: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 jjrP8HmGA8Ob for ; Mon, 30 May 2011 08:48:45 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.97.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7E5E07E5 for ; Mon, 30 May 2011 08:48:44 -0700 (PDT)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 3E3CEF81FE for ; Mon, 30 May 2011 17:48: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 226BAF81AE for ; Mon, 30 May 2011 17:48:41 +0200 (CEST)
Received: (qmail 19876 invoked by uid 1007); 30 May 2011 17:48:41 +0200
Date: Mon, 30 May 2011 17:48:41 +0200
From: Gert Doering 
To: dcrocker@bbiw.net
Message-ID: <20110530154841.GM45955@Space.Net>
References:  <4DE3B8FD.7040209@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4DE3B8FD.7040209@dcrocker.net>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "v6ops@ietf.org" , IETF Discussion , Apps Review 
Subject: Re: [v6ops] Review of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps	area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 30 May 2011 15:48:53 -0000

Hi,

On Mon, May 30, 2011 at 08:34:21AM -0700, Dave CROCKER wrote:
> "AAAA ACL" or "V6 DNS ACL" or "V6 resolver ACL" now seem to me quite good 
> labels.  They provide useful, direct and precise meaning, while avoiding the 
> various referential and denotational problems of a loaded term like whitelist.

I have no idea what a "v6 DNS ACL" should be, except maybe an ACL that
protects which IPv6 clients are allowed to talk to a DNS server.

Whitelisting, on the other hand, is the term that Google introduced for
this kind of "thing" and people seem to clearly understand what this 
is about.  "You are on my white list of people that I like talking to!".

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 cb.list6@gmail.com  Mon May 30 09:05: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 32294E07EF for ; Mon, 30 May 2011 09:05:11 -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 XdNk23lxjbhw for ; Mon, 30 May 2011 09:05:10 -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 3876BE07E0 for ; Mon, 30 May 2011 09:05:10 -0700 (PDT)
Received: by wyb29 with SMTP id 29so3208678wyb.31 for ; Mon, 30 May 2011 09:05:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pzGU1HAItGIKov0XUEOBHo4IN2QD4Ed1b8KBCj+XHO0=; b=r+a5qoGIK6kvrgkvjcMaksd5wN9fhpjXy90kp78HuiqykV5TNVo99C4w9yaLvV/vSF 9w9xj/9u+34wO9CR4B7C779tmSJdjzVdKIAjiLvjwLC65PCgrpWtoMHMHOd5qOO6Vi2b LwspF8ospjJuBIH3ybXHuzaZl44Y81vJGJ2QI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OSwe1lJ8+IYuszhAAO+8cWFUmXF1g7U3IRjOadWe96MBwVMgHv04lt0Cy2+sE/d4rB X6ODE5D7jhT2I8n3eDfPSA23rNb73SZi1dxmNgYZrwSYiJNqYXQawAeohggkr3InemJ/ srwOXDvpIEl6W/lzn3nAo4OG19lVe61lTUEtM=
MIME-Version: 1.0
Received: by 10.216.65.203 with SMTP id f53mr2888322wed.54.1306771509295; Mon, 30 May 2011 09:05:09 -0700 (PDT)
Received: by 10.216.179.199 with HTTP; Mon, 30 May 2011 09:05:09 -0700 (PDT)
Received: by 10.216.179.199 with HTTP; Mon, 30 May 2011 09:05:09 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 30 May 2011 09:05:09 -0700
Message-ID: 
From: Cameron Byrne 
To: "Livingood, Jason" 
Content-Type: multipart/alternative; boundary=000e0ce0b4ea9d393c04a4807357
Cc: "J.D. Falk" , "v6ops@ietf.org" 
Subject: Re: [v6ops] Issue 2: draft-ietf-v6ops-v6-aaaa-whitelisting-implications
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 30 May 2011 16:05:11 -0000

--000e0ce0b4ea9d393c04a4807357
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On May 30, 2011 6:59 AM, "Livingood, Jason" <
Jason_Livingood@cable.comcast.com> wrote:
>
> Seeking WG guidance to close open issues.
>
> From Appendix B:
> 2. JD Falk question - should I add a sub-section to 9 to explain how best
to implement if you did it? (transparent/published policies, SLA on decisio=
n
making,etc.)
>
> Proposed direction (please comment if you disagree):
> This is sort of 'best practices' or 'recommended practices' for
Whitelisting. I think this was raised in a WG meeting two IETFs ago and the
direction was to not include that as it could be an entirely separate
document later on =97 and once the practice had more time in deployment. I'=
d
like to close this out and not include these new sections. The WG can alway=
s
decide such a new document is useful later.
>

Agreed. Separate document.

Cb

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

--000e0ce0b4ea9d393c04a4807357
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




On May 30, 2011 6:59 AM, "Livingood, Jason" <Jason_Livingood@cable.comcast.com&g=
t; wrote:

>

> Seeking WG guidance to close open issues.

>

> From Appendix B:

> 2. JD Falk question - should I add a sub-section to 9 to explain how b=
est to implement if you did it? (transparent/published policies, SLA on dec=
ision making,etc.)

>

> Proposed direction (please comment if you disagree):=A0

> This is sort of 'best practices' or 'recommended practices=
' for Whitelisting. I think this was raised in a WG meeting two IETFs a=
go and the direction was to not include that as it could be an entirely sep=
arate document later on =97 and once the practice had more time in deployme=
nt. I'd like to close this out and not include these new sections. The =
WG can always decide such a new document is useful later.


>


Agreed. Separate document.


Cb


> Jason

>

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

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

>




--000e0ce0b4ea9d393c04a4807357--

From v6ops@globis.net  Mon May 30 09:29: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 6D56BE06E6 for ; Mon, 30 May 2011 09:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.24
X-Spam-Level: 
X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=-0.242,  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 ffWmPIHBvlQC for ; Mon, 30 May 2011 09:29:11 -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 B232CE0678 for ; Mon, 30 May 2011 09:29:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 490958700EF; Mon, 30 May 2011 18:29:08 +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 WGhIbyC2i77m; Mon, 30 May 2011 18:29:03 +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 A47828700B2; Mon, 30 May 2011 18:29:03 +0200 (CEST)
Message-ID: <4DE3C5CF.9070504@globis.net>
Date: Mon, 30 May 2011 18:29:03 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: "Livingood, Jason" ,  "v6ops@ietf.org WG" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070407060803030707040705"
Subject: Re: [v6ops] Issue 3: draft-ietf-v6ops-v6-aaaa-whitelisting-implications
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 30 May 2011 16:29:12 -0000

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

As the original maker of the comment, I expressly agree to close the 
issue exactly as you propose.

Livingood, Jason wrote:
> Seeking WG guidance to close open issues.
>
> From Appendix B:
> 3. Per Ray Hunter - "Which is why my original posting suggested that 
> the WG might wish to express a concern about anyone making assumptions 
> about any undocumented architectural links between DNS and transport, 
> and also suggest that operators of aaaa whitelists (party X) should 
> disclose their aaaa methodology and data, and that they should not 
> share whitelist data with other aaaa operators in an uncontrolled 
> manner, so that at least Party Y could see what was happening and why, 
> and also have a chance of correcting it."
>
> Proposed direction (please comment if you disagree):
> Some of this should now be addressed in Section 7.3.1 (De-Whitelisting 
> May Occur). Other aspects of this are similar to the feedback from 
> J.D. Falk. As such, this relates to 'recommended practices' for 
> Whitelisting. I think this was raised in a WG meeting two IETFs ago 
> and the direction was to not include that as it could be an entirely 
> separate document later on — and once the practice had more time in 
> deployment. I'd like to close this out and not include these new 
> sections (also noting some of the question is addressed in 7.3.1). The 
> WG can always decide such a new document is useful later.
>
> Jason
>
> _______________________________________________ v6ops mailing list 
> v6ops@ietf.org  
> https://www.ietf.org/mailman/listinfo/v6ops


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




  


As the original maker of the comment, I expressly agree to close the
issue exactly as you propose.



Livingood, Jason wrote:


  
  

  

  

  
Seeking WG guidance to close open issues.

  


  

  
From Appendix B:

  
3. Per Ray Hunter - "Which is why my original posting suggested
that the WG might wish to express a concern about anyone making
assumptions about any undocumented architectural links between DNS and
transport, and also suggest that operators of aaaa whitelists (party X)
should disclose their aaaa methodology and data, and that they should
not share whitelist data with other aaaa operators in an uncontrolled
manner, so that at least Party Y could see what was happening and why,
and also have a chance of correcting it."

  


  

  
Proposed direction (please comment if you disagree): 

  
Some of this should now be addressed in Section 7.3.1
(De-Whitelisting May Occur). Other aspects of this are similar to the
feedback from J.D. Falk. As such, this relates to 'recommended
practices' for Whitelisting. I think this was raised in a WG meeting
two IETFs ago and the direction was to not include that as it could be
an entirely separate document later on — and once the practice had more
time in deployment. I'd like to close this out and not include these
new sections (also noting some of the question is addressed in 7.3.1).
The WG can always decide such a new document is useful later. 

  


  

  
Jason

  


  

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

  

  








--------------070407060803030707040705--

From lorenzo@google.com  Mon May 30 23:10: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 DB00EE0700 for ; Mon, 30 May 2011 23:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 ggOj60UO+k9L for ; Mon, 30 May 2011 23: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 0E457E06D4 for ; Mon, 30 May 2011 23:10: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 p4V6A8bg029774 for ; Mon, 30 May 2011 23:10:08 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306822209; bh=QNZSFlli55cjrPwL/x+BDCJjVdA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GSFWZU2L+BFEfylUuWctiIJ6JoTwAKJfISGNxLLI4pSmsQ3L9Ncdu7n/yNk01T5lH 2xqPB41oPjM6qC6HUjJug==
Received: from yxe1 (yxe1.prod.google.com [10.190.2.1]) by kpbe11.cbf.corp.google.com with ESMTP id p4V6A1f3024829 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 30 May 2011 23:10:07 -0700
Received: by yxe1 with SMTP id 1so2481904yxe.25 for ; Mon, 30 May 2011 23:10:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oyVX/gc61gBxzLHbPQFgEUSGslTK7g062bfu2SI8XK4=; b=ZOP3zSYuKeDuyHHZ2E6o4X9HG4B+RBBdoqVmyqY7v8IWG2kpDHyo2qy0ryQua2CqTr uCup36Dtbgtse/48u6aw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=NqgAyJ3EivTsdT7Lk4wYxvzFVLaqxR2cLLks+kGbHH06sVx9cy1/0U0AXgijs59MiI 29LRm93Pj4bLkuSdJDDw==
Received: by 10.150.7.15 with SMTP id 15mr4510149ybg.378.1306822207110; Mon, 30 May 2011 23:10:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Mon, 30 May 2011 23:09:47 -0700 (PDT)
In-Reply-To: <20110530154841.GM45955@Space.Net>
References:  <4DE3B8FD.7040209@dcrocker.net> <20110530154841.GM45955@Space.Net>
From: Lorenzo Colitti 
Date: Mon, 30 May 2011 23:09:47 -0700
Message-ID: 
To: Gert Doering 
Content-Type: multipart/alternative; boundary=000e0cd2878870809c04a48c4132
X-System-Of-Record: true
Cc: "v6ops@ietf.org" , Apps Review , Dave Crocker , IETF Discussion 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 31 May 2011 06:10:11 -0000

--000e0cd2878870809c04a48c4132
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 30, 2011 at 8:48 AM, Gert Doering  wrote:

> I have no idea what a "v6 DNS ACL" should be, except maybe an ACL that
> protects which IPv6 clients are allowed to talk to a DNS server.
>

ACL is the wrong term. Saying it's an ACL makes it easy to make the argument
that whoever is implementing this is denying access to a particular resource
(the AAAA record).

In fact, the opposite is true - by electing not to return an AAAA record,
the implementer is able to allow access to a particular resource (the
content that the user wants to reach) instead of publishing the resource
over IPv6 where some users can't usefully reach it.

Which is of course, the root of the problem here. It is the reason why many
large website operators have either implemented whitelisting (Google,
Facebook) or have announced that they will be implementing whitelisting
(Yahoo, Akamai). And it is the reason why said website operators are not
contributing to this document.

--000e0cd2878870809c04a48c4132
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, May 30, 2011 at 8:48 AM, Gert Doering <gert@space.net>=
; wrote:


I have no idea what a "v6 DNS ACL" should be, except maybe an ACL=
 that

protects which IPv6 clients are allowed to talk to a DNS server.

ACL is the wrong term.=A0Saying it's an ACL m=
akes it easy to make the argument that whoever is implementing this is deny=
ing access to a particular resource (the AAAA record).




In fact, the opposite is true - by electing not to retu=
rn an AAAA record, the implementer is able to allow access to a particular =
resource (the content that the user wants to reach) instead of publishing t=
he resource over IPv6 where some users can't usefully reach it.




Which is of course, the root of the problem here. It is=
 the reason why many large website operators=A0have either implemented whit=
elisting (Google, Facebook) or have announced that they will be implementin=
g whitelisting (Yahoo, Akamai). And it is the reason why said website opera=
tors are not contributing to this document.





--000e0cd2878870809c04a48c4132--

From joelja@bogus.com  Mon May 30 23:21: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 11AACE06D4; Mon, 30 May 2011 23:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.682
X-Spam-Level: 
X-Spam-Status: No, score=-101.682 tagged_above=-999 required=5 tests=[AWL=0.316, 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 xEwwMb1+HQHt; Mon, 30 May 2011 23:21:05 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E43EBE06BE; Mon, 30 May 2011 23:21:04 -0700 (PDT)
Received: from wifi-216-59.mtg.afnog.org ([196.200.216.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p4V6KIDA010617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 May 2011 06:20:38 GMT (envelope-from joelja@bogus.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-4--49386231
From: Joel Jaeggli 
In-Reply-To: 
Date: Mon, 30 May 2011 23:20:11 -0700
Message-Id: <7006BAA9-E515-42E7-85E2-06E1263CAD0E@bogus.com>
References:  <4DE3B8FD.7040209@dcrocker.net> <20110530154841.GM45955@Space.Net> 
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 [147.28.0.81]); Tue, 31 May 2011 06:20:53 +0000 (UTC)
Cc: IETF Discussion , "v6ops@ietf.org" , Dave Crocker , Apps Review 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 31 May 2011 06:21:06 -0000

--Apple-Mail-4--49386231
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On May 30, 2011, at 11:09 PM, Lorenzo Colitti wrote:

> On Mon, May 30, 2011 at 8:48 AM, Gert Doering  wrote:
> I have no idea what a "v6 DNS ACL" should be, except maybe an ACL that
> protects which IPv6 clients are allowed to talk to a DNS server.
>=20
> ACL is the wrong term. Saying it's an ACL makes it easy to make the =
argument that whoever is implementing this is denying access to a =
particular resource (the AAAA record).
>=20
> In fact, the opposite is true - by electing not to return an AAAA =
record, the implementer is able to allow access to a particular resource =
(the content that the user wants to reach) instead of publishing the =
resource over IPv6 where some users can't usefully reach it.
>=20
> Which is of course, the root of the problem here. It is the reason why =
many large website operators have either implemented whitelisting =
(Google, Facebook) or have announced that they will be implementing =
whitelisting (Yahoo, Akamai). And it is the reason why said website =
operators are not contributing to this document.

But you've contributed to this document, so have others from that list.

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


--Apple-Mail-4--49386231
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


On May 30, 2011, at 11:09 PM, Lorenzo Colitti wrote:

On Mon, May 30, 2011 at 8:48 AM, Gert Doering <gert@space.net> wrote:


I have no idea what a "v6 DNS ACL" should be, except maybe an ACL that

protects which IPv6 clients are allowed to talk to a DNS server.

ACL is the wrong term. Saying it's an ACL makes it easy to make the argument that whoever is implementing this is denying access to a particular resource (the AAAA record).




In fact, the opposite is true - by electing not to return an AAAA record, the implementer is able to allow access to a particular resource (the content that the user wants to reach) instead of publishing the resource over IPv6 where some users can't usefully reach it.




Which is of course, the root of the problem here. It is the reason why many large website operators have either implemented whitelisting (Google, Facebook) or have announced that they will be implementing whitelisting (Yahoo, Akamai). And it is the reason why said website operators are not contributing to this document.






But you've contributed to this document, so have others from that list.

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


--Apple-Mail-4--49386231--

From lorenzo@google.com  Mon May 30 23:48: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 0D7D3E07D8 for ; Mon, 30 May 2011 23:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 SRHlZFBAQF7B for ; Mon, 30 May 2011 23:48:27 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4B0E07BD for ; Mon, 30 May 2011 23:48:27 -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 p4V6mQQm003953 for ; Mon, 30 May 2011 23:48:26 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306824506; bh=FrzuBnQOmnqgYtanwRJny9rAWyA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=gUGFYFjesN3C8KOGpt3fNOztLRWlet55YBzY8mgKmMFG4UrtYBZu1Qi+Gx10ojHBX PaGmhbjc6GPLJf7lHMY1A==
Received: from gxk27 (gxk27.prod.google.com [10.202.11.27]) by wpaz9.hot.corp.google.com with ESMTP id p4V6mP8k014253 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 30 May 2011 23:48:25 -0700
Received: by gxk27 with SMTP id 27so2314831gxk.15 for ; Mon, 30 May 2011 23:48:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MhH8+2cFafGleUo/wv6dxT+9tWBqPoMXgBW3PhkPITw=; b=M5Ob57nm9DGFHmQ9QEI5wMoblW2QjZr9DtOTG8154qYSEfhAHIFKep+TzCFqyQTwuA OO5izU6OLzZz/KiJP+1A==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=iPDKcWdPjEh2O0wp/mzj/mF+ntEcs6ZMi/qIpIMbgbiM9Be6RIM3fc0Ijhw+YPpLUn w5ymAJbedRbKrtH5cU/w==
Received: by 10.150.113.20 with SMTP id l20mr4609357ybc.36.1306824505169; Mon, 30 May 2011 23:48:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Mon, 30 May 2011 23:48:04 -0700 (PDT)
In-Reply-To: <7006BAA9-E515-42E7-85E2-06E1263CAD0E@bogus.com>
References:  <4DE3B8FD.7040209@dcrocker.net> <20110530154841.GM45955@Space.Net>  <7006BAA9-E515-42E7-85E2-06E1263CAD0E@bogus.com>
From: Lorenzo Colitti 
Date: Mon, 30 May 2011 23:48:04 -0700
Message-ID: 
To: Joel Jaeggli 
Content-Type: multipart/alternative; boundary=000e0cd568306a19da04a48cca65
X-System-Of-Record: true
Cc: IETF Discussion , "v6ops@ietf.org" , Dave Crocker , Apps Review 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 31 May 2011 06:48:28 -0000

--000e0cd568306a19da04a48cca65
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli  wrote:

> But you've contributed to this document, so have others from that list.
>

I don't want to contribute to the document because - in my opinion, and
speaking only for myself - I don't think it can be made into a balanced
assessment of the issue without major changes.

Since a) I don't have even a fraction of the time I would need to actually
contribute said changes, b) the document is already in an advanced state of
the IETF process, and c) it doesn't matter so much what the document ends up
saying, because most of the organizations for whom this is an issue have
already looked at the data and recognized that they have no alternative, I
was simply steering clear of the document entirely.

It's true that I have pointed out things I think are incorrect. But I did
not view these as contributions, more as offering occasional token
opposition lest silence be interpreted as assent. :-) But perhaps you're
right and I should not comment on it at all.

Cheers,
Lorenzo

--000e0cd568306a19da04a48cca65
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli <=
span dir=3D"ltr"><joelja@bogus.com> wrote:



But you've contributed to=
 this document, so have others from that list.



I don't want to contribute to the document because - in my opinion, and=
 speaking only for myself - I don't think it can be made into a balance=
d assessment of the issue without major changes.



Since a) I don't have even a fraction of the time I would need to actua=
lly contribute said changes, b) the document is already in an advanced stat=
e of the IETF process, and c) it doesn't matter so much what the docume=
nt ends up saying,=A0because most of the organizations for whom this is an =
issue have already looked at the data and recognized that they have no alte=
rnative, I was simply steering clear of the document entirely.




It's true that I have pointed out things I think ar=
e incorrect. But I did not view these as contributions, more as offering oc=
casional token opposition lest silence be interpreted as assent. :-) But pe=
rhaps you're right and I should not comment on it at all.




Cheers,
Lorenzo


--000e0cd568306a19da04a48cca65--

From joelja@bogus.com  Tue May 31 00:00: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 3DD9EE07BD; Tue, 31 May 2011 00:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.088
X-Spam-Level: 
X-Spam-Status: No, score=-102.088 tagged_above=-999 required=5 tests=[AWL=0.510, 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 0MnKzUIu4+iS; Tue, 31 May 2011 00:00:48 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2B370E0798; Tue, 31 May 2011 00:00:47 -0700 (PDT)
Received: from wifi-216-59.mtg.afnog.org ([196.200.216.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p4V70NGI011412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 May 2011 07:00:31 GMT (envelope-from joelja@bogus.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-6--46976651
From: Joel Jaeggli 
In-Reply-To: 
Date: Tue, 31 May 2011 00:00:21 -0700
Message-Id: 
References:  <4DE3B8FD.7040209@dcrocker.net> <20110530154841.GM45955@Space.Net>  <7006BAA9-E515-42E7-85E2-06E1263CAD0E@bogus.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 [147.28.0.81]); Tue, 31 May 2011 07:00:38 +0000 (UTC)
Cc: IETF Discussion , "v6ops@ietf.org" , Dave Crocker , Apps Review 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 31 May 2011 07:00:49 -0000

--Apple-Mail-6--46976651
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On May 30, 2011, at 11:48 PM, Lorenzo Colitti wrote:

> On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli  =
wrote:
> But you've contributed to this document, so have others from that =
list.
>=20
> I don't want to contribute to the document because - in my opinion, =
and speaking only for myself - I don't think it can be made into a =
balanced assessment of the issue without major changes.

I do things that the ietf says are a bad idea all the time, I take the =
concerns expressed in informational documents that I've read =
under-advisement when I do so.

> Since a) I don't have even a fraction of the time I would need to =
actually contribute said changes, b) the document is already in an =
advanced state of the IETF process, and c) it doesn't matter so much =
what the document ends up saying, because most of the organizations for =
whom this is an issue have already looked at the data and recognized =
that they have no alternative, I was simply steering clear of the =
document entirely.
>=20
> It's true that I have pointed out things I think are incorrect. But I =
did not view these as contributions, more as offering occasional token =
opposition lest silence be interpreted as assent. :-) But perhaps you're =
right and I should not comment on it at all.
>=20
> Cheers,
> Lorenzo


--Apple-Mail-6--46976651
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


On May 30, 2011, at 11:48 PM, Lorenzo Colitti wrote:

On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli <joelja@bogus.com> wrote:



But you've contributed to this document, so have others from that list.



I don't want to contribute to the document because - in my opinion, and speaking only for myself - I don't think it can be made into a balanced assessment of the issue without major changes.

I do things that the ietf says are a bad idea all the time, I take the concerns expressed in informational documents that I've read under-advisement when I do so.



Since a) I don't have even a fraction of the time I would need to actually contribute said changes, b) the document is already in an advanced state of the IETF process, and c) it doesn't matter so much what the document ends up saying, because most of the organizations for whom this is an issue have already looked at the data and recognized that they have no alternative, I was simply steering clear of the document entirely.




It's true that I have pointed out things I think are incorrect. But I did not view these as contributions, more as offering occasional token opposition lest silence be interpreted as assent. :-) But perhaps you're right and I should not comment on it at all.




Cheers,
Lorenzo




--Apple-Mail-6--46976651--

From cancanhuang110@gmail.com  Tue May 31 00:27: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 5EA58E0742 for ; Tue, 31 May 2011 00:27:28 -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 PRm1YtLY+DY4 for ; Tue, 31 May 2011 00:27:27 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38C20E077E for ; Tue, 31 May 2011 00:27:27 -0700 (PDT)
Received: by fxm15 with SMTP id 15so3230579fxm.31 for ; Tue, 31 May 2011 00:27:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=b9ibDx/6eo/mp/IsnYMX/0Y+7BeLMkRfYe3ffqiiHjA=; b=JcOq4j4GVYv0i1yrfOXC+QNJBrPNrMBTZ0jmhdB2jmoBZlP4GS/ifkSlfJlF/srKqA OOlJSAXqW4b1tVby/MJKTVtsYZwlpRKJ+zkKM8HSPZakhTYRciEZMK0aHzhPRJjxOSy2 unCLTccxthu95aO5yV8oTH9aavmTkridSODs0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Cv/9UID0erH//jW8HcZIRRGNs4srE1qDgMZ2GeG0qb82CkIbbtaO+xmIW3aF6wv0Qh R8Y6cayi+noWfW8hz12TF2VkwLQJVLndEr4103a4gwvDvtNdcXPhOLSXIT2l09jhYcWW +Kum0oJC4O4ErnRMEu94zXlU1FqdVFXghhfdc=
MIME-Version: 1.0
Received: by 10.223.23.143 with SMTP id r15mr2001453fab.29.1306826846304; Tue, 31 May 2011 00:27:26 -0700 (PDT)
Received: by 10.223.126.144 with HTTP; Tue, 31 May 2011 00:27:26 -0700 (PDT)
In-Reply-To: <449804.6587.qm@web111416.mail.gq1.yahoo.com>
References: <449804.6587.qm@web111416.mail.gq1.yahoo.com>
Date: Tue, 31 May 2011 15:27:26 +0800
Message-ID: 
From: huang cancan 
To: Behcet Sarikaya 
Content-Type: multipart/alternative; boundary=00151747b53cf4fbb404a48d55a5
Cc: IPv6 Operations 
Subject: Re: [v6ops] New Version Notification for draft-sarikaya-v6ops-prefix-delegation-05.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, 31 May 2011 07:27:28 -0000

--00151747b53cf4fbb404a48d55a5
Content-Type: text/plain; charset=ISO-8859-1

 I have briefly read your draft.I think it is well written and much better
than the former version.


On Fri, May 27, 2011 at 12:59 AM, Behcet Sarikaya
wrote:

>
>
> >
>
> > A new version of I-D, draft-sarikaya-v6ops-prefix-delegation-05.txt has
> been
> >successfully submitted by Behcet Sarikaya and posted to the IETF
>  repository.
> >
> > Filename:      draft-sarikaya-v6ops-prefix-delegation
> > Revision:      05
> > Title:         DHCPv6 Prefix Delegation as  IPv6 Migration Tool in Mobile
> >Networks
> > Creation date:      2011-05-26
> > WG ID:         Individual  Submission
> > Number of pages: 12
> >
> > Abstract:
> >    As interest on  IPv6 deployment is increasing in cellular networks
> >    several migration  issues are being raised and IPv6 prefix management
> >    is the one  addressed in this document.  Based on the idea that DHCPv6
> >     servers can manage prefixes, we address prefix management issues such
> >     as the access router offloading delegation and release tasks of the
> >     prefixes to a DHCPv6 server using DHCPv6 PD.  The access router
>  first
> >    requests a prefix for an incoming mobile node from the DHCPv6  server.
> >    The access router may next stateless or stateful address  allocation
> >    to the mobile node, e.g. with a Router Advertisement or  using DHCP.
> >    We also describe prefix management using Authentication  Authorization
> >    and Accounting servers.
> >
> >
> >
> >
> >
> >
> > The IETF Secretariat
> >
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--00151747b53cf4fbb404a48d55a5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


=A0I have briefly read your draft.I think it is well written and much =
better than the former version.



=A0


On Fri, May 27, 2011 at 12:59 AM, Behcet Sarikay=
a <behcets=
arikaya@yahoo.com> wrote:




>

> A new v=
ersion of I-D, draft-sarikaya-v6ops-prefix-delegation-05.txt has been
&g=
t;successfully submitted by Behcet Sarikaya and posted to the IETF =A0repos=
itory.

>
> Filename: =A0 =A0 =A0draft-sarikaya-v6ops-prefix-delegation> Revision: =A0 =A0 =A005
> Title: =A0 =A0 =A0 =A0 DHCPv6 Prefix =
Delegation as =A0IPv6 Migration Tool in Mobile
>Networks
> Crea=
tion date: =A0 =A0 =A02011-05-26

> WG ID: =A0 =A0 =A0 =A0 Individual =A0Submission
> Number of page=
s: 12
>
> Abstract:
> =A0 =A0As interest on =A0IPv6 deplo=
yment is increasing in cellular networks
> =A0 =A0several migration =
=A0issues are being raised and IPv6 prefix management

> =A0 =A0is the one =A0addressed in this document. =A0Based on the idea =
that DHCPv6
> =A0 =A0 servers can manage prefixes, we address prefix =
management issues such
> =A0 =A0 as the access router offloading dele=
gation and release tasks of the

> =A0 =A0 prefixes to a DHCPv6 server using DHCPv6 PD. =A0The access rou=
ter =A0first
> =A0 =A0requests a prefix for an incoming mobile node f=
rom the DHCPv6 =A0server.
> =A0 =A0The access router may next statele=
ss or stateful address =A0allocation

> =A0 =A0to the mobile node, e.g. with a Router Advertisement or =A0usin=
g DHCP.
> =A0 =A0We also describe prefix management using Authenticat=
ion =A0Authorization
> =A0 =A0and Accounting servers.
>
>=

>

>
>
>
> The IETF Secretariat
>
______________=
_________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinf=
o/v6ops





--00151747b53cf4fbb404a48d55a5--

From jason_livingood@cable.comcast.com  Tue May 31 06:23: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 5B489E07B2; Tue, 31 May 2011 06:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.28
X-Spam-Level: 
X-Spam-Status: No, score=-108.28 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 5hVVgIrZ+Mww; Tue, 31 May 2011 06:23: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 97FC1E0850; Tue, 31 May 2011 06:22:31 -0700 (PDT)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128628846; Tue, 31 May 2011 09:17:02 -0400
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Tue, 31 May 2011 09:17:02 -0400
From: "Livingood, Jason" 
To: Lorenzo Colitti , Joel Jaeggli 
Thread-Topic: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
Thread-Index: AQHMH17K/TZcHaXuhE61OwYpuBgohJSm60kA
Date: Tue, 31 May 2011 13:17:00 +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.10.0.110310
x-originating-ip: [24.40.55.72]
Content-Type: multipart/alternative; boundary="_000_CA0A60E828C51jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , Apps Review , IETF Discussion , Dave Crocker 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 31 May 2011 13:23:05 -0000

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

On 5/31/11 2:48 AM, "Lorenzo Colitti" > wrote:

On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli > wrote:
But you've contributed to this document, so have others from that list.

I don't want to contribute to the document

While you have not contributed text per se (by sending it directly), I try =
to be a good listener and items you and other Googlers have raised have bee=
n included in the document around motivations and so on. Even new Sections =
3.2 and 3.2 were added based on listening to you and/or your colleagues tal=
k about the issue (and some direct conversations a couple of weeks ago).

In any case, I appreciate your feedback and opinions. At the end of the day=
 it is only an informational I-D, and not a standard or BCP, so maybe not s=
uch a big deal.

Regards
Jason

--_000_CA0A60E828C51jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <953917ACD40B9D44A7C530ED48F84EB4@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable











On 5/31/11 2:48 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:














On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli <=
span dir=3D"ltr">
<joelja@bogus.com> wro=
te:








But you've contributed to this document, so have others from that list=
.













I don't want to contribute to the document












While you have not contributed text per se (by sending it directly), I=
 try to be a good listener and items you and other Googlers have raised hav=
e been included in the document around motivations and so on. Even new Sect=
ions 3.2 and 3.2 were added based
 on listening to you and/or your colleagues talk about the issue (and some =
direct conversations a couple of weeks ago). 







In any case, I appreciate your feedback and opinions. At the end of th=
e day it is only an informational I-D, and not a standard or BCP, so maybe =
not such a big deal. 







Regards


Jason




--_000_CA0A60E828C51jasonlivingoodcablecomcastcom_--

From fbrockne@cisco.com  Tue May 31 08:09: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 8949EE07EB for ; Tue, 31 May 2011 08:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.699
X-Spam-Level: 
X-Spam-Status: No, score=-7.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_PAIN=2.3, 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 9BfzLI4JKVzN for ; Tue, 31 May 2011 08:09:33 -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 B3AF0E0854 for ; Tue, 31 May 2011 08:09:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fbrockne@cisco.com; l=9563; q=dns/txt; s=iport; t=1306854572; x=1308064172; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=asAWeZ1RgSfEL3+MidJ0s5J4/QdJhgzzgdGA1x//wKg=; b=ce+bsrUbP04aqB+d446SLLF8xf2ytKMxn0O9o0u2gsxd/zSBqWiREamu LFtGP4MbPMxdw5SzQA6t0K+s6VzaMWzfnrKxn1IZX397c5Mzc+ZPebTnG T7i59aVn/p7TAHHHmAUUYUMuUix+JYddjPrk2KbJmURZ3icp4IEmSmnZH c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgYBAOMD5U2Q/khN/2dsb2JhbABTl0uOUneoVJ1Yhh4EhByQeopV
X-IronPort-AV: E=Sophos;i="4.65,297,1304294400"; d="scan'208";a="91592541"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 31 May 2011 15:09:31 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4VF9V2K024333; Tue, 31 May 2011 15:09:31 GMT
Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 31 May 2011 17:09:31 +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: Tue, 31 May 2011 17:09:27 +0200
Message-ID: <0D212BD466921646B58854FB79092CEC05D11D7B@XMB-AMS-106.cisco.com>
In-Reply-To: <4CF04D93-43FC-4D44-B3AD-D16E7F480593@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-01
Thread-Index: Acwat+WpKkM6MQ+9SmuqNQXf4VHxTwE6yC/A
References: <7B661D1F-F127-45A8-B3E1-DDA6ED10AD35@cisco.com><9EFA85B3-43E6-441B-82B6-2C19084F5B39@apple.com> <4CF04D93-43FC-4D44-B3AD-D16E7F480593@gmail.com>
From: "Frank Brockners (fbrockne)" 
To: "jouni korhonen" , "james woodyatt" 
X-OriginalArrivalTime: 31 May 2011 15:09:31.0522 (UTC) FILETIME=[BE54AE20:01CC1FA4]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-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, 31 May 2011 15:09:39 -0000

Even though a little too late, here are a few additional comments on
I-D.ietf-v6ops-3gpp-eps-01.=20

-- Section 6.2

* The section uses the term "S4-SGSN": Might be useful to briefly
explain what a S4-SGSN is (or cover it as part of the glossary).

-- Section 6.3

* Step 6: Might be useful to point out that the UE would ignore any
prefix received in PCO in an access accept as part of the PDP
establishment procedure (or directly refer to 3GPP 29.061:  "The Attach
Accept message will be sent along to the UE without the IPv6 prefix.",
"The UE shall ignore the IPv6 prefix if it receives one in the
message.")

-- Section 6.4

The current text states=20
"If a network knows a mobile may do handovers between Release-8
 and pre-Release-8 networks (segment), network will only provide
 single stack bearers, even if the mobile host requests dual-stack
 bearers.  This can happen e.g. if an operator is using pre-
 Release-8 SGSNs in some parts of the network."

Shouldn't this be "Rel-9 SGSNs"?

-- Section 8.5

Similar to the comment above, the text references pre-Release-8
networks. Would it make sense to differentiate things a bit further
in the text - highlighting the fact (which the I-D already states
elsewhere), that v4v6 support only comes with Rel-9 for the SGSN?
Right now the reader might things a bit

This is the text I was referring to:=20

"First, the visited network (S4-)SGSN does not=20
 support the IPv6 PDP Context or
 IPv4v6 PDP Context types.  These should mostly concern pre-Release-8
 networks but there is no definitive rule as the deployed feature sets
 vary depending on implementations and licenses. "

-- Section 8.7

The text states: "If for some reason a SGSN does not understand the
requested PDP Type,
   then the PDP Type is handled as IPv4."

While this is "common understanding" it might make sense to point out
that 3GPP 24.008 is a bit ambiguous here. Other 3GPP docs, e.g.
23.975 handle this with a note. E.g.
"Note: The 3GPP specification TS 24.008 is not entirely unambiguous on
the treatment of unknown PDP types.=20
Even if the information element coding for "PDP type" specifies that a
request for an "unknown PDP=20
type" shall be treated as if it were a request for PDP type v4, the
error signalling elsewhere in the=20
specification include the possibility to signal an error code "unknown
PDP address or PDP type".

Should we include something similar here?


A few nits that I found while reading:

--- section 8.7:

 s/respone/response

--- section 6.4:

"If a network knows a mobile will not be able to do handover to
       pre-Release-8 network (segment), it will provide mobile with
       dual-stack bearers on request"

 s/provide mobile/provide the mobile

-- section 8.6

heading: s/rat/RAT

Regards, Frank

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of jouni korhonen
> Sent: Wednesday, May 25, 2011 10:43 AM
> To: james woodyatt
> Cc: v6ops@ietf.org WG
> Subject: Re: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-01
>=20
> James,
>=20
> Thanks for the review. Really appreciated! See my initial comments
> inline.
>=20
> On May 23, 2011, at 9:45 PM, james woodyatt wrote:
>=20
> > On May 22, 2011, at 11:00 , Fred Baker wrote:
> >>
> >> The working group last call for this draft announced last week
> continues for another week. Please feel free to comment on it.
> >
> > I am in the target audience for this document, so my contributions
> will seem more critical than constructive and predominantly editorial
> in nature, mainly because I'm not confident that my knowledge of 3GPP
> protocols and technologies is complete.
> >
> > Please do not interpret my criticisms as opposition to this draft.
I
> very much want to see a document with this information published in
the
> RFC series.
> >
> > ----
> >
> > p1. The abstract seems overly verbose.  Here is a proposed rewrite:
> >
> >   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.
>=20
> Looks OK to me.
>=20
>=20
> >
> > p2. This sentence needs updating:
> >
> >   However, the support for IPv6
> >   in commercially deployed networks by the end of 2010 is nearly
non-
> >   existent.
>=20
> Yes. Cameron also pointed this out.
>=20
>=20
> >
> > p3. In section 2.1, Terminology, I think it would help if the
> abbreviations were all collected into one table and expanded once in
> each glossary subsection entry and in each top level section where
they
> are used.  The terms in the glossary subsection should be headed by
> expanded abbreviations, and they should be presented in alphabetical
> order.
>=20
> Hmm.. OK to collect all abbreviations. Do you mean that each of these
> current entries in the terminology section would become a subsection
of
> their own?
>=20
> >
> > p4. In section 2.1, Terminology, the definition of "Packet Data
> Network" introduces what seems to be a specialized term, 'packet
domain
> network,' that goes undefined in this section.  Please clarify.
>=20
> s/domain/core
>=20
> Good catch. Packet core network means the operator internal network.
>=20
>=20
> >
> > p5. In section 2.1, Terminology, the definition of "Policy and
> Charging Control (PCC) framework" explains that it's used for QoS
> policy, which I think I might understand, but also for 'charging
> control' which is never defined.  It also doesn't appear to be
> inferable from context in the draft.  The dependent clause "but needed
> if dynamic policy and charging control by means of PCC rules based on
> user and services are desired" is therefore really not much use.
> Please clarify.
>=20
> Ok. But I do not want to go into too much details.. PCC is a beast of
> its own.. brrr..
>=20
> >
> > p6. In section 2.1, Terminology, the term "evolved packet core" is
> introduced and used in the document, but never defined.  Please
> clarify.
>=20
> Oops :) Will add it.
>=20
> >
> > p7. I think section 2.2, The concept of APN, might more properly
> belong in section 3 [but I'm not sure].  If it really belongs in
> section 2, because it describes an architecture independent of the
> Internet Protocol, then perhaps this should be explicitly mentioned
> here.
>=20
> I have no strong opinion here. Section 2.2 could fit nicely between
> current Sections 3.1 and 3.2.
>=20
> >
> > p8. In section 3.1, figure 2, what does the abbreviation TE mean?
> Also, I gather that PLMN stands for Public Land Mobile Network, but
> this term is not properly introduced.  The "i.e." parentheticals in
the
> Gn/Gp table entry are no help to me.
> >
>=20
> More stuff to terminology section.. TE is Terminal Equipment e.g. your
> laptop. MT would then be your modem.
>=20
>=20
> > p9. In section 5.3, Prefix Delegation, the second paragraph is
mostly
> unintelligible to me.  The citation of RFC 3633, section 12.1, is
> confusing, because that document doesn't place any limitations on the
> delegating router, only the requesting router, which is contrary to
> what this draft states.  The sentences that follow in that paragraph
> therefore don't make sense to me.  Please clarify.
>=20
> There was a long discussion on this in DHC WG. The restriction applies
> also to delegating router. When you delegate a prefix to a requesting
> router, then the delegating router must not advertise (in RAs) any of
> these prefixes on its downstream link towards requesting router..
which
> would be the case in 3GPP architecture. Thus all this prefix
delegation
> work and description here.
>=20
> >
> > p10. In section 6, the abbreviation "DS" is used, presumably to
stand
> for 'dual-stack,' but no proper introduction is given.  I think it
> would be better to eliminate some uses of it, particularly in figures
> 5, 6 and 7, and expand it fully everywhere else.
>=20
> Ok.
>=20
> >
> > p11. In section 6.4, the abbreviation IPv4v6 is introduced and used
> several places thereafter.  I can infer that this signals a special
> type of 3GPP bearer that transports both IPv4 and IPv6 at the same
> time, but I don't like this abbreviation.  If it's official 3GPP
> terminology, then please cite it and add it to the Terminology
section.
> Otherwise, please come up with a more descriptive term, e.g. "dual-
> stack IP" should work in a pinch, and use that instead.
> >
>=20
> Right, will add IPv4v6 to terminology section as it is formal 3GPP
> jargon.
>=20
>=20
> > p12. Throughout, I think it would be better to use a hyphen when
> writing IPv4-only and IPv6-only.
>=20
> Ack.
>=20
> Thanks for the thorough review.
>=20
> - Jouni
>=20
>=20
> >
> >
> > --
> > james woodyatt 
> > member of technical staff, core os networking
> >
> >
> >
> > _______________________________________________
> > 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 Fred.L.Templin@boeing.com  Tue May 31 08:16: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 3D93AE0755 for ; Tue, 31 May 2011 08:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.057
X-Spam-Level: 
X-Spam-Status: No, score=-5.057 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock4=1.54]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk4LrULRrT0U for ; Tue, 31 May 2011 08:16:17 -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 489E1E07C6 for ; Tue, 31 May 2011 08:16:17 -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 p4VFG6Nu013283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 31 May 2011 08:16:07 -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 p4VEHHmf018631; Tue, 31 May 2011 07:17:17 -0700 (PDT)
Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4VEHGxK018595 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 31 May 2011 07:17:17 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Tue, 31 May 2011 08:16:05 -0700
From: "Templin, Fred L" 
To: Ray Hunter 
Date: Tue, 31 May 2011 08:16:04 -0700
Thread-Topic: [v6ops] Subject: Re: Happy eyeballs update,draft-ietf-v6ops-happy-eyeballs-02
Thread-Index: AcwdQ9mK0wwT9pogSYy9PtMkDFCoSACYFGLA
Message-ID: 
References: <4DDE8029.70606@globis.net><4DDE9D05.30605@globis.net><4DDEB336.7000701@globis.net><20110527042009.74819FFD8BB@d ru	gs.dv.isc.org><4DDF3AD7.9090400@globis.net><9091FF4A-4793-4EED-AAD6-9586 484813C1@nominum.com> <4DDFBA97.2000801@globis.net>  <4DE10706.8060506@globis.net>
In-Reply-To: <4DE10706.8060506@globis.net>
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_E1829B60731D1740BB7A0626B4FAF0A65C6A729998XCHNW01Vnwnos_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Subject: Re: Happy eyeballs 		update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 31 May 2011 15:16:19 -0000

--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A729998XCHNW01Vnwnos_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ray,

Have you read RFC1687? The document is 17yrs old and may have some
dated concepts, but it covers a number of concerns that are similar to the
ones you have raised. Here is the conclusion, which to a certain extent
still rings true today:

Conclusion

   In summary, the key factor which will determine whether -- and to
   what extent -- IPng will be deployed by large end users is whether
   IPng will become an essential element for the construction of
   applications which are critically needed by our businesses.  If IPng
   is bundled with applications which satisfy critical business needs,
   it will be deployed.  If it isn't, it is of little relevance to the
   large end user.  Regardless of what happens to IPng, the large mass
   of IPv4 devices will ensure that IPv4 will remain an important
   protocol for the foreseeable future and that continued development of
   IPv4 products is advisable.

Thanks - Fred
fred.l.templin@boeing.com
________________________________
From: Ray Hunter [mailto:v6ops@globis.net]
Sent: Saturday, May 28, 2011 7:31 AM
To: Templin, Fred L
Cc: v6ops@ietf.org WG
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update,draft-ietf-v6ops-ha=
ppy-eyeballs-02

I would hope people reading the v6ops list just recognize someone applying =
ITIL principles and processes to the discussion, no matter what the technol=
ogy. Please rest assured that I also pose similar questions and follow simi=
lar steps when introducing any new service, or provider, or indeed anything=
 else significantly new to the operational environment that has potential t=
o affect the SLA, but of course that doesn't get posted to this list.

best regards,
RayH

Templin, Fred L wrote:
Ray,

Based on your link to the RFC3484 thread, you seem to be still
concerned about ISATAP. Please have a look at the latest draft
to see if it satisfies the concerns:

http://www.ietf.org/id/draft-templin-v6ops-isops-07.txt

Thanks - Fred

________________________________
From: v6ops-bounces@ietf.org [mailto:v6ops-b=
ounces@ietf.org] On Behalf Of Ray Hunter
Sent: Friday, May 27, 2011 7:52 AM
To: Ted Lemon
Cc: v6ops@ietf.org WG
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update,draft-ietf-v6ops-ha=
ppy-eyeballs-02

Interesting concept of engineering: there are solutions and they are all ju=
st fine, but why do you insist on coming with that daft requirement after w=
e've already designed? ;)

See existing thread on RFC3484 bis http://www.ietf.org/mail-archive/web/ipv=
6/current/msg13920.html for my input to how RFC3484 address family selectio=
n does not meet my customer's requirements today to be able to prefer IPv4 =
in an operational network to avoid excessive latency for interactive applic=
ations in the presence of IPv6 over tunnels but still allowing them to roll=
 out IPv6 native, and a suggestion to improve this by codifying address sel=
ection policy of RFC3484 bis into DHCPv6.

And also a suggestion of adding one or more separate tables to the prefix p=
olicy table to be able to codify rules in policy, rather than these being h=
ard coded into operating systems or applications. e.g. whether RFC1918 addr=
esses should be considered global (in the presence of IPv4 NAT) or truly lo=
cal (isolated IPv4 RFC1918 islands once IPv6 becomes ubiquitous and the IPv=
4 Internet is becoming fragmented for CGN or whatever other reason)

The basic point is that one size does not fit all. Otherwise the Internet w=
ould be the only IP network in the World. And it clearly isn't.

The IPv6 end node implementations today do not have standardized default be=
havior.

One vendor will turn on DHCPv6. Another vendor hates the whole concept of D=
HCPv6 and will possibly implement DHCPv6, but not enable it.

One vendor will turn on temporary addresses by default. Another will not be=
cause they hate the idea.

Today's infrastructures are multi-vendor. To achieve consistent behavior a =
network manager has to manually override default settings on every single m=
achine of the flavor they don't like, no matter whether you are a fan of SL=
AAC or DHCPv6. You can't win. Yes they will work together on the wire, but =
is it easy to operate and manage?Just ask any real busy network administrat=
or today who performs daily operations in a large commercial environment an=
d has to trace problems what he/she thinks about that and whether today's t=
ools help them do their job.

One vendor will turn on Happy Eyeballs on one application. Another will not=
. One person wants IPv6 preferred today. Another doesn't.

The IPv6 end node implementations today do not have standard ways of being =
able to over ride those defaults (which have anyway not been coordinated ac=
ross the industry).

So over riding of any defaults that are not appropriate for a particular en=
d users' requirements relies on operating system specific / proprietary man=
agement techniques such as Microsoft Active Directory.

However, in these days of the exploding numbers of devices, Internet of Eve=
rything, highly mobile devices, devices running multiple interfaces and tec=
hnologies, and Bring Your Own Device, these assumptions of host management =
control being equal to network management control are breaking down.

The IPv6 set of standards does not have a standard way of communicating or =
signaling appropriate behavior from a network device to an end node. DHCPv6=
 might grow to become that standard, but there is certainly no consensus at=
 this time. DHCPv6 today isn't even backwards compatible with all of DHCPv4=
 e.g. all of the vendor extensions.

If you compare that situation to say 3G or GSM mobile telephone networks, y=
ou will see that these standards do exist in that World for similar functio=
ns (although obviously using different protocols). And for a good reason. T=
hese standards are needed when devices are produced by different vendors, a=
re highly mobile, some devices are rapidly turned over whilst others have l=
ong operational lifetimes, and they are all managed by different entities.

There are standards for network equipment behavior (including backwards com=
patibility and release management). There are standards for end node behavi=
or (again including release management). There are standards for signaling =
between a network operators device and an end terminal to ensure that the e=
nd node behaves in a manner appropriate for that operators network.

I'm not saying the Internet should go as far as those ITU style standards, =
as they also have their downsides. But I am flagging up that existing assum=
ptions about how defaults and settings on IT and Internet systems are expec=
ted to be managed should be challenged. Hard coding settings is not the way=
 to make this transition/ deployment a success. IMHO

If you need further evidence that people need more control of how the end n=
odes behave on their networks today, I suggest the WG casts its net wider t=
o attempt to quantify all end user requirements and Service Level Agreement=
s that exist for all systems running IPv4 operationally today, and how each=
 one will translate into IPv6 in the future.

Everything from light bulbs to web surfing to stock trading systems to elec=
tricity network control systems to spacecraft control systems to nuclear po=
wer plants.
[Many of which also include standard off the shelf operating systems and ap=
plications and IETF defined standard protocols in some part of their operat=
ions]

This has been addressed before in the v6ops list, so is nothing new, but it=
 did not seem to gain traction there for whatever reason.

See http://tools.ietf.org/html/draft-vandevelde-v6ops-pref-ps-00

Regards,
RayH

Ted Lemon wrote:
Le May 27, 2011 =E0 1:47 AM, Ray Hunter a =E9crit :
Is it really such a big deal to give network managers some knobs to turn, t=
ogether with an easy and standard communication mechanism to do this? The e=
xisting mechanism that covered AF preference selection (RFC3484) recognised=
 this requirement for a need to implement different policies for different =
networks at different times during the transition (although IMHO the standa=
rdized tuning tools and communication methods are rather lacking at this ti=
me).

Not only is it not a big deal, but as several people have explained to you,=
 there exist mechanisms already that we think are adequate.   But you insis=
t that those mechanisms aren't adequate.   You haven't actually made any ar=
gument as to why they are inadequate; although you seem certain that they a=
re not.

It would be awfully nice if we could actually identify what it is about the=
 existing methods doesn't work for you.   If you think there is some new me=
chanism that is needed, it would be helpful if you could describe such a me=
chanism.   It would also help if you could explain why it is better than th=
e mechanisms we've already described.  Then we could have a discussion abou=
t whether that mechanism is easier or harder to implement than existing mec=
hanisms, and whether it would be more or less effective.



--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A729998XCHNW01Vnwnos_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Hi Ray,


 


Have you read RFC1687? The document is 17yrs old a=
nd may=20
have some


dated concepts, but it covers a number of concerns=
 that are=20
similar to the


ones you have raised. Here is the conclusion, whic=
h to a=20
certain extent


still rings true today:


 


Conclusion

   In summary, the k=
ey=20
factor which will determine whether -- and to
   what extent -=
-=20
IPng will be deployed by large end users is whether
   IPng wi=
ll=20
become an essential element for the construction of
   applica=
tions=20
which are critically needed by our businesses.  If IPng
  =
; is=20
bundled with applications which satisfy critical business needs,
 &=
nbsp;=20
it will be deployed.  If it isn't, it is of little relevance to=20
the
   large end user.  Regardless of what happens to IPn=
g,=20
the large mass
   of IPv4 devices will ensure that IPv4 will r=
emain=20
an important
   protocol for the foreseeable future and that=20
continued development of
   IPv4 products is=20
advisable.


 


Thanks -=20
Fred



  

  

  From: Ray Hunter [mailto:v6ops@globis=
.net]=20
  
Sent: Saturday, May 28, 2011 7:31 AM
To: Templin, Fr=
ed=20
  L
Cc: v6ops@ietf.org WG
Subject: Re: [v6ops] Subject:=
 Re:=20
  Happy eyeballs update,draft-ietf-v6ops-happy-eyeballs-02


  
I would hope people reading the v6ops list just recognize some=
one=20
  applying ITIL principles and processes to the discussion, no matter what =
the=20
  technology. Please rest assured that I also pose similar questions and fo=
llow=20
  similar steps when introducing any new service, or provider, or indeed=20
  anything else significantly new to the operational environment that has=20
  potential to affect the SLA, but of course that doesn't get posted to thi=
s=20
  list.

best regards,
RayH

Templin, Fred L wrote:=20
  
    
    
Ray,

    
&nb=
sp;

    
Based on your link to the RFC3484 thread, you =
seem to=20
    be still

    
concerned about ISATAP. Please have a look at&=
nbsp;the=20
    latest draft

    
to see if it satisfies the=20
concerns:

    
&nb=
sp;

    
http://www.ietf.org/id/draft-templin-v6ops-iso=
ps-07.txt

    
&nb=
sp;

    
Thanks - Fred


    
      

      

      From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org<=
/A>]=20
      On Behalf Of Ray Hunter
Sent: Friday, May 27, 2011 7=
:52=20
      AM
To: Ted Lemon
Cc: v6ops@ietf.org WG
Subject: Re:=20
      [v6ops] Subject: Re: Happy eyeballs=20
      update,draft-ietf-v6ops-happy-eyeballs-02

Interes=
ting=20
      concept of engineering: there are solutions and they are all just fin=
e,=20
      but why do you insist on coming with that daft requirement after we'v=
e=20
      already designed? ;)

See existing thread on RFC3484 bis http://www.ietf.org/mail-archive/web/ipv6/cu=
rrent/msg13920.html=20
      for my input to how RFC3484 address family selection does not meet my=
=20
      customer's requirements today to be able to prefer IPv4 in an operati=
onal=20
      network to avoid excessive latency for interactive applications in th=
e=20
      presence of IPv6 over tunnels but still allowing them to roll out IPv=
6=20
      native, and a suggestion to improve this by codifying address selecti=
on=20
      policy of RFC3484 bis into DHCPv6.

And also a suggestion of ad=
ding=20
      one or more separate tables to the prefix policy table to be able to=
=20
      codify rules in policy, rather than these being hard coded into opera=
ting=20
      systems or applications. e.g. whether RFC1918 addresses should be=20
      considered global (in the presence of IPv4 NAT) or truly local (isola=
ted=20
      IPv4 RFC1918 islands once IPv6 becomes ubiquitous and the IPv4 Intern=
et is=20
      becoming fragmented for CGN or whatever other reason)

The basi=
c=20
      point is that one size does not fit all. Otherwise the Internet would=
 be=20
      the only IP network in the World. And it clearly isn't.

The IP=
v6=20
      end node implementations today do not have standardized default=20
      behavior.

One vendor will turn on DHCPv6. Another vendor hates=
 the=20
      whole concept of DHCPv6 and will possibly implement DHCPv6, but not e=
nable=20
      it.

One vendor will turn on temporary addresses by default. An=
other=20
      will not because they hate the idea.

Today's infrastructures a=
re=20
      multi-vendor. To achieve consistent behavior a network manager has to=
=20
      manually override default settings on every single machine of the fla=
vor=20
      they don't like, no matter whether you are a fan of SLAAC or DHCPv6. =
You=20
      can't win. Yes they will work together on the wire, but is it easy to=
=20
      operate and manage?Just ask any real busy network administrator today=
 who=20
      performs daily operations in a large commercial environment and has t=
o=20
      trace problems what he/she thinks about that and whether today's tool=
s=20
      help them do their job.

One vendor will turn on Happy Eyeballs=
 on=20
      one application. Another will not. One person wants IPv6 preferred to=
day.=20
      Another doesn't.

The IPv6 end node implementations today do no=
t=20
      have standard ways of being able to over ride those defaults (which h=
ave=20
      anyway not been coordinated across the industry).

So over ridi=
ng of=20
      any defaults that are not appropriate for a particular end users'=20
      requirements relies on operating system specific / proprietary manage=
ment=20
      techniques such as Microsoft Active Directory.

However, in the=
se=20
      days of the exploding numbers of devices, Internet of Everything, hig=
hly=20
      mobile devices, devices running multiple interfaces and technologies,=
 and=20
      Bring Your Own Device, these assumptions of host management control b=
eing=20
      equal to network management control are breaking down.

The IPv=
6 set=20
      of standards does not have a standard way of communicating or signali=
ng=20
      appropriate behavior from a network device to an end node. DHCPv6 mig=
ht=20
      grow to become that standard, but there is certainly no consensus at =
this=20
      time. DHCPv6 today isn't even backwards compatible with all of DHCPv4=
 e.g.=20
      all of the vendor extensions.

If you compare that situation to=
 say=20
      3G or GSM mobile telephone networks, you will see that these standard=
s do=20
      exist in that World for similar functions (although obviously using=20
      different protocols). And for a good reason. These standards are need=
ed=20
      when devices are produced by different vendors, are highly mobile, so=
me=20
      devices are rapidly turned over whilst others have long operational=20
      lifetimes, and they are all managed by different entities.

The=
re=20
      are standards for network equipment behavior (including backwards=20
      compatibility and release management). There are standards for end no=
de=20
      behavior (again including release management). There are standards fo=
r=20
      signaling between a network operators device and an end terminal to e=
nsure=20
      that the end node behaves in a manner appropriate for that operators=
=20
      network.

I'm not saying the Internet should go as far as those=
 ITU=20
      style standards, as they also have their downsides. But I am flagging=
 up=20
      that existing assumptions about how defaults and settings on IT and=20
      Internet systems are expected to be managed should be challenged. Har=
d=20
      coding settings is not the way to make this transition/ deployment a=
=20
      success. IMHO

If you need further evidence that people need mo=
re=20
      control of how the end nodes behave on their networks today, I sugges=
t the=20
      WG casts its net wider to attempt to quantify all end user requiremen=
ts=20
      and Service Level Agreements that exist for all systems running IPv4=
=20
      operationally today, and how each one will translate into IPv6 in the=
=20
      future.

Everything from light bulbs to web surfing to stock tr=
ading=20
      systems to electricity network control systems to spacecraft control=
=20
      systems to nuclear power plants.
[Many of which also include stand=
ard=20
      off the shelf operating systems and applications and IETF defined sta=
ndard=20
      protocols in some part of their operations]

This has been addr=
essed=20
      before in the v6ops list, so is nothing new, but it did not seem to g=
ain=20
      traction there for whatever reason.

See http://tools.ietf.org/html/draft-vandevelde-=
v6ops-pref-ps-00

Regards,
RayH

Ted=20
      Lemon wrote:=20
      

        

        
Le May 27, 2011 =E0 1:47 AM, Ray Hunter a =E9crit :

        
Is=20
          it really such a big deal to give network managers some knobs to =
turn,=20
          together with an easy and standard communication mechanism to do =
this?=20
          The existing mechanism that covered AF preference selection (RFC3=
484)=20
          recognised this requirement for a need to implement different pol=
icies=20
          for different networks at different times during the transition=20
          (although IMHO the standardized tuning tools and communication me=
thods=20
          are rather lacking at this time).


        
Not only is it not a big deal, but as several people have expl=
ained=20
        to you, there exist mechanisms already that we think are adequate.=
=20
          But you insist that those mechanisms aren't adequate.  =
 You=20
        haven't actually made any argument as to why they are inadequate;=20
        although you seem certain that they are not.

        


        
It would be awfully nice if we could actually identify what it=
 is=20
        about the existing methods doesn't work for you.   If you thin=
k=20
        there is some new mechanism that is needed, it would be helpful if =
you=20
        could describe such a mechanism.   It would also help if you c=
ould=20
        explain why it is better than the mechanisms we've already describe=
d.=20
         Then we could have a discussion about whether that mechanism =
is=20
        easier or harder to implement than existing mechanisms, and whether=
 it=20
        would be more or less effective.

        




--_000_E1829B60731D1740BB7A0626B4FAF0A65C6A729998XCHNW01Vnwnos_--

From phdgang@gmail.com  Tue May 31 08:52: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 E79CFE0755 for ; Tue, 31 May 2011 08:52:53 -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 uPaaN3oEVoZE for ; Tue, 31 May 2011 08:52:49 -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 B662AE080E for ; Tue, 31 May 2011 08:52:49 -0700 (PDT)
Received: by yxk30 with SMTP id 30so2513389yxk.31 for ; Tue, 31 May 2011 08:52:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=weuT/L/3NcNDmdxd0eT4buYQjSIQ+agH+4WwOhHB4Fg=; b=G3s3CLl44RfIePfQid8XDG5XqTc5uIa8se3lJQTxxwVtFVjXrq9L+U6hA9plIxJx9K DbCUm6s0oP5ZwlEHj2Z+BpKhbWdOwQ8b0YNDMKR95GJfd6I7xvLXYkt+WLMLoU/xNNop KtwZkUBE07Q6XwchRc/qt/8JqOY6BtLmD+/yU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TmB4WoK+gKN2wmUAxGLrZ7+JiIIGhbhxw/YEHA8+WVvx//uQLJJNtUVZgqZsfMorTy LpdW0AxkcIXHxntVb5QZvt9b/IdChf/rAwDSlcKPE0rQIRtAe/dxvSJa9xAzh78oTGrW /BJv774zPiYcpbM9dZ4aeamAynhmDRkwf7o4I=
MIME-Version: 1.0
Received: by 10.151.79.14 with SMTP id g14mr5210105ybl.187.1306857169204; Tue, 31 May 2011 08:52:49 -0700 (PDT)
Received: by 10.151.107.13 with HTTP; Tue, 31 May 2011 08:52:49 -0700 (PDT)
In-Reply-To: <449804.6587.qm@web111416.mail.gq1.yahoo.com>
References: <449804.6587.qm@web111416.mail.gq1.yahoo.com>
Date: Tue, 31 May 2011 23:52:49 +0800
Message-ID: 
From: GangChen 
To: Behcet Sarikaya 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IPv6 Operations 
Subject: Re: [v6ops] New Version Notification for draft-sarikaya-v6ops-prefix-delegation-05.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, 31 May 2011 15:52:54 -0000

Hello Behcet,

I think that is a valid scenario in mobile network.
Also, your revision looks good for me.

BRs

Gang

2011/5/27, Behcet Sarikaya :
>
>
>>
>
>> A new version of I-D, draft-sarikaya-v6ops-prefix-delegation-05.txt has
>> been
>>successfully submitted by Behcet Sarikaya and posted to the IETF
>> repository.
>>
>> Filename:      draft-sarikaya-v6ops-prefix-delegation
>> Revision:      05
>> Title:         DHCPv6 Prefix Delegation as  IPv6 Migration Tool in Mobile
>>Networks
>> Creation date:      2011-05-26
>> WG ID:         Individual  Submission
>> Number of pages: 12
>>
>> Abstract:
>>    As interest on  IPv6 deployment is increasing in cellular networks
>>    several migration  issues are being raised and IPv6 prefix management
>>    is the one  addressed in this document.  Based on the idea that DHCPv6
>>     servers can manage prefixes, we address prefix management issues such
>>     as the access router offloading delegation and release tasks of the
>>     prefixes to a DHCPv6 server using DHCPv6 PD.  The access router  first
>>    requests a prefix for an incoming mobile node from the DHCPv6  server.
>>    The access router may next stateless or stateful address  allocation
>>    to the mobile node, e.g. with a Router Advertisement or  using DHCP.
>>    We also describe prefix management using Authentication  Authorization
>>    and Accounting servers.
>>
>>
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

From fanf2@hermes.cam.ac.uk  Tue May 31 09:00: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 262EEE088B; Tue, 31 May 2011 09:00:50 -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 HIn+kdR6sAPF; Tue, 31 May 2011 09:00:41 -0700 (PDT)
Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 192B4E089F; Tue, 31 May 2011 09:00:35 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-SpamDetails: not scanned
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:41956) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1QRRMu-00056L-Xz (Exim 4.72) (return-path ); Tue, 31 May 2011 17:00:32 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QRRMu-0002jL-Fe (Exim 4.67) (return-path ); Tue, 31 May 2011 17:00:32 +0100
Date: Tue, 31 May 2011 17:00:32 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Gert Doering 
In-Reply-To: <20110530154841.GM45955@Space.Net>
Message-ID: 
References:  <4DE3B8FD.7040209@dcrocker.net> <20110530154841.GM45955@Space.Net>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
Cc: "v6ops@ietf.org" , Apps Review , dcrocker@bbiw.net, IETF Discussion 
Subject: Re: [v6ops] Review of:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps	area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 31 May 2011 16:00:50 -0000

Gert Doering  wrote:
>
> Whitelisting, on the other hand, is the term that Google introduced for
> this kind of "thing" and people seem to clearly understand what this
> is about.  "You are on my white list of people that I like talking to!".

I think it's OK to refer to it as "whitelisting". I think it is confusing
to refer to it as "DNS whitelisting". "Resolver whitelist" is better (it's
a whitelist of resolvers) or perhaps "IPv6 whitelisting" (what members of
the list are cleared to use) if you need a short phrase.

Speaking of confusing, the first sentence of the abstract and introduction
in the current revision of the draft is an abomination that should be
taken out and shot.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.

From jouni.nospam@gmail.com  Tue May 31 09: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 255B2E07F6 for ; Tue, 31 May 2011 09:51:37 -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=[AWL=-1.800, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_PAIN=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 mSeI7brX5amh for ; Tue, 31 May 2011 09:51:33 -0700 (PDT)
Received: from vs15.mail.saunalahti.fi (vs15.mail.saunalahti.fi [195.197.172.101]) by ietfa.amsl.com (Postfix) with ESMTP id E2A01E07E0 for ; Tue, 31 May 2011 09:51:32 -0700 (PDT)
Received: from saunalahti-vams (localhost [127.0.0.1]) by vs15.mail.saunalahti.fi (Postfix) with SMTP id 36CE9100067; Tue, 31 May 2011 19:51:31 +0300 (EEST)
Received: from vs15.mail.saunalahti.fi ([127.0.0.1]) by vs15.mail.saunalahti.fi ([195.197.172.101]) with SMTP (gateway) id A0363334744; Tue, 31 May 2011 19:51:31 +0300
Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs15.mail.saunalahti.fi (Postfix) with ESMTP id 248A8100067; Tue, 31 May 2011 19:51:31 +0300 (EEST)
Received: from a83-245-215-74.elisa-laajakaista.fi (a83-245-215-74.elisa-laajakaista.fi [83.245.215.74]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id AFE172165DE; Tue, 31 May 2011 19:51:26 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jouni 
In-Reply-To: <0D212BD466921646B58854FB79092CEC05D11D7B@XMB-AMS-106.cisco.com>
Date: Tue, 31 May 2011 19:51:26 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <7B661D1F-F127-45A8-B3E1-DDA6ED10AD35@cisco.com><9EFA85B3-43E6-441B-82B6-2C19084F5B39@apple.com> <4CF04D93-43FC-4D44-B3AD-D16E7F480593@gmail.com> <0D212BD466921646B58854FB79092CEC05D11D7B@XMB-AMS-106.cisco.com>
To: Frank Brockners (fbrockne) 
X-Mailer: Apple Mail (2.1084)
X-Antivirus: VAMS
Cc: IPv6 Operations 
Subject: Re: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-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, 31 May 2011 16:51:37 -0000

Hi Frank,

Thanks for the review. See my initial responses inline.

On May 31, 2011, at 6:09 PM, Frank Brockners (fbrockne) wrote:

> Even though a little too late, here are a few additional comments on
> I-D.ietf-v6ops-3gpp-eps-01.=20

Not too late.. as I have not done a new version yet.

>=20
> -- Section 6.2
>=20
> * The section uses the term "S4-SGSN": Might be useful to briefly
> explain what a S4-SGSN is (or cover it as part of the glossary).

Ack. Will add it.

>=20
> -- Section 6.3
>=20
> * Step 6: Might be useful to point out that the UE would ignore any
> prefix received in PCO in an access accept as part of the PDP
> establishment procedure (or directly refer to 3GPP 29.061:  "The =
Attach
> Accept message will be sent along to the UE without the IPv6 prefix.",
> "The UE shall ignore the IPv6 prefix if it receives one in the
> message.")

Good point. However, we do not mention PCOs in the whole document so =
far. I we do add text about PCOs, I would be tempted to write a bit =
more. For example the fact that DNS server IPv6 addresses get typically =
configured using PCOs.

>=20
> -- Section 6.4
>=20
> The current text states=20
> "If a network knows a mobile may do handovers between Release-8
> and pre-Release-8 networks (segment), network will only provide
> single stack bearers, even if the mobile host requests dual-stack
> bearers.  This can happen e.g. if an operator is using pre-
> Release-8 SGSNs in some parts of the network."
>=20
> Shouldn't this be "Rel-9 SGSNs"?

No.. The assumption in the above text is that from Rel-8 onwards the =
SGSN is actually S4-SGSN. However, as the world has moved on this  does =
not really hold anymore in real life. There are SGSNs out there these =
days that are not S4-SGSNs and not Rel-9 SGSNs but still can do PDP Type =
IPv4v6.. sigh. I try to rewrite this to cover the current situation:

* Legacy Pre-rel-8 SGSN -> only single stack bearers
* Rel-8 S4-SGSN  -> dual stack bearers
* Rel-9 SGSN (without S4) -> dual stack bearers
* Pre-rel-9 SGSN with PDP Type IPv4v6 "patch" -> dual stack bearers

Ok, this was the story from the SGSN side.. then the PGW/GGSN side =
causes another "tweak" here. In a Rel-8 PGW also capable of running in =
Gn (GGSN) mode may not support PDP Type IPv4v6 in Gn until Rel-9 ;) So =
even if your SGSN is up to date, the Gn side on PGW may cause a hick-up.


>=20
> -- Section 8.5
>=20
> Similar to the comment above, the text references pre-Release-8
> networks. Would it make sense to differentiate things a bit further
> in the text - highlighting the fact (which the I-D already states
> elsewhere), that v4v6 support only comes with Rel-9 for the SGSN?
> Right now the reader might things a bit

See above. Would the above list be detailed enough?

>=20
> This is the text I was referring to:=20
>=20
> "First, the visited network (S4-)SGSN does not=20
> support the IPv6 PDP Context or
> IPv4v6 PDP Context types.  These should mostly concern pre-Release-8
> networks but there is no definitive rule as the deployed feature sets
> vary depending on implementations and licenses. "
>=20
> -- Section 8.7
>=20
> The text states: "If for some reason a SGSN does not understand the
> requested PDP Type,
>   then the PDP Type is handled as IPv4."
>=20
> While this is "common understanding" it might make sense to point out

And also based on field testing.

> that 3GPP 24.008 is a bit ambiguous here. Other 3GPP docs, e.g.
> 23.975 handle this with a note. E.g.

23.975 *cough*

> "Note: The 3GPP specification TS 24.008 is not entirely unambiguous on
> the treatment of unknown PDP types.=20
> Even if the information element coding for "PDP type" specifies that a
> request for an "unknown PDP=20
> type" shall be treated as if it were a request for PDP type v4, the
> error signalling elsewhere in the=20
> specification include the possibility to signal an error code "unknown
> PDP address or PDP type".
>=20
> Should we include something similar here?

Isn't the above the same what the existing test says more or less. Also =
Section 8.7 says "The above respone/cause codes apply to Release-8 and =
onwards.  In pre-Release-8 networks used response/cause codes vary =
depending on the vendor, unfortunately." This is also based on field =
experience.

>=20
>=20
> A few nits that I found while reading:
>=20
> --- section 8.7:
>=20
> s/respone/response
>=20
> --- section 6.4:
>=20
> "If a network knows a mobile will not be able to do handover to
>       pre-Release-8 network (segment), it will provide mobile with
>       dual-stack bearers on request"
>=20
> s/provide mobile/provide the mobile
>=20
> -- section 8.6
>=20
> heading: s/rat/RAT

Ack. Thanks!

- Jouni


>=20
> Regards, Frank
>=20
>> -----Original Message-----
>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On =
Behalf
>> Of jouni korhonen
>> Sent: Wednesday, May 25, 2011 10:43 AM
>> To: james woodyatt
>> Cc: v6ops@ietf.org WG
>> Subject: Re: [v6ops] reviewing I-D.ietf-v6ops-3gpp-eps-01
>>=20
>> James,
>>=20
>> Thanks for the review. Really appreciated! See my initial comments
>> inline.
>>=20
>> On May 23, 2011, at 9:45 PM, james woodyatt wrote:
>>=20
>>> On May 22, 2011, at 11:00 , Fred Baker wrote:
>>>>=20
>>>> The working group last call for this draft announced last week
>> continues for another week. Please feel free to comment on it.
>>>=20
>>> I am in the target audience for this document, so my contributions
>> will seem more critical than constructive and predominantly editorial
>> in nature, mainly because I'm not confident that my knowledge of 3GPP
>> protocols and technologies is complete.
>>>=20
>>> Please do not interpret my criticisms as opposition to this draft.
> I
>> very much want to see a document with this information published in
> the
>> RFC series.
>>>=20
>>> ----
>>>=20
>>> p1. The abstract seems overly verbose.  Here is a proposed rewrite:
>>>=20
>>>  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.
>>=20
>> Looks OK to me.
>>=20
>>=20
>>>=20
>>> p2. This sentence needs updating:
>>>=20
>>>  However, the support for IPv6
>>>  in commercially deployed networks by the end of 2010 is nearly
> non-
>>>  existent.
>>=20
>> Yes. Cameron also pointed this out.
>>=20
>>=20
>>>=20
>>> p3. In section 2.1, Terminology, I think it would help if the
>> abbreviations were all collected into one table and expanded once in
>> each glossary subsection entry and in each top level section where
> they
>> are used.  The terms in the glossary subsection should be headed by
>> expanded abbreviations, and they should be presented in alphabetical
>> order.
>>=20
>> Hmm.. OK to collect all abbreviations. Do you mean that each of these
>> current entries in the terminology section would become a subsection
> of
>> their own?
>>=20
>>>=20
>>> p4. In section 2.1, Terminology, the definition of "Packet Data
>> Network" introduces what seems to be a specialized term, 'packet
> domain
>> network,' that goes undefined in this section.  Please clarify.
>>=20
>> s/domain/core
>>=20
>> Good catch. Packet core network means the operator internal network.
>>=20
>>=20
>>>=20
>>> p5. In section 2.1, Terminology, the definition of "Policy and
>> Charging Control (PCC) framework" explains that it's used for QoS
>> policy, which I think I might understand, but also for 'charging
>> control' which is never defined.  It also doesn't appear to be
>> inferable from context in the draft.  The dependent clause "but =
needed
>> if dynamic policy and charging control by means of PCC rules based on
>> user and services are desired" is therefore really not much use.
>> Please clarify.
>>=20
>> Ok. But I do not want to go into too much details.. PCC is a beast of
>> its own.. brrr..
>>=20
>>>=20
>>> p6. In section 2.1, Terminology, the term "evolved packet core" is
>> introduced and used in the document, but never defined.  Please
>> clarify.
>>=20
>> Oops :) Will add it.
>>=20
>>>=20
>>> p7. I think section 2.2, The concept of APN, might more properly
>> belong in section 3 [but I'm not sure].  If it really belongs in
>> section 2, because it describes an architecture independent of the
>> Internet Protocol, then perhaps this should be explicitly mentioned
>> here.
>>=20
>> I have no strong opinion here. Section 2.2 could fit nicely between
>> current Sections 3.1 and 3.2.
>>=20
>>>=20
>>> p8. In section 3.1, figure 2, what does the abbreviation TE mean?
>> Also, I gather that PLMN stands for Public Land Mobile Network, but
>> this term is not properly introduced.  The "i.e." parentheticals in
> the
>> Gn/Gp table entry are no help to me.
>>>=20
>>=20
>> More stuff to terminology section.. TE is Terminal Equipment e.g. =
your
>> laptop. MT would then be your modem.
>>=20
>>=20
>>> p9. In section 5.3, Prefix Delegation, the second paragraph is
> mostly
>> unintelligible to me.  The citation of RFC 3633, section 12.1, is
>> confusing, because that document doesn't place any limitations on the
>> delegating router, only the requesting router, which is contrary to
>> what this draft states.  The sentences that follow in that paragraph
>> therefore don't make sense to me.  Please clarify.
>>=20
>> There was a long discussion on this in DHC WG. The restriction =
applies
>> also to delegating router. When you delegate a prefix to a requesting
>> router, then the delegating router must not advertise (in RAs) any of
>> these prefixes on its downstream link towards requesting router..
> which
>> would be the case in 3GPP architecture. Thus all this prefix
> delegation
>> work and description here.
>>=20
>>>=20
>>> p10. In section 6, the abbreviation "DS" is used, presumably to
> stand
>> for 'dual-stack,' but no proper introduction is given.  I think it
>> would be better to eliminate some uses of it, particularly in figures
>> 5, 6 and 7, and expand it fully everywhere else.
>>=20
>> Ok.
>>=20
>>>=20
>>> p11. In section 6.4, the abbreviation IPv4v6 is introduced and used
>> several places thereafter.  I can infer that this signals a special
>> type of 3GPP bearer that transports both IPv4 and IPv6 at the same
>> time, but I don't like this abbreviation.  If it's official 3GPP
>> terminology, then please cite it and add it to the Terminology
> section.
>> Otherwise, please come up with a more descriptive term, e.g. "dual-
>> stack IP" should work in a pinch, and use that instead.
>>>=20
>>=20
>> Right, will add IPv4v6 to terminology section as it is formal 3GPP
>> jargon.
>>=20
>>=20
>>> p12. Throughout, I think it would be better to use a hyphen when
>> writing IPv4-only and IPv6-only.
>>=20
>> Ack.
>>=20
>> Thanks for the thorough review.
>>=20
>> - Jouni
>>=20
>>=20
>>>=20
>>>=20
>>> --
>>> james woodyatt 
>>> member of technical staff, core os networking
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>=20
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops


From lorenzo@google.com  Tue May 31 09:52: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 58787E0841 for ; Tue, 31 May 2011 09:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.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, 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 bWSigyj65n95 for ; Tue, 31 May 2011 09:52:54 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 84FC7E0829 for ; Tue, 31 May 2011 09:52:51 -0700 (PDT)
Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p4VGqo17003034 for ; Tue, 31 May 2011 09:52:50 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306860771; bh=FHJFYtd0YIhp+q1VU7ptc1HbeEk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=AiBrnQWwYq89Hwf22E9V6pkEq6MPKNCx1XpMDdvavjYgfVj1tHGLH14qMVovhNBNh bEFvOiK7X/0/avqlddB4g==
Received: from yia13 (yia13.prod.google.com [10.243.65.13]) by hpaq3.eem.corp.google.com with ESMTP id p4VGqgQc023685 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 31 May 2011 09:52:49 -0700
Received: by yia13 with SMTP id 13so2386113yia.34 for ; Tue, 31 May 2011 09:52:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=J9EVmdnRsMC9NjMrwJDjm7zZgMxbVn78n3r5YdWfj+E=; b=kVyMQYKwIvnD9V8gVA7kMYOdricoy0o7Yg9rS6iL7xJY0UsUVubO5X8ZetYAX1STQg IdrSM/Z0pHhbETJXggzw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=iJX0AL3K7Hb6QipvsOW/5XPqP6b7hYD2IjK3pgWBva+06bsbUkE9pOWIrEY51EAOtD Fo+ZAigSo6vvyrpMyPxw==
Received: by 10.151.24.10 with SMTP id b10mr5120949ybj.93.1306860768479; Tue, 31 May 2011 09:52:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.101.5 with HTTP; Tue, 31 May 2011 09:52:28 -0700 (PDT)
In-Reply-To: 
References:  
From: Lorenzo Colitti 
Date: Tue, 31 May 2011 09:52:28 -0700
Message-ID: 
To: "Livingood, Jason" 
Content-Type: multipart/alternative; boundary=000e0cd23ef6e048bc04a4953bcf
X-System-Of-Record: true
Cc: "v6ops@ietf.org" , Apps Review , IETF Discussion , Dave Crocker 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 31 May 2011 16:52:55 -0000

--000e0cd23ef6e048bc04a4953bcf
Content-Type: text/plain; charset=ISO-8859-1

On Tue, May 31, 2011 at 6:17 AM, Livingood, Jason <
Jason_Livingood@cable.comcast.com> wrote:

>   While you have not contributed text per se (by sending it directly), I
> try to be a good listener and items you and other Googlers have raised have
> been included in the document around motivations and so on. Even new
> Sections 3.2 and 3.2 were added based on listening to you and/or your
> colleagues talk about the issue (and some direct conversations a couple of
> weeks ago).
>

Sure - anything said at the IETF and on mailing lists is subject to the note
well. But I wouldn't want to be seen as having contributed to the document.

Regards,
Lorenzo

--000e0cd23ef6e048bc04a4953bcf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, May 31, 2011 at 6:17 AM, Livingood, Jaso=
n <Jason_Livingood@cable.comcast.com> wrote:













While you have not contributed text per se (by sending it directly), I=
 try to be a good listener and items you and other Googlers have raised hav=
e been included in the document around motivations and so on. Even new Sect=
ions 3.2 and 3.2 were added based
 on listening to you and/or your colleagues talk about the issue (and some =
direct conversations a couple of weeks ago).=A0



Sure - anything said at the IETF and on mailing lists is subject to the not=
e well. But I wouldn't want to be seen as having contributed to the doc=
ument.

Regards,
Lorenzo



--000e0cd23ef6e048bc04a4953bcf--

From jason_livingood@cable.comcast.com  Tue May 31 10:02: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 62231E06A0; Tue, 31 May 2011 10:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.462
X-Spam-Level: 
X-Spam-Status: No, score=-108.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 GNwqP+2FueuI; Tue, 31 May 2011 10:02:32 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1E151E068E; Tue, 31 May 2011 10:02:31 -0700 (PDT)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128770891; Tue, 31 May 2011 13:02:23 -0400
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; Tue, 31 May 2011 13:02:22 -0400
From: "Livingood, Jason" 
To: Tony Finch 
Thread-Topic: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
Thread-Index: AQHMH7SBsFho1RXKqkGG4vTPzIoAbg==
Date: Tue, 31 May 2011 17:02:22 +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.10.0.110310
x-originating-ip: [147.191.227.190]
Content-Type: multipart/alternative; boundary="_000_CA0A968728D56jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , IETF Discussion 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 31 May 2011 17:02:33 -0000

--_000_CA0A968728D56jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

On 5/31/11 12:00 PM, "Tony Finch" > wrote=
:

Speaking of confusing, the first sentence of the abstract and introduction
in the current revision of the draft is an abomination that should be
taken out and shot.

[JL] Great feedback =96 I just did it. Here's the updated Abstract (carried=
 into the Intro as well). If you think it is still convoluted, just say so =
and I'll take another turn at it.

New text:
"This document describes the practice and implications of whitelisting DNS =
recursive resolvers in order to limit AAAA resource record responses (which=
 contain IPv6 addresses) sent by authoritative DNS servers. This is an IPv6=
 transition mechanism used by domains as a method for incrementally transit=
ioning inbound traffic to a domain from IPv4 to IPv6 transport. The audienc=
e for this document is the Internet community generally, particularly IPv6 =
implementers."

Thanks!
Jason

--_000_CA0A968728D56jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <0EBEEB2E77252A4E9EA49B7C054B38E9@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable









On 5/31/11 12:00 PM, "Tony Finch" <dot@dotat.at> wrote:











Speaking of confusing, the first sentence of the abstract and introduc=
tion


in the current revision of the draft is an abomination that should be<=
/div>

taken out and shot.









[JL] Great feedback =96 I just did it. Here's the updated Abstract (ca=
rried into the Intro as well). If you think it is still convoluted, just sa=
y so and I'll take another turn at it.







New text:


"This document describes the practice and implications of whit=
elisting DNS recursive resolvers in order to limit AAAA resource record res=
ponses (which contain IPv6 addresses) sent by authoritative DNS servers. Th=
is is an IPv6 transition mechanism used
 by domains as a method for incrementally transitioning inbound traffic to =
a domain from IPv4 to IPv6 transport. The audience for this document is the=
 Internet community generally, particularly IPv6 implementers."






Thanks!


Jason




--_000_CA0A968728D56jasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Tue May 31 13: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 51249E0679; Tue, 31 May 2011 13:30:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.162
X-Spam-Level: 
X-Spam-Status: No, score=-108.162 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 Jmje2MCnM6vc; Tue, 31 May 2011 13:30:28 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE49E0789; Tue, 31 May 2011 13:30:27 -0700 (PDT)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128913207; Tue, 31 May 2011 16:30:17 -0400
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; Tue, 31 May 2011 16:30:17 -0400
From: "Livingood, Jason" 
To: Dave Crocker 
Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
Thread-Index: AQHMH9GMnHR+sjqO9E6E35G4C6F/uA==
Date: Tue, 31 May 2011 20:30:14 +0000
Message-ID: 
In-Reply-To: <4DE3B8FD.7040209@dcrocker.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [147.191.227.190]
Content-Type: multipart/alternative; boundary="_000_CA0A98D728D62jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , IETF Discussion , Apps Review 
Subject: Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 31 May 2011 20:30:31 -0000

--_000_CA0A98D728D62jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Dave - Thanks for the additional feedback. Any changes noted below will be =
made soon in a -06 update. See inline comments.

Regards
Jason

On 5/30/11 11:34 AM, "Dave CROCKER" > wrote:

(I see that you've posted -05.  This response is for completeness.)

On 5/29/2011 7:54 PM, Livingood, Jason wrote:
[JL] Duly noted in my previous emails. I'm keeping the naming as an open is=
sue
in the =9604 and will be seeking WG and WG co-chair guidance one way or the=
 other.

One of the reasons for cross-area review is to look for cross-area problems=
.

Separate from the legal formalities, the purpose of 'trademark' is to try t=
o
avoid market confusion.  Market confusion was exactly the reason that I rai=
sed
concern about the naming and I wasn't the only one who noticed the problem.=
  (My
original, informal posting was directly result of that confusion...)

So I'm sorry to see that the naming conflict is felt to be irrelevant by th=
ose
running the working group.  (I was also a little surprised to see that that=
 core
of folk constitute working group rough consensus, for removing open items.)

As for the actual term "whitelisting" I suppose we should admire the boldne=
ss of
the view that access to v6 is a priviledge -- note that that's the denotati=
onal
perspective of the word whitelisting...

[JL] Duly noted.

         operator of a website, such as www.example.com, the operator
         essentially applies an access control list (ACL) on the authoritat=
ive
         DNS servers for the domain example.com. The ACL is populated with

     An ACL usually is a yes/no mechanism. Here, however, the mechanism is =
for
     asserting a preference for IPv6 over IPv4.

     That does not seem to match the definition of ACL that I'm used to, un=
less the
     semantic is defined as denying IPv4 access to the listed clients.

     The term ACL is particularly odd to use if the mechanism pertains to r=
esponses
     rather than queries.


[JL] I am using 'ACL' in the most general possible sense and am open to
alternative descriptors if you wish to suggest one. But most people seem to=
 know
an ACL is a list that, if you are listed on it, grants you access to some
resource. In this case if the resolver is on the list then it gets AAAA RRs=
.

On reflection, the term is growing on me for this use.

"AAAA ACL" or "V6 DNS ACL" or "V6 resolver ACL" now seem to me quite good
labels.  They provide useful, direct and precise meaning, while avoiding th=
e
various referential and denotational problems of a loaded term like whiteli=
st.

[JL] Great! And I like thinking about it more in terms of granting "access"=
 to AAAA RRs than viewing it as "blocking" AAAA RRs, as I find access contr=
ol a more neutral term and one that is still easy to understand conceptuall=
y.

[JL] I took a stab at a new diagram in =9604 =97 so take a look and let me =
know if
it is what you are suggesting (I've left the original one in for now).

Took a quick look at the added diagram in the new draft.  The thing about a
protocol timeline diagram is that it uses verticality to provide ordering. =
 So a
response is lower down than a request. I don't get that from your Figure 2.

[JL] Oh! Now I understand what you were asking for. See my email under sepa=
rate cover with an example to see if I am getting closer. Others can see wh=
at I now have in draft form at https://img.skitch.com/20110531-j1r2ubr43273=
fd9i8xuj6btyn9.jpg


(By the way, your first sub-scenario, with Resolver 1, shows only a v4 resp=
onse,
without indicating whether the resolver sent a v6 or v4 query.  For the rev=
iew,
I think this distinction between transport and data -- "how is the
query/response transported" vs. "what RRs are returned" -- was a continuing
point of confusion for me. )

[JL] Ack. I'll add an extra note at the top of the diagram to clarify that =
the access control logic is independent of whether IPv6 transport is used b=
etween the host and resolver, or resolver and authority.

         At least one highly-trafficked domain has noted that they have
         received requests to not send DNS responses with AAAA resource
         records to particular resolvers. In this case, the operators of


     "At least one" seems a rather tiny statistic. Perhaps the actual stati=
stic is
     significantly larger?


[JL] It does not seem to be. Other than this being passed along by Google, =
I've
not heard of any similar stories. Nevertheless, it seemed interesting enoug=
h to
include.

As an anecdote, it is perhaps interesting.  As a basis for promoting the en=
tire
effort, not so much.  I couldn't tell which role it was serving, but it fel=
t
like the latter.


         network infrastructure is not yet ready to handle the large traffi=
c
         volume which may be associated with the hosts in their network
         connecting to the websites of these domains. This concern is clear=
ly


     So even though the site allows v6 DNS queries to go out from a host, i=
t can't
     really support having the host use v6?


[JL] A network isn't really in control of the end host's limitations w/r/t =
IPv6
impairment. A good summary of the issue of impairment is @ http://www.fud.n=
o/ipv6/

That sort of commentary, along with the citation, might be good to include,=
 for
clarification.

[JL] Done.



         While in Section 1 the level of IPv6-related impairment has been
         estimated to be as high as 0.078% of Internet users, which is a


     8 hundredths of one percent?

I think that that's 8 of every 10,000 Internet users?


     That's considered a high percentage?


[JL] It is. I joked at one of the v6ops WG meetings awhile ago that at that
rate, it'd be cheaper and easier for me (an ISP) to just buy new computers =
for
the affected "impaired" users than to have to navigate years of whitelistin=
g
with a variety of domains. In any case, one recent measurement estimates it=
 at
0.05% now and another at 0.015%. Despite this, this practice is still gener=
ating
some interest. I'm hoping World IPv6 Day goes well and is informative for t=
he
community as to this percentage on a widespread basis, across a wide variet=
y of
web sites.


     Even if it is 8%, is that considered high?


[JL] 8% of the Internet finding google.com or facebook.com inaccessible wou=
ld be
bad for everyone. That could generate several hundred thousand support call=
s per
day to a big ISP.

On reflection, I'm surprised to hear that IPv6 usage is up as high as 8 out=
 of
every 10,000 users, nevermind a large multiple of that.  (Although it does =
carry
a backhanded note of encouragement about v6 adoption, I'm a bit suspicious =
of
the statistic.)

[JL] Important to keep in mind that the IPv6-impairment occurs in situation=
s where someone usually does not have functioning IPv6 transport =97 just s=
eeing the AAAA RR causes issues.

         troubleshooting standpoint. In this scenario, a DNS recursive
         resolver operator will have no way to systematically determine
         whether DNS whitelisting is or is not implemented for a domain, si=
nce
         the absence of AAAA resource records may simply be indicative that
         the domain has not yet added IPv6 addressing for the domain, rathe=
r
         than that they have done so but have restricted query access via D=
NS


     The premise is that, in large scale use, servers /will/ have a way to
     systematically determine whether it is implemented? What are the exist=
ing
     examples of having such a capability for other Internet protocols and =
services?


[JL] Perhaps I'm overplaying this point, but you know someone has email ser=
vice
if they have an MX record for example, or a website if the host answers on
TCP/80. But as I re-read this it is probably overkill and so I've deleted i=
t. I
have however moved some of the text to a prior section, since determining
whether or not domains are whitelisting is still a challenge at scale.

Note that a site can have email service without an MX and that TCP:80 is no=
t
merely an "indicator" of web service, but actually /is/ the web service.

My point is that this idea of signaling/registering support of a service, a=
s
separate from actually providing the service, is not part of typical Intern=
et
service requirements and the simplification this provides is significant.  =
We
need to be careful that we do not inadvertently teach folks that "signaling
support" is an expected feature.

(And with this response, given that you already deleted the text, it's my t=
urn
to overplay a point...)

         nature, not to mention physics. For example, as Sir Issac Newton
         noted, "Every object in a state of uniform motion tends to remain =
in
         that state of motion unless an external force is applied to it" [L=
aws


     Code does not have momenum. Neither do configurations or lists. This r=
eally
     isn't about physics.


[JL] But people and processes do have (operational) momentum=85

Indeed, and the process of dealing with the naming issue for this does seem=
 to
show that...


     It is entirely about group psychology, as you note, and the administra=
tive
     challenges in the logistics of large-scale operational changes (which =
probably
     /does/ have something to with physics, but it seems a stretch to credi=
t Newton.
     How about Heisenberg?...)


[JL] Hmmm=85 I don't think it is Heisenberg-related. But it's such an inter=
esting
citation I feel it's almost a personal challenge to figure out a way to kee=
p it
in there. ;-)

How certain of it's being a challenge are you?  Does your certainty change =
as
you think about it?

[JL] I'm not wed to the reference. It was suggested earlier in the developm=
ent of the document. If you have any better reference to the notion of mome=
ntum taking some effort to slow, I'm open to that.

  The way I think about it is that in 5 or 10 years none of the
people working on the details of the IPv6 transition now will still be invo=
lved
in the day-to-day operational work. But DNS Whitelisting could still be in =
place
=96 and once something gets a momentum to it (people, processes, and
organizations) it is really, really hard to change that.

Well, I seriously applaud that concern, especially since its validity is pr=
oven
every day (including in the IETF...)

On the average, I tend to believe that the best way to instruct folks later=
 is
by imparting information about tradeoffs and, especially, cost vs. benefit.

In the current case, the near-term cost/benefit makes some sense.

In the long term, the scaling cost of maintenance and the architectural cos=
t of
losing spontaneous interoperability strike me as pretty f'ing expensive.


         8.3. Do Not Implement DNS Whitelisting

         As an alternative to adopting DNS whitelisting, the Internet
         community generally can choose to take no action whatsoever,
         perpetuating the current predominant authoritative DNS operational
         model on the Internet, and leave it up to end users with IPv6-rela=
ted
         impairments to discover and fix those impairments.


     That is, place the burden of fixing a problem on those creating it?


[JL] In a way. It gets back to the question you asked about what level of
impairment justifies this practice. One obvious option is to let end users =
sort
it out (presumably by consulting with their ISPs / network operators). This=
 may
be simpler and it's the way solutions to non-IPv6 problems tend to work tod=
ay.

On the average, demanding that an end-user make an explicit decision about =
an
operational tuning issue does not work very well.

[JL] Thanks again for your feedback!

Jason



d/

--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


--_000_CA0A98D728D62jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable









Dave - Thanks for the additional feedback. Any changes noted below wil=
l be made soon in a -06 update. See inline comments.









Regards


Jason







On 5/30/11 11:34 AM, "Dave CROCKER" <dhc@dcrocker.net> wrote:









(I see that you've posted -05.  This response is for complet=
eness.)







On 5/29/2011 7:54 PM, Livingood, Jason wrote:




[JL] Duly noted in my previous emails. I'm keeping the naming as an op=
en issue


in the =9604 and will be seeking WG and WG co-chair guidance one way o=
r the other.









One of the reasons for cross-area review is to look for cross-area pro=
blems.







Separate from the legal formalities, the purpose of 'trademark' is to =
try to



avoid market confusion.  Market confusion was exactly the re=
ason that I raised



concern about the naming and I wasn't the only one who noticed the pro=
blem.  (My



original, informal posting was directly result of that confusion...)






So I'm sorry to see that the naming conflict is felt to be irrelevant =
by those



running the working group.  (I was also a little surprised t=
o see that that core



of folk constitute working group rough consensus, for removing open it=
ems.)







As for the actual term "whitelisting" I suppose we should ad=
mire the boldness of



the view that access to v6 is a priviledge -- note that that's the den=
otational



perspective of the word whitelisting...









[JL] Duly noted. 











         operator of a website, such as www.e=
xample.com, the operator


         essentially applies a=
n access control list (ACL) on the authoritative


         DNS servers for the d=
omain example.com. The ACL is populated with







     An ACL usually is a yes/no mechanism. Here, h=
owever, the mechanism is for


     asserting a preference for IPv6 over IPv4.






     That does not seem to match the definition of=
 ACL that I'm used to, unless the


     semantic is defined as denying IPv4 access to=
 the listed clients.







     The term ACL is particularly odd to use if th=
e mechanism pertains to responses


     rather than queries.












[JL] I am using 'ACL' in the most general possible sense and am open t=
o


alternative descriptors if you wish to suggest one. But most people se=
em to know


an ACL is a list that, if you are listed on it, grants you access to s=
ome


resource. In this case if the resolver is on the list then it gets AAA=
A RRs.









On reflection, the term is growing on me for this use.







"AAAA ACL" or "V6 DNS ACL" or "V6 resolver AC=
L" now seem to me quite good 


labels.  They provide useful, direct and precise meaning, wh=
ile avoiding the



various referential and denotational problems of a loaded term like wh=
itelist.









[JL] Great! And I like thinking about it more in terms of granting &qu=
ot;access" to AAAA RRs than viewing it as "blocking" AAAA RR=
s, as I find access control a more neutral term and one that is still easy =
to understand conceptually.











[JL] I took a stab at a new diagram in =9604 =97 so take a look and le=
t me know if


it is what you are suggesting (I've left the original one in for now).=










Took a quick look at the added diagram in the new draft.  Th=
e thing about a 


protocol timeline diagram is that it uses verticality to provide order=
ing.  So a



response is lower down than a request. I don't get that from your Figu=
re 2.









[JL] Oh! Now I understand what you were asking for. See my email under=
 separate cover with an example to see if I am getting closer. Others can s=
ee what I now have in draft form at https://img.skitch.com/20110531-j1=
r2ubr43273fd9i8xuj6btyn9.jpg 














(By the way, your first sub-scenario, with Resolver 1, shows only a v4=
 response,



without indicating whether the resolver sent a v6 or v4 query. &n=
bsp;For the review,



I think this distinction between transport and data -- "how is th=
e 


query/response transported" vs. "what RRs are returned"=
 -- was a continuing 


point of confusion for me. )









[JL] Ack. I'll add an extra note at the top of the diagram to clarify =
that the access control logic is independent of whether IPv6 transport is u=
sed between the host and resolver, or resolver and authority.











         At least one highly-t=
rafficked domain has noted that they have


         received requests to =
not send DNS responses with AAAA resource


         records to particular=
 resolvers. In this case, the operators of












     "At least one" seems a rather tiny =
statistic. Perhaps the actual statistic is


     significantly larger?












[JL] It does not seem to be. Other than this being passed along by Goo=
gle, I've


not heard of any similar stories. Nevertheless, it seemed interesting =
enough to


include.









As an anecdote, it is perhaps interesting.  As a basis for p=
romoting the entire



effort, not so much.  I couldn't tell which role it was serv=
ing, but it felt



like the latter.














         network infrastructur=
e is not yet ready to handle the large traffic


         volume which may be a=
ssociated with the hosts in their network


         connecting to the web=
sites of these domains. This concern is clearly












     So even though the site allows v6 DNS queries=
 to go out from a host, it can't


     really support having the host use v6?












[JL] A network isn't really in control of the end host's limitations w=
/r/t IPv6


impairment. A good summary of the issue of impairment is @ 
http://www.fud.no/ipv6/









That sort of commentary, along with the citation, might be good to inc=
lude, for



clarification.









[JL] Done.





















         While in Section 1 th=
e level of IPv6-related impairment has been


         estimated to be as hi=
gh as 0.078% of Internet users, which is a












     8 hundredths of one percent?









I think that that's 8 of every 10,000 Internet users?














     That's considered a high percentage?












[JL] It is. I joked at one of the v6ops WG meetings awhile ago that at=
 that


rate, it'd be cheaper and easier for me (an ISP) to just buy new compu=
ters for


the affected "impaired" users than to have to navigate years=
 of whitelisting


with a variety of domains. In any case, one recent measurement estimat=
es it at


0.05% now and another at 0.015%. Despite this, this practice is still =
generating


some interest. I'm hoping World IPv6 Day goes well and is informative =
for the


community as to this percentage on a widespread basis, across a wide v=
ariety of


web sites.












     Even if it is 8%, is that considered high?











[JL] 8% of the Internet finding google.com or facebook.com inaccessibl=
e would be


bad for everyone. That could generate several hundred thousand support=
 calls per


day to a big ISP.









On reflection, I'm surprised to hear that IPv6 usage is up as high as =
8 out of



every 10,000 users, nevermind a large multiple of that.  (Al=
though it does carry



a backhanded note of encouragement about v6 adoption, I'm a bit suspic=
ious of



the statistic.)









[JL] Important to keep in mind that the IPv6-impairment occurs in situ=
ations where someone usually does not have functioning IPv6 transport =97 j=
ust seeing the AAAA RR causes issues.











         troubleshooting stand=
point. In this scenario, a DNS recursive


         resolver operator wil=
l have no way to systematically determine


         whether DNS whitelist=
ing is or is not implemented for a domain, since


         the absence of AAAA r=
esource records may simply be indicative that


         the domain has not ye=
t added IPv6 addressing for the domain, rather


         than that they have d=
one so but have restricted query access via DNS












     The premise is that, in large scale use, serv=
ers /will/ have a way to


     systematically determine whether it is implem=
ented? What are the existing


     examples of having such a capability for othe=
r Internet protocols and services?












[JL] Perhaps I'm overplaying this point, but you know someone has emai=
l service


if they have an MX record for example, or a website if the host answer=
s on


TCP/80. But as I re-read this it is probably overkill and so I've dele=
ted it. I


have however moved some of the text to a prior section, since determin=
ing


whether or not domains are whitelisting is still a challenge at scale.=










Note that a site can have email service without an MX and that TCP:80 =
is not



merely an "indicator" of web service, but actually /is/ the =
web service.







My point is that this idea of signaling/registering support of a servi=
ce, as



separate from actually providing the service, is not part of typical I=
nternet



service requirements and the simplification this provides is significa=
nt.  We



need to be careful that we do not inadvertently teach folks that "=
;signaling 


support" is an expected feature.







(And with this response, given that you already deleted the text, it's=
 my turn



to overplay a point...)









         nature, not to mentio=
n physics. For example, as Sir Issac Newton


         noted, "Every ob=
ject in a state of uniform motion tends to remain in


         that state of motion =
unless an external force is applied to it" [Laws












     Code does not have momenum. Neither do config=
urations or lists. This really


     isn't about physics.












[JL] But people and processes do have (operational) momentum=85









Indeed, and the process of dealing with the naming issue for this does=
 seem to



show that...














     It is entirely about group psychology, as you=
 note, and the administrative


     challenges in the logistics of large-scale op=
erational changes (which probably


     /does/ have something to with physics, but it=
 seems a stretch to credit Newton.


     How about Heisenberg?...)












[JL] Hmmm=85 I don't think it is Heisenberg-related. But it's such an =
interesting


citation I feel it's almost a personal challenge to figure out a way t=
o keep it


in there. ;-)









How certain of it's being a challenge are you?  Does your ce=
rtainty change as



you think about it?









[JL] I'm not wed to the reference. It was suggested earlier in the dev=
elopment of the document. If you have any better reference to the notion of=
 momentum taking some effort to slow, I'm open to that.









  The way I think about it is that in 5 or 10 years none of =
the




people working on the details of the IPv6 transition now will still be=
 involved


in the day-to-day operational work. But DNS Whitelisting could still b=
e in place


=96 and once something gets a momentum to it (people, processes, and

organizations) it is really, really hard to change that.









Well, I seriously applaud that concern, especially since its validity =
is proven



every day (including in the IETF...)







On the average, I tend to believe that the best way to instruct folks =
later is



by imparting information about tradeoffs and, especially, cost vs. ben=
efit.







In the current case, the near-term cost/benefit makes some sense.






In the long term, the scaling cost of maintenance and the architectura=
l cost of



losing spontaneous interoperability strike me as pretty f'ing expensiv=
e.














         8.3. Do Not Implement=
 DNS Whitelisting







         As an alternative to =
adopting DNS whitelisting, the Internet


         community generally c=
an choose to take no action whatsoever,


         perpetuating the curr=
ent predominant authoritative DNS operational


         model on the Internet=
, and leave it up to end users with IPv6-related


         impairments to discov=
er and fix those impairments.












     That is, place the burden of fixing a problem=
 on those creating it?












[JL] In a way. It gets back to the question you asked about what level=
 of


impairment justifies this practice. One obvious option is to let end u=
sers sort


it out (presumably by consulting with their ISPs / network operators).=
 This may


be simpler and it's the way solutions to non-IPv6 problems tend to wor=
k today.









On the average, demanding that an end-user make an explicit decision a=
bout an



operational tuning issue does not work very well.









[JL] Thanks again for your feedback!







Jason



















d/







-- 







   Dave Crocker


   Brandenburg InternetWorking


   bbiw.net











--_000_CA0A98D728D62jasonlivingoodcablecomcastcom_--

From fernando.gont.netbook.win@gmail.com  Tue May 31 13:46: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 1DEC6E08B2 for ; Tue, 31 May 2011 13:46:46 -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 L23c1X4yGKzG for ; Tue, 31 May 2011 13:46:45 -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 68C02E08AE for ; Tue, 31 May 2011 13:46:45 -0700 (PDT)
Received: by gxk19 with SMTP id 19so2656892gxk.31 for ; Tue, 31 May 2011 13:46:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=Zin1LVnOIDUo/L7fgUgQ/yss7b/5lZc9GHjY7PkGsKk=; b=FbAtIUhEdWK2LyYjNu6YRaKthvJZKgitpp0E5Zwz3S3NsG72bi9qBAsnrJeuXpdfOO pqKL8G9rrf59KtnF8TQuH+OOPDE/c8nTTBjmrZVQv8q7gjqv/MGGOOzcfNwynweSi3RW gRRFix4jsXc26SWyL0CUqSTr0JEM2eURAxhPs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=flylFYoJns3AInxrJs29URKSuT4olF7lmdrqgucmlFVvBiX0eKY3vP228bHkdv/Dq6 mH1tMrg47bD04DEFPyiWSwFioGh4wxlfYUuTklIrmMVdnSf0vT2enTdjhQhoYaNozlUp Jm+SGBiIuc7HFsMEc0cMsVDNRHuOB/kNck4rc=
Received: by 10.91.19.23 with SMTP id w23mr5451983agi.200.1306874804731; Tue, 31 May 2011 13:46:44 -0700 (PDT)
Received: from [192.168.0.114] ([190.190.97.123]) by mx.google.com with ESMTPS id c21sm260141ana.50.2011.05.31.13.46.40 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 13:46:44 -0700 (PDT)
Sender: Fernando Gont 
Message-ID: <4DE553A4.5030005@gont.com.ar>
Date: Tue, 31 May 2011 17:46:28 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
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
Subject: [v6ops] New I-D 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: Tue, 31 May 2011 20:46:46 -0000

Folks,

I have just published a new Internet-Draft
(draft-gont-v6ops-ra-guard-evasion-00) entitled "IPv6 Router
Advertisement Guard (RA-Guard) Evasion".

The I-D is available at:
http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt

The Abstract of the I-D is:
---- cut here ----
   The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly
   employed to mitigate attack vectors based on forged ICMPv6 Router
   Advertisement messages.  Many existing IPv6 deployments rely on RA-
   Guard as the first line of defense against the aforementioned attack
   vectors.  This document describes possible ways in which current RA-
   Guard implementations can be circumvented, and discusses possible
   mitigations.
---- cut here ----

Note: A closely related (and just published) I-D is
draft-gont-6man-nd-extension-headers-00, which is aimed at the 6man wg
(rather than v6ops).

Any comments on any of these I-Ds will be very welcome.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From jouni.nospam@gmail.com  Tue May 31 14:45: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 4FDC1E06EB for ; Tue, 31 May 2011 14:45:53 -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 ua0mEzljhTtv for ; Tue, 31 May 2011 14:45:52 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDF6E06D1 for ; Tue, 31 May 2011 14:45:52 -0700 (PDT)
Received: by eye13 with SMTP id 13so2235368eye.31 for ; Tue, 31 May 2011 14:45:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=g5cmCNHdqdjkozVkunqcSb4eQKBK89yzXy2oOX+rFas=; b=xktOXxTDZiqwl90e0pdMOWHrITukXsM8RL9q3R0wD3QKR2EgLeHwx1by7S+ALkbD/5 LIwxO3BwyveSAzKFBZ8uI6WkJUqlgn55VApYqrhZu+r/bKoV5xWbGAEkCo2VFQOJkDeB VqUkPq/AiTgRalURDExKWHEaUeXdON3QopPKA=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=WLnma0yq8Gz7K1hBU2ii0JOJfQjxttj8YbnU0Dby9sU5xM2SNDLbCaYqZ1Gnmt2+/+ NfscIzNsVQ7HiGcT5h39PiBIMb21shy944T+FG0EXSohnnWQW0ZN59VpTQMdSBJP6uWz eJl/YevqHnQIq1vtmQy3OaJtakGferAyjgSXo=
Received: by 10.14.11.26 with SMTP id 26mr2401764eew.114.1306878351098; Tue, 31 May 2011 14:45:51 -0700 (PDT)
Received: from a88-114-65-153.elisa-laajakaista.fi (a88-114-65-153.elisa-laajakaista.fi [88.114.65.153]) by mx.google.com with ESMTPS id a41sm298023eeg.7.2011.05.31.14.45.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 14:45:49 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <449804.6587.qm@web111416.mail.gq1.yahoo.com>
Date: Wed, 1 Jun 2011 00:45:46 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <2960D350-CDE4-4545-8798-48B110EDD601@gmail.com>
References: <449804.6587.qm@web111416.mail.gq1.yahoo.com>
To: Behcet Sarikaya 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] New Version Notification for draft-sarikaya-v6ops-prefix-delegation-05.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, 31 May 2011 21:45:53 -0000

I think the question laid by Ole is still valid i.e. whether this I-D is =
the "best practice" or good guidance for mobile networks. Clearly the =
I-D has now turned to mostly about 3GPP system. And I seriously think =
the clarification 3GPP needs for its prefix delegation belongs to =
TS29.061. For example, it would be beneficial to state there that all =
prefixes delegated for PDN Connections are /64 (obvious) unless the UE =
is the requesting router, IAIDs could map to TEIDs etc. Then if we face =
a problem that requires IETF involvement, we can deal with it here.=20

- Jouni


On May 26, 2011, at 7:59 PM, Behcet Sarikaya wrote:

>=20
>=20
>>=20
>=20
>> A new version of I-D, draft-sarikaya-v6ops-prefix-delegation-05.txt =
has been =20
>> successfully submitted by Behcet Sarikaya and posted to the IETF  =
repository.
>>=20
>> Filename:      draft-sarikaya-v6ops-prefix-delegation
>> Revision:      05
>> Title:         DHCPv6 Prefix Delegation as  IPv6 Migration Tool in =
Mobile=20
>> Networks
>> Creation date:      2011-05-26
>> WG ID:         Individual  Submission
>> Number of pages: 12
>>=20
>> Abstract:
>>   As interest on  IPv6 deployment is increasing in cellular networks
>>   several migration  issues are being raised and IPv6 prefix =
management
>>   is the one  addressed in this document.  Based on the idea that =
DHCPv6
>>    servers can manage prefixes, we address prefix management issues =
such
>>    as the access router offloading delegation and release tasks of =
the
>>    prefixes to a DHCPv6 server using DHCPv6 PD.  The access router  =
first
>>   requests a prefix for an incoming mobile node from the DHCPv6  =
server.
>>   The access router may next stateless or stateful address  =
allocation
>>   to the mobile node, e.g. with a Router Advertisement or  using =
DHCP.
>>   We also describe prefix management using Authentication  =
Authorization
>>   and Accounting servers.
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> The IETF Secretariat
>>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From prondou@gmail.com  Tue May 31 16:57: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 1C340E07C9; Tue, 31 May 2011 16:57:32 -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 igLJsXQYqR6V; Tue, 31 May 2011 16:57:31 -0700 (PDT)
Received: from mailrelay001.isp.belgacom.be (mailrelay001.isp.belgacom.be [195.238.6.51]) by ietfa.amsl.com (Postfix) with ESMTP id E8D5EE06A0; Tue, 31 May 2011 16:57:30 -0700 (PDT)
X-Belgacom-Dynamic: yes
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIBAEd+5U1R9wUR/2dsb2JhbAAMRxDcOYZrOYhnhh4EkE+OZTc
Received: from 17.5-247-81.adsl-dyn.isp.belgacom.be (HELO [192.168.1.40]) ([81.247.5.17]) by relay.skynet.be with ESMTP; 01 Jun 2011 01:57:29 +0200
Message-ID: <4DE58062.90207@gmail.com>
Date: Wed, 01 Jun 2011 01:57:22 +0200
From: Pierre Rondou 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: behave@ietf.org, v6ops@ietf.org, netfilter-devel@vger.kernel.org,  evyncke@cisco.com, guy.leduc@ulg.ac.be,  Cyril Soldani 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [v6ops] Netfilter Module for NAT64 available
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 31 May 2011 23:57:32 -0000

Hello everybody,

I'm currently a student at the University of Liège. As part of my master 
thesis, I have to develop a Linux kernel module for NAT64 ( 
http://datatracker.ietf.org/doc/rfc6146/ ).

I now consider my module as finished (i.e, all functionalities are 
implemented) and publish it.

It is available on sourceforge:

http://sourceforge.net/projects/nat64/

Feel free to test it and report to me any bug, bad implementation, 
error, ...

Like my previous module (http://sourceforge.net/projects/nativi/ , which 
have been updated), it can get included in Xtables/Kernel if you want, 
for now it is limited to 2.6.32 kernel.
I may provide patches for this a bit later.

Documentation is provided in the source code, if you have any question 
don't hesitate to ask me.

Regards,

Pierre RONDOU

From dwing@cisco.com  Tue May 31 18:12: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 17C09E0795 for ; Tue, 31 May 2011 18:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.604
X-Spam-Level: 
X-Spam-Status: No, score=-110.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 iLxUHDcRxXAr for ; Tue, 31 May 2011 18:12: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 66268E06B9 for ; Tue, 31 May 2011 18:12:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1117; q=dns/txt; s=iport; t=1306890740; x=1308100340; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=ydD24QeaYcUClr776a9XYT2Ez4bfjRk7k61d9e5/7tk=; b=BYSaoJbT47ft1tTEP26gyoHHmOXB7RJO4bXa9iLMg+ERF4OrByCS6RTn GNUpcLWamHyMRXLGZuFGIAAZK/nhz3+j/b9DOl/AA3z61luzh0jwxO1f/ FRVGb6tRKFRK17ABn037s0erAZ3MG71PoKeeAv+W7l7TymA23+DTihydg 4=;
X-IronPort-AV: E=Sophos;i="4.65,300,1304294400"; d="scan'208";a="457440842"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 01 Jun 2011 01:12:19 +0000
Received: from dwingWS ([10.21.119.247]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p511CJ8d009780; Wed, 1 Jun 2011 01:12:19 GMT
From: "Dan Wing" 
To: "'Templin, Fred L'" , 
References: <4DDE8029.70606@globis.net><4DDE9D05.30605@globis.net><4DDEB336.7000701@globis.net><20110527042009.74819FFD8BB@drugs.dv.isc.org><4DDF3AD7.9090400@globis.net>	<9091FF4A-4793-4EED-AAD6-9586484813C1@nominum.com> 
In-Reply-To: 
Date: Tue, 31 May 2011 18:11:58 -0700
Message-ID: <077801cc1ff8$f454a440$dcfdecc0$@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: Acwcc7v0fpKy2EG1Qm21dOTzmk6ZiAABMwfgAN4fOsA=
Content-Language: en-us
Subject: Re: [v6ops] Subject: Re: Happy eyeballs 	update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 01 Jun 2011 01:12:25 -0000

> If I set address selection policy rules that de-prefer
> certain IPv6 prefixes (e.g., 2001:db8:0:1::/64) and makes
> them to be of lesser priority than IPv4, will HE respect
> that and use IPv4?

Not as currently written, no.  The steps are 
described in
http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-02#section-5.3

An algorithm that uses the host's address selection rules
is easy:  getaddrinfo(), then attempt to connect to each 
address in the order returned, delaying NNNN milliseconds
between connection attempts.

What Happy Eyeballs is trying to accomplish is not simply
walking the host's address selection table quickly; Happy
Eyeballs is trying to react to the success (or failure)
of IPv6 or IPv4, with the idea that (a) the address 
selection table is incorrect or (b) there is a problem with
the network path.  (b) cannot be fixed by the address
selection table.

There might be some way to get Happy Eyeballs to accomplish
its goal while still honoring the host's address selection
policy rule better.  I don't know how to do that, though.
Ideas welcome.

-d



From marka@isc.org  Tue May 31 19:55: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 649BEE068E for ; Tue, 31 May 2011 19:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.383
X-Spam-Level: 
X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=1.217,  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 FkVqtlfkEqV1 for ; Tue, 31 May 2011 19:55:25 -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 AEFE2E0675 for ; Tue, 31 May 2011 19:55:24 -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 C07FEC94AF; Wed,  1 Jun 2011 02:55: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 53954216C7A; Wed,  1 Jun 2011 02:55:14 +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 69DB8102D764; Wed,  1 Jun 2011 12:55:12 +1000 (EST)
To: "Dan Wing" 
From: Mark Andrews 
References: <4DDE8029.70606@globis.net><4DDE9D05.30605@globis.net><4DDEB336.7000701@globis.net><20110527042009.74819FFD8BB@drugs.dv.isc.org><4DDF3AD7.9090400@globis.net> <9091FF4A-4793-4EED-AAD6-9586484813C1@nominum.com>  <077801cc1ff8$f454a440$dcfdecc0$@com>
In-reply-to: Your message of "Tue, 31 May 2011 18:11:58 MST." <077801cc1ff8$f454a440$dcfdecc0$@com>
Date: Wed, 01 Jun 2011 12:55:12 +1000
Message-Id: <20110601025512.69DB8102D764@drugs.dv.isc.org>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 01 Jun 2011 02:55:25 -0000

In message <077801cc1ff8$f454a440$dcfdecc0$@com>, "Dan Wing" writes:
> > If I set address selection policy rules that de-prefer
> > certain IPv6 prefixes (e.g., 2001:db8:0:1::/64) and makes
> > them to be of lesser priority than IPv4, will HE respect
> > that and use IPv4?
> 
> Not as currently written, no.  The steps are 
> described in
> http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-02#section-5.3
> 
> An algorithm that uses the host's address selection rules
> is easy:  getaddrinfo(), then attempt to connect to each 
> address in the order returned, delaying NNNN milliseconds
> between connection attempts.
> 
> What Happy Eyeballs is trying to accomplish is not simply
> walking the host's address selection table quickly; Happy
> Eyeballs is trying to react to the success (or failure)
> of IPv6 or IPv4, with the idea that (a) the address 
> selection table is incorrect or (b) there is a problem with
> the network path.  (b) cannot be fixed by the address
> selection table.
> 
> There might be some way to get Happy Eyeballs to accomplish
> its goal while still honoring the host's address selection
> policy rule better.  I don't know how to do that, though.
> Ideas welcome.

I don't think HE needs to go this far.  Truly, fast recovery will
be enough with the application re-using the working address for the
same host.  We have over-reacted.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From jasonlin.gz@gmail.com  Tue May 31 20:44: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 C3C13E06A1 for ; Tue, 31 May 2011 20:44:17 -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 zqlzZiV+B6r5 for ; Tue, 31 May 2011 20:44:17 -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 D0527E0658 for ; Tue, 31 May 2011 20:44:16 -0700 (PDT)
Received: by vxg33 with SMTP id 33so5266753vxg.31 for ; Tue, 31 May 2011 20:44:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=O6HICaa0nnb6/vqN038fmg+uFncSUugR1P5/yNvlQ9U=; b=DD0dTjrd7t7SktO9irYFlND65edWfzwt0xitsbK1t5+fJMEn0l0usY+S7zN1B70HWG J77l860os2kDCDcanq/oA44mdYLf4DAe4lu2L4HfJ5HnXz+3qIdCehBbWZMBI+XfhP86 MyAOfS1GQ534t0EKQ+9vQlIdDTDmCFf9EdjjI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WNATFsOD/M2y/6YRsjenErXnTTFp2huhwjTzdeqgsiE7UBezurMr7XxWDE2EUwID9x fov0NJf6G5NjoEabpAaJbeCOw0l5yNnT5lMdpTrPEcziyjlQhfoKIwhU/fvBmLbB+OBC pyxbA1ZV7PA4iqr6ygt8b4sO859Lje9wq7cA8=
MIME-Version: 1.0
Received: by 10.52.73.170 with SMTP id m10mr1489734vdv.160.1306899856268; Tue, 31 May 2011 20:44:16 -0700 (PDT)
Received: by 10.52.164.104 with HTTP; Tue, 31 May 2011 20:44:16 -0700 (PDT)
In-Reply-To: <2960D350-CDE4-4545-8798-48B110EDD601@gmail.com>
References: <449804.6587.qm@web111416.mail.gq1.yahoo.com> <2960D350-CDE4-4545-8798-48B110EDD601@gmail.com>
Date: Wed, 1 Jun 2011 11:44:16 +0800
Message-ID: 
From: Jason Lin 
To: jouni korhonen 
Content-Type: multipart/alternative; boundary=bcaec5016643b09db904a49e553a
Cc: IPv6 Operations 
Subject: Re: [v6ops] New Version Notification for draft-sarikaya-v6ops-prefix-delegation-05.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, 01 Jun 2011 03:44:17 -0000

--bcaec5016643b09db904a49e553a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I think this draft is useful for mobile networks. But I still have some
questions and comments:
    - What is this draft's final goal?
    - Whether the term 'MN' is the same as 'UE'? If yes, it is better to
modify the figure 1.
    - It is better to provide the full name of abbreviations.
    - In the figure 3, there should be a DHCP client element in =91MN=92 an=
d a
DHCP Server element in AR. Is it better to show them in the figure?
    - What are the Solicit message and Advertise message shown in figure 3
used for? It seems also need to be briefly explained in section 3.2.


Best Regards,

Jinyan Lin
China Telecom


On Wed, Jun 1, 2011 at 5:45 AM, jouni korhonen wrot=
e:

>
> I think the question laid by Ole is still valid i.e. whether this I-D is
> the "best practice" or good guidance for mobile networks. Clearly the I-D
> has now turned to mostly about 3GPP system. And I seriously think the
> clarification 3GPP needs for its prefix delegation belongs to TS29.061. F=
or
> example, it would be beneficial to state there that all prefixes delegate=
d
> for PDN Connections are /64 (obvious) unless the UE is the requesting
> router, IAIDs could map to TEIDs etc. Then if we face a problem that
> requires IETF involvement, we can deal with it here.
>
> - Jouni
>
>
> On May 26, 2011, at 7:59 PM, Behcet Sarikaya wrote:
>
> >
> >
> >>
> >
> >> A new version of I-D, draft-sarikaya-v6ops-prefix-delegation-05.txt ha=
s
> been
> >> successfully submitted by Behcet Sarikaya and posted to the IETF
>  repository.
> >>
> >> Filename:      draft-sarikaya-v6ops-prefix-delegation
> >> Revision:      05
> >> Title:         DHCPv6 Prefix Delegation as  IPv6 Migration Tool in
> Mobile
> >> Networks
> >> Creation date:      2011-05-26
> >> WG ID:         Individual  Submission
> >> Number of pages: 12
> >>
> >> Abstract:
> >>   As interest on  IPv6 deployment is increasing in cellular networks
> >>   several migration  issues are being raised and IPv6 prefix managemen=
t
> >>   is the one  addressed in this document.  Based on the idea that DHCP=
v6
> >>    servers can manage prefixes, we address prefix management issues su=
ch
> >>    as the access router offloading delegation and release tasks of the
> >>    prefixes to a DHCPv6 server using DHCPv6 PD.  The access router
>  first
> >>   requests a prefix for an incoming mobile node from the DHCPv6  serve=
r.
> >>   The access router may next stateless or stateful address  allocation
> >>   to the mobile node, e.g. with a Router Advertisement or  using DHCP.
> >>   We also describe prefix management using Authentication  Authorizati=
on
> >>   and Accounting servers.
> >>
> >>
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> > _______________________________________________
> > 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
>

--bcaec5016643b09db904a49e553a
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


I think this draft is useful for mobile networks. But I still hav=
e some questions and comments:
=A0 =A0 - What is this draft's=
 final goal?
=A0 =A0 - Whether the term 'MN' is the same =
as 'UE'? If yes, it is better to modify the figure 1.


=A0 =A0 - It is better to provide the full name of abbreviations.=A0
=A0 =A0 - In the figure 3, there should be a DHCP client element i=
n =91MN=92 and a DHCP Server element in AR. Is it better to show them in th=
e figure?=A0


=A0 =A0 - What are the Solicit message and Advertise message shown in =
figure 3 used for? It seems also need to be briefly explained in section 3.=
2.

=A0
Best Regards,


Jinyan Lin
China Telecom


On Wed, Jun 1, 2011 at 5:45 AM, jouni korhonen =
<jouni.nospam@gmail.com> wrote:





I think the question laid by Ole is still valid i.e. whether this I-D is th=
e "best practice" or good guidance for mobile networks. Clearly t=
he I-D has now turned to mostly about 3GPP system. And I seriously think th=
e clarification 3GPP needs for its prefix delegation belongs to TS29.061. F=
or example, it would be beneficial to state there that all prefixes delegat=
ed for PDN Connections are /64 (obvious) unless the UE is the requesting ro=
uter, IAIDs could map to TEIDs etc. Then if we face a problem that requires=
 IETF involvement, we can deal with it here.





- Jouni






On May 26, 2011, at 7:59 PM, Behcet Sarikaya wrote:



>

>

>>

>

>> A new version of I-D, draft-sarikaya-v6ops-prefix-delegation-05.tx=
t has been

>> successfully submitted by Behcet Sarikaya and posted to the IETF =
=A0repository.

>>

>> Filename: =A0 =A0 =A0draft-sarikaya-v6ops-prefix-delegation

>> Revision: =A0 =A0 =A005

>> Title: =A0 =A0 =A0 =A0 DHCPv6 Prefix Delegation as =A0IPv6 Migrati=
on Tool in Mobile

>> Networks

>> Creation date: =A0 =A0 =A02011-05-26

>> WG ID: =A0 =A0 =A0 =A0 Individual =A0Submission

>> Number of pages: 12

>>

>> Abstract:

>> =A0 As interest on =A0IPv6 deployment is increasing in cellular ne=
tworks

>> =A0 several migration =A0issues are being raised and IPv6 prefix m=
anagement

>> =A0 is the one =A0addressed in this document. =A0Based on the idea=
 that DHCPv6

>> =A0 =A0servers can manage prefixes, we address prefix management i=
ssues such

>> =A0 =A0as the access router offloading delegation and release task=
s of the

>> =A0 =A0prefixes to a DHCPv6 server using DHCPv6 PD. =A0The access =
router =A0first

>> =A0 requests a prefix for an incoming mobile node from the DHCPv6 =
=A0server.

>> =A0 The access router may next stateless or stateful address =A0al=
location

>> =A0 to the mobile node, e.g. with a Router Advertisement or =A0usi=
ng DHCP.

>> =A0 We also describe prefix management using Authentication =A0Aut=
horization

>> =A0 and Accounting servers.

>>

>>

>>

>>

>>

>>

>> The IETF Secretariat

>>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org=


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



_______________________________________________

v6ops mailing list

v6ops@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/v6ops





--bcaec5016643b09db904a49e553a--

From jasonlin.gz@gmail.com  Tue May 31 21:22: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 7A228E07B5 for ; Tue, 31 May 2011 21:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.198
X-Spam-Level: 
X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 Y9EfQCqo0NAQ for ; Tue, 31 May 2011 21:22:13 -0700 (PDT)
Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id BF957E07AC for ; Tue, 31 May 2011 21:22:13 -0700 (PDT)
Received: by pxi20 with SMTP id 20so3651313pxi.27 for ; Tue, 31 May 2011 21:22:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UWGgGpQnxMyRQk1Gg/Gj7p0S+7BzQdEb4S9tAR0Y3Zc=; b=wVqRY1P8LNgOcAW0DcgONAFcD2JMr1tRZPnFBEqH9okQ8Cgxha6M7xMy/YqFUfrHxp OifUIno2FDzauezTFUju+wGXMeKKtIsNdntImPddMQWF4Uk2MsA2FbSjKK1m8U2EStDw ILfjy9uuxQjRp/cIfcRkcVaKFnT7eltOng36s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Tc9gCMCAsiet1YHskh+cZJbYrqsJBw+/VNhhEJUkeQ0XOCdMn5t1/enIhNrg25jSNf 0p4gtq98N2GE3fJ9Txjie4GWTgMWOhG7j/6y4a5YXX+Wo3jB8ShviVeIxdGXziKPyT1R CbIJttkkD/wlL/TDxtf8dk4CmFUnEuZUDP0BE=
MIME-Version: 1.0
Received: by 10.68.2.129 with SMTP id 1mr2399473pbu.145.1306902133222; Tue, 31 May 2011 21:22:13 -0700 (PDT)
Received: by 10.68.64.168 with HTTP; Tue, 31 May 2011 21:22:13 -0700 (PDT)
In-Reply-To: <20110601025512.69DB8102D764@drugs.dv.isc.org>
References: <4DDE8029.70606@globis.net> <4DDE9D05.30605@globis.net> <4DDEB336.7000701@globis.net> <20110527042009.74819FFD8BB@drugs.dv.isc.org> <4DDF3AD7.9090400@globis.net> <9091FF4A-4793-4EED-AAD6-9586484813C1@nominum.com>  <077801cc1ff8$f454a440$dcfdecc0$@com> <20110601025512.69DB8102D764@drugs.dv.isc.org>
Date: Wed, 1 Jun 2011 12:22:13 +0800
Message-ID: 
From: Jason Lin 
To: Mark Andrews 
Content-Type: multipart/alternative; boundary=bcaec5215e29682d8304a49edd81
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Subject: Re: Happy eyeballs update, draft-ietf-v6ops-happy-eyeballs-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 01 Jun 2011 04:22:14 -0000

--bcaec5215e29682d8304a49edd81
Content-Type: text/plain; charset=ISO-8859-1

I think the objective of the Initial Headstart (IH) is good. But it is hard
to say whether 100ms has bad influence to dual-stack users, we need more
experimental statistics. If the influence is obviously, user will change
their browser to another which has set IH=0.

So I think this value will adapt the market needs. Software companies will
change the value by providing updates.

- Jinyan Lin


On Wed, Jun 1, 2011 at 10:55 AM, Mark Andrews  wrote:

>
> In message <077801cc1ff8$f454a440$dcfdecc0$@com>, "Dan Wing" writes:
> > > If I set address selection policy rules that de-prefer
> > > certain IPv6 prefixes (e.g., 2001:db8:0:1::/64) and makes
> > > them to be of lesser priority than IPv4, will HE respect
> > > that and use IPv4?
> >
> > Not as currently written, no.  The steps are
> > described in
> >
> http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-02#section-5.3
> >
> > An algorithm that uses the host's address selection rules
> > is easy:  getaddrinfo(), then attempt to connect to each
> > address in the order returned, delaying NNNN milliseconds
> > between connection attempts.
> >
> > What Happy Eyeballs is trying to accomplish is not simply
> > walking the host's address selection table quickly; Happy
> > Eyeballs is trying to react to the success (or failure)
> > of IPv6 or IPv4, with the idea that (a) the address
> > selection table is incorrect or (b) there is a problem with
> > the network path.  (b) cannot be fixed by the address
> > selection table.
> >
> > There might be some way to get Happy Eyeballs to accomplish
> > its goal while still honoring the host's address selection
> > policy rule better.  I don't know how to do that, though.
> > Ideas welcome.
>
> I don't think HE needs to go this far.  Truly, fast recovery will
> be enough with the application re-using the working address for the
> same host.  We have over-reacted.
>
> Mark
> --
> 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
>

--bcaec5215e29682d8304a49edd81
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I think the objective of the Initial Headstart (IH) is good. But it is=
 hard to say whether 100ms has bad influence to dual-stack users, we need m=
ore experimental statistics. If the influence is obviously, user will chang=
e their browser to another which has set IH=3D0.=A0



So I think this value will adapt the market needs. Soft=
ware companies will change the value by providing updates.

- Jinyan Lin



On Wed, Jun 1, 2011 at 10:55 AM, Mark Andrews <marka@isc.org> wrote:




In message <077801cc1ff8$f454a440$dcfdecc0$@com>, "Dan Wing"=
; writes:

> > If I set address selection policy rules that de-prefer

> > certain IPv6 prefixes (e.g., 2001:db8:0:1::/64) and makes

> > them to be of lesser priority than IPv4, will HE respect

> > that and use IPv4?

>

> Not as currently written, no. =A0The steps are

> described in

> http://tools.ietf.org/html/draft-ietf-v6o=
ps-happy-eyeballs-02#section-5.3

>

> An algorithm that uses the host's address selection rules

> is easy: =A0getaddrinfo(), then attempt to connect to each

> address in the order returned, delaying NNNN milliseconds

> between connection attempts.

>

> What Happy Eyeballs is trying to accomplish is not simply

> walking the host's address selection table quickly; Happy

> Eyeballs is trying to react to the success (or failure)

> of IPv6 or IPv4, with the idea that (a) the address

> selection table is incorrect or (b) there is a problem with

> the network path. =A0(b) cannot be fixed by the address

> selection table.

>

> There might be some way to get Happy Eyeballs to accomplish

> its goal while still honoring the host's address selection

> policy rule better. =A0I don't know how to do that, though.

> Ideas welcome.




I don't think HE needs to go this far. =A0Truly, fast recovery wi=
ll

be enough with the application re-using the working address for the

same host. =A0We have over-reacted.



Mark


--

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

_______________________________________________





--bcaec5215e29682d8304a49edd81--