On Sun, 13 Jun 2010 10:31:46 +0800 Fortune HUANG <[email protected]> wrote:
> Hi Mark, > > I think it should be read like this: > Some options would be extended from DHCPv6 to RA, and all those extensions > might be in a single draft. > Some or all of the DHCPv6 options doesn't matter - it's duplicating existing functionality, with no evidence that the existing functionality doesn't work or is unacceptably inefficient. In all the recent discussion regarding the supposed "inadequacies" of DHCPv6, the best people seem to have come up with is "I don't like it". There has been no "we tried to deploy it, but we had this problem, and we see RA DHCPv6 options to be the only solution", or, "on our embedded platform with X KB of RAM, we couldn't fit a stateless DHCPv6 client". In other words, I think the people who want to add these sorts of options into RAs are obligated to prove, not just hypothesise, that existing methods aren't adequate. I have great concerns that reinventing how end-nodes are configured, (and that is what putting DHCPv6 options in RAs is), is only going to further create yet another reason for people to delay deploying IPv6. I'm working on a deployment of IPv6 to 100K+ ADSL residential subscribers. If there is any introduced doubt or confusion at this point in time as to the methods and machanims will be used to provision end-nodes, then it is safer for organisations like the one I'm working with to halt their deployments until there is a clear and single direction. I don't want to have to be in the position to recommend stopping deployment, yet I'll have to if I think that organisations I work with are about to go to a great expense to deploy services and supporting infrastructure that will be obsolete in only a few years time. As a protocol, IPv6 is supposed to ready to be deployed, and I broadly think it is - all the functions required to provision commercial residential IPv6 services are specified and code exists. The "rough consensus and running code" threshold has been met. People may feel the need to "tweak" it, however I don't think they realise the hidden and significant costs those "tweaks" will create to existing and near future deployments, including the possibility of causing those deployments to stop. Have a think about the following post, regarding detecting rogue DNS server addresses or rogue DNS domains in rogue RAs, and then consider that the same problem will occur with any and all other options that may be added to RAs. Bear in mind that the devices are intended to do rouge RA detection are layer 2 devices. Think about how hard it is for a layer 2 device to inspect a packet type verses inspecting the values of options (that may or may not be present) for validity. Think about the question of whether it be acceptable to upgrade the firmware in all layer 2 devices every time a new RA option is defined, and whether it is reasonable to have to configure all layer 2 switches with all the values for RA options so they can inspect them for validity. http://www.ops.ietf.org/lists/v6ops/v6ops.2010/msg00756.html Regards, Mark. > Best regards, > Fortune > > -----Original Message----- > From: Mark Smith [mailto:[email protected]] > Sent: Sunday, June 13, 2010 9:55 AM > To: Fortune HUANG > Cc: [email protected] > Subject: Re: Question about SLAAC: how the host determines the > prefixesallocated from different prefix pools > > Hi Fortune, > > On Sun, 13 Jun 2010 08:31:47 +0800 > Fortune HUANG <[email protected]> wrote: > > > > > Hi Mark, > > > > As discussed in my previous emails, this is an improvement to RA. > > 1) The service type of the prefix is the property of a prefix, it > > should be carried in RA rather than stateless DHCP. > > 2) The RA approach has the advantage that the server doesn't need to > > maintain the states of each host, while the stateful DHCPv6 approach > > doesn't have. > > > > So, according to the text you quoted, we should not reject this > improvement. > > > > This was the text I was referring to - > > "but also DNS, SNTP information, VLAN/service etc then a proposal combining > all the options in a draft can be made to WG." > > I read that as a proposal is going to be made to provide all DHCPv6 options > in RAs. Is that the case? > > Regards, > Mark. > > > Best regards, > > Fortune > > > > > > -----Original Message----- > > From: Mark Smith > > [mailto:[email protected]] > > Sent: Friday, June 11, 2010 4:57 PM > > To: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) > > Cc: Fortune HUANG; 'Brian Haberman'; [email protected] > > Subject: Re: Question about SLAAC: how the host determines the > > prefixesallocated from different prefix pools > > > > On Fri, 11 Jun 2010 11:40:49 +0530 > > "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" > > <[email protected]> wrote: > > > > > Hi Fortune, > > > > > > Perhaps TR-177 discussion on broadband forum would be a more > > > appropriate > > place for this discussion. > > > > > > If operational model is clear (i.e. which parameters need to be > > > provided through RA) not just service/prefix but also DNS, SNTP > > information, VLAN/service etc then a proposal combining all the > > options in a draft can be made to WG. > > > > > > > http://www.ietf.org/rfc/rfc1958.txt > > > > "Architectural Principles of the Internet" > > > > "3.2 If there are several ways of doing the same thing, choose one. > > If a previous design, in the Internet context or elsewhere, has > > successfully solved the same problem, choose the same solution unless > > there is a good technical reason not to. Duplication of the same > > protocol functionality should be avoided as far as possible, without > > of course using this argument to reject improvements." > > > > > > > -- > > > Shree > > > > > > -----Original Message----- > > > From: Fortune HUANG [mailto:[email protected]] > > > Sent: Friday, June 11, 2010 6:30 AM > > > To: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK); 'Brian Haberman'; > > > [email protected] > > > Subject: RE: Question about SLAAC: how the host determines the > > > prefixesallocated from different prefix pools > > > > > > Hi Shree, > > > > > > Sorry for the late reply because I was on a bussiness trip yesterday. > > > > > > The reason I propose to extend RA is because that DHCPv6 may not be > > > available in some scenario. > > > If the extension is simple enough, it may be worthy. > > > > > > > > > Best regards, > > > Fortune > > > > > > > > > -----Original Message----- > > > From: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) > > > [mailto:[email protected]] > > > Sent: Wednesday, June 09, 2010 9:54 PM > > > To: Fortune HUANG; 'Brian Haberman'; [email protected] > > > Subject: RE: Question about SLAAC: how the host determines the > > > prefixesallocated from different prefix pools > > > > > > Hi Fortune, > > > > > > Why extend RA to achieve something that's already available through > > > DHCPv6 (a proven operational model) ? > > > > > > -- > > > Shree > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list [email protected] Administrative > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
