RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6

[Changming Liu <[e-mail]>]

Mark,

Thanks for the suggestion. We already have this DNS proxy solution
implemented. That will work for DNS in this situation. How about other
configurations? How about other scenarios that configration can change in
the fly? Without a good infrustruture in place, we need to conquer this
problem one by one. Why don't we have once-for-all solution? 

Another point is that not all the people buy into the proxy idea. Remember
that in old days, the firwalls are almost all proxy based. Look at now, they
almost are stateful. What a change!

Changming

-----Original Message-----
From: Mark Stapp
To: Bernie Volz
Cc: 'Changming Liu'; 'Ted Lemon '; '''JINMEI Tatuya / ???? ' ' ';
[e-mail]; '''Tim Chown ' ' '
Sent: 3/3/2004 6:05 AM
Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6

or the CPE could supply its own address (if it has an address on the 
downstream link) as the dns server address, and act as a forwarder for
its 
clients. the CPE knows which upstream links and upstream dns resolvers
to 
use, so it should make the decision, not the clients. the downstream 
clients should be insulated from upstream network issues as much as 
possible, imo. I agree with Bernie: this doesn't sound like a problem
that 
should be solved by reconfiguring the clients repeatedly.

-- Mark

At 08:48 AM 3/3/2004 -0500, Bernie Volz wrote:
>For this situation, why don't you advertise BOTH DNS servers (primary
and
>secondary) and simply have the CPE do the proper routing? If the
primary
>link is up, the CPE sends the packets over the primary link. If the
primary
>is down, the CPE sends the packets over the secondary link. Using the
>routing infrastructure and CPE knowledge of which link is up or down
seems
>to me to be the best solution.
>
>Note that you need to do this anyway with any active sessions that are
>running - as I'm sure your big customer doesn't want all sessions to be
>broken.
>
>It seems to me, unless I don't understand something, there really is no
>issue here.
>
>- Bernie
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Changming Liu
>Sent: Wednesday, March 03, 2004 3:33 AM
>To: 'Ted Lemon '; Changming Liu
>Cc: '''JINMEI Tatuya / ???? ' ' '; '''[e-mail] ' ' '; '''Tim
Chown ' '
>'
>Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6
>
>Hi Ted,
>
> >Your scenario seems like a configuration error.   Setting things up
so
> >that the client has to update DNS server information immediately on a
> >frequent basis is simply bad network design.   I don't think the goal
> >of this renumbering effort is to accommodate that kind of
> >configuration.   The right way to fix this is to put a DNS cache
> >downstream of the flaky link.
>
>If I  was not clear in describing the scenario, pleae forgive me. Our
>customer is one of the biggest Telecoes in the world. Without their
>permission, I can not disclose too much details. Needless to say, it
should
>not be that bad design after so many engineers working on it.
>
>Let me try it again in different way. Let's say a multi-homed CPE with
two
>upstream links, one connected to one of its ISPs, one is primary and
one is
>backup. DHCP are enabled on both links for configuration info such as
DNS.
>These two ISPs offer different DNS servers. 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?
>
>This CPE runs DHCP server on the downstream link to pass the DNS info
to the
>local LAN. Once the primary ISP is up, its DNS info neends to push to
>downstream. Of course, you an hope the primary links never goes down
>unplanned(if it is true, why dualhome at the first palce?). The
lifetime
>solution does not solve this problem.
>
>If you need more info, we can get together to discuss this.
>
>Changming
>Netscreen Technoloies Inc
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg
>
>
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg

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