IETF Logo Mail Archive

RE: [dhcwg] Interface

Erik Nordmark <Erik.Nordmark@eng.sun.com> Wed, 19 September 2001 09:59 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28079; Wed, 19 Sep 2001 05:59:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00064; Wed, 19 Sep 2001 05:55:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00038 for <dhcwg@optimus.ietf.org>; Wed, 19 Sep 2001 05:55:10 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28017 for <dhcwg@ietf.org>; Wed, 19 Sep 2001 05:55:08 -0400 (EDT)
Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27249; Wed, 19 Sep 2001 03:54:19 -0600 (MDT)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8J9sNr19359; Wed, 19 Sep 2001 11:54:24 +0200 (MET DST)
Date: Wed, 19 Sep 2001 11:50:02 +0200
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: RE: [dhcwg] Interface
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
Cc: "'Guja, ArturX'" <ArturX.Guja@intel.com>, dhcwg@ietf.org
In-Reply-To: "Your message with ID" <66F66129A77AD411B76200508B65AC697B35F4@eambunt705.ena-east.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.1000893002.609.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET="US-ASCII"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

> The client *MUST* send the messages through the interface being configured.
> The client uses multicast messages and if directly received by the server,
> that's the way it knows what link the client is on. If a relay receives it
> and forwards it, that's how it can tag the message having come from that
> link so that the server knows what link the client is on. If the server
> doesn't know the correct link, it can't assign the proper addresses.

Bernie,

I suspect that the real constraint is that the client MUST send the
message on an interface attached to the same *LINK* as the interface it
is trying to configure. When the client has multiple interfaces attached to
the same link the server/relay can't tell which one was used (short of
inspecting the source MAC address which may or may not differ).

If the document will cover this distinction it would make sense to
add a reference to draft-ietf-ipngwg-scoping-arch-02.txt.

   Erik




_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg

v2.23.0 | Report a Bug | By Email