A Plea for Architectural & Specification Stability with IPv6

[RJ Atkinson <[e-mail]>]

All,

  When I talk with users (academic, business/enterprise, or
governmental) about IPv6, the single most common concern they
raise is that:

	The IETF keeps changing IPv6.  Clearly IPv6 is not yet
	ready for widespread use until they stop changing 
	the specifications.

  The IETF community is largely one of protocol-minded folks.
As engineers and scientists, we also love to optimise and improve 
things.  There are daily temptations to tweak, edit, change,
and improve IETF protocols -- especially if there is an active
IETF Working Group for a given IETF protocol.

  If folks in the IETF IPv6 WG want IPv6 to be more widely deployed, 
more rapidly deployed, and its capabilities to be more widely used, 
then WE NEED TO STOP CHANGING THE IPv6 SPECIFICATIONS.

  As I say this, I specifically am NOT referring to Fernando Gont's
work, which is important in educating implementers and users about
how to safely implement, deploy, and use IPv6.  I also am NOT referring
to the work in draft-halpern-6man-nd-pre-resolve-addr, since that
I-D can be implemented and used WITHOUT any IPv6 specification 
changes.  I also am NOT referring to potential link-specific
"IPv6 over new-link-type-X" specifications that do NOT change
any of the IPv6 base specifications.

  I AM including a number of other proposals [examples include,
but are not limited to (1) changing every ND implementation merely
to optimise for one broken MAC protocol, (2) changing the IPv6 
architecture that separates IIDs from routing goop in a clean way 
with a change that (a) also reduces the entropy available from the 
IPv6 Privacy extensions, (b) facilitates tracking of users, (c) breaks 
the ability to use CGAs, and (d) breaks the ability to protect ND], 
that were presented last week and that have been topics of discussion 
on this list within the last few weeks.

  My bottom line is that non-security-related changes to the IPv6
standards-track specifications (including ND, ICMPv6, and so forth) 
needs to be avoided.

  By contrast, documenting *optional* implementation optimisations, 
ideally as Informational status documents, is fine.  Documenting security 
issues and ways that those issues can be mitigated also is fine.
Documenting how IPv6 runs over some new type of link layer also is
fine, but again really might be published as Informational status,
rather than standards-track.

Yours,

Ran Atkinson