date:20150213


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-modell dsl/lte can't) by
upnp or by the user.


That's fine, and I agree in theory.

But Sony and Microsoft aren't going to just assume or enforce that, and 
I don't blame them. They have to assume some proportion of devices will 
be behind a firewall or NAT, and will write the code accordingly.


Done correctly, it's very little additional burden over just sending 
straight UDP packets. There's really no reason for system/app vendors to 
*not* implement traversal, and it doesn't harm the network.


But you're right, this has gone off-topic. The point was that IPv6 makes 
this situation - person-to-person networking - better than in the NAT44 
world, and would improve e.g. internet gaming.

Re: Why do we still need IPv4 when we are migrating to IPv6...

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:
>
>- «The cost/benefit of doing anything else than keeping IPv4 as a native
>  service for now does not add up»
>- «Spending money on IPv4 addresses and keeping IPv4 as a native service
>  is for now far cheaper than any alternative like MAP, lw4o6, or CGN»
>- «Doing something else than keeping IPv4 as a native service doesn't
>  work in the real world, even though the ideology is nice»
>- «We are not yet at the magic threshold where we can realistically look
>  into any alternatives to keeping IPv4 as a native service»
>- «Doing something else than keeping IPv4 as a native service is out of
>  the question because it will make or service no longer "premium"»
>- «Doing something else than keeping IPv4 as a native service won't fly
>  with the business side of the company»

That more or less sums it up, thank you. :)

>Considering the business side of your company is apparently already
>persuaded by these arguments and are on board with your desire to keep
>IPv4 as a native service for now, I am somewhat puzzled as to why you
>see a need for further arguments to bolster your position. But again,
>I'm probably just being dense.

My desire to get further arguments, is that due to my agreement to the 
ideology, they wanted second opinions from someone else hence the question 
to the mailing list. So basically there are only two options, as far as I 
see it:

1) Do CGN/MAP/lw4o6 and degrade the service somewhat, for 75% of the 
customer base it does not matter but there are still 25% of the customers 
who cares. Find incentives to persuade existing customers to let go of 
their native IPv4 address.
2) Buy more addresses for now, and do not degrade the service.

Anyways, thank you all for your opinions.

/Ragnar

Re: Why do we still need IPv4 when we are migrating to IPv6...

2015-02-13 Thread Thomas Schäfer


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.


Sorry, the thread is slightly off topic. But one of the first questions 
was about "premium" maybe also meaning comfort. There are soho-routers 
with comfortable firewalls, but not the "standard"-models.


And also AVM has one handicap - the integrated vpn doesn't support IPv6.

Thomas




Am 13.02.2015 um 15:22 schrieb Steinar H. Gunderson:

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 */




--

Re: Why do we still need IPv4 when we are migrating to IPv6...


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.


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.


Quite right, sorry - I'm forgetting that. Whether the app code even 
*look* at the return value of send() on a UDP socket is another matter ;o)


I'd hope NAT traversing apps will know to ignore this, at least during 
setup.

Re: Why do we still need IPv4 when we are migrating to IPv6...

2015-02-13 Thread Tore Anderson

* 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 a native
  service for now does not add up»
- «Spending money on IPv4 addresses and keeping IPv4 as a native service
  is for now far cheaper than any alternative like MAP, lw4o6, or CGN»
- «Doing something else than keeping IPv4 as a native service doesn't
  work in the real world, even though the ideology is nice»
- «We are not yet at the magic threshold where we can realistically look
  into any alternatives to keeping IPv4 as a native service»
- «Doing something else than keeping IPv4 as a native service is out of
  the question because it will make or service no longer "premium"»
- «Doing something else than keeping IPv4 as a native service won't fly
  with the business side of the company»

Considering the business side of your company is apparently already
persuaded by these arguments and are on board with your desire to keep
IPv4 as a native service for now, I am somewhat puzzled as to why you
see a need for further arguments to bolster your position. But again,
I'm probably just being dense.

Tore

