RE: RFC 5006 status

["Hemant Singh (shemant)" <shemant@cisco.com>]

>-----Original Message-----
>From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
>Sent: Monday, March 22, 2010 4:35 PM
>To: Hemant Singh (shemant)
>Cc: alh-ietf@tndh.net; IPv6 Operations
>Subject: Re: RFC 5006 status

>I really think you are worrying about things that won't happen in a simple
>unmanaged network where only SLAAC is used.

>In a managed network, surely we can assume consistent management,
>and fairly rapid action when inconsistency arises. We can't design
>solutions that are 100% immune to fat fingers.

Fat-fingering configuration of the RA was icing on the cake for two bigger problem I raised in my emails.  Still fat-fingering is a recognized problem in v6ops with (http://tools.ietf.org/html/draft-ietf-v6ops-rogue-ra-00). Snipped from the Abstract of this draft is the following text:

[However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network.]

The two bigger problems were (a) DHCPv6 and ND being used together in one network and (b) which was that folks sometimes miss that the ND RFC 4861 always refers to default router(s) with a plural.  In both (a) and (b) who wins if a client receives information from two authoritative sources?  I would certainly like such a RFC to be on Standards Track if the community desires it.  But unless potential pitfalls are documented, perhaps with a new paragraph to RFC 5006, and then the document goes thru a IETF review and gets a new RFC number, I am not comfortable with RFC 5006 for Standards Track just yet.  App behavior cannot be assured.  Again, unless I see documents in BEHAVE or other RFCs for DNS64 lookup etc. with specific text for app behavior, I am not convinced app behavior can break domain lookup.  My apologies in advance if I have missed any existing text in this regard for app behavior.

Hemant