Hi Martin,
[chop]
Perhaps it would be simpler just to add some text saying that
Ethernet NICs that do not support 33 multicast may not (cannot?) be
able to support v6?
"cannot" is too strict. IPv6 is a big thing. Only a certain form of
easy stateless autoconf is not supported if the 33 multicas
Hi Alex,
Alexandru Petrescu wrote:
Greg Daley wrote:
I think that Alex was thinking about end hosts which don't support IPv6.
YEs, hosts that support v4 ok and can't support v6 because of the 33
requirement of RA (RAs must be sent to 33:33:0:0:0:1 by this RFC).
Receiving an initial RA is essential
Hi Bob,
On Tue, 01 Mar 2005 11:28:24 -0800
Bob Hinden <[EMAIL PROTECTED]> wrote:
> Mark,
>
> >As Martin Dunmore suggested -
> >
> >"Perhaps it would be simpler just to add some text saying that Ethernet NICs
> >that do not support 33 multicast may not (cannot?) be able to support v6?"
>
> Doesn
Christian,
[No hats on]
The practical consequence is that the current multicast based systems,
in practice, do not run well over wireless networks. You may remember
that, in San Diego, IPv6 was initially turned off on the WIFI network.
Too many multicast packets were clogging the network. It could
Mark,
As Martin Dunmore suggested -
"Perhaps it would be simpler just to add some text saying that Ethernet NICs
that do not support 33 multicast may not (cannot?) be able to support v6?"
Doesn't this also mean that these NICs don't completely support IEEE
Ethernet either? I haven't looked in a w
> > MAC-layer filtering should be used when available, but the entire
IPv6
> > ND should not rely on its existence. IPv6 ND should work with plain
> > broadcast as well.
>
> It's my recollection that (8 years ago, for RFC 1972) we took
> a very conscious decision *not* to do this. Many of us had
Alexandru Petrescu [EMAIL PROTECTED] wote:
> >>> In that case, there will be old cards which can't support 33:33
> >>> MAC addresses. Perhaps it is well to note that these cards
> >>> won't be able to run IPv6.
> >>
> >> Ok, so that's an option. Another is to just say that when 33
> >> mult
On Tue, 2005-03-01 at 17:02 +0100, Alexandru Petrescu wrote:
>Jeroen Massar wrote:
>>>Ok, so that's an option. Another is to just say that when 33 multicast
>>>is not available for broadcast, just use ff broadcast.
>>
>>
>> Which is what various drivers already do. Most of the time when you have
On Tue, 2005-03-01 at 09:07, Alexandru Petrescu wrote:
> > I've seen: 1) device driver bugs. either they fail to program the
> > multicast filter or they try and get it wrong. A common multicast
> > filter is a bit vector with associated hash function. (if
> > filter[hash(dst)] is set, recei
David Malone wrote:
On Tue, Mar 01, 2005 at 03:51:34PM +0200, Jari Arkko wrote:
On the other hand, if the problem is in bad drivers (as Bill points
out), this may be a different issue. I guess part of the problem
is that for plain old IPv4 usage multicast features in NICs and the
drivers don't ge
Jeroen Massar wrote:
Ok, so that's an option. Another is to just say that when 33 multicast
is not available for broadcast, just use ff broadcast.
Which is what various drivers already do. Most of the time when you have
a card and RA's don't work, ifconfig eth0 promisc and done.
I don't think 'if
Martin Dunmore wrote:
In that case, there will be old cards which can't support 33:33
MAC addresses. Perhaps it is well to note that these cards
won't be able to run IPv6.
Ok, so that's an option. Another is to just say that when 33
multicast is not available for broadcast, just use ff broa
On Tue, Mar 01, 2005 at 03:51:34PM +0200, Jari Arkko wrote:
> On the other hand, if the problem is in bad drivers (as Bill points
> out), this may be a different issue. I guess part of the problem is
> that for plain old IPv4 usage multicast features in NICs and the
> drivers don't get tested well,
Brian Haberman wrote:
I am not sure what to do in order to deal with such an
interoperability issue. The IPv6 layer has no way of knowing what
the capabilities are of the other NICs on a LAN.
Exactly, that's why I find this difficult.
Do you have a proposal to address such issues?
An idea is to
Mark Smith wrote:
Do you have examples of such hardware / chipsets ? I'd think it'd
have to be really, really old not to have basic multicast and
promiscous capabilities. I'd wonder about the value of introducing
layer 2 broadcasts into IPv6 just to cater for such old and rare
hardware.
Yeah, I thi
Bill Sommerfeld wrote:
Are you able to put a rough date of manufacture on those
cards/chipsets ? I've recently done a bit of looking into the chips
on the old NE2K style cards (the NatSemi NS8390D chipset), and
even they have a multicast filtering capability. I first
encountered them on NICs in
On Tue, 01 Mar 2005 15:51:34 +0200
Jari Arkko <[EMAIL PROTECTED]> wrote:
> Mark Smith wrote:
>
> >Do you have examples of such hardware / chipsets ? I'd think it'd have
> >to be really, really old not to have basic multicast and promiscous
> >capabilities. I'd wonder about the value of introducin
Alexandru Petrescu wrote:
...
MAC-layer filtering should be used when available, but the entire IPv6
ND should not rely on its existence. IPv6 ND should work with plain
broadcast as well.
It's my recollection that (8 years ago, for RFC 1972) we took
a very conscious decision *not* to do this. Many
Mark Smith wrote:
Do you have examples of such hardware / chipsets ? I'd think it'd have
to be really, really old not to have basic multicast and promiscous
capabilities. I'd wonder about the value of introducing layer 2
broadcasts into IPv6 just to cater for such old and rare hardware.
I tend t
> > In that case, there will be old cards which can't support 33:33 MAC
> > addresses. Perhaps it is well to note that these cards won't be
> > able to run IPv6.
>
> Ok, so that's an option. Another is to just say that when 33
> multicast
> is not available for broadcast, just use ff broa
On Tue, 2005-03-01 at 07:38, Mark Smith wrote:
> Are you able to put a rough date of manufacture on those cards/chipsets
> ? I've recently done a bit of looking into the chips on the old NE2K
> style cards (the NatSemi NS8390D chipset), and even they have a
> multicast filtering capability. I firs
I am not sure what to do in order to deal with such an interoperability
issue. The IPv6 layer has no way of knowing what the capabilities
are of the other NICs on a LAN.
Do you have a proposal to address such issues?
Regards,
Brian
On Mar 1, 2005, at 7:58, Alexandru Petrescu wrote:
Brian Haberman
On Tue, 2005-03-01 at 13:53 +0100, Alexandru Petrescu wrote:
>Greg Daley wrote:
>> I think that Alex was thinking about end hosts which don't support
>> IPv6.
>
>YEs, hosts that support v4 ok and can't support v6 because of the 33
>requirement of RA (RAs must be sent to 33:33:0:0:0:1 by this RFC).
Hi Alex,
On Tue, 01 Mar 2005 13:58:44 +0100
Alexandru Petrescu <[EMAIL PROTECTED]> wrote:
> Brian Haberman wrote:
>
> > My experience with ethernet cards and drivers is that if they don't
> > have multicast capability, they map MAC addresses with the group bit
> > on to FF:FF:FF:FF:FF:FF prior
Brian Haberman wrote:
My experience with ethernet cards and drivers is that if they don't
have multicast capability, they map MAC addresses with the group bit
on to FF:FF:FF:FF:FF:FF prior to transmit.
Yep but about the transmitter that _does_ have the multicast capability
and the receiver that do
Greg Daley wrote:
I think that Alex was thinking about end hosts which don't support
IPv6.
YEs, hosts that support v4 ok and can't support v6 because of the 33
requirement of RA (RAs must be sent to 33:33:0:0:0:1 by this RFC).
Receiving an initial RA is essential to configure the stack. Ok, IPv6
Hi Mark,
Wow, let me see if I can dust off the date. The cards I am
referring to were circa 1993-1995. I can't recall coming across
an ethernet chip after 1995 that did not have some level of
multicast filtering ability. YMMV...
Brian
On Mar 1, 2005, at 7:38, Mark Smith wrote:
Hi Brian,
On
Hi Brian,
On Tue, 1 Mar 2005 07:21:37 -0500
Brian Haberman <[EMAIL PROTECTED]> wrote:
> My experience with ethernet cards and drivers is that if they don't
> have multicast capability, they map MAC addresses with the group
> bit on to FF:FF:FF:FF:FF:FF prior to transmit.
>
> On the receive side,
My experience with ethernet cards and drivers is that if they don't
have multicast capability, they map MAC addresses with the group
bit on to FF:FF:FF:FF:FF:FF prior to transmit.
On the receive side, these cards would go into promiscuous receive
mode and then filter at the device driver.
Regards,
Manfredi, Albert E wrote:
Alexandru Petrescu wrote:
Anyone proposed until now to update RFC2464 "IPv6 over Ethernet
Networks"? If not, I'd like to propose updating the following
text:
An IPv6 packet with a multicast destination address DST,
consisting of the sixteen octets DST[1] through DST
30 matches
Mail list logo
