Which is definitely not true in general. Some do that, many do not inspect
beyond 128, some go further.
On Mon, Jun 10, 2013 at 8:09 AM, Arturo Servin arturo.ser...@gmail.comwrote:
There is another conversation in v6ops that mentioned that
switching
ASICs do not inspect beyond 40
That's completely true; many switch chips cannot route on longer than /64
prefixes, so attempting to do so starts to either heat up the software slow
path, or consume ACL entries, or is simply not supported at all. While
this is arguably a bug, it is also pretty much ubiquitous in the current
Ok maybe I'm overstating it a bit... but there are a lot of those chips out
there, and they are painful.
On Tue, Jun 4, 2013 at 9:08 AM, joel jaeggli joe...@bogus.com wrote:
On 6/3/13 3:59 PM, Andrew McGregor wrote:
That's completely true; many switch chips cannot route on longer than /64
There is an issue with using a MAC-based link local address on an interface
that does not have that MAC address, which is that any other interface
using that MAC that turns up is going to fail DAD. Normally this will be
another interface on the same device, but even then it can be an issue.
B) is usually correct, although this depends on the semantics of the lower
layer in question. If it is Ethernet, by changing the MAC address, you have
made a new interface and so the old address end point has gone away. It is
usually best to drop the link and restart layer 2 at that point, as any
Indeed, an 802.11 AP should be able to do this without breaking 802.11.
However, there are probably wider cases where unicast fanout is worth
doing.
BTW, it's a common misconception that 802.11 transmit rates have something
to do with range; actually, they're only very weakly correlated with
Isn't this something that could be done entirely at the sub-IP layer for
link technologies where this is an issue? I'd argue that all multicast in
802.11 is badly broken, and should be fixed at that layer (multicast can be
more than 50x slower than unicast, and packet loss can approach 80% while
On 3/11/2012, at 2:29 PM, Alexandru Petrescu alexandru.petre...@gmail.com
wrote:
(I am not sure this prohibition of advertising an expired prefix is
specified or coded, I just suppose it as natural).
Alex
It is specified, unfortunately current implementations often fail to behave as
On 24/07/2012, at 4:45 PM, Hesham Soliman wrote:
= The router doesn't need to know the host's route table, it knows which
address it included in its RAs, which is what the host records.
I'm not sure why you think that there is no way the router can construct
that message reliably. If it
On 25/07/2012, at 9:19 PM, Philipp Kern wrote:
Andrew,
am Wed, Jul 25, 2012 at 07:11:53PM +1200 hast du folgendes geschrieben:
However, if it is not a misconfiguration, and you wish to redirect traffic
that has a better first hop, or is on-link but the host for whatever reason
does not
discussion would help.
Andrew McGregor
Allied Telesis Labs
smime.p7s
Description: S/MIME cryptographic signature
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo
On 24/07/2012, at 4:09 PM, Karl Auer wrote:
On Tue, 2012-07-24 at 15:46 +1200, Andrew McGregor wrote:
Unfortunately, there is no way that a router can reliably generate
that response, if it has more than one link-local address
Do you mean has more than one link-local address or has more
On 24/07/2012, at 4:15 PM, Hesham Soliman wrote:
I've come across what looks like a bug in the ICMPv6 spec.
= You mean in 4861 or ICMPv6?
That's what I'm trying to work out, and I could see two potential solutions.
Specifically, RFC 4861 says that A host MUST silently discard any
13 matches
Mail list logo
