I'm curious about the implementation status. I know the Windows
implementation does not implement the RFC 2462 optimization - it
performs DAD on every address independently. What about other
implementations?
FWIW The Solaris implementation does supress DAD on addresses configured
using the
Date:Mon, 03 Jun 2002 11:32:26 -0700
From:Charles E. Perkins [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| My questions were related whether that model should be our design goal.
Maximum flexibility. Long term we will find a way to use that.
This implies
Date:Mon, 3 Jun 2002 11:46:03 -0700
From:Dave Thaler [EMAIL PROTECTED]
Message-ID:
[EMAIL PROTECTED]
| No. In fact, I would expect that if any prefix is multilink, then all
| of them should be.
Why? I'm no expert on multi-link, in fact, I'm not sure I
My guess is that it will just effectively mean people will not
use multiple prefixes for mobile nodes.
i guess so too, and therefore, i don't feel a need to provide
special hack in DAD. it is not a protocol issue, but an operational
matter.
I agree that we don't need
| My preference is that we just ban DAD optimization in all cases.
That's certainly an option. The new prefix causes several thousand
nodes to all attempt DAD at the same time argument is the one which
makes me hesitant to simply support this without further investigation.
If that is a
Dear list,
this issue is taking much time and ammunition, and it's mostly wasted. We know that
the decision between MUST and SHOULD will be made in the IESG, not here. It all boils
down to interpreting the words of RFC2119.
The make some progress, I'd like to suggest a work plan.
Step 1:
Hesham,
The text looks fine to me.
Regards,
Brian
Hesham Soliman (ERA) wrote:
Hi all,
After some discussion on the list, I'd like to
propose the following text for MLD in the cellular
host draft:
2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6
MLD
After some discussion on the list, I'd like to
propose the following text for MLD in the cellular
host draft:
2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6
MLD may be supported by cellular hosts.
2.9.1 MLD in 3GPP networks
Within 3GPP networks, hosts
Date:Tue, 4 Jun 2002 12:26:31 +0200 (CEST)
From:Erik Nordmark [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| If that is a problem then the MAY for the optimization in RFC 2462
| wouldn't be sufficient as a solution - very few implementations do
| the
Hi Itojun,
i still don't understand why you are trying to impose additional
restriction for link-local multicast groups (maybe i'm dumb).
without MLD joins for link-local multicast groups, default routers
won't be able to know which multicast group the 3GPP node is
interested in. there's no
I've been thinking about the DNS discovery, as well as the larger
service discovery with no 3rd party dependencies issue, for a while.
Just like Steve Deering and many others I'd like the IETF to explore
the larger issue, since I'm very much interested in making the future
Internet more
From: [EMAIL PROTECTED]
i still don't understand why you are trying to impose additional
restriction for link-local multicast groups (maybe i'm dumb).
without MLD joins for link-local multicast groups, default routers
won't be able to know which multicast group the
From: Markku Savela [EMAIL PROTECTED]
Once again, I must have missed something. Why is there ever any reason
to do MLD on any link-local group?
Well, from other posts here, I guess it's to help those switches and
such.
However, it does somewhat bother me, that we have an exact
Here are some additional review comments from various IESG reviewers:
RFC 3155 should be added to the normative refs in my
opinion. I'm not opposed to keeping the non-normative
ref to the 2.5/3G TCP issues draft that started me on
this.
Another reviewer:
Comments on
Thanks Thomas (and the IESG) for the comments.
Some responses inline:
RFC 3155 should be added to the normative refs in my
opinion. I'm not opposed to keeping the non-normative
ref to the 2.5/3G TCP issues draft that started me on
this.
Ok!
2.4.1 says that the host must support receipt of
I think SIIT communication using v4-mapped addresses should be represented
as InetAddressType ipv6(2), and InetAddress of :::x.y.z.q .
What is the relationship between a zone index and an IPv4-mapped IPv6
address? Thanks!
I think that some implementations provide the zone concept for IPv4
Erik,
I know there is considerable prejudice against SLP as a solution to the
general problem, but it certainly is available. It supports discovery
without a 3rd party. The only definitive criticism that I've ever heard
about SLP is the coupling of a directory service function with service
As
Neighbor Discovery operates without relying on
MLD, joining on solicited node and all nodes
multicast addresses is not required.
I read join to mean the action performed on the IP stack to indicate
group membership (e.g. adding the group to the list of groups listened
to and
actually, SLP seems like a much better fit than DNS for the
problem of discovering hosts on an ad hoc network - not just
because SLP is desinged to work without an third-party
server but also because service discovery seems to fit the
likely use model better than host name lookup.
in
actually, SLP seems like a much better fit than DNS for the
problem of discovering hosts on an ad hoc network - not just
because SLP is desinged to work without an third-party
server but also because service discovery seems to fit the
likely use model better than host name lookup.
in
sorry, I was even more confused than that - I got two message
threads from different groups mixed up. please disregard my
previous message.
actually, SLP seems like a much better fit than DNS for the
problem of discovering hosts on an ad hoc network - not just
because SLP is desinged to
21 matches
Mail list logo
