Subject: Re: [dhcwg] DHCP - VLANS

From: "Sasi Kiran" <[email-masked]>
Date: Tue, 27 Dec 2005 18:41:42 +0530

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>So what information is needed to properly identify a =
stolen
computer well enough to locate it?&nbsp; I would think the public IP, =
the fqdn
and the identification of the ISP would be sufficient, but that is not =
my area
of expertise.&nbsp; The existence of a MAC from a stolen computer on =
their network
should be enough to obtain a warrant for the client information =
associated with
the stolen MAC.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Think about it, for the cost of transmitting a single =
packet
to a stolen MAC repository, we could greatly increase the chance of =
recovery of
stolen network devices.&nbsp; I would like to work with your group and =
others
toward implementing this mechanism within DHCP.</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Regards</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Tom Loveday</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0006_01C6385C.C49FC6F0--

--===============1579041208==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

--===============1579041208==--

---

From: "David W. Hankins" <[email-masked]>
Date: Sat, 25 Feb 2006 20:28:24 +0000

Dec 27?

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
        by megatron.ietf.org with esmtp (Exim 4.43)
        id 1FCPJU-0006CQ-9R; Thu, 23 Feb 2006 17:51:56 -0500
			     ^^^^^^^^^^^^^^^^
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
        by megatron.ietf.org with esmtp (Exim 4.32) id 1ErEcP-00064B-2P
        for [email-masked]; Tue, 27 Dec 2005 08:11:57 -0500
				     ^^^^^^^^^^^^^^^^
"Let's do the Time Warp agaaaain!"

Well, happy new year.  Again.

On Tue, Dec 27, 2005 at 06:41:42PM +0530, Sasi Kiran wrote:
> How would DHCP differentiates requests which are coming from different  
> vlans and assign appropriate vlan base address to clients.

If you're using a DHCP server that straddles every VLAN, it's easy*,
this is the same as having a DHCP server physically attached to multiple
broadcast domains with generally only one new minor wrinkle (the DHCP
server's (virtual) interfaces all share the same (physical) MAC address).

If you're using one or more DHCP relays that are working on the VLANs,
in general again it works easy as pie - so long as your relay has an
address on every vlan...this address once placed in the giaddr field
informs the server which network the client is on.  In the case where
your relay does not have an address on every vlan, it must make use of
the Relay Agent option's Link Selection suboption (RFC3527), which may
or may not be supported by your relay.

* - Note that this requires the DHCP server to be able to tell the
    difference between a packet media-level unicast, broadcast, and
    which interface it was physically received upon (this may be
    different than which Berkeley Socket it was read out from for
    example...consider the case where a DHCP client unicasts its
    renewal to the DHCP server, and the server uses berkeley sockets
    bound to the destination address the client selects - even if
    this packet is read in from a different interface, it will be
    delivered to the "other interface"s socket).

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins