Hi Fortune, On Thu, 17 Jun 2010 10:02:08 +0800 Fortune HUANG <fqhu...@huawei.com> wrote:
> Hi Mark, > > I think DHCPv6 and RA fit in different scenarios. If DHCPv6 without RA is > perfect for some scenario, just use it. You cannot use DHCPv6 only - RAs are essential for announcing one or more routers availability onto a link. > But recently I had some conversations with some network operators, RA is > preferred in some scenario because the DHCP server don't need to maintain > the state of each terminal. > RAs + Stateless DHCPv6 is completely stateless. IPv6 has both stateless and stateful end-node configuration methods. It is unfortunate that that is the case, rather than just one single method - either stateless or stateful. The reason is that some users of IPv6 want "database" driven address assignment and configuration i.e. stateful IPv6, while others want lower resource stateless. That is unfortunate complexity that we already are going to have to wear the cost of. By making RAs do what stateless DHCPv6 already does is further complexity that fundamentally doesn't achieve anything new - other than creating more things that can break, and more points of failure. In fact it does less - there are no proposed methods for how router per-interface RA option configuration updating can be centralised, yet they already exist for DHCPv6 (by having router interfaces act as DHCPv6 relays). So after people work out RA options, they'll then think about how to scale distributing the configuration for them ... and then they'll have completely re-invented stateless DHCPv6. The fundamental result will be two near equal methods of achieving the same thing, and twice as many possibilities for misconfiguration, arbitration between conflicting options supplied by the alternative methods and code bugs. As I said before, it all sounds like "I don't like it" or maybe in your operator case, "I don't fully understand how IPv6 works" reasoning. It seems to me that the challenge of providing hard evidence of failures or inadequacies of existing methods still stands. Regards, Mark. > Best regards, > Fortune > > -----Original Message----- > From: Mark Smith [mailto:i...@69706e6720323030352d30312d31340a.nosense.org] > Sent: Monday, June 14, 2010 2:16 PM > To: Fortune HUANG > Cc: ipv6@ietf.org > Subject: Re: Question about SLAAC: how the host determines the > prefixesallocated from different prefix pools > > On Sun, 13 Jun 2010 10:31:46 +0800 > Fortune HUANG <fqhu...@huawei.com> 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:i...@69706e6720323030352d30312d31340a.nosense.org] > > Sent: Sunday, June 13, 2010 9:55 AM > > To: Fortune HUANG > > Cc: ipv6@ietf.org > > 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 <fqhu...@huawei.com> 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:i...@69706e6720323030352d30312d31340a.nosense.org] > > > Sent: Friday, June 11, 2010 4:57 PM > > > To: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) > > > Cc: Fortune HUANG; 'Brian Haberman'; ipv6@ietf.org > > > 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)" > > > <shrinivas_ashok.jo...@alcatel-lucent.com> 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:fqhu...@huawei.com] > > > > Sent: Friday, June 11, 2010 6:30 AM > > > > To: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK); 'Brian Haberman'; > > > > ipv6@ietf.org > > > > 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:shrinivas_ashok.jo...@alcatel-lucent.com] > > > > Sent: Wednesday, June 09, 2010 9:54 PM > > > > To: Fortune HUANG; 'Brian Haberman'; ipv6@ietf.org > > > > 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 ipv6@ietf.org > > > > Administrative > > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > > ------------------------------------------------------------------ > > > > -- > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > > > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
