Folks, I can't speak on behalf of all cable operators, but I can provide my own current perspective on IPv6 and the M/O flags.
There are three primary types of DHCPv4 clients in cable networks today: cable modems, functional entities co-resident with the cable modems (such as PacketCable MTA VoIP endpoints, CableHome gateways, etc.), and customer computers and other customer-controlled equipment. For our business, we want the ability to control which prefixes were assigned to which customer devices. For example, we may want to assign different prefixes to devices corresponding to non-customers and to "not-yet-customers" (those that will self-provision their service). Our current plans are that cable modems and co-resident functional entities would use DHCPv6 for stateful address configuration as part of their own boot process. DHCPv6 would also provide information for configuration downloads, time servers, and domain name servers (as needed). I don't think we would want to use address autoconfiguration for those devices/entities. Customer computers and other customer equipment tend to be a little trickier, since such devices may be used in different service provider contexts (e.g. wireless, where bandwidth is much more precious than in cable), and since OS developers don't always worry about service provider network requirements (especially if they are focused on personal computing or enterprise network/IT requirements first). One possible approach is that cable modems (or some subset of cable modems) would use DHCPv6 prefix delegation (PD) to get a customer-specific prefix, which could be learned by customer computers through address autoconfiguration (e.g. the cable modem would become an IPv6 router). The customer computers could use DHCPv6 (ala RFC 3736) to obtain additional parameters (e.g. domain name servers), but DHCPv6 use would be optional for network access. This plan presumes that PD scales for our customer base, which today is largely residential broadband customers. The other approach is that each customer computer would use DHCPv6 for stateful address configuration. This matches our current IPv4 deployment model where every customer computer is a DHCPv4 client of our DHCP servers. But this approach would mandate DHCPv6 use for network access, which may be fairly painful when there are few/no DHCPv6 client implementations in OS's today. :^( What does that mean for the M/O flags discussion? I suspect we might try to deploy both approaches for customer computer address allocation, which would imply that we would want to use something like the M/O flags to signal to customer computers when DHCPv6 is necessary for network access, and when it is not. While we expect cable modems to use DHCPv6 exclusively, I have heard of other cable operators that want to experiment with address autoconfig for cable modems -- although to be honest I am not really sure how that would work. I would think it is our responsibility (as service providers) to set the M/O flag settings correctly and appropriately on our edge routers (CMTSs). Hope this perspective helps. -- Rich -----Original Message----- From: Bernie Volz (volz) [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 25, 2005 1:55 PM To: Woundy, Richard; Iljitsch van Beijnum; Thomas Narten Cc: [email protected]; IETF IPv6 Mailing List Subject: RE: [dhcwg] Re: purpose of m/o bit So Rich, I'll ask. What would you like to see happen? - Bernie > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Woundy, Richard > Sent: Wednesday, May 25, 2005 1:39 PM > To: Iljitsch van Beijnum; Thomas Narten > Cc: [email protected]; IETF IPv6 Mailing List > Subject: RE: [dhcwg] Re: purpose of m/o bit > > >All of this, coupled with the fact that, AFAIK, no OS implements > DHCPv6, means that there is essentially zero experience with DHCPv6 in > the operational community. This means that at this time, there is > little point in asking the operational community what should happen > with the M > and O bits. > > Or perhaps this could be the ideal time to ask the > operational community > what should happen with the M and O bits -- before software developers > go too far down a particular direction without operator guidance? > > Some of us operators do more than just configure and test vendor > products. > > -- Rich > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Iljitsch van Beijnum > Sent: Wednesday, May 25, 2005 5:43 AM > To: Thomas Narten > Cc: [email protected]; IETF IPv6 Mailing List > Subject: [dhcwg] Re: purpose of m/o bit > > > [Crossposted to dhcwg even though I'm not on that list, as people > there may be able to add some useful insights.] > > On 24-mei-2005, at 16:45, Thomas Narten wrote: > > > I wonder if there is key question here that the community > has simply > > not agreed on (yet), and that that question is at the heart of all > > this "confusion". > > > Does the community feel that operators need RA bits that > > control/indicate whether a client is to invoke DHC? That > is, is there > > a need for the sys admin to signal to client whether DHC is to be > > invoked? > > By a strange coincidence, I spent most of the day yesterday taking > several DHCPv6 implementations for a test drive, for reasons > unrelated to this discussion. > > These implementations are: KAME DHCP6, the unnamed Linux fork of the > KAME implementation at http://dhcpv6.sourceforge.net/ and the Cisco > IOS implemenation. > > Conclusion: the Cisco implementation is incomplete (no address > assignment) and the other two are too immature to be of much use. > > I'm impressed with the prefix delegation functionality, but as > before, the prospect of running such a complex protocol just to > optain a domain search list and some DNS resolvers makes me very > uncomfortable. > > All of this, coupled with the fact that, AFAIK, no OS implements > DHCPv6, means that there is essentially zero experience with DHCPv6 > in the operational community. This means that at this time, there is > little point in asking the operational community what should happen > with the M and O bits. > > In other words: this is not the time declare the bits useless and > remove them. > > > Second, is it important that such a signal be honored by clients? > > (That is, if clients end up mostly ignoring the flags, does their > > presence become useless?) > > Depends. There are three possible ways this can play out: > > - the DNS resolver issue is solved in a way that doesn't requite > DHCP, so most people don't don't run DHCPv6 at all, others > run it all > the time -> no bits necessary > - the DNS resolver issue isn't solved in another way, so everyone > runs some form of DHCPv6 all the time -> no bits necessary > - DHCP provides benefits but some people are reluctant to use it -> > helpful to know whether to bother running DHCPv6 > > > For example, should the sys admin be able to say "do not run DHC, > > doing so wastes local resources and won't get you any config info"? > > (And should that be honored by clients?) > > I think it's good to recognize that in the past, there have often > been security issues with non-text based UDP protocols, so knowing > there is no need to run DHCP and then not running it would be good > security. > > > Fundamentally, it is only the access network that has knowledge of > > whether running DHC is useful. Thus, by default, clients (arguably) > > can't know whether running DHC is useful, so by default they shold > > invoke DHC (unless the sys admin signals "don't invoke DHC"). > > > Or (switching the argument), by default, client should not > invoke DHC, > > > unless the local sys admin indicates doing so is appropriate. > > There isn't really a difference here, except for what happens when > there are no RAs. > > I would be interested in hearing viewpoints on the usefulness of > running DHCPv6 even though the hints indicate that there is > no need to. > > _______________________________________________ > dhcwg mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
