RE: [dhcwg] Interface

"Bernie Volz (EUD)" <> Wed, 19 September 2001 15:19 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id LAA03998; Wed, 19 Sep 2001 11:19:20 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id LAA08692; Wed, 19 Sep 2001 11:13:33 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id LAA08667 for <>; Wed, 19 Sep 2001 11:13:31 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id LAA03881 for <>; Wed, 19 Sep 2001 11:13:29 -0400 (EDT)
Received: from ( []) by (8.11.3/8.11.3) with ESMTP id f8JFCo701637 for <>; Wed, 19 Sep 2001 10:12:50 -0500 (CDT)
Received: from eamrcnt749 ( []) by (8.11.3/8.11.3) with SMTP id f8JFCnx18457 for <>; Wed, 19 Sep 2001 10:12:49 -0500 (CDT)
Received: FROM BY eamrcnt749 ; Wed Sep 19 10:12:25 2001 -0500
Received: by with Internet Mail Service (5.5.2653.19) id <TG5TGT9N>; Wed, 19 Sep 2001 10:12:25 -0500
Message-ID: <>
From: "Bernie Volz (EUD)" <>
To: "'Erik Nordmark'" <>
Cc: "'Guja, ArturX'" <>,
Subject: RE: [dhcwg] Interface
Date: Wed, 19 Sep 2001 10:12:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1411D.774433E0"
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>


Your clarification on the constraint sounds reasonable to me and might well be what is in the draft. I don't recall exactly how it is worded in the draft, so perhaps Ralph will want to make sure we are clear on this.

- Bernie

-----Original Message-----
From: Erik Nordmark []
Sent: Wednesday, September 19, 2001 5:50 AM
To: Bernie Volz (EUD)
Cc: 'Guja, ArturX';
Subject: RE: [dhcwg] Interface

> 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.


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.