Re: Why do we still need IPv4 when we are migrating to IPv6...

2015-02-13 Thread Steinar H. Gunderson

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 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. They might not even see the ICMP error if they're 
just doing dumb send() calls.



U2 sends a packet from U2IP,U2PORT to U1IP,U1PORT.
HGW2 creates flow state.
Packet hits HGW1 which already has a flow state, and packet successfully
reaches U1.
U1 now can start sending packets to U2 as well and they've worked around
both of them having HGWs with stateful firewalls disallowing new
connections to them.

Right?


Yes.



The crucial step here seems to be the fact that initial packets might be
dropped and error messages be generated, but these should be ignored by
the application. Is this commonplace? Is it a problem at all?


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.

Re: Why do we still need IPv4 when we are migrating to IPv6...

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.

Reducing the price of the service is not an option for the sales people, 
unless there are other benefits, and right now there are none. Spending 
for example $650K on IP addresses is far cheaper than reducing the price 
by 20% in addition to investing in the technology to enable MAP, lw4o6 or 
CGN. So unfortunately, we can put the ideology aside and concentrate on 
deploying IPv6 while keeping IPv4 as good as possible. When we finally 
meet the magic threshold, we can start discussing which technology is best 
for keeping the legacy IPv4 available.

I might have misunderstood you, but I think we have totally different 
perspectives when we look at the problem, thus I agree in the ideology, it 
doesn't work like that in the real world.

My goal with my question was to find sensible arguments for keeping IPv4 
as a native service for now, since the cost/benefit does not add up yet. 
However, in the future it might, but I think we are not there yet for the 
next couple of years.

/Ragnar







On 13.02.15, 13.38, "Tore Anderson"  wrote:

>* 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 thousands of your own customers disagree with your statement
>> >above.
>> >
>> >In the same way, you in all likelihood have a non-zero amount of end
>> >customers who do care about having a public IPv4 address all to
>> >themselves. If you did make this an opt-in feature, I'm sure you'd
>> >have many thousands of users opting in to that, too.
>> 
>> Compared to the amount of customers, only 1,6% of all our customer
>> having the opt-in option have done so for IPv6. Back in the days when
>> we where doing CGN (yes we have done it for more than 10 years),
>> around 25% of our customers chose to opt-in for a public IPv4
>> address. The main reason for this was that CGN did disrupt their
>> service. Typical examples where OTT SIP services that did not support
>> STUN, customers who wanted to have their own server at home, gamers
>> and more.
>
>Note that with MAP (maybe also lw4o6, but I'm less familiar with it)
>home servers will work. This is because the customer actually does get
>a public IPv4 address routed to his CPE - the additional restriction is
>that he is limited as to which source ports he can use. So he can't
>expect to be able to set up his SSH server on port 22/tcp, but he will
>be able to set it up on some other port which might well be sufficient
>for his use case.
>
>Same thing goes for gamers, there the inbound ports are typically
>dynamically assigned with UPnP or something like that, so the CPE is in
>a position to simply assign a port from its assigned range for inbound
>traffic. So for gamers, MAP ought to be pretty much equivalent to
>regular public IPv4 with NAT44 in HGW.
>
>Anyway, if 25% of your customers have a problem with traditional
>stateful CGN, then you can expect that less than 25% would have a
>problem with MAP. Not only because more application protocols work, but
>also because the mandatory native IPv6 will help avoid problems by
>sidestepping the MAP system and the CPE's NAT44 completely.
>
>> So I disagree with your statements. 25% of the customer base don't
>> care about addressing, but they do care about connectivity, and as
>> long as there are no perceived differences between IPv4 and IPv6. The
>> 1,6% who have chosen to opt-in for IPv6 are the geeks and the curious
>> people.
>
>I'm not sure how you can disagree with my statements, since you confirm
>them to be true:
>
>1) A non-zero amount of your customers (1.6%) care about IPv6
>2) A non-zero amount of your customers (25%) care about public IPv4
>3) The majority of your customers (73.4-75%) do not care about neither
>   IPv6 nor public IPv4
>
>Right? Group #3 is where you have the largest potential for starting to
>break free of IPv4...
>
>> >But if you flip it around, there's a non-zero amount of end customers
>> >who do not care about neither having an exclusive public IPv4 address
>> >nor about having IPv6. If I were to venture a guess, that group would
>> >constitute the majority of your customers. Reclaiming those addresses
>> >would likely allow you to postpone your next IPv4 purchase quite a
>> >while, so I'd give that approach serious consideration if I were you.
>> 
>> With reference to my statement above, reclaiming is not something you
>> can do without the customer having a choice, and who would like to
>> get their services degraded?
>
>I've never suggested that you should not give th

