[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RFC 5006 status






On Mon, 22 Mar 2010, Hemant Singh (shemant) wrote:

-----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.]


So as rogue dhcp server. Rogue-RA draft does not cope with rogue dhcp servers, but similar problem can happen...


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.

It can be assured with consistent configuration. Don't configure differently.


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.

I think BEHAVE and other DNS64 users has to be asked if they are confortable with the RFC 5006 style DNS propagation or not.

Best Regards,
		Janos Mohacsi