<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: Vista keeps name server options from previous lease</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=2>see bottom<BR>
<BR>
-----Original Message-----<BR>
From: dhcp-users-bounce@isc.org on behalf of Frank Sweetser<BR>
Sent: Sat 9/15/2007 9:19 AM<BR>
To: dhcp-users@isc.org<BR>
Subject: Re: Vista keeps name server options from previous lease<BR>
<BR>
Kirsten Petersen wrote:<BR>
>> What we are<BR>
>> seeing with Vista clients is this: the client picks up a lease from the<BR>
>> wireless network and gets the options for the main campus name servers.<BR>
>> Then, the user plugs into a wired port in the residence hall and gets a<BR>
>> new lease from the dhcp server on that network.  However, their name<BR>
>> server option does not get updated.  Thus, they don't get redirected to<BR>
>> the registration page, because they are talking to the wrong nameservers.<BR>
<BR>
>This sounds like you're running into an issue that's been brought up a couple<BR>
>of times, so far with no resolution.  If you search through the list archives<BR>
>for a thread with a subject of "dhcpinform request from Vista gets wrong Name<BR>
>servers" you'll see all the details, but the short version is that the dhcp<BR>
>server uses a slightly different set of logic to calculate what options should<BR>
>be returned to DHCPINFORM requests than DHCPDISCOVER ones.<BR>
<BR>
-------------------------------------------------------------------------<BR>
<BR>
There is a workaround that works much of the time but not all. Vista always does a dhcpinform request but does not always include the nameserver option in the request. It seems that the trigger for including the nameserver option is a failure to resolve IPv6 tunnel coordination server names. The workaround is to define the servers in your captive DNS. It may not always be required that they are reachable. As an aside, I was not amuzed to look up how destructive a teredo is.<BR>
<BR>
; these are the vista workarounds<BR>
teredo.ipv6.microsoft.com.wherever.edu.      IN      A       65.54.227.136<BR>
teredo.ipv6.microsoft.com.wherever.edu.      IN      A       65.54.227.138<BR>
teredo.ipv6.microsoft.com.wherever.edu.      IN      A       65.54.227.140<BR>
teredo.ipv6.microsoft.com.wherever.edu.      IN      A       65.54.227.142<BR>
teredo.ipv6.microsoft.com.wherever.edu.      IN      A       65.54.227.144<BR>
teredo.ipv6.microsoft.com.              IN      A       65.54.227.136<BR>
teredo.ipv6.microsoft.com.              IN      A       65.54.227.138<BR>
teredo.ipv6.microsoft.com.              IN      A       65.54.227.140<BR>
teredo.ipv6.microsoft.com.              IN      A       65.54.227.142<BR>
teredo.ipv6.microsoft.com.              IN      A       65.54.227.144<BR>
6to4.ipv6.microsoft.com.wherever.edu.        IN      A       192.88.99.1<BR>
6to4.ipv6.microsoft.com.                IN      A       192.88.99.1<BR>
time.windows.com.wherever.edu.               IN      A       207.46.130.100<BR>
time.windows.com.                       IN      A       207.46.130.100<BR>
dns.msftncsi.com.wherever.edu.               IN      A       131.107.255.255<BR>
dns.msftncsi.com.                       IN      A       131.107.255.255<BR>
<BR>
<><Randy<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>