IETF Logo Mail Archive

Re: [BEHAVE] two ideas

<mohamed.boucadair@orange-ftgroup.com> Mon, 01 March 2010 12:37 UTC

Return-Path: <mohamed.boucadair@orange-ftgroup.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301683A8A83 for <behave@core3.amsl.com>; Mon, 1 Mar 2010 04:37:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.806
X-Spam-Level:
X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhkOp+gIuhGl for <behave@core3.amsl.com>; Mon, 1 Mar 2010 04:37:57 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 6109728C2D8 for <behave@ietf.org>; Mon, 1 Mar 2010 04:37:56 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 39BB91D0026; Mon, 1 Mar 2010 13:37:55 +0100 (CET)
Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1CA104C018; Mon, 1 Mar 2010 13:37:55 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 1 Mar 2010 13:37:55 +0100
From: mohamed.boucadair@orange-ftgroup.com
To: Dacheng Zhang <zhangdacheng@huawei.com>, "behave@ietf.org" <behave@ietf.org>
Date: Mon, 01 Mar 2010 13:37:54 +0100
Thread-Topic: [BEHAVE] two ideas
Thread-Index: Acq3hWDiPhSOgCmZS+iRRNm0BifuwQBtd6sw
Message-ID: <18206_1267447075_4B8BB523_18206_6111_1_94C682931C08B048B7A8645303FDC9F30EFAFF53CD@PUEXCB1B.nanterre.francetelecom.fr>
References: <019001cab785$62d06b80$070d6f0a@china.huawei.com>
In-Reply-To: <019001cab785$62d06b80$070d6f0a@china.huawei.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F30EFAFF53CDPUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.3.1.115422
Subject: Re: [BEHAVE] two ideas
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2010 12:37:58 -0000

Dear Dacheng,

Please see inline.

Cheers,
Med

________________________________
De : behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] De la part de Dacheng Zhang
Envoyé : samedi 27 février 2010 09:18
À : behave@ietf.org
Objet : [BEHAVE] two ideas

Hello, everybody:

After reading draft-wing-behave-dns64-config-02, I have two ideas here, and hope to get your kindly comments:

1. In section 3.2, it is suggested to use DNSsec to disable DNS64. But in order to deal with the circumstance where synthesized addresses have been already encapsulated in AAAA records, maybe it is a good idea to specify a new flag in the DNS answer containing an AAAA RR. The flag indicates that a synthesized address is contained in the RR. An updated dual-stack host can recognize it while conventional ones will just ignore the flag.
[Med] I'm not sure what kind of flags can be used, but an alternative proposal to define a new RR for synthesised AAAA can be found at: http://tools.ietf.org/html/draft-boucadair-behave-dns-a64-01. Does A64 RR solves the issue you have?

2. In the sections 3.5 and 3.6, solutions of using DHCP to identify dual stack host are introduced. I want to know whether it is another feasible solution to define an option for dual stack hosts. If such an option is attached in a request from a host, the DHCP server will ensure that the host has a dual-stack.

What do you think of them?

BR ^_^

Dacheng

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

v2.23.0 | Report a Bug | By Email