Thanks for the discussion. Inline please. On Thu, Dec 1, 2011 at 7:23 AM, Lorenzo Colitti <lore...@google.com> wrote:
> On Wed, Nov 30, 2011 at 13:30, Brian E Carpenter < > brian.e.carpen...@gmail.com> wrote: > >> To me this is a killer argument. A general solution that is applicable >> to all deployment scenarios is vastly better than a free-for all of >> vendor options, which will increase the implementation burden for >> everybody and reduce the chances of smooth zero-conf operation. >> > > Actually, what decreases the implementation burden is not having the > option at all. The use cases I've heard so far for this option are all a > bit specious and I think they are outweighed by the harm that would be > caused if this option were to get into general use. > Form the discussion in this thread, the use cases exist in BBF and cellular network, apply to host and RG/CPE and are met by individual user and network operators. To me, they are not specious. > > The reasoning goes something like this: > > 1. The option is defined. > 2. OS foo implements it. > 3. Some network, somewhere, decides that they're only going to use DHCPv6 > for routing, because they only support OS foo. > 4. Other OSes are forced to implement the option because if they don't, > they are at a disadvantage compared to OS foo > 5. Once all OSes implement it, some other network, somewhere else, decides > that they're only going to support DHCPv6 for routing because it's easier > and because it matches what they do in IPv4, so they turn off RAs. > You need not worry about turning off RAs. RA is mandated for mobile host to abtain /64 prefix in cellular network. While, for DHCPv6, you anyway need to switch on it IMHO. When you enable the tethering feature, the mobile host shall use DHCPv6 for prefix delegation. > Then we have a problem, because DHCPv6 has much less rich semantics than > RAs in the general case. A few examples: > > - DHCPv6 is static. A lease is a promise and it can't be deprecated except > by the server that originally made the promise. If that server is not > around any more, or if clients don't support reconfigure, it can't be > deprecated at all. You can work around this with short lease times, but > that creates a scaling problem on the DHCPv6 server, because it's > centralized. > - The way the standards and the clients are written, clients pick one > DHCPv6 advertise and stick to it. So they can't merge multiple sources of > information. > - DHCPv6 does not share fate with routing; in fact, it has no knowledge of > routing. > - The combination of the fact that you can't merge multiple sources of > information and the fact that you can only provide static information means > that you're basically forced to hand out stuff that doesn't change. If > you're using DHCPv6 to set the default router, that basically means you're > forced to use VRRP or NAT if you want any sort of redundancy. > > To me, the lack of functionality that will result if we take the path of > least resistance described above far outweighs the benefits of being able > to configure [default] routes and on-link prefixes on a per-host basis. You > can do this in lots of other ways, for example assigning the hosts you want > to treat differently to different VLANs. > Here we discuss host with multiple interface. I am not sure how VLAN can be used here. This also introduced the extra complexity. > > >> 2) Per user/host configuration makes DHCPv6 be used for the >> >> on-demand configuration. >> >> RA/RIO does not meet this requirement, which is a real requirement >> in networks with heterogeneous types of host. DHCPv6 does meet this >> requirement. >> > > You can use selective unicast router advertisements for this if you want. > There's no reason you can't look the RA properties in RADIUS. And of > course, you can put the separate hosts on separate VLANs (which is probably > the right thing to do in general). > If you use selective unicast RA for those on-demand subscribers, you are more likely using RA in a stateful way. The benefits of RA is lost. Regards, Tao > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > >
_______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
