> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Pekka Savola > Sent: Tuesday, February 25, 2003 12:00 PM > To: Vijayabhaskar A K > Cc: 'Ralph Droms'; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [dhcwg] Re: WG last call on > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > On Mon, 24 Feb 2003, Vijayabhaskar A K wrote: > > > That is, the requesting router is in charge of all the > prefixes until > > > they expire. The robust requesting router implementation > will perform > > > some sane refreshing of these bindings way before they > expire, even > > > periodically. > > > > > > Thus, I fail to see any reason why these values would have to be > > > communicated from the delegator. > > > > Yes, I agree that the it can refresh the bindings at any periodic > > intervals it want. But, what if the delegating router is dead > > and not responding at all? > > Then it will try again a bit later and succeed.
The time "bit later" is well defined by DHCPv6 base architecture. > > > Hence, dhcpv6 provides you with > > two values: > > T1 -> This is the time at which the requesting router starts > > contacting the delegating router for the renewal of the lease... > > T2 -> If till the expiration of T2 it didn't get the response > > from the delegating router, it can contact any available > > dhcpv6 server to refresh its bindings. > > Do you mean that similar T1 & T2 values are being used by > DHCP base spec? > In that case I guess it's ok, but otherwise, I still fail to see the > usability. Yes, T1 and T2 values are being used in DHCPv6 base spec. > > > Ofcourse, the requesting router can generate these values itself. > > With DHCPv6 server sending T1 and T2 values, the requesting > > router dont need to recalculate the values again and again.. > > Trust the DHCPv6 server, the values provided by it makes the > > requesting router to refresh its bindings well before the expiry.. > > Well, typically the conventional wisdom is *not* to trust any > external > parties to any extent greater than necessary :-) If you are able to trust the prefixes given by DHCPv6, then there will be no harm in trusting the time values provided by it :-) > > > > Prefix delegation by DHCP is not meant to be > > > all-purpose-zero-configuration tool for routers, I think. > > > > > > This seems conflicting -- a fringe case which should not came up. > > > > > > Better would be just require that the requesting router > will get a > > > delegation from all the ISP's for itself, and subnet accordingly. > > > > > > If the following does not apply, it seems to me that there > > > must be routers > > > connected to the downstreaming interfaces -- which in turn > > > could perform > > > prefix delegation directly from the ISP, the first router > acting as a > > > relay. > > > > > > Doesn't seem to be need for this.. > > > > Need not be. Simple case is Home networks, they dont afford to have > > individual routers for every ISPs. They may need multiple ISPs > > for high availablity or some other reason. In this case, there will > > be only one border router with mutiple appliances/nodes in the > > downstreaming interfaces, which may span in one or more links. > > In this case, it needs to unique IA_PD for every ISP. > > Seems a bit far-fetched, IMO, but ok.. > > > > Regardless of that, I'm not sure how the requesting router would > > > discover more of these delegating routers -- how would they be > > > connected? Which kind of infrastructure would typically > be between > > > requesting router and multiple delegating routers? > > > > I beleive there will be unique dialup connection with each ISPs. > > .. as above, I've yet to see dial-up routers deployed which > would have two > dial-out adapters and phone jacks, but ok.. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > dhcwg mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