Re: Why do we still need IPv4 when we are migrating to IPv6...

2015-02-13 Thread Mikael Abrahamsson

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 are multiple providers disallowing incoming connections
to IPv6 addresses for customers. But if I understand correctly, including
what you described before, this would work:

U1=User1, U2=User2...
HGW1=HomeGateWay, belonging to U1.
Assume IPv6 and no NAT.

U1 and U2 are going to play a game together. They're speaking to the game
server. U1 says "please talk to me on UDP port "please talk to me on UDP port . Game server informs
respective user about the other users' IP/PORT combination.

Now, U1 sends a UDP packet from U1IP,U1PORT to U2IP,U2PORT.
HGW1 creates flow state for U1IP,U1PORT<->U2IP,U2PORT.
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.
U2 sends a packet from U2IP,U2PORT to U1IP,U1PORT.
HGW2 creates flow state.
Packet hits HGW1 which already has a flow state, and packet successfully
reaches U1.
U1 now can start sending packets to U2 as well and they've worked around
both of them having HGWs with stateful firewalls disallowing new
connections to them.

Right?

The crucial step here seems to be the fact that initial packets might be
dropped and error messages be generated, but these should be ignored by
the application. Is this commonplace? Is it a problem at all?

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Why do we still need IPv4 when we are migrating to IPv6...


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 ends of the connection send packets to each
other to open their respective firewall.

I do agree that the firewall in question needs to not send rejects for
this traffic for this to work. I am happy this use-case was brought up,
because I hadn't heard and thought about this before. Personally I don't
want to silently drop packets, so I guess clients need to try a few
times and not listen to the (initial) ICMP messages until the "hole" is
open.


It all depends on the behaviour of the device(s)

It's perfectly possible for a CPE to send ICMP errors without those 
errors creating a NAT table entry and blocking the "real" (inside) host 
from using that 5-tuple.


In the situation I described yesterday, the CPE is Linux, and it could 
have done something like:


iptables -t raw -A OUTPUT -p icmp -j NOTRACK

Or it could not send errors for unknown UDP flows directed to high ports 
e.g.:


iptables -A INPUT -m state --state RELATED,ESTABLISHED -j PERMIT
iptables -A INPUT -p udp --dport 1024:65545 -j DROP

There's a bunch of different solutions.

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.


If you're NATing IPv6, well... you brought it on yourself ;o)

Cheers,
Phil

Re: Why do we still need IPv4 when we are migrating to IPv6...

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 time. Or introduce a new invoice item for IPv4
> with a symbolic charge, reducing the base fee accordingly so the total
> stays the same. Inform them that the IPv4 charge can go away if they
> disable the public IPv4 option in the customer portal.

Price reductions will be something he can not decide on his own.

That being said, calculating the cost of new IPv4 plus adding it to
the available pools versus the one-time reduction in income may be a
good way to influence this internal discussion.

Richard

-- 
Richard

Re: Why do we still need IPv4 when we are migrating to IPv6...

2015-02-13 Thread Tore Anderson

