Charles E. Perkins a écrit :
[...]
Alexandru Petrescu wrote:
Charles E. Perkins a écrit :
[...]
So far the only hard problem seems to be how to avoid squabbling over
whether link-locals are needed.
I am not sure why the proponents of necessity are so adept at
ignoring the solutions that do not need link-locals.
It's very simple why: I have a prototype which involves protocol
extensions (RA) only on the parts of the System which use exclusively
link-locals addresses. You forbidding link-local addresses equates
with
forbidding my protocol extensions on the core of my prototype, makes
all break.
I _do not_ forbid link-local addresses. I'm not even one of the
document authors, and I didn't create that language.
But the document does not forbid link-locals either.
Well it does, here is how:
draft-baccelli says:
Note that while link-local addresses are assumed to be "on link", the
utility of link-local addresses is limited as described in Section 6.
The word "limited" strikes.
draft-baccelli says:
o A subnet prefix configured on this interface should be of length
/128.
The link-local prefix of IPv6 LLs is fe80::/10, and not /128.
draft-baccelli says:
o Any [IPv4] subnet prefix configured on this interface should be
of length
/32.
Yet the prefix of the IPv4 LL is 169.254/16, and not a /32.
draft-baccelli says:
Note that the use of IPv4 link-local addresses [RFC3927] in this
context should be discouraged for most applications
"Discouraged" means discouraged. And which "context"? The word
"context" appears precisely once in the draft.
These 4 things make me think the draft-baccelli co-authors and Editors
want to forbid the LLs.
How do we fix these 4 things such that I don't misunderstand them again?
Alex