Re: Something with filters

[Tassos Chatzithomaoglou]

Jen had presented some similar stats a year ago.

https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf

--
Tassos

Jeroen Massar wrote on 27/8/2014 19:01:
> I was doing some traceroutes to determine some weird claim of a transit
> (not shown in the below trace) being "tier1" while another transit
> actually popped up in their network and then noticed this beauty:
>
>  9  2001:5a0:a00::2e (2001:5a0:a00::2e)  79.018 ms  79.910 ms  79.960 ms
> 10  :: (::)  101.893 ms  102.004 ms  103.574 ms
> 11  rar3.chicago-il.us.xo.net (:::65.106.1.155)  104.732 ms
>
> Yeah baby, we can use the unspecified address in ICMP replies!
>
> Why oh why is that packet even allowed to come back to me, let alone
> travel all those hops...
>
> Oh, yeah, something with uRPF and other such awesome standards.
>
> Greets,
>  Jeroen
>

Re: Residential subscribers: numbered or unnumbered?

[Tassos Chatzithomaoglou]

We do numbered: SLAAC for WAN (TR-069 is done over IPv6, although still 
fighting to make it work correctly in DS-Lite from all vendors) and DHCPv6-PD 
for LAN for all our PPPoE subscribers.

Recently we added the option of doing DHCPv6 for WAN too, since we found CPEs 
that do not behave gently to the BRAS/BNG if that's not the case.

--
Tassos

Philip Matthews wrote on 25/3/2014 19:29:
> Folks:
>
> Until recently, I was under the impression that most people were using 
> numbered v6 links to residential subscribers, allocating the WAN address 
> using DHCPv6.  However, recently two people have told me about a number of 
> providers that are doing unnumbered instead.
>
> So for anyone who has deployed or is planning to deploy residential IPv6, I 
> am curious to know which way you are going, and more importantly why you 
> selected that approach? My interest is primarily in IPoE, but I don't mind 
> hearing about PPPoE as well.
>
> The arguments I know or have heard for going numbered are:
> * Have a WAN address that one can ping remotely to verify connectivity (here 
> I am assuming using DHCPv6 to assign a specific IID like ::1)
> * Want to use TR-069
>
> The arguments I can think of for going unnumbered are:
> * Greater security
> * Plan to ping the loopback address on the CPE
>
>
> Additional questions for those who have chosen the unnumbered approach or are 
> using SLAAC to number the WAN address.
> * What are you doing wrt having an address to ping to confirm the CPE is 
> reachable?
> * For those doing unnumbered, do all CPEs implement the same algorithm for 
> selecting the loopback address according to WAA-7 in RFC 7084? If not, how do 
> you handle this? For example, do you only select CPEs that implement the same 
> algorithm? Do you just try the likely candidates until one works? Or 
> something else?
>
>
> - Philip

the SDN/NFV & stateful/stateless paradox

[Tassos Chatzithomaoglou]

I'm thinking out loud

>From one side, the industry is trying to promote the SDN/NFV model vs the 
>traditional appliance-per-service one.
>From the other side, the same industry is trying to promote the stateless 
>model vs the stateless one regarding the IPv6 transition.

For an NFV perspective, i can see the DS-Lite solution being a better 
representative than Lw4o6/MAP, since it can "transfer" much more functionality 
(NAT) from the CPE to a compute server, making the virtual CPE a closer reality.
So, if the compute power keeps on increasing (while at the same time cost 
starts decreasing),  is there a chance in the near future we start re-thinking 
of changing our "IPv6-state" preferences?
Or IPv6 transition mechanisms won't even exist when that happens?




--
Tassos

Win7 & ULA prefix selection policy

[Tassos Chatzithomaoglou]

After experimenting a little with ULAs, i noticed that Win7 uses ULA as source 
in order to connect to a global IPv6 address, while at the same time destroying 
the quick switchover effect of HE. Linux on the other hand doesn't seem to 
suffer from the same issue.

I did a quick search and i found out that this is expected behavior, so a 
solution from MS shouldn't be expected any time soon (although there is a 
workaround by changing the prefix selection policy).

C:\Users\Tassos>netsh interface ipv6 show prefixpolicies
Querying active state...

Precedence  Label  Prefix
--  -  
50  0  ::1/128
40  1  ::/0
30  2  2002::/16
20  3  ::/96
10  4  :::0:0/96
 5  5  2001::/32


