IETF Logo Mail Archive

Re: [dhcwg] New Version Notification - draft-ietf-pcp-dhcp-10.txt

Ted Lemon <ted.lemon@nominum.com> Tue, 01 April 2014 14:45 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1349B1A086E for <dhcwg@ietfa.amsl.com>; Tue, 1 Apr 2014 07:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9cN3Qhe54xV for <dhcwg@ietfa.amsl.com>; Tue, 1 Apr 2014 07:45:31 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id AF7791A0858 for <dhcwg@ietf.org>; Tue, 1 Apr 2014 07:45:31 -0700 (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 7BD361B83EE for <dhcwg@ietf.org>; Tue, 1 Apr 2014 07:45:28 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 750AB190043; Tue, 1 Apr 2014 07:45:28 -0700 (PDT)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 1 Apr 2014 07:45:28 -0700
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F54484AFA@PUEXCB1B.nanterre.francetelecom.fr>
Date: Tue, 01 Apr 2014 10:45:26 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <B5DDE7C1-071E-4781-AA0C-A91AB7F81441@nominum.com>
References: <20140401074050.4622.92489.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36F544848AE@PUEXCB1B.nanterre.francetelecom.fr> <657EBF08-AD6C-4E76-AF8B-DADF707B6720@nominum.com> <94C682931C08B048B7A8645303FDC9F36F54484AFA@PUEXCB1B.nanterre.francetelecom.fr>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.1874)
X-Originating-IP: [192.168.1.10]
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/CYGkJQLK-39rJKYfAwN41OqDLnI
Cc: DHC WG <dhcwg@ietf.org>, "draft-ietf-pcp-dhcp@tools.ietf.org" <draft-ietf-pcp-dhcp@tools.ietf.org>, "pcp-chairs@tools.ietf.org" <pcp-chairs@tools.ietf.org>
Subject: Re: [dhcwg] New Version Notification - draft-ietf-pcp-dhcp-10.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Apr 2014 14:45:33 -0000

On Apr 1, 2014, at 10:41 AM, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:
> [Med] This text seems OK to me. I have only one minor comment is that this is not specific to OPTION_V6_PCP_SERVER but can apply each time we need to provide a list of IP addresses to a dual-stack host connected via an IPv6-only connectivity using an encapsulation mode. I' suggest to remove the sentence starting with " This behavior is ...".

What I am specifically trying to avoid is DHCPv6 servers simply doing A queries for all FQDN resolutions and returning IPv4-mapped IPv6 addresses in all cases.   This would be disastrous.   If some future option requires this functionality, it should refer either to this specification, or to 3315bis, assuming that 3315bis documents this capability.   But it absolutely cannot be enabled by default on all DHCPv6 options.

v2.23.0 | Report a Bug | By Email