On Mon, 25 Mar 2002, Yamasaki Toshi wrote: > Probably what I want to say is that it'd the best idea to have one > "lite-weight" solution to solve major requirements, which is compatible > for a "full-covered" solution to solve also minor requiremnts. To > achieve this, there seems three solutions: > > 1) DNCP (DHCP-lite) as a "lite-weight", DHCP as a "full-covered" > 2) APD as a "lite-weight", APD-heavy as a "full-covered" > 3) RA+PDopt as a "lite-weight", RA+PDopt-heavy as a "full covered" > > Ralf is writing DNCP, and currently nobody seems writing APD-heavy nor > RA+PDopt-heavy.
I don't think mechanisms of 2) or 3) (ie. ICMP6) even should be used for "heavy" operations: if one requires these, one can always use DHCPv6 or static allocations. So, the only problems I see outright: 1. writing requirements to see what we actually want 2. developing APD further, e.g. to a bit more lightweight solution 3. writing a lightweight DHCPv6 solution; IMO, DHCPv6 specification should be split anyway though. ( 4. possibly fixing the few problems with RA delegation, if that is preferred to APD) > > > I think APD is simple enough, and DNCP is also simple enough. > Technically > > > there is almost no difference between DNCP and APD. > > > > True, but APD has IMO unnecessary components of stateful nature, like > > prefix return message. > > > Now I see what you mean by "statefull" :-) > I agree with you that you don't need "prefix return" like messages when you > assume only dedicated(fixed) prefix and flat rate access services, and I > guess that is often the case. True. And this can be, to some extent, be remedied by short lifetimes and need be. > But if you assume also non-dedicated(dynamic?) prefix and non-flat rate(per > time?) access services, for exapmle, remote access or roaming services, your > customers probably want "prefix return" like messages, for exapmle when they > want to temporalily stop using IPv6 access to save mony but continue to use > IPv4 access. > > # I don't like this kind of services personally :-), but we should avoid > killing any posibility of new business models. Solutions don't have to cover every corner case. This is IMO one where DHCPv6 could be useful, due to its stateful nature. > > > It assumes only P-to-P enviroment. Again you need another solution for > > > non-P-to-P enviroment. Our goal is to achieve auto-configuration, right? > > > Then, how dose a CPE know whether it is conneted to P-to-P link or > P-to-MP > > > link automatically? > > > > Prefix Delegation need not be (IMO) completely automatic: it's completely > > ok to have to add a 'request-prefix interface eth0', 'request-prefix > > interface any', or whatever in the configuration of the CPE. > > I agree with you that Prefix Delegation doesn't have to be 100% automatic. > > But I still don't think that it is a better idea to define different > mechanisms for P-to-P and non-P-to-P respectively, because, for example, it > is difficlt for a CPE to know whether its eth0 is connceted to P-to-P > ethernet or non-P-to-P ethernet. In non-P-t-P case the security is important (assuming that multiple customers share one ethernet medium); the other case might be more than one ISP in one non-P-t-P medium but with only one customer. In both cases, security associations (e.g. manually keyed ones) could be built which would protect (mostly at least) from unwanted queries and responses. If not via IPSEC, the packets would have to contain some form of identification other than addresses anyway. In the first case, instead of all-routers multicast address,. some other, e.g. "all-delegators" could be used. In the second case, I imagine one would like to use DHCPv6 for policy reasons. Some other issues in non-P-t-P cases could be fixed as well I think; only, I think we'd first have to identify which links are non-P-t-P so we can decide whether this restriction is an important enough one to be required for consideration. Routed ATM? Bridged ATM? Dial-up? Cable? Some Ethernet solutions (which?) ... Potentially, I see only Bridged ATM except some weirder Ethernet ones (e.g. Ethernet to a neighbourhood with one upstream router and all homes there connected to a switch) as possibly problemaic here, but I don't have that deep knowledge on how all of these are used in the world to say for sure. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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] --------------------------------------------------------------------