Latest rfc 6724 defines a specific policy for ULAs, while the older one rfc 
3484 didn't:

  PrefixPrecedence Label
  ::1/128   50 0
  ::/0  40 1
  :::0:0/96 35 4
  2002::/16 30 2
  2001::/32  5 5
  fc00::/7   313
  ::/96  1 3
  fec0::/10  111
  3ffe::/16  112

Does anyone know if MS has any plans to implement the newer RFC? It's almost a 
year since the RFC came out.
Dave as an author might be a hint, but i have seen many similar cases without 
the expected result.


-- 
Tassos

Re: What is Brocade up to here?

[Tassos Chatzithomaoglou]

  
  
https://ripe67.ripe.net/presentations/288-Jen_RIPE67.pdf
  includes similar behaviors.
  --
Tassos

  sth...@nethelp.no wrote on 27/10/2013 17:35:


  % host brocade.com
brocade.com has address 144.49.210.200
brocade.com has IPv6 address 2620:100:4:6401::20

If I try "telnet 2620:100:4:6401::20 80" I get this rather "interesting"
result (my IPv6 address is 2001:8c0:9602:1::2):

16:27:01.107632 IP6 2001:8c0:9602:1::2.14710 > 2620:100:4:6401::20.80: Flags [S], seq 148079426, win 65535, options [mss 1440,nop,wscale 3,sackOK,TS val 1218395701 ecr 0], length 0
16:27:01.289048 IP6 2620:100:4:6400::7 > 2001:8c0:9602:1::2: ICMP6, neighbor solicitation, who has 2001:8c0:9602:1::2, length 32
16:27:01.289200 IP6 2620:100:4:6400::7 > 2001:8c0:9602:1::2: ICMP6, neighbor solicitation, who has 2001:8c0:9602:1::2, length 32

Since brocade.com is around 80 ms and more than 15 router hops away, I'm
really curious about the neighbor solicitation. It is quite consistent.

(Oh yeah, I never get an answer from port 80 on the IPv6 address. But HE
takes care of things nicely, so brocade.com works in my browser.)

Anybody know what Brocade is up to here?

Steinar Haug, AS 2116




  

Re: Caching learned MSS/MTU values

[Tassos Chatzithomaoglou]

I see that WinXP keeps the /128 for the last 32 entries.

C:\Documents and Settings\Tassos>ipv6 rc
2a02:1788:4fd::b2ff:5201 via 4/fe80::218:18ff:fef6:5b54
 src 4/2a02:2148:82:6000:1430:f026:c55a:b75b
 PMTU 1500
2a02:1788:2fd::ab via 4/fe80::218:18ff:fef6:5b54
 src 4/2a02:2148:82:6000:1430:f026:c55a:b75b
 PMTU 1500
2a02:2148:2fff:ff02::3e01:2619 via 4/fe80::218:18ff:fef6:5b54
 src 4/2a02:2148:82:6000:1430:f026:c55a:b75b
 PMTU 1500


C:\Documents and Settings\Tassos>netsh interface ipv6 show global
Querying active state...

General Global Parameters
-
Default Hop Limit   : 128 hops
Neighbor Cache Limit: 256 entries per interface
Route Cache Limit   : 32 entries
Reassembly Limit: 16770400 bytes


Win7 seems to keep /128 for the last 128 entries.

C:\Users\Tassos>netsh interface ipv6 show destinationcache

Interface 10: Local Area Connection


PMTU Destination Address   Next Hop Address
 - -
1492 2001:0:5ef5:79fb:1c3e:d863:c447:6318  fe80::200:ff:fe00:0
1492 2001:0:9d38:6ab8:4a3:31f0:411e:6346   fe80::200:ff:fe00:0
1492 2001:0:9d38:6ab8:10c5:11cb:b08a:5623  fe80::200:ff:fe00:0
1492 2001:0:9d38:6ab8:3485:2015:a1ca:a777  fe80::200:ff:fe00:0
1492 2001:0:9d38:6abd:1cbd:1b0c:e0f1:34d3  fe80::200:ff:fe00:0
1492 2001:0:9d38:90d7:20a2:147a:9a93:4e6b  fe80::200:ff:fe00:0
1500 2a02:2149:8104:3100:4484:bf55:88d6:bcc3   
2a02:2149:8104:3100:4484:bf55:88d6:bcc
1492 fe80::200:ff:fe00:0   fe80::200:ff:fe00:0
1492 2001:0:9d38:90d7:2020:3f27:a9ec:39ce  fe80::200:ff:fe00:0
1492 2001:0:5ef5:79fd:873:3f92:ac11:1ee6   fe80::200:ff:fe00:0

