IETF Logo Mail Archive

Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC

Ronald Bonica <rbonica@juniper.net> Tue, 21 February 2012 19:54 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E9221E8071 for <v6ops@ietfa.amsl.com>; Tue, 21 Feb 2012 11:54:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.517
X-Spam-Level:
X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wliJ078rOojR for <v6ops@ietfa.amsl.com>; Tue, 21 Feb 2012 11:54:47 -0800 (PST)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCE321E8088 for <v6ops@ietf.org>; Tue, 21 Feb 2012 11:54:39 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT0P2QlRADbm9ejMcbx4fJHSDXGvQdt80@postini.com; Tue, 21 Feb 2012 11:54:42 PST
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Feb 2012 11:51:31 -0800
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 21 Feb 2012 14:51:04 -0500
From: Ronald Bonica <rbonica@juniper.net>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>, "EXT - joelja@bogus.com" <joelja@bogus.com>, Marc Lampo <marc.lampo@eurid.eu>
Date: Tue, 21 Feb 2012 14:51:03 -0500
Thread-Topic: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC
Thread-Index: AQHM8NFGCTjaobpzcUWNbcVExb7NG5ZHwiJA
Message-ID: <13205C286662DE4387D9AF3AC30EF456D7671A2C69@EMBX01-WF.jnpr.net>
References: <4F42C1E6.7010606@bogus.com> <CB695DB0.5117A%jason_livingood@cable.comcast.com>
In-Reply-To: <CB695DB0.5117A%jason_livingood@cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456D7671A2C69EMBX01WFjnprn_"
MIME-Version: 1.0
X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Feb 2012 19:54:48 -0000

Jason,

Please post the most recent version of the draft. If I hear no objections by COB Friday, I will send that version on to the RFC editor for publication.

                                                                                               Ron

From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
Sent: Tuesday, February 21, 2012 2:45 PM
To: EXT - joelja@bogus.com; Marc Lampo; Ronald Bonica
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC

On 2/20/12 4:57 PM, "Joel jaeggli" <joelja@bogus.com<mailto:joelja@bogus.com>> wrote:
IMHO the following applies.

if you have one zone yeah I agree.

If you have two zones one with aaaa and one without (assuming this is done with dns views style implementation) you can sign both and they'll both be valid and complete from the vantage point of a client which resolves one or the other of them but not both.

this is a traditional split horizon problem. it's just not inside/outside.

Exactly, which is one of the reasons section 4.3.4 is there (Similarities to Split DNS). This is two zones (or 'views' of the zone data). Both can be signed.

Jason

v2.23.0 | Report a Bug | By Email