Hi Thomas,
Thomas Narten wrote:
> Do folks think this above is a significant issue?
I just finished writing & documenting a v6 stack for embedded systems.
My employer will be selling it as C source code, along with technical
manuals explaining how to port the code. My experience is that many of
our customers will go through every source file and structure in an
effort to understand all the details of what they are preparing to field
and support.
I currently have a site-local address field in my interface structure,
right alongside link-local and global addresses. There's also a few
paragraphs in the manual explaining why the field is there and how it is
initialized. If site local addresses disappear from the RFCs, I know
from experience that I'll have customers calling our support team and
asking what these fields are and how they should be initialized.
If the vote is to deprecate these addresses, we (my employer) will take
a hit even if we delete these fields from the sources and documents the
same day the RFC is blessed. There will always be some customers using
the older RFCs, or testing against older v6 implementations, and they'll
want to know where the site-local support is.
This issue is not big enough that anyone should brain damage IPv6 over
it, but it's actually part of a larger issue - the credibility of IPv6.
If this WG decides that site-local addresses really serve no purpose
after specifying them since 1995, it will not give the developers and
users of the world warm fuzzies about the stability of IPv6. This debate
has already generated amusement and cynicism among my v4-only
co-workers.
I have not voted yet, since there's good reasons on both sides; and
I've never had the experience of renumbering or merging a large IPv6
network. What I'd really like to see is site locals left in the spec,
but issue a recommendation that they be avoided, by both developers and
users, until their use is better understood.
Sorry to bore you with my personal problems, by you asked :-)
-JB-
Thomas Narten wrote:
>
> Hi James.
>
> > However, I believe some of the resistance to deprecation may be the
> > result of people who have implementations and would rather not have
> > to pay the costs of ripping out that code and putting in something
> > new.
>
> This I don't understand. AFAIK, there is little or no code to rip
> out. And if the code is there, but no site-locals are actually
> configured or assigned to nodes, any code related to site-locals
> doesn't get executed and is harmless. So I don't see what problem
> there is with deprecating them with regards to existing
> implementations. I don't imagine anyone is going to say we need to put
> wording in some spec that makes existing implementations that have
> code related to site-locals be declared non-conformant. That would be
> silly.
>
> Do folks think this above is a significant issue?
>
> Thomas
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
--
-JB-
#############################################################
H
(==)o(==) H John Bartas - Main Propeller head
_I_ H InterNiche Technologies Inc. (408) 257-8014 x219
/ \ H 1340 S. DeAnza Blvd. Suite 102
----- H San Jose CA 95129
O O H [EMAIL PROTECTED]
" H www.iniche.com
\___/ H
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
