Hi,
On Thu, Feb 12, 2015 at 02:37:09PM -0800, Erik Kline wrote:
> Sure this potential Data Retention Directive will not be IPv6-specific
> and somehow exempt IPv4?
I read the original concern as "if they force DR on us, and we run a
CGN, it will not be possible / too expensive / ... to log the NA
Thus wrote Gert Doering (g...@space.net):
> On Thu, Feb 12, 2015 at 02:37:09PM -0800, Erik Kline wrote:
> > Sure this potential Data Retention Directive will not be IPv6-specific
> > and somehow exempt IPv4?
>
> I read the original concern as "if they force DR on us, and we run a
> CGN, it will n
Am 12.02.2015 um 19:59 schrieb Eric Vyncke (evyncke):
Is it related to the paranoid option of blocking all inbound traffic? To
mimick NAT44 ?
I afraid so.
Regarding to
http://download.microsoft.com/download/A/C/4/AC4484B8-AA16-446F-86F8-BDFC498F8732/Xbox%20One%20Technical%20Details.docx
"Ev
On 12.02.15, 22.53, "Tore Anderson" wrote:
>There's a non-zero amount of end customers who *do* care about IPv6.
>After all, you do have a opt-in service which several thousand of your
>customers did actually opt in to - so it would seem to me that several
>thousands of your own customers disag
On 12.02.15, 23.37, "Erik Kline" wrote:
>> Appreciate your feedback, but as long as the majority of Norwegian
>>content providers does not move on IPv6, including governmental sites,
>>and the potential risk of the Norwegian government implementing some
>>sort of Data Retention Directive, it
On 13.02.15, 10.03, "Gert Doering" wrote:
>Hi,
>
>On Thu, Feb 12, 2015 at 02:37:09PM -0800, Erik Kline wrote:
>> Sure this potential Data Retention Directive will not be IPv6-specific
>> and somehow exempt IPv4?
>
>I read the original concern as "if they force DR on us, and we run a
>CGN, it wi
On Fri, Feb 13, 2015 at 11:52 AM, Steinar H. Gunderson wrote:
> On the contrary, it gives you a great single point to log everything.
> I'm sure PST will be thrilled.
Plus, "too expensive" is only a problem for the carriers, not for the vendors.
Adding a way to dump the state of the CGN should b
On Fri, 13 Feb 2015, Thomas Schäfer wrote:
and the practice in Germany to blocking all IPv6-inbound traffic the
result is the problem for some gamers.
So I guess applications should use the same technique as one does to
traverse NAT44:s, ie both ends of the connection send packets to each
ot
On Fri, Feb 13, 2015 at 12:26 PM, Mikael Abrahamsson wrote:
> so I guess clients need to try a few times and not listen to the (initial)
> ICMP messages until the "hole" is open.
That sounds slightly broken as well.
Richard
On Fri, 13 Feb 2015, Richard Hartmann wrote:
On Fri, Feb 13, 2015 at 12:26 PM, Mikael Abrahamsson wrote:
so I guess clients need to try a few times and not listen to the (initial)
ICMP messages until the "hole" is open.
That sounds slightly broken as well.
I agree. Do you have a better sug
On Fri, Feb 13, 2015 at 12:32 PM, Mikael Abrahamsson wrote:
> I agree. Do you have a better suggestion?
Of course not.
While I personally tend to DROP instead of REJECT, both are far from
ideal in the real world.
Richard
Dear ipv6-ops,
We are currently looking for volunteers with native IPv6 lines to
help us in our v6 measurement research.
8<- Background
We are interested in measuring IPv6 performance from home. As part
of the LEONE project [1], we have developed measurement tests that
compare performan
* Anfinsen, Ragnar
> On 12.02.15, 22.53, "Tore Anderson" wrote:
>
> >There's a non-zero amount of end customers who *do* care about IPv6.
> >After all, you do have a opt-in service which several thousand of
> >your customers did actually opt in to - so it would seem to me that
> >several thousan
On Fri, Feb 13, 2015 at 1:38 PM, Tore Anderson wrote:
> How to introduce it to existing customers, you might ask? Maybe just
> ask them? Send an SMS saying 20% off your next bill if you give up your
> IPv4 address (and enable IPv6?), pointing out it's not binding and can
> be re-enabled at any tim
On 13/02/15 11:26, Mikael Abrahamsson wrote:
On Fri, 13 Feb 2015, Thomas Schäfer wrote:
and the practice in Germany to blocking all IPv6-inbound traffic the
result is the problem for some gamers.
So I guess applications should use the same technique as one does to
traverse NAT44:s, ie both en
On Fri, 13 Feb 2015, Phil Mayers wrote:
None of this should be a problem for non-NATed IPv6. The absence of NAT
will mean an ICMP error doesn't "block" a NAT translation - there's no
such thing to block - so a CPE can send errors or not.
Ah, thanks for pointing that out.
So currently there a
Tore,
In an ideal world, all your statements are true, and for us who has been
roaming the IPv6 forums and meetings the last year knows all this.
However, the business side does not see it the same way we do, and that is
something we all have to deal with and why we are moving so slowly.
Reduc
On 13/02/15 13:27, Mikael Abrahamsson wrote:
Packet reaches HGW2, which has no flow state, and is dropped. ICMP error
message might be created.
In case of ICMP error message, U1 should ignore this.
That's an application-layer issue. It all depends on how they're talking
to the socket API. The
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 se
* Anfinsen, Ragnar
> My goal with my question was to find sensible arguments for keeping IPv4
> as a native service for now
Maybe I'm being dense, but you seem to already have all the answers to
this question yourself? For example:
- «The cost/benefit of doing anything else than keeping IPv4 as
On 13/02/15 14:22, Steinar H. Gunderson wrote:
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.
Why a discussion to drill the firewall with very tricky things?
(it's sound to me like the same sh... stun and other legacy ipv4 horrors.)
In my opinion the firewall should be configurable (unfortunately
DTAG-speedport-series, including the hybrid-modell dsl/lte can't) by
upnp or by the user.
On 13.02.15, 15.29, "Tore Anderson" wrote:
>* Anfinsen, Ragnar
>
>> My goal with my question was to find sensible arguments for keeping
>>IPv4
>> as a native service for now
>
>Maybe I'm being dense, but you seem to already have all the answers to
>this question yourself? For example:
>
>- «T
On 13/02/15 14:37, Thomas Schäfer wrote:
Why a discussion to drill the firewall with very tricky things?
(it's sound to me like the same sh... stun and other legacy ipv4 horrors.)
In my opinion the firewall should be configurable (unfortunately
DTAG-speedport-series, including the hybrid-model
24 matches
Mail list logo
