On Thu, 30 Nov 2006 23:09:10 +1100,
Hesham Soliman [EMAIL PROTECTED] said:
Substantive:
Some of other standards track documents have extended ND. Some of
these extensions should be mentioned in this document, as some of them
seem to actually update this document.
= We discussed these
On Thu, 30 Nov 2006 23:09:10 +1100,
Hesham Soliman [EMAIL PROTECTED] said:
The set of addresses assigned to an interface may change over time.
New addresses might be added and old addresses might be removed
[ADDRCONF]. In such cases the node MUST join and leave the
On Wed, 29 Nov 2006 14:48:40 -0500,
Ralph Droms [EMAIL PROTECTED] said:
How, exactly, is this padding encoded? And, why bother?
See the length field:
Length 8-bit unsigned integer. The length of the option
(including the type and length fields) in units of
8 octets. The
= Yes to both questions I think. If we didn't point to
MLDv1 then the
change woulod not be backward compatible. I.e. using MLDv2
only would break
old implementations. As for the second question, I agree
that it makes MLDv2
normative but I was hoping the or would get us out of
But, I was shouted down, so I don't oppose it either.
Perhaps, but this also makes it sound like there were now compelling
reasons to oppose the change.
Fact is, the IPv6 WG made the decision a long time ago (10+ years?)
that even if snooping bridges are an abomination (and many people
think
Meanwhile. If I remember correctly, this sentence was added due to a
claim from someone who argued it is not clear that joining a
multicast
group normally involves MLD (whether it's v1 or v2)
operations.
Perhaps it was me? I opposed the need to use MLD (of any kind) for
Erik Nordmark wrote:
Thomas Narten wrote:
CurHopLimitThe default hop limit to be used when sending
(unicast) IP packets.
why only unicast? seems like this should also apply to multicast. Are
the default values for multicast different than unicast? (I
On Fri, Dec 01, 2006 at 03:33:59PM +0200, Markku Savela wrote:
I was countered that these MLD's were needed for some intelligent
bridges to get neighbor discovery work. My view was that such layer 2
sniffing devices should not generate requirements to IP layer, and all
information for them
Just as a general intuition, I'm concerned that the IPv6 suite is becoming
less careful over time about the use of soft state inferred from snooping
various protocol interactions. IMHO, inferring soft state is OK, as long as
that state is an optimization and not a requirement for system
Ralph Droms wrote:
Just as a general intuition, I'm concerned that the IPv6 suite is becoming
less careful over time about the use of soft state inferred from snooping
various protocol interactions. IMHO, inferring soft state is OK, as long as
that state is an optimization and not a requirement
10 matches
Mail list logo
