is disabled:
1) ICMPv6 destination unreachable/admininistratively prohibited.
2) Other ICMPv6 destination unreachable.
3) Silent discard.
I vote for 3 but I could be convinced about 1 or 2. It appears that
IPv4 is supposed to do the equivalent of 1.
Tim Hartrick
description. Please
correct me if I am wrong about this.
I'll agree with this. But should we take this to the next logical step,
i.e. just define one bit?
I disagree with this. If it will prevent such talk we should add a
reference to DHCPv6-lite.
Can we ship this spec. Please.
Tim
the hosts on a network to implement something or if they
have implemented it, enable something. They can't. Jeeze, what a sorry
state of affairs.
Tim Hartrick
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
On Wed, 2005-06-01 at 11:29, Soliman, Hesham wrote:
It would be better than what's there now, but ideally, the
text should
just be removed entirely.
Doing address resolution on multiple links
can lead to ambiguous results. There could be multiple destinations
responding to
Bob,
On Mon, 2005-05-23 at 09:48, Bob Hinden wrote:
Part of me is starting to think that we might be better off waiting for
there to be more operational experience with deployments of DHCPv6 to see
how much confusion there really is. I agree it is good for vendors to
implement similar
Jinmei,
On Mon, 2005-05-23 at 14:23, JINMEI Tatuya / wrote:
More than part of me is thinking this. It seems to me that there is a
continuing confusion about how these bits interact with local decisions
by the administrator of a specific machine or network. People are
asking
until the bugs become features. The answer is to
fix the the implementations.
Tim Hartrick
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
of unimplemented or not widely implemented
implementation options is overkill.
Tim Hartrick
Mentat Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
is wrong and should be corrected.
Tim Hartrick
Mentat Inc.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
not clear, not to open every
feature for the full-scale debate and revision. There is running, shipping
code that makes use of these bits. What, exactly, is the upside in breaking
that code?
Tim Hartrick
Mentat Inc.
IETF IPv6 working
Greg,
Backward compatability shouldn't really be a problem.
Hosts which are doing RFC2461 Router Discovery
will understand RAs with options or bits in them
indicating solicitation or completeness, but just not
be able to access the improved function.
If a host that understands the new
well.
Is there some reason why we wouldn't want to add a new bit, say the
Complete bit, to the reserved field of the router advertisement? I realize
I just finished ranting against adding new bits but using one of the reserved
bits for this purpose seems cleaner to me.
Tim Hartrick
Mentat Inc
features
our grand children will be working on it.
Just my $.02
Tim Hartrick
Mentat Inc.
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
13 matches
Mail list logo
