How about that one?
(Please reply to the mailing list only)
You wouldn't be posting to the list... 
Received: from [77.105.232.43] (port=53699 helo=fredan-pc.localnet)
by mail.fredan.se with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.71) (envelope-from<fredan-nanog@fredan.se>)
id 1QURHg-0004ZJ-4d
for nanog@nanog.org; Thu, 09 Jun 2011 00:31:32 +0200
Well, that's another problem.
To make a long story short, the network (not mine and I don't have any kind of
control over that either) that my customers (including me) are using, did put
in new equipment (a switch) over a year ago and after that I lost my IPv6
connection that I had previously. That switch does not support IPv6 it turns
out.
This is exactly the things that the customers really need to better understand
and why it's not gonna work for them.
You did miss a thing:
$ dig mx fredan.se
;; ANSWER SECTION:
fredan.se. 3597 IN MX 10 mail.fredan.se.
;; ADDITIONAL SECTION:
mail.fredan.se. 3597 IN A 77.105.235.102
mail.fredan.se. 3597 IN AAAA 2001:4db8:e001:ffff:2::17
So I do have a IPv6 connection but not to my customers.
Dumb question.. what does the switch (L2) have to do with IPv6 (L3), or is it one of those 'somewhere in between the two' things?
Paul
IPv6 has its own ethertype. (0x86DD) see the list: http://en.wikipedia.org/wiki/EtherType
We've also encountered old IOSes that didn't forward Ethernet frames that contained IPv6 payload.
Well, a modern switch should work fine, even if not directly IPv6 aware,
but it won't understand multicast and will generally flood multicast
frames to all interfaces. So definitely stipulate IPv6 capability, even
for switches....
Regards, K.
And it won't have DHCPv6 snooping, or tools to mitigate rogue RAs.
Tim
Wouldn't the multicast flooding be just like broadcasts tho? Some of
my sites don't have switches that will be upgraded or upgradeable to
software that will support IPv6 directly (at least not for a few
years). Is that going to cause major headaches? I under stand the RA
risks but the DHCPv6 snooping I'm not too clear on.
Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts?
Hi Iljitsch,
The switches from Extreme Networks do MLD and MLD snooping, I know for sure on the x450's and up, probably below that line as well.
Erik Bais
Cisco has had MLD snooping support for some time. But they seem to
have broken it in a recent release, so it drops ND traffic and breaks
IPv6; been after them to fix it, but doesn't look like it's been
resolved yet.
But you're correct that without MLD snooping IPv6 ND traffic is on par
with IPv4 broadcast traffic and not a major problem. It does mean,
however, that a large IPv6 multicast stream, like video or system
imaging, would be about as bad as doing so on IPv4 without IGMP
snooping.
Iljitsch,
Of course the ethernet hardware in the host will filter multicast packets the host isn't listening for, so it just wastes some bandwidth on ports where the traffic isn't needed. This is unlike ARP, each ARP packet wakes up the CPU.
While I certainly agree it is not a major problem, it should be _even less_
of a problem than ARP. Yes, the non-MLD-snooping switch forwards all
multicast to every port - but the other end of those cables (the nodes
plugged in to the switch) don't need to process the frame at all - not
listening for that MAC. Compared to ARP, where the frame is picked up and
handed to layer3/IPv4 before being discarded.
/TJ
Nice. Juniper went a step farther - IGMP snooping breaks some IPv6
multicast on EX series (e.g. DHCPv6).
Chasing JNPR since November... Not a priority for them to fix though,
I think it's "planned" for end of this year in 11.4 or so. Who needs
DHCPv6 while using IGMP snooping anyway, eh?
So if IGMP snooping already breaks IPv6, I'm really looking forward to
upcoming MLD snooping bugs
Best regards,
Daniel
PS: PR/456700 - "closed" state and "resolved in" information is bogus,
they don't care to fix that either. It's definately NOT resolved in
10.4R3. And it affects more than just EX8200 - personally confirmed
EX3200 and rumor is "all EX".