> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Pekka Savola > Sent: Tuesday, February 25, 2003 12:19 PM > To: Ralph Droms > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [dhcwg] Re: WG last call on > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > > > Similar discussion has already been had, so I'll try to keep > it at the > minimum. > > On Mon, 24 Feb 2003, Ralph Droms wrote: > > At 10:57 PM 2/22/2003 +0200, Pekka Savola wrote: > > >On Tue, 11 Feb 2003, Ralph Droms wrote: > > > > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt > describes new DHCPv6 > > > > options and a mechanism through which a "delegating > router" (e.g., an ISP > > > > aggregation device) can assign and delegate one or more > prefixes to a > > > > "requesting router" (e.g., CPE). This draft is available as > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt- > prefix-delegation-02.txt > > > > > >A few comments. > > > > > >Bigger issues -- I'm sorry for bringing them up so late > (relatively), but > > >I haven't really thought/read about the big picture, before. > > > > > >1) I fail to see why to add T1 and T2 in IA_PD. They seem to be > > >mostly redundant -- the requesting router should just take > the minimum of > > >lifetimes of the prefixes, calculate it in the same > fashion, that's it. > > >Of course, there is an assumption (which doesn't seem to > be properly > > >addressed!) that the requesting router is free to refresh > the delegation > > >when it feels right, even every hour, day, month etc. > without regard to > > >the lifetimes -- indeed, I think *NO* implementation would > just wait until > > >the last minute to refresh them. > > > > > >Is there something I'm missing? > > > > 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 :-) 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. If the requesting routers doesn't want to trust the time values, they can just ignore the T1 and T2 values and refresh the leases whenever it wishes. > > > >2) Multiple IA_PD looks unnecessarily complex. Are there any valid > > >reasons why it wouldn't be just enough to have only one IA_PD per > > >requesting router? (The option to and subsequent complexity of) > > >generating one for each interface seems like a completely > unnecessary > > >feature to me -- it's the router which should be doing > prefix delegation > > >to it's downstream interfaces! > > > > > >The only feature I can quickly think of which could profit > from this is > > >kind of "shared routers" where the connected interfaces > are separate > > >administrative entities with differently configured > properties at the ISP. > > >This seems questionable to me, a case for manual configuration or > > >"advanced prefix delegation" to me. > > > > > >So, I think the possibility to do prefix delegation in > more complex ways > > >than really necessary should be seriously considered. > Keep it Simple, > > >Stupid would be a good rule. > > > > There is no requirement that the delegating router supply more than > > one IA_PD to the requesting router, and limiting the delegation to > > only one IA_PD seems overly restrictive. For example, a delegating > > router might send one IA_PD for each ISP used by a customer site. > > 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 > > > It is not the intention of the draft that the requesting router > > receive one IA_PD for each of its downstream interfaces. If that > > is your understanding of the draft, then we need to clarify > > the text. In section 11.1, the draft specifies that the > > requesting router assigns subnets from the delegated prefixes > > to each of its downstream interfaces. > > I understood well that the particular behaviour is only > optional, but the > problem seems to be that the "main behaviour" is described quickly > (indeed, it's rather simple) and then the spec goes on at > great length > describing the fringe cases. This makes an unwary reader > think the fringe > cases are actually more than just fringe cases. > > At least, there should be some clearer separation between the two and > possibly some guidance when (for example) not to use special > mechanisms. > > > >3) One item that may also need some consideration is the > option to let the > > >requesting router give its preference to some values > (prefix length, > > >lifetimes, IAprefix-options contents (maybe?), the > prefixes). I'm not > > >sure of the usefulness of these, really. In the real > world, I think ISP's > > >set them, either to some values communicated off-band, or > otherwise. The > > >complexity required (policy, policy,...) when the > delegating router must > > >decide whether it can agree to the requested values seems > like a big hit. > > >I'm not really sure whether it's worth it, even though it > may offer some > > >flexibility for some corner cases. The only commonly used > one I could > > >think of would be whether the customer wants _single_ /64 > (for the only > > >one subnet!) or whole /48 -- seems like a heavy baggage for that. > > > > The cost of allowing the requesting router to express its > preferences > > isn't all that great - a simple delegating router can simply ignore > > the requesting router's preferences... > > 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. 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. 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. If there is no preconfiguration, then the server wont be able to provide the preferred prefix of the requesting routers. This problem remains unsolved. 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. > 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? > > > > > option-code: OPTION_IA_PD (TBD) > > > > > > option-length: 12 + length of IA_PD-options field. > > > > > >==> is it necessary to say how the option-code is > stored/transported > > >(signed/unsigned) ? I guess this is clear enough? > > > > The format of the option code is (should be?) specified in the > > DHCPv6 spec. > > Ok -- it's just that AFAICS, I don't see that a connection > has been made > between the two (even if they use the same name). > > > > The requesting router MUST ignore any Advertise message > that includes > > > a Status Code option containing the value NoPrefixAvail, > > > > > >==> where is the defintion of NoPrefixAvail or other codes? > > > > Needs a pointer to the DHCPv6 spec? > > At the minimum. > > > > message for the user, a Server Identifier option with > the delegating > > > router's DUID and a Client Identifier option with the > requesting > > > router's DUID. > > > > > >==> DUID used for the first time (inherited from DHCPv6 > spec I think), > > >spell it out? > > > > Needs a pointer to the DHCPv6 spec? > > Yes please, and spell out the abbreviation in the text (no > need to put it > up in terminology IMO). > > > > When a requesting router subnets a delegated prefix, > it must assign > > > additional bits to the prefix to generate unique, > longer prefixes. > > > For example, if the requesting router in Figure 1 were > delegated > > > 3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and > > > 3FFE:FFFF:0:2::/64 for assignment to the two links in > the subscriber > > > network. > > > > > >==> I'm not sure if the first sentence is entirely > accurate. One could > > >use prefix delegation to get multiple /64's directly from > your ISP, then > > >extra bits wouldn't be needed at all. > > > > But that wouldn't be "subnetting", I don't think - just > reassignment? > > Ah, got me there :-). The problem with the language seems to > be that even > though it says "when ... subnets", there are no other "whens" so this > paragraph is taken to imply all of it (especially since the > main form of > prefix delegation always includes subnetting, as noted earlier in the > draft). > > > >14. Security Considerations > > > > > >==> personally I'm rather worried about the requestor > being able to give > > >"guidance" to the delegator what on what it wants. > Unreliable input could > > >lead to bad results in an implementation which hasn't been > done carefully > > >(requesting link/site-local prefixes which don't exist, > effect of bogus > > >prefixlengths etc.etc.). [more of this was above] > > > > Paranoid delegating routers can simply ignore the guidance... > > Yep, put that in there :-) > > -- > 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] --------------------------------------------------------------------
