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. > >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). > 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). 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. > > 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 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
