How about that one? (Please reply to the mailing list only) -- //fredan
On 6/8/2011 3:31 PM, fredrik danerklint wrote:
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.
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
-- //fredan
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 On 6/8/2011 1:08 PM, fredrik danerklint wrote:
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.
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
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. On 06/09/2011 03:37 PM, Paul Graydon wrote:
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
On 6/8/2011 1:08 PM, fredrik danerklint wrote:
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.
On Wed, 2011-06-08 at 17:37 -1000, Paul Graydon wrote:
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?
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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
On 9 Jun 2011, at 05:36, Karl Auer wrote:
On Wed, 2011-06-08 at 17:37 -1000, Paul Graydon wrote:
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?
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....
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. On Thu, Jun 9, 2011 at 1:55 AM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
On 9 Jun 2011, at 05:36, Karl Auer wrote:
On Wed, 2011-06-08 at 17:37 -1000, Paul Graydon wrote:
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?
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....
And it won't have DHCPv6 snooping, or tools to mitigate rogue RAs.
Tim
On 9 jun 2011, at 6:36, Karl Auer wrote:
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....
Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts?
yes http://www.google.com/search?q=mld+snooping+switch On Jun 9, 2011, at 9:49 AM, Iljitsch van Beijnum wrote:
On 9 jun 2011, at 6:36, Karl Auer wrote:
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....
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 Verstuurd vanaf mijn iPad Op Jun 9, 2011 om 18:49 heeft Iljitsch van Beijnum <iljitsch@muada.com> het volgende geschreven:
On 9 jun 2011, at 6:36, Karl Auer wrote:
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....
Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts?
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. On Thu, Jun 9, 2011 at 12:49 PM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 9 jun 2011, at 6:36, Karl Auer wrote:
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....
Are there any switches out there that do MLDP snooping to avoid flooding IPv6 multicasts?
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On 9 jun 2011, at 19:34, Ray Soucy wrote:
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.
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.
On Thu, Jun 9, 2011 at 13:34, Ray Soucy <rps@maine.edu> wrote:
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. <snip>
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
On Thu, Jun 09, 2011 at 01:34:25PM -0400, Ray Soucy wrote:
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.
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". -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
participants (14)
-
Daniel Roesen -
Erik Bais -
fredrik danerklint -
Iljitsch van Beijnum -
Jeff Walter -
Joel Jaeggli -
Joseph Jackson -
Karl Auer -
Martin Millnert -
Paul Graydon -
Ray Soucy -
Richard Patterson -
Tim Chown -
TJ