* 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 thousands of your own customers disagree with your statement
> >above.
> >
> >In the same way, you in all likelihood have a non-zero amount of end
> >customers who do care about having a public IPv4 address all to
> >themselves. If you did make this an opt-in feature, I'm sure you'd
> >have many thousands of users opting in to that, too.
> 
> Compared to the amount of customers, only 1,6% of all our customer
> having the opt-in option have done so for IPv6. Back in the days when
> we where doing CGN (yes we have done it for more than 10 years),
> around 25% of our customers chose to opt-in for a public IPv4
> address. The main reason for this was that CGN did disrupt their
> service. Typical examples where OTT SIP services that did not support
> STUN, customers who wanted to have their own server at home, gamers
> and more.

Note that with MAP (maybe also lw4o6, but I'm less familiar with it)
home servers will work. This is because the customer actually does get
a public IPv4 address routed to his CPE - the additional restriction is
that he is limited as to which source ports he can use. So he can't
expect to be able to set up his SSH server on port 22/tcp, but he will
be able to set it up on some other port which might well be sufficient
for his use case.

Same thing goes for gamers, there the inbound ports are typically
dynamically assigned with UPnP or something like that, so the CPE is in
a position to simply assign a port from its assigned range for inbound
traffic. So for gamers, MAP ought to be pretty much equivalent to
regular public IPv4 with NAT44 in HGW.

Anyway, if 25% of your customers have a problem with traditional
stateful CGN, then you can expect that less than 25% would have a
problem with MAP. Not only because more application protocols work, but
also because the mandatory native IPv6 will help avoid problems by
sidestepping the MAP system and the CPE's NAT44 completely.

> So I disagree with your statements. 25% of the customer base don't
> care about addressing, but they do care about connectivity, and as
> long as there are no perceived differences between IPv4 and IPv6. The
> 1,6% who have chosen to opt-in for IPv6 are the geeks and the curious
> people.

I'm not sure how you can disagree with my statements, since you confirm
them to be true:

1) A non-zero amount of your customers (1.6%) care about IPv6
2) A non-zero amount of your customers (25%) care about public IPv4
3) The majority of your customers (73.4-75%) do not care about neither
   IPv6 nor public IPv4

Right? Group #3 is where you have the largest potential for starting to
break free of IPv4...

> >But if you flip it around, there's a non-zero amount of end customers
> >who do not care about neither having an exclusive public IPv4 address
> >nor about having IPv6. If I were to venture a guess, that group would
> >constitute the majority of your customers. Reclaiming those addresses
> >would likely allow you to postpone your next IPv4 purchase quite a
> >while, so I'd give that approach serious consideration if I were you.
> 
> With reference to my statement above, reclaiming is not something you
> can do without the customer having a choice, and who would like to
> get their services degraded?

I've never suggested that you should not give the customer a choice.
Quite the opposite, I think you *should* give them a choice to have a
public IPv4 address. That way, you can in good conscience keep your
«premium» label - just like you do with your by-choice IPv6 offering.

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 time. Or introduce a new invoice item for IPv4
with a symbolic charge, reducing the base fee accordingly so the total
stays the same. Inform them that the IPv4 charge can go away if they
disable the public IPv4 option in the customer portal.

If ~10k customers take the bait, hey presto, you have reclaimed enough
addresses to grow by ~40k new subscribers. I can guarantee you that at
least 1 customer would opt out of public IPv4 btw. ;-)

> Just to be clear. I am not speaking against IPv6, quite the contrary,
> as you know I have been a pro IPv6 tech for a long time, but I still
> have my management team to deal with. And we are not saying "no
> IPv6", we have rather moved on to "no IPv4?". I think it is to early,
> and CGN will degrade our service for 25% of our customers, which is a
> bit to high as of today.

I think you must have misunderstood me completely.

I am *not* suggesting that you deploy MAP/CGN for those 25% of your
customers who w

[request]: host a probe for v6 measurements

2015-02-13 Thread Bajpai, Vaibhav

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 performance over IPv4 and IPv6 to: a) Dual-stacked websites
and b) YouTube content delivery network (in collaboration with Aalto
University). The tests comes bundled with a LEONE SamKnows probe.

[1] http://www.leone-project.eu