C:\Users\Tassos>netsh interface ipv6 show global
Querying active state...

General Global Parameters
-
Default Hop Limit   : 128 hops
Neighbor Cache Limit: 256 entries per interface
Route Cache Limit   : 128 entries per compartment


--
Tassos

Jason Fesler wrote on 17/10/2013 19:05:
> I'm once again considering trying to improve on the test-ipv6.com 
>  PMTUD failure detection. Due to limitations on the 
> client side I can't use raw sockets to generate test packets. The client is 
> JavaScript and runs in a browser; all I can do is try fetching urls from 
> multiple locations, each with a different MTU. 
>
> I know that the various operating systems tend to cache any PMTUD issues that 
> they can detect; future connections to that destination will use smaller 
> packets accordingly. What I can not see to find is an adequate description of 
> what granularity this gets cached with. /128? /64?   Also, I the absence of 
> Packet Too Big messages, what does each OS do?
>
> If anyone has pointers, please share. It will affect what and how I can 
> improve the site, given the restrictions I have with the client side.
>
>
>
>
> -- 
>  Jason Fesler, email/jabber mailto:jfes...@gigo.com>> 
> resume: http://jfesler.com
>  "Give a man fire, and he'll be warm for a day;
>  set a man on fire, and he'll be warm for the rest of his life."
>
>

Re: Microsoft: Give Xbox One users IPv6 connectivity

[Tassos Chatzithomaoglou]

I just had a look at our TR-069 stats and only 31,7% of our managed CPEs have 
UPnP enabled.
Hint: We mostly ship CPEs with UPnP disabled by default (due to some security 
issues we had in the past).

--
Tassos

Christopher Palmer wrote on 11/10/2013 21:31:
> Our data shows that only 24% of user-encountered networks have a NAT that 
> supports UPnP management (we successfully create a port mapping). That's 
> across the Windows 7 and 8 population. That's unfiltered, so it will include 
> hits from corporate environments, hot spots and such, etc. 
>
> I feel pretty good about "infering" that the number is residential networks 
> is around 35%, looking at the top-of-the-line number and looking at other 
> population metrics we collect.
>
> Nowhere near 80% :(. Sometimes a home router "supports" UPnP, but it's not 
> activated by default. 
>
> -Original Message-
> From: ipv6-ops-bounces+christopher.palmer=microsoft@lists.cluenet.de 
> [mailto:ipv6-ops-bounces+christopher.palmer=microsoft@lists.cluenet.de] 
> On Behalf Of erik.tarald...@telenor.com
> Sent: Friday, October 11, 2013 12:12 AM
> To: ipv6-ops@lists.cluenet.de
> Subject: SV: Microsoft: Give Xbox One users IPv6 connectivity
>
> I don't have numbers for other markets, but in Norway I would say more than 
> 80% have UPnP enabled gateways.  At least the ISP I work for have provided 
> customers with UPnP enabled gateways the last 7+ years.  Most devices I can 
> see in the Norwegian market (online and physical stores) have support for 
> UPnP.
>
> But not to derail the discussion to much.  Even with UPnP enabled, there are 
> apparently very different ways to enterpete how to use UPnP.  Some clients 
> fail misserably if they dont get the port they seek, some release the port as 
> soon as it has been granted (older version of microsoft messenger did this, 
> caused a lot of cpu usage on the gateways).  Some clients do not understand 
> that they have a port, and proceede to the next port and then use up all 
> ports on the gateway.
>
> -Erik Taraldsen
> Telenor
>
> 
> Fra: ipv6-ops-bounces+erik.taraldsen=telenor@lists.cluenet.de 
> [ipv6-ops-bounces+erik.taraldsen=telenor@lists.cluenet.de] på vegne 
> av Mikael Abrahamsson [swm...@swm.pp.se]
> Sendt: 11. oktober 2013 06:50
> To: Christopher Palmer
> Cc: ipv6-ops@lists.cluenet.de
> Emne: RE: Microsoft: Give Xbox One users IPv6 connectivity
>
> On Thu, 10 Oct 2013, Christopher Palmer wrote:
>
>> The thing about protocols like UPnP - the vendors who would ignore an 
>> IETF recommendation are likely to be the same vendors to skip out on 
>> making an adequate UPnP stack. Most people today do NOT have home 
>> routers that support UPnP.
> Do you have numbers on this? My belief has been that most people today who 
> care about anything more than web surfing would have a decently new gateway 
> (less than 3-5 years old) and that this would support UPnP.
>
> I don't have any numbers so I would like to know more :)
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>
>

Re: Microsoft: Give Xbox One users IPv6 connectivity

[Tassos Chatzithomaoglou]

So Xbox One is actually the first (at least well-known) 
device/network/service/etc that uses IPv6 the way it was supposed to be, with 
IPSec?

--
Tassos

Tore Anderson wrote on 9/10/2013 23:54:
> http://www.nanog.org/sites/default/files/wed.general.palmer.xbox_.47.pdf
>
> Quoting from slide 2:
>
> «Network operators that want to provide the best possible user
> experience for Xbox One Users:
> * Provide IPv6 Connectivity»
>
> Gamers tend to be a demanding bunch. I can tell from a ton of forum
> posts and such that a common problem of theirs is that the Xbox (360)
> reports the «NAT Type» as being «Moderate» or even «Strict». If word
> gets around in those communities that a reliable remedy for such
> problems is to switch to an ISP that supports IPv6...
>
> Kudos to Chris and Microsoft!
>
> Anyone have any information on the PS4?
>
> Tore
>

ipv6 port scanning by CERNET

[Tassos Chatzithomaoglou]

Is anyone aware of any recent experiment run by CERNET?

The last few days we're getting continuous port scannings from 
2001:DA8:1:FFFE::108.

The same address appears as the top one in 
https://ietf.org/usagedata/usage_201310.html#TOPSITES.

-- 
Tassos

Re: teredo.ipv6.microsoft.com off?

[Tassos Chatzithomaoglou]

Thanks for the update Sander.
The following seems to have the full info.

http://translate.google.com/translate?depth=1&hl=en&ie=UTF8&prev=_t&rurl=translate.google.com&sl=auto&tl=en&u=http://ipv6.br/teredo-sunset-mais-um-passo-na-transicao-para-o-ipv6/

At the same time, i'm thinking out loud...
Why would a windows application send an a request to an IPv6 DNS server over 
native IPv6 in order to find the IPv4 address of a server and get IPv6 over 
IPv4 connectivity?

--
Tassos

Sander Steffann wrote on 12/7/2013 02:31:
> Hi,
>
>> Anyone found out what happened with teredo.ipv6.microsoft.com ?
>>
>> http://translate.google.com/translate?hl=en&sl=de&u=http://www.heise.de/netze/meldung/IPv6-Tunnel-Microsofts-Teredo-Server-nicht-erreichbar-1915972.html&prev=/search%3Fq%3Dteredo%2Bmicrosoft%2Bipv6%26safe%3Doff%26sa%3DX%26biw%3D1303%26bih%3D803%26tbs%3Dqdr:w
>>
>> Since yesterday we have quite an increase of NXDOMAIN in relevant dns 
>> requests.
>>
>> Has Microsoft made the big step?
> Almost :-)   This is what is happening now:
>
>> As an attempt to "measure" the impact of this sunsetting, we would like to
>> switch off the service for a few days. Resultant feedback and telemetry will
>> help us inform the future of the Teredo service and its default configuration
>> on Windows. We intend to conduct this experiment from  approximately July 9
>> 0:0:00 UTC, to July 15 0:0:00 UTC.
> So it will come back, but it *is* the start of the sunsetting process.
>
> Cheers,
> Sander
>
>
>

Re: [pfSense] IPv6 Routing in pfSense

[Tassos Chatzithomaoglou]

Sorry for the delayed answer.

Some examples are the following:

Under WAN interface, if i choose SLAAC, then i cannot get DHCPv6-PD work at all.
If i choose DHCP6, then i get an extra option "DHCPv6 Prefix Delegation size" 
which imho is not needed.
The same happens on the LAN interface too.

Under "Services: DHCPv6 Server", i get the following message which is confusing 
atleast.
"The DHCPv6 Server can only be enabled on interfaces configured with static IP 
addresses.
Only interfaces configured with a static IP will be shown."

Generally, i tried to mimic the config we use on our CPEs (since pfsense if 
being used by quite a few of our customers as a wan router with a adsl modem in 
bridge mode), but i couldn't do it.

A sample IPv6 gui template we provide to our CPE vendors (which can be used to 
grab some ideas) is the following:

*Interface* *Title*
*Choices*
*Type*
*Default*
*WAN*

*IPv4/IPv6*
IPv4
IPv4 & IPv6
IPv6
Single choice
IPv4 & IPv6
*IPv6 Address Assignment*   SLAAC
DHCPv6
Static  Multiple choicesSLAAC
*DHCPv6-PD* Enable
Disable Single choice   Enable
*Tunnel*None
DS-Lite
MAP
Single choice   None
* DS-Lite AFTR* Manual (+IP)
Auto (from DHCPv6)  Single choice   Manual
*PCP*
Enable
Disable Single choice   Disable
   *PCP Server*
Manual (+IP)
DS-Lite AFTR
Auto (from DHCPv6)  Single choice   DS-Lite AFTR
*LAN*
*IPv6*  Enable
Disable
Single choice   Enable
*SLAAC* Enable
Disable Single choice   Enable
* SLAAC Prefix* Manual
Auto (from DHCPv6-PD)   Single choice   Auto (from DHCPv6-PD)
* SLAAC Options*MTU
DNS Multiple choicesMTU (from WAN MTU or 1492)
*DHCPv6 Server* Enable
Disable Single choice   Enable
* DHCPv6 Prefix*None
Manual
Auto (from DHCPv6-PD)   Single choice   None
* DHCPv6 Options*   Prefix
DNS (manual)
DNS (from DHCPv6-PD)Multiple choicesDNS (from DHCPv6-PD)
 



--
Tassos

Seth Mos wrote on 02/07/2013 15:50:
> On 2-7-2013 14:08, Tassos Chatzithomaoglou wrote:
>> I've been trying for many months to make DHCPv6-PD work reliably over PPPoE, 
>> but i haven't got any positive result until now.
>> Besides that, i find confusing a lot of IPv6 options in the GUI.
>> Other than that, Dual-Stack seems to work fine.
> The DHCP6 renewal still seems to be biting us which is being looked at.
>
> What is confusing about the IPv6 options? Do you mean that the label or
> text is not describing or explaining it well?
>
> Kind regards,
>
> Seth
>
>> --
>> Tassos
>>
>> Nick Buraglio wrote on 01/07/2013 20:10:
>>> I've worked pretty extensively with pfSense since it's early alpha
>>> days and have had private builds with IPv6 for years and years. It
>>> works well under 2.1-BETA and has supported DHCPv6-PD for a while on
>>> the WAN side.I've been using the 2.1-BETA train in production for
>>> a very long time with good results but I don't believe the IPv6 DNS is
>>> assigned via IPv4, it doesn't exist in the IPv4 lease tracking file
>>> and hacking through the interface code briefly it looks like there is
>>> mechanism for obtaining the DNS via DHCPv6 on the WAN side.  This is
>>> further strengthened by the fact that I have correct ISP assigned IPv6
>>> name servers assigned to me and they exist in the places I expect
>>> based on that code.
>>>
>>> nb
>>>
>>>
>>> On Mon, Jul 1, 2013 at 11:41 AM, Eugen Leitl  wrote:
>>>> - Forwarded message from Mark Tinka  -
>>>>
>>>> Date: Mon, 1 Jul 2013 18:39:13 +0200
>>>> From: Mark Tinka 
>>>> To: l...@lists.pfsense.org
>>>> Subject: Re: [pfSense] IPv6 Routing in pfSense
>>>> Organization: SEACOM
>>>> User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; )
>>>> Reply-To: mark.ti...@seacom.mu, pfSense support and discussion 
>>>> 
>>>>
>>>> On Monday, July 01, 2013 06:23:03 PM Jim Pingle wrote:
>>>>
>>>>> Sure. A purely routed IPv6 setup was one of the first
>>>>> things to work well on 2.1.
>>>>>
>>>>> We do not do any NAT on IPv6 by default, there is NPt if
>>>>> someone really needs to do that, but it's all manual.
>>>>>
>>>>> And the settings for IPv4 

teredo.ipv6.microsoft.com off?

[Tassos Chatzithomaoglou]

Anyone found out what happened with teredo.ipv6.microsoft.com ?

http://translate.google.com/translate?hl=en&sl=de&u=http://www.heise.de/netze/meldung/IPv6-Tunnel-Microsofts-Teredo-Server-nicht-erreichbar-1915972.html&prev=/search%3Fq%3Dteredo%2Bmicrosoft%2Bipv6%26safe%3Doff%26sa%3DX%26biw%3D1303%26bih%3D803%26tbs%3Dqdr:w

Since yesterday we have quite an increase of NXDOMAIN in relevant dns requests.

Has Microsoft made the big step?

-- 
Tassos

Re: [pfSense] IPv6 Routing in pfSense

[Tassos Chatzithomaoglou]

I've been trying for many months to make DHCPv6-PD work reliably over PPPoE, 
but i haven't got any positive result until now.
Besides that, i find confusing a lot of IPv6 options in the GUI.
Other than that, Dual-Stack seems to work fine.

--
Tassos

Nick Buraglio wrote on 01/07/2013 20:10:
> I've worked pretty extensively with pfSense since it's early alpha
> days and have had private builds with IPv6 for years and years. It
> works well under 2.1-BETA and has supported DHCPv6-PD for a while on
> the WAN side.I've been using the 2.1-BETA train in production for
> a very long time with good results but I don't believe the IPv6 DNS is
> assigned via IPv4, it doesn't exist in the IPv4 lease tracking file
> and hacking through the interface code briefly it looks like there is
> mechanism for obtaining the DNS via DHCPv6 on the WAN side.  This is
> further strengthened by the fact that I have correct ISP assigned IPv6
> name servers assigned to me and they exist in the places I expect
> based on that code.
>
> nb
>
>
> On Mon, Jul 1, 2013 at 11:41 AM, Eugen Leitl  wrote:
>> - Forwarded message from Mark Tinka  -
>>
>> Date: Mon, 1 Jul 2013 18:39:13 +0200
>> From: Mark Tinka 
>> To: l...@lists.pfsense.org
>> Subject: Re: [pfSense] IPv6 Routing in pfSense
>> Organization: SEACOM
>> User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; )
>> Reply-To: mark.ti...@seacom.mu, pfSense support and discussion 
>> 
>>
>> On Monday, July 01, 2013 06:23:03 PM Jim Pingle wrote:
>>
>>> Sure. A purely routed IPv6 setup was one of the first
>>> things to work well on 2.1.
>>>
>>> We do not do any NAT on IPv6 by default, there is NPt if
>>> someone really needs to do that, but it's all manual.
>>>
>>> And the settings for IPv4 and IPv6 are independent, you
>>> can do NAT on IPv4 while routing IPv6.
>> Excellent, Jim!
>>
>> Looking forward to 2.1.
>>
>> I suppose the other thing I'll then be thinking about is how
>> end-users are assigned IPv6 address information.
>>
>> Typical deployments have tended to use SLAAC with DHCPv4 for
>> the DNS. I've previously done SLAAC with DHCPv6 for DNS.
>> >From what I can see on doc.pfsense.org, I see pfSense will
>> support stateful address assignments using DHCPv6, in
>> addition to SLAAC.
>>
>> Would you be able to confirm whether 2.1 or later will
>> support DNS via DHCPv6 as well, as well as DHCP-PD?
>>
>> I suppose, for now, the default gateway will need to be
>> assigned via SLAAC, the one thing about DHCPv6 I still don't
>> find amusing.
>>
>> Cheers,
>>
>> Mark.
>>
>>
>>
>> ___
>> List mailing list
>> l...@lists.pfsense.org
>> http://lists.pfsense.org/mailman/listinfo/list
>>
>>
>> - End forwarded message -
>> --
>> Eugen* Leitl http://leitl.org";>leitl http://leitl.org
>> __
>> ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
>> AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5

Re: measurement data of IPv6 flows and IPv6 download rate for Dual-Stack subscribers

[Tassos Chatzithomaoglou]

Thanks a lot for the information Matej,

Our stats seem to agree with yours regarding the bytes ratio, but there is a 
significant difference in the flows ratio.
Taking into account that we're still evaluating the flows' measurements, there 
is a slight possibility we might be doing something wrong.
Unless our users are opening too many (not http) connections.

--
Tassos

Matej Gregr wrote on 26/06/2013 15:48:
> Hello Tassos,
>   yes, we are doing the same measurements in our network and in the
> whole NREN network (CESNET) in the Czech Republic.
> You can access the statistics from our network at
> http://6lab.cz/live-statistics/ipv6-brno-univeristy-of-technology/ and
> for the whole NREN network at
> http://6lab.cz/live-statistics/ipv6-cesnet-nework/
>
> True is, that the statistics at 6lab.cz are not from dual stack only
> network, but from the whole networks. I have done measurements only from
> dual stack network (6000 users) with the following results.
>
> Around 80 % of users in the dual stack network are configured with IPv4
> and IPv6, the rest are only IPv4 (mainly Windows XP).
>
> The IPv4/IPv6 ratios of flows and bytes are following.
>
> IP4 flows IN ratio:  85.7 %IP4 bytes IN ratio: 83 %
> IP6 flows IN ratio:  14.3 %IP6 bytes IN ratio: 17 %
> IP4 flows OUT ratio: 85.7 %IP4 bytes OUT ratio: 93 %
> IP6 flows OUT ratio: 14.3 %IP6 bytes OUT ratio: 7%
>
> Greets,
>
> M.
>
>
>
>
> On 06/26/2013 11:28 AM, Tassos Chatzithomaoglou wrote:
>> I don't know if anyone is doing such measurements or have similar data, but 
>> i'm looking for the following:
>>
>> percent rate of number of IPv6 flows VS number of IPv6+IPv4 flows for 
>> Dual-Stack subscribers, how it evolves over time
>> percent rate of IPv6 download rate VS IPv6+IPv4 download rate for Dual-Stack 
>> subscribers, how it evolves over time
>>
>> I'm actually trying to come up with an algorithm that calculates the 
>> difference in resource (flows,bandwidth) usage of NAT444 vs IPv6+NAT44 
>> subscribers.
>> I've made some calculations based on our own numbers (currently 5% and 17%), 
>> but it would be good to get input from others too.
>>
>> Thanks,
>> Tassos
>>
>

measurement data of IPv6 flows and IPv6 download rate for Dual-Stack subscribers

[Tassos Chatzithomaoglou]

I don't know if anyone is doing such measurements or have similar data, but i'm 
looking for the following:

percent rate of number of IPv6 flows VS number of IPv6+IPv4 flows for 
Dual-Stack subscribers, how it evolves over time
percent rate of IPv6 download rate VS IPv6+IPv4 download rate for Dual-Stack 
subscribers, how it evolves over time

I'm actually trying to come up with an algorithm that calculates the difference 
in resource (flows,bandwidth) usage of NAT444 vs IPv6+NAT44 subscribers.
I've made some calculations based on our own numbers (currently 5% and 17%), 
but it would be good to get input from others too.

Thanks,
Tassos

Re: Dual stack statistics?

[Tassos Chatzithomaoglou]

For everyone interested, some updated numbers from 
http://www.ipv6-taskforce.gr/images/5thMeeting/b2%20-%20dkotsilis%20-%202%20ipv6%20forthnet.pdf,
 since more subscribers got ipv6 connectivity.

IPv4/IPv6 upload: 96%/4%
IPv4/IPv6 download: 83%/17%


I'm leaning towards a 25%/5% in the next few months, unless something strange 
happens in the p2p community and upload gets a boost.



--
Tassos

Tassos Chatzithomaoglou wrote on 27/02/2013 22:56:
> I had a quick look at this month's accounting data from a bras (around 4k 
> dual-stack users) and here are some more numbers:
>
> IPv4/IPv6 upload: 98%/2%
> IPv4/IPv6 download: 93%/7%
>
> Supposing the acct records are right (we've hit quite a few bugs on radius 
> ipv6 attrib records), i find this quite low...
>
> --
> Tassos
>
> Brian E Carpenter wrote on 28/01/2013 10:11:
>> I was just wondering if anyone has collected statistics on how much
>> IPv6 traffic a typical dual stack user sees in practice.
>>
>> Maybe there's a way to crowdsource some data.
>> If I run netstat -s (on Windows 7) I see that 15 to 20%
>> of my inbound packets are IPv6, for example.
>>
>>Brian
>>
>>
>>
>>
>