"Boffelli, Lorenzo" <Lorenzo_Boffelli@alliedtelesyn.com> Thu, 08 July 2004 20:13 UTC

Received: from megatron.ietf.org (megatron.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25186; Thu, 8 Jul 2004 16:13:47 -0400 (EDT)
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BibIj-0008N1-Vo; Thu, 08 Jul 2004 11:59:09 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiZ10-0003eI-Ag for dhcwg@megatron.ietf.org; Thu, 08 Jul 2004 09:32:42 -0400
Received: from ietf-mx (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20870 for <dhcwg@ietf.org>; Thu, 8 Jul 2004 09:32:35 -0400 (EDT)
Received: from ietf-mx.ietf.org ([] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiZ0u-000273-Lp for dhcwg@ietf.org; Thu, 08 Jul 2004 09:32:36 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiYzr-0001nN-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 09:31:32 -0400
Received: from maileu.alliedtelesyn.com ([] helo=alliedtelesyn.com) by ietf-mx with esmtp (Exim 4.12) id 1BiYzN-0001Tu-00 for dhcwg@ietf.org; Thu, 08 Jul 2004 09:31:01 -0400
Received: from svr-mila-e2k1.eu.alliedtelesyn.com ([] RDNS failed) by alliedtelesyn.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 8 Jul 2004 15:25:19 +0200
Received: from svr-mila-fs3.eu.alliedtelesyn.com ([]) by svr-mila-e2k1.eu.alliedtelesyn.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 8 Jul 2004 15:30:28 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 8 Jul 2004 15:30:28 +0200
Message-ID: <BDF585B7763FB84CADEE238EC6FF489820D282@svr-mila-fs3.eu.alliedtelesyn.com>
Thread-Index: AcRk71uf14fqy8D8TtGKWFM+JXzRFQ==
From: "Boffelli, Lorenzo" <Lorenzo_Boffelli@alliedtelesyn.com>
To: <dhcwg@ietf.org>
X-OriginalArrivalTime: 08 Jul 2004 13:30:29.0014 (UTC) FILETIME=[BC2B6B60:01C464EF]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_30_40,HTML_MESSAGE, LINES_OF_YELLING,LINES_OF_YELLING_2,SUBJ_ALL_CAPS autolearn=no version=2.60
X-Mailman-Approved-At: Thu, 08 Jul 2004 11:59:08 -0400
Cc: "Paradiso, Francesco" <Francesco_Paradiso@alliedtelesyn.com>
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1533312703=="
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org

When a client receive a OFFER ACK message it must check the transaction ID.
Why the field chaddr must not be validate?

I have a case in which two different clients generate the same transaction ID. OK I am very unluky but this has happen.
Both the clients accepts the OFFERs and the ACKs sent in broadcast and get the same IP address.
If the clients would check the chaddr before accepting a message this would not be occured.

There are some unknow (to me) side effects created by a clients that execs this check of the chaddr field?
Thank you

Lorenzo Boffelli
Integration Test Group Leader 

Allied Telesis Multimedia S.r.l.
P.zza Tirana 24/4B - 20147 Milano MI - Italy

Office +39 02 41411237 (ext. 37)
Fax +39 02 41411261 

dhcwg mailing list