Re: Voice channels (FTTH, DOCSIS, VoLTE)

[Mikael Abrahamsson]

On Mon, 21 Nov 2016, Jean-Francois Mezei wrote:


I need to verify some claims made by incumbents in Canada that VoLTE
data travels on a totally separate channel between the phone and the
antenna.


Typically it travels on another "bearer" compared to Internet traffic.

http://blog.3g4g.co.uk/2013/08/volte-bearers.html

Think of bearers as "tunnels" between the mobile core network and the 
device. They have a lot in common with ATM PVCs in that they can have 
different QoS characteristics. So the VoLTE bearer can have scheduling 
priorities that means it'll always be low-latency and highest priority, 
meaning it might work well when the "Internet" bearer does not.


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

Re: pay.gov and IPv6

[JORDI PALET MARTINEZ]

Tested again from four different networks. Not working for me.

Same in other web sites hosted by 1&1 (for example www.legalveritas.es). All 
their IPv6 web sites are broken, every time I need to access their web sites, 
need to disable IPv6, I know how to do that, but regular folks not.

tbit from 2001:df0:4:4000::1:115 to 2001:8d8:100f:f000::2d5
server-mss 1420, result: pmtud-fail
app: http, url: http://diskmakerx.com/
[  0.010] TX SYN 64  seq = 0:0
[  0.286] RX SYN/ACK 64  seq = 0:1
[  0.286] TX 60  seq = 1:1
[  0.297] TX233  seq = 1:1(173)
[  0.573] RX 60  seq = 1:174  
[  0.799] RX   1480  seq = 1:174(1420)
[  0.799] RX 73  seq = 1421:174(13)
[  0.799] RX   1480  seq = 1434:174(1420)  
[  0.799] RX   1480  seq = 2854:174(1420)  
[  0.799] TX PTB   1280  mtu = 1280
[  0.799] RX   1480  seq = 4274:174(1420)  
[  0.799] RX   1480  seq = 5694:174(1420)  
[  0.799] RX   1480  seq = 7114:174(1420)  
[  0.801] RX   1480  seq = 8534:174(1420)  
[  0.809] TX 60  seq = 174:1  
[  0.821] RX   1480  seq = 9954:174(1420)  
[  0.824] RX   1480  seq = 11374:174(1420)
[  1.628] RX   1480  seq = 1:174(1420)
[  1.629] TX PTB   1280  mtu = 1280
[  3.288] RX   1480  seq = 1:174(1420)
[  3.288] TX PTB   1280  mtu = 1280
[  6.612] RX   1480  seq = 1:174(1420)
[  6.612] TX PTB   1280  mtu = 1280
[ 13.252] RX   1480  seq = 1:174(1420)



Regards,
Jordi


-Mensaje original-
De: Mark Andrews 
Responder a: 
Fecha: lunes, 21 de noviembre de 2016, 1:26
Para: Carl Byington 
CC: , 
Asunto: Re: pay.gov and IPv6


In message <1479686835.13553.4.ca...@ns.five-ten-sg.com>, Carl Byington 
writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Sun, 2016-11-20 at 10:51 +0100, JORDI PALET MARTINEZ wrote:
> > For example, you will not get this working if you have a lower MTU
> > than 1.500, which is quite normal, not just for tunnels, but also
> > because the PPP/others encapsulation in many access links:
> 
> > http://diskmakerx.com/
> 
> curl -6 -v http://diskmakerx.com/
> 
> That works here via an he.net tunnel. Perhaps 1and1 fixed something.

And the advertised MSS was what?  On my box I'm seeing 1220 for
IPv6 compared with 1460 for IPv4.  1220 shouldn't see PMTU problems.

1460 on the other hand will cause problems as more clients are
forced behind IPv4 as a service links.

11:14:50.056215 IP 172.30.42.121.52280 > 217.160.0.214.80: Flags [S], seq 
2115844511, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 538455715 
ecr 0,sackOK,eol], length 0
11:14:50.137770 IP6 2001:470:a001:4:c00d:3d8c:14e7:6de3.52282 > 
2001:8d8:100f:f000::2d5.80: Flags [S], seq 4181372812, win 65535, options [mss 
1220,nop,wscale 4,nop,nop,TS val 538455793 ecr 0,sackOK,eol], length 0

Mark

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
> 
> iEYEAREKAAYFAlgyOp4ACgkQL6j7milTFsFslACfaRbslKuUHrxGJyuI+j8X/Sle
> AZ8AoIg2wF/GWBdDtphQSuD9/gGMDfOA
> =4nAp
> -END PGP SIGNATURE-
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org





**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.

Re: Voice channels (FTTH, DOCSIS, VoLTE)

[Marcin Cieslak]

On Mon, 21 Nov 2016, Jean-Francois Mezei wrote:

> Would DOCSIS be the same as FTTH, with the cableco voice service riding
> isnide the same DOCSIS bandwidth but with pre-allocated bandwidth, or do
> they allocate separate NTSC channels with a totally separate data pipe ?

DOCSIS has a possibility to provision unidirectional data flows with
certain quality of service characteristics. A pair of these is usually
dedicated to a casual Internet connection, another one can be used for
layer 2 telephony service, etc. Allocating a whole TV channel frequency
would be a big waste. Not even sure it would be possible with standard
DOCSIS.

Marcin Cieślak

Voice channels (FTTH, DOCSIS, VoLTE)

[Jean-Francois Mezei]

I need to verify some claims made by incumbents in Canada that VoLTE
data travels on a totally separate channel between the phone and the
antenna.

Does anyone have links to relevant VoLTE documentation that would
provide how VoLTE is provisioned ? I was under the impression that it
was more of an "app" on the phone that used the same IP address given
for access to Internet. Does the phone get a separate IP and possibly
separate VLAN with dedicated bandwidth to ensure voice call quality?

Or are all the performance tricks done on land beyond the antenna once
the packets are identified as VoLTE, but the phone itself just treats
them as a normal app ?

I know that for FTTH, there is a separate "channel" where the "POTS"
emulation can be provided with its own dedicated IP and bandwidth.

Would DOCSIS be the same as FTTH, with the cableco voice service riding
isnide the same DOCSIS bandwidth but with pre-allocated bandwidth, or do
they allocate separate NTSC channels with a totally separate data pipe ?

(in which case, in systems with only 42mhz of uplink frequencies, the
voice would have its own NTSC channel on uplink?

Re: pay.gov and IPv6

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2016-11-21 at 11:26 +1100, Mark Andrews wrote:
> And the advertised MSS was what?  On my box I'm seeing 1220 for
> IPv6 compared with 1460 for IPv4.  1220 shouldn't see PMTU problems.

  --> 2001:8d8:100f:f000::2d5 syn w/ mss 1440
  <-- 2001:8d8:100f:f000::2d5 syn,ack w/ mss 1420
  --> 2001:8d8:100f:f000::2d5 ack
  --> 2001:8d8:100f:f000::2d5 GET / HTTP/1.1
  <-- 2001:8d8:100f:f000::2d5 ack
  <-- 2001:8d8:100f:f000::2d5 data...


data is a 1480 byte ipv6 packet:

ip6.header.payload.length = 1440 which is the tcp packet
tcp.header.length = 32 bytes
tcp.data.size = 1408 bytes (http response)


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlgyRUYACgkQL6j7milTFsH8tgCeLB9E9C2pjFqgp1w2YpipmvzZ
ib4Ani/cQmAgEo3QPfA9hMntGq4VLoO/
=mmCW
-END PGP SIGNATURE-

Re: pay.gov and IPv6

[Mark Andrews]

In message <1479686835.13553.4.ca...@ns.five-ten-sg.com>, Carl Byington writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Sun, 2016-11-20 at 10:51 +0100, JORDI PALET MARTINEZ wrote:
> > For example, you will not get this working if you have a lower MTU
> > than 1.500, which is quite normal, not just for tunnels, but also
> > because the PPP/others encapsulation in many access links:
> 
> > http://diskmakerx.com/
> 
> curl -6 -v http://diskmakerx.com/
> 
> That works here via an he.net tunnel. Perhaps 1and1 fixed something.

And the advertised MSS was what?  On my box I'm seeing 1220 for
IPv6 compared with 1460 for IPv4.  1220 shouldn't see PMTU problems.

1460 on the other hand will cause problems as more clients are
forced behind IPv4 as a service links.

11:14:50.056215 IP 172.30.42.121.52280 > 217.160.0.214.80: Flags [S], seq 
2115844511, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 538455715 
ecr 0,sackOK,eol], length 0
11:14:50.137770 IP6 2001:470:a001:4:c00d:3d8c:14e7:6de3.52282 > 
2001:8d8:100f:f000::2d5.80: Flags [S], seq 4181372812, win 65535, options [mss 
1220,nop,wscale 4,nop,nop,TS val 538455793 ecr 0,sackOK,eol], length 0

Mark

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
> 
> iEYEAREKAAYFAlgyOp4ACgkQL6j7milTFsFslACfaRbslKuUHrxGJyuI+j8X/Sle
> AZ8AoIg2wF/GWBdDtphQSuD9/gGMDfOA
> =4nAp
> -END PGP SIGNATURE-
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: pay.gov and IPv6

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sun, 2016-11-20 at 10:51 +0100, JORDI PALET MARTINEZ wrote:
> For example, you will not get this working if you have a lower MTU
> than 1.500, which is quite normal, not just for tunnels, but also
> because the PPP/others encapsulation in many access links:

> http://diskmakerx.com/

curl -6 -v http://diskmakerx.com/

That works here via an he.net tunnel. Perhaps 1and1 fixed something.




-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlgyOp4ACgkQL6j7milTFsFslACfaRbslKuUHrxGJyuI+j8X/Sle
AZ8AoIg2wF/GWBdDtphQSuD9/gGMDfOA
=4nAp
-END PGP SIGNATURE-

Re: list scrap by long time participant?

[Job Snijders]

On Sun, Nov 20, 2016 at 12:19:35PM -0800, Scott Weeks wrote:
> --- Begin forwarded message:
> 
> Hi Ladies and Gentlemen,
> 
> .
> Contact me for further details.
> -
> 
> Did anyone get this?  I hesitate to think a long time NANOG
> participant sent me this.  NANOG is the only way he would've gotten my
> email address.
> 
> scott

Scott, everyone,

If you receive spam or other crap, and you suspect it is because of your
NANOG mailing list membership, please reach out to adm...@nanog.org.

Kind regards,

Job

list scrap by long time participant?

[Scott Weeks]

--- Begin forwarded message:

Hi Ladies and Gentlemen,

We have three of the top five transit providers in our 
portfolio: Telia, Cogent, and GTT. Also NTT, Telecom 
Italia, and PCCW.

Telia pricing is attractive given the quality of the 
product. Contact me for further details.
-



Did anyone get this?  I hesitate to think a long time
NANOG participant sent me this.  NANOG is the only way
he would've gotten my email address.

scott

Re: pay.gov and IPv6

[JORDI PALET MARTINEZ]

Somebody pointed to me that even happy eyeballs will not fall back to IPv4 when 
PMTUD is blocked …

This is a big issue, many folks are deploying IPv6 web sites, and not 
double-checking this. Actually, this is VERY BIG issue with all the 1&1 sites. 
I tried to contact them many times for more than a year, and they seem to not 
care, so clearly not a recommended hosting provider, as they don’t care about 
the quality of service that their customers have. I will change my mind if 
someone from 1&1 is finally responding, in case they are in this list … For 
example, you will not get this working if you have a lower MTU than 1.500, 
which is quite normal, not just for tunnels, but also because the PPP/others 
encapsulation in many access links:

http://diskmakerx.com/

Furthermore, I mention this filtering problem in the article about the IPv6 
survey results, for those that don’t follow RIPE LABS site:

https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deployment-survey

Regards,
Jordi


-Mensaje original-
De: NANOG  en nombre de JORDI PALET MARTINEZ 

Responder a: 
Fecha: viernes, 18 de noviembre de 2016, 21:05
Para: 
Asunto: Re: pay.gov and IPv6

I tested from my home and happy eyeballs is not falling back to IPv4.

So, I tend to suspect that is not ICMPv6 filtering, but something else, 
such as wrong load balancer or ECMP configuration.

Regards,
Jordi


-Mensaje original-
De: NANOG  en nombre de Carl Byington 

Responder a: 
Fecha: sábado, 19 de noviembre de 2016, 3:22
Para: 
Asunto: Re: pay.gov and IPv6


> > I am working with pay.gov.c...@clev.frb.org, trying to explain the
> problem.

The intersection of government bureaucracy and technical issues is
frustrating to say the least. I just sent the message below, but have no
expectation that it will change anything. 

==

On Fri, 2016-11-18 at 12:39 +, CLEV Pay Gov wrote:
> It would be best to discuss this via phone.  Please contact our help
> desk at the number below and we could see if there's anything we could
> do over the phone to help troubleshoot.

That is hopeless. Verbal technical discussions rarely work unless both
sides can see the same text. Have you ever tried (while talking on the
phone) to get someone to type in clev.frb.org without making a bunch of
mistakes in the spelling??

Anyway, just for my amusement, I did call 800-624-1373, Option #2, and
am on the line now, trying to explain this. 10 minutes and counting. Ok,
there does not seem to be any overall ticket for "pay.gov does not work
at all". They refuse to open a tech support ticket.


> If not, we may need to open a ticket for our technical support.

Please open a ticket, and attach the following text for your tech
support folks. Alternatively, have them look at the "pay.gov and ipv6"
thread on nanog:

http://mailman.nanog.org/pipermail/nanog/2016-November/thread.html



www.pay.gov has an IPv6 address of 2605:3100:fffd:100::15, but that
machine or its upstream routers are filtering icmpv6 messages. That web
site is not accessible from systems with an MTU of 1280 bytes.

The test case is:

echo -e 'GET /public/home HTTP/1.0\n' | \
openssl s_client -servername www.pay.gov -ign_eof -connect \
'[2605:3100:fffd:100::15]:443'

Run that (or just use a browser to try https://www.pay.gov) from a
system with a 1500 byte MTU, and it works. Run it from a system with
upstream connectivity via a tunnel, so the path MTU is smaller, and it
fails. Such tunnels are common for IPv6.

Please stop filtering icmpv6.









**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the use of the 
individual(s) named above. If you are not the intended recipient be aware that 
any disclosure, copying, distribution or use of the contents of this 
information, including attached files, is prohibited.





**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains