Re: Why do we still need IPv4 when we are migrating to IPv6...
On Fri, Feb 13, 2015 at 02:12:31PM +, Phil Mayers wrote: > As above, depends on how they're using the socket API. As a rule for > UDP connections, you actually have to put *more* work in to see ICMP > errors. It's certainly possible to ignore them. FWIW, at least on Linux, if you keep doing send() on an UDP connection where the other end sends ICMP destination unreachable, you'll get errors back (ECONNREFUSED) eventually, although typically not on every packet you send. /* Steinar */ -- Software Engineer, Google Switzerland
Re: Why do we still need IPv4 when we are migrating to IPv6...
On Wed, Feb 11, 2015 at 08:42:00PM +, Anfinsen, Ragnar wrote: > I am working with my management team to implement IPv6, but I got an > interesting question from one of the managers; Why do we need more IPv4 if > we are moving towards IPv6? Maybe because the move is going too slowly? Case in point: http://goo.gl/q4EGQ3 shows disappointingly little Altibox, even though you've been talking about IPv6 for the last five years, at least. Maybe it's time to stop going opt-in :-) /* Steinar */ -- Software Engineer, Google Switzerland
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4)
On Mon, Sep 22, 2014 at 06:44:11PM +0200, Andrew ? Yourtchenko wrote: > The standards' purpose is to facilitate the interoperability. > > "MLD snooping" happens within a single device. What about the interaction between switches and the machines? All interoperability is not about inter-switch/-router. A few things that would be nice to have standardized (and then put into the BCP document): 1. Support for IPv4 and IPv6. 2. Support for working correctly in the presence of PIM (I've seen switches get greatly confused by this, and mess up the refcounting). 3. Support for SSM. > A result of composition of multiple independent correct > implementations of this function remains the same - "if you join the > group, you should get the traffic, if you did not, you should not". I suppose the standard would exist to define what _is_ a correct implementation. /* Steinar */ -- Software Engineer, Google Switzerland
Re: Something with filters
On Thu, Aug 28, 2014 at 04:31:22PM +0200, Enno Rey wrote: > to be honest, as another security person, I'm not really sure about the > benefit of uRPF in the IPv6 world, in some scenarios. > imagine a single infected smartphone on LTE, generating connections with > potentially 2^64 different source addresses from its assigned /64. How > would you counter that with uRPF? With uRPF in place, you can just block off that /64. Without, the smartphone can fake addresses in the entire 2000::/3 unicast space. That's a pretty obvious win; uRPF didn't in itself prevent the attack, but it made it a lot easier to mitigate it. Also, uRPF makes a large class of traffic amplification attacks impossible, since you can't fake the source address anymore. /* Steinar */ -- Software Engineer, Google Switzerland
Re: IPv6 Policy based routing?
2013/4/19 Dick Visser : > Cisco says it's not supported on any platform. I'm fairly certain I've done this on 2901. /* Steinar */ -- Software Engineer, Google Switzerland
