Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6

From: Changming Liu <[email-masked]>
Date: Wed, 3 Mar 2004 16:48:46 -0800

Are you talking about CPE being a proxy? Marked already suggested that and
I've replied his email.

If not proxy, the primary and backup selections need to be passed to the
client PCs once any of these ones is changed. That's why we need the
reconfigure message at the first place.

Changming

-----Original Message-----
From: Ted Lemon
To: Changming Liu
Cc: [email-masked] ' ' '
Sent: 3/3/2004 2:52 PM
Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6

On Mar 3, 2004, at 2:32 AM, Changming Liu wrote:
> The requirement is that as long
> as primary ISP is up, use it right away including DNS. This is due to 
> cost
> struture. Is this reasonable requirement?

Sure.   The right way to do this is to set up a DNS caching server that 
normally contacts the primary ISP's DNS server to resolve queries, but 
will contact the secondary if the primary doesn't answer.   This allows 
for automatic failover, with no significant time delay.   If it's set 
up right, the user shouldn't even notice when the switch happens.

The point is that the wrong way to do it is to do it with DHCP.   The 
DNS protocol is already designed to correctly handle the situation 
you're describing, so there's no reason to place the burden on the DHCP 
protocol to solve this problem.

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Mar 2004 21:37:11 -0600

> reconfigure message at the first place.

No, I am talking about a DNS caching name server, not a proxy.   There 
are no proxies in DNS.   I'd suggest reading RFC1033 and RFC1034 to get 
some background on how this is done.

You seem to be attempting to re-engineer the Internet on the back of 
DHCP.   You are not talking about unplanned renumbering - you are 
talking about a planned system for on-the-fly reconfiguration based on 
asynchronous events.   Whether or not this is a good idea, it is out of 
scope for the DHC working group, and is not part of the stated goal of 
the effort we are currently undertaking.