RFC 1888 defined a destination option called NSAP Address
with option type code 11-0-00011 = 195 decimal, C3 hexadecimal.
Unfortunately, the IANA Considerations in RFC 4048
faild to discuss this option. It is still listed at
http://www.iana.org/assignments/ipv6-parameters
My opinion is that it
At 01:58 p.m. 07/07/2005, Bob Hinden wrote:
http://kerneltrap.org/node/5382
There is a thread on /. about this today as well. I think most of this is
old news. The new ICMPv6 update that is being worked on has a major
revision to the Security Considerations section that should cover these
On Jul 11, 2005, at 11:54, Elwyn Davies wrote:
Late breaking thought...
Paragraph 2 of Section 7.2.1 of draft-ietf-ipv6-2461bis-03.txt says
that joining and leaving the solicited-node multicast group SHOULD be
done using MLD (and the reference is to RFC2710 i.e., MLDv1). We now
have
On Mon, Jul 11, 2005 at 05:44:20PM -0400, Brian Haberman wrote:
[...]
The main, current benefit of MLDv2 is to support source-specific
multicast
(SSM). However, the NDP use of multicast is non-SSM (ASM or any-source
multicast) and does not need MLDv2 capability in order to function
On Jul 11, 2005, at 18:06, Elwyn Davies wrote:
My understanding that as well as a reference to MLDv2 we would need to
mention that if any of the routers are 'legacy' that support only
MLDv1, then any MLDv2 routers would have to have their configuration
flags set to make them operate in MLDv1
On Mon, Jul 11, 2005 at 06:16:03PM -0400, Brian Haberman wrote:
On Jul 11, 2005, at 18:06, Elwyn Davies wrote:
My understanding that as well as a reference to MLDv2 we would need to
mention that if any of the routers are 'legacy' that support only
MLDv1, then any MLDv2 routers would have
My understanding that as well as a reference to MLDv2 we
would need to
mention that if any of the routers are 'legacy' that support only
MLDv1, then any MLDv2 routers would have to have their
configuration
flags set to make them operate in MLDv1 compatibility
mode. Hosts