We currently have ~44 Vantage points (VP). Each VP runs a Leone
SamKnows probe. The google map [2] shows where these probes are
deployed. As you can see the VP sample is too small.

[2] http://goo.gl/E43p32

We prefer measuring from home networks, but are also open to
deploying probes elsewhere. Here is the current distribution of
probes by network type:

|+--|
|  TYPE  |  # (PROBES)  |
|+--|
|  Residential   |  26  |
|  Research/NREN |  8   |
|  Operator Lab  |  4   |
|  IXP   |  1   |
|  Business  |  3   |
|  Data Center   |  2   |
|+--|
|  Total |  44  |
|+--|




8<- Request:
If you receive native IPv6 at home (or elsewhere), it would be great
if you can host a LEONE SamKnows probe for us. The probe will run
standard SamKnows tests [3] and our IPv6 tests. All of these are
active measurement tests only.

[3] https://www.samknows.com/tests-and-metrics




8<- Action:
Let me know if you’re interested, and I can share details on how to
get the probe to you. We only have limited number of LEONE SamKnows
probes. We will process the requests on first come first serve basis.





8<- Research Impact.
a) Measuring YouTube from Dual-Stacked Hosts
   Saba Ahsan, Vaibhav Bajpai, Jörg Ott, Jürgen Schönwälder
   Passive and Active Measurement Conference (PAM 2015),
   New York, March 2015.
   
http://vaibhavbajpai.com/documents/papers/proceedings/dualstack-youtube-pam-2015.pdf

b) Measuring TCP Connection Establishment Times of Dual-Stacked Web Services
   Vaibhav Bajpai, Jürgen Schönwälder
   9th International Conference on Network and Service Management, (CNSM 2013)
   Zürich, October 2013.
   
http://vaibhavbajpai.com/documents/papers/proceedings/dualstack-tcp-cnsm-2013.pdf

c) Measuring the Effects of Happy Eyeballs
   IPv6 Operations (v6ops) Working Group, IETF 87
   Berlin, July 2013
   https://vimeo.com/71407427



8<- Thanks.
Thank you so much for helping us in our research activity.



Best, Vaibhav

=
Vaibhav Bajpai

Research I, Room 91
Computer Networks and Distributed Systems (CNDS) Lab
School of Engineering and Sciences
Jacobs University Bremen, Germany

www.vaibhavbajpai.com
=


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Re: Why do we still need IPv4 when we are migrating to IPv6...

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

Re: Re: Why do we still need IPv4 when we are migrating to IPv6...

2015-02-13 Thread Mikael Abrahamsson


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 suggestion?

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Re: Why do we still need IPv4 when we are migrating to IPv6...

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

Re: Re: Why do we still need IPv4 when we are migrating to IPv6...

2015-02-13 Thread Mikael Abrahamsson


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 
other to open their respective firewall.


I do agree that the firewall in question needs to not send rejects for 
this traffic for this to work. I am happy this use-case was brought up, 
because I hadn't heard and thought about this before. Personally I don't 
want to silently drop packets, so I guess clients need to try a few times 
and not listen to the (initial) ICMP messages until the "hole" is open.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Why do we still need IPv4 when we are migrating to IPv6...

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 be more or less
trivial and if they can charge extra for compliance all the better.
Sounds like near net win from the vendor's POV.

Richard

Re: Why do we still need IPv4 when we are migrating to IPv6...

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 will not be possible / too expensive / ... to log the NAT 
>mappings that the CGN did".

Spot on... :)

/Ragnar

Re: Why do we still need IPv4 when we are migrating to IPv6...

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 makes sense to by addresses instead 
>>of doing CGN or equivalent.
>
>Sure this potential Data Retention Directive will not be IPv6-specific
>and somehow exempt IPv4?

Definitely not, it will not look at the difference between IPv4 and IPv6, 
but the amount of data needed to be stored when doing CGN, or similar, 
would thousand fold compared to native IPv4.

/Ragnar

Re: Why do we still need IPv4 when we are migrating to IPv6...