[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fourth alternative [was Re: Moving forward ....]
I'm going to poke my nose into this thread in hope of alleviating some
possible misapprehension concerning interpretation of the original "fourth
alternative" text. Please see below for comments.
On Tue, 19 Aug 2003, Erik Nordmark wrote:
> > It's from my reading of the discussion (on the mailing list and in the
> > meetings) and the fact that the working group decided to accept
> > <draft-hinden-ipv6-global-local-addr-02.txt> as a working group document in
> > Vienna.
> I didn't know there were such side effects associated with accepting that
> as a WG document.
> My assumption was that it was a fine thing to work on possible replacements
> and to understand the cost/benefit tradeoffs of such replacements.
> But presumably the WG should be capable to still say "we don't like any of
> Your logic seems to preclude such a conclusion.
>From a review of previous messages in this thread, the text which seems to
have trigged the above is:
>Furthermore, based on the record of the question from the minutes of the SF
>meeting and the question put to the ipng mailing list, how was this
>conclusion arrived at:
>>A fourth alternative is to not replace site-local addresses in any form,
>>but I think the working group has made it clear that this is not a
As I interpret Bob's text cited at the head of this note, the citing of
the decision to accept <draft-hinden-ipv6-global-local-addr-02.txt> as a
WG document is evidence in support of the assertion that the fourth
alternative (specifically, to decline to replace site locals in any form)
has not found any credible level of support in the list. As I interpret
the history, and based on my memory of the tenor of disussions at Vienna
(yes, I snuck in), the decision to accept said draft as a WG document was
a direct result of the WG collective opinion that one or more alternatives
to SL are clearly necessary, and that
<draft-hinden-ipv6-global-local-addr-02.txt> offers at least the potential
of a workable alternative. Based on this sequence and history, the
decision to accept the Hinden draft was a consequence, rather than the
origin, of the disapprobation of the suggestion to deprecate Site-Locals
without pursuing work on suitable replacements for local addressing
allocations. As I remember the discussions, it is not Bob's logic, but
rather the collective logic of the group as demonstrated in the WG
decision (expressed as a show of hands), which precludes the conclusion
that SL may or should be deprecated without some provision for work on
viable alternatives. Notwithstanding the very strong IETF tradition of
stare decisis, it is possible (although not, IMO, likely) that after
discussion we will conclude that we cannot find a workable alternative.
Should we reach this eventuality, we will have, if deprecation of SL
proceeds before viable alternatives are codified, exactly the condition
postulated in the fourth alternative; but that is, as I read the history,
clearly _not_ the intended outcome. (If anyone is brave enough to attempt
a diagram of that last sentence, I'd love to see the result. ;-( )
> FWIW, I think a multi6 solution with id/loc separation will make the
> local addressing concerns go away.
While a multi6 solution such as you suggest above would undoubtedly
obviate one set of requirements which drive demand for local addressing,
other requirement sets now extant will not be obviated thereby; the demand
for local addressing will persist until _all_ requirement sets which drive
that demand are satisfied by other solutions. Some of these requirement
sets (such as address stability and address portability for enterprise
networks across ISP changes) are perhaps less amenable to engineered
solutions than are the multihoming issues.
I devoutly wish that the issue of local addressing were so straightforward
that a single solution would resolve the issue entirely; sadly, that does
not appear to be the case, based discussions in this WG.
Alan E. Beard <firstname.lastname@example.org>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
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@example.com