On Wed, 26 Feb 2003, Vijayabhaskar A K wrote: > > > The spec allows for flexibility in deployment scenarios by > > > allowing the ISP (through the delegating router) to control > > > the behavior of the requesting router, or by leaving the > > > behavior under the control of the requesting router > > > by setting T1 and T2 to 0 (see section 8 of the draft). > > > > Yes, I noticed they can be zero -- all I'm questioning is the > > usability of > > this flexibility. I fail to see why such flexibility is useful. The > > requesting router can be as flexible as it wants -- and > > refresh bindings > > when it deems it necessary even without guidance. > > On reading your previous mail, i thought you have agreed with T1 and T2 :-)
Well, if it's DHCPv6 functionality, it's ok to keep some of those intact even if misguided.. :-) > Probably, the routers which are "wise" enough to rely up of prefixes > provided by the DHCPv6 server and "dumb" enough to trust the time > values provided by it, may need this ;-) Perhaps, these T1 and T2 values > exist from > DHCPv4 architecture itself and worked successfully. Well, the routers MUST have this code *anyway*, as they cannot be sure T1/T2 will always be provided, so I really see little use.. > > I don't see it overly restrictive myself: as an operator and end-user, > > if someone connects to two ISP's, it's (almost, at least) always done > > either from two separate routers (no use doing it from one, really), > > or in a serial fashion (terminate one, establish the other -- like > > dialup). > > Simultaneous connection is also needed in some cases, as i told > earlier, like, high availablity High availability to two ISP's from one router is a joke. > > Certainly. I see this as a potential problem from two directions: > > > > 1) delegating router handling untrusted input values, creating > > delegations based on them, and > > > > 2) the requesting router requesting something that > > architectually differs > > *a lot* from what's given (example: /64's directly for its > > interfaces, and > > one /48 delegated). > > The same problem will occur, when the requesting router is expecting > the /48 and the server ignoring its preference and just gives > it /64. Sure. (Or the same for different changes in prefix lengths.) > The solution would be, > 1) when a site registers with ISP, preconfigure the topology of the > site in the dhcpv6 server. Thus, it can provide the requesting > router with necessary prefixes. I think it is natural to be able to expect that the ISP configures this kind of stuff (one /64, multiple /64, /48 -- that's all they need!) out-of-band. As currently. I don't think there's any reason to expect otherwise. > 2) If the site topology is not known, configure dhcpv6 server > with some dynamic pool which always provide a single /64 prefix > for the IA_PD. Let the requesting router send as many as IA_PD > it wants. But, here the concept of subnetting dies. Very discourageable, IMO. > Basically, the site which is connecting to ISP is authenticated, > moreover, they pay for whatever service they use, i dont see > that any harm in taking the preference from the requesting > router and assign the prefix accordingly. You fail to understand the relationship between the ISP and the user. Whether they use /64, /48 or whatever is, and will typically be, pre-agreed when people sign up for the service. Communicated out-of-band. I don't think that typically the user is able to affect that decision (at prefix delegation time) at all. Of course, ISP's could change their models, but don't count on it.. > > Then what? Can the requesting router > > handle this > > kind of situation? The problem is that entering preferences > > *in-band* > > (instead of out-of-band, as usual) seems problematic, as it creates > > difficult situations at both ends in the cases the > > preferences are not met > > (and policy decisions even if met). > > > > At the very least, one should clarify something along the > > lines of "In any > > case, the requesting router MUST NOT depend on any of its > > preferences to > > be honored" if this feature is really necessary. > > I pay for my using the services provided by ISPs, why shouldn't > my preferences be honoured? ISP's will love you for spending 50$/mo for the premium service instead of 30$/mo, so -- maybe they'll let you say the preference. For the rest, it won't matter and it's configured out-of-band. Most agreements with ISP's are very draconian. The problems like these are not solved with specifications. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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] --------------------------------------------------------------------
