On 05/08/2016 03:53 PM, James Knott wrote:

On 05/08/2016 11:17 AM, Jeremy Baker wrote:

...

Hope this helps you out.

- I am able to get dhcpcd to get an IPv6 address, though it appears on the lan side, not wan. I also can't get it to advertise the prefix to the network. Are you doing that?

Here's what I have in radvd.conf:

interface eth1 { AdvSendAdvert on; MaxRtrAdvInterval 30;

prefix ::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; AdvValidLifetime 300; AdvPreferredLifetime 120; }; };

And the relevant part of dhcpcd.conf:

# from https://wiki.archlinux.org/index.php/IPv6 duid noipv6rs waitip 6 # Uncomment this line if you are running dhcpcd for IPv6 only. #ipv6only

# use the interface connected to WAN interface eth0 ipv6rs iaid 1 # use the interface connected to your LAN ia_pd 1 eth1 ia_pd 1/::/64 eth1/0/64

I am using radvd. My config is interface eth2 { AdvSendAdvert on; AdvManagedFlag off; AdvOtherConfigFlag off; prefix ::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; RDNSS (ip6 dns server) { }; }; -- Jeremy Baker GnuPGP fingerprint = EE66 AC49 E008 E09A 7A2A 0195 50EF 580B EDBB 95B6 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/08/2016 09:58 PM, James Knott wrote:

On 05/08/2016 09:31 PM, Jeremy Baker wrote:

...

I am using radvd. My config is Did you have to do anything about wicked? Also, I don't know why I see an IPv6 address on my LAN interface but not the WAN side. Well, I didn't have to touch wicked since my adsl configuration is done without the help of suse (there is no longer a dsl option in yast), but I did notice this from the dhcpcd docs:

noipv6rs # disable routing solicitation denyinterfaces eth2 # Don't touch eth2 at all interface eth0 ipv6rs # enable routing solicitation get the # default IPv6 route ia_na 1 # request an IPv6 address ia_pd 2 eth1/0 # request a PD and assign it to eth1 ia_pd 3 eth2/1 eth3/2 # req a PD and assign it to eth2 and eth3 # we cannot use SLA 0 above because we are # assinging the PD to more than one interface It would appear that in addition to a prefix, it can also request an address. Maybe try adding the ia_na line and see if that works? -- Jeremy Baker GnuPGP fingerprint = EE66 AC49 E008 E09A 7A2A 0195 50EF 580B EDBB 95B6 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

09.05.2016 21:58, James Knott пишет:

On 05/08/2016 11:49 PM, Jeremy Baker wrote:

...

It would appear that in addition to a prefix, it can also request an address. Maybe try adding the ia_na line and see if that works?

I now get an IPv6 on my WAN interface, but it only lasts for a few seconds. Here's the relevant bit of my dhcpcd.conf:

duid noipv6rs waitip 6 # Uncomment this line if you are running dhcpcd for IPv6 only. ipv6only # use the interface connected to WAN interface eth0 ipv6rs iaid 1 # use the interface connected to your LAN ia_na 1 ia_pd 2 eth1 ia_pd 3/::/64 eth1/0/64

Only one ia_pd statement for interface that gets prefix is needed. I am not sure what it does in this case, whether first or last wins. Also you need to know length of prefix that is delegated. In particular, delegated prefix length need to be smaller than assigned prefix length; so your second ia_pd will likely not work. If you want to assign 64 prefix to eth1 you need to request 56 prefix from server. Another consideration is that sla_id 0 is special; are you sure you really want it? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/09/2016 10:32 PM, James Knott wrote:

...

Only one ia_pd statement for interface that gets prefix is needed. I am

...

not sure what it does in this case, whether first or last wins. Also you need to know length of prefix that is delegated. In particular, delegated prefix length need to be smaller than assigned prefix length; so your second ia_pd will likely not work. If you want to assign 64 prefix to eth1 you need to request 56 prefix from server. Another consideration is that sla_id 0 is special; are you sure you really want it? I have commented out the line ia_pd 3/::/64 eth1/0/64

I'm not really sure what I want, as when I look around the net, I see different things, with no clear idea of what's needed.

I now have an IPv6 on my WAN interface that seems to be staying, but no IPv6 address on my LAN interface. Here's my radvd.conf: interface eth1 { AdvSendAdvert on; MaxRtrAdvInterval 30; prefix ::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr off; AdvValidLifetime 300; AdvPreferredLifetime 120; }; }; -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/09/2016 11:23 PM, Andrei Borzenkov wrote:

IP address on LAN interface (if you mean router) is assigned by dhcpcd. radvd job is just to pick up prefix from it and advertise. So forget about radvd until you actually got prefix delegation working. How do you start it (exact command line)? Does dhcpcd request prefix? Does it get anything back? Start it with --debug and check logs.

firewall:/etc # dhcpcd --debug dhcpcd-6.10.1 starting eth0: disabling kernel IPv6 RA support eth1: disabling kernel IPv6 RA support eth0: executing `/usr/lib/dhcpcd-run-hooks' PREINIT eth0: executing `/usr/lib/dhcpcd-run-hooks' CARRIER eth1: executing `/usr/lib/dhcpcd-run-hooks' PREINIT eth1: executing `/usr/lib/dhcpcd-run-hooks' CARRIER DUID 00:01:00:01:1e:c2:1b:8a:00:14:d1:2b:ed:ea eth0: IAID 00:00:00:01 eth0: IAID 00:00:00:02 eth0: delaying IPv6 router solicitation for 0.4 seconds eth0: reading lease `/var/db/dhcpcd-eth0.lease6' eth0: DHCPv6 REPLY: Unknown binding eth0: accepted reconfigure key eth0: rebinding prior DHCPv6 lease eth0: delaying REBIND6 (xid 0x2aa365), next in 0.8 seconds eth1: IAID 17:a7:f2:d3 eth0: soliciting an IPv6 router eth0: sending Router Solicitation eth0: broadcasting REBIND6 (xid 0x2aa365), next in 1.0 seconds eth0: accepted reconfigure key eth0: DHCPv6 REPLY: Unknown binding eth0: REPLY6 received from fe80::217:10ff:fe91:41f eth0: adding address 2607:f798:804:93:4c11:38f0:afc:dd1b/128 eth0: pltime 171644 seconds, vltime 343870 seconds eth0: renew in 85822 seconds, rebind in 137315 seconds eth0: writing lease `/var/db/dhcpcd-eth0.lease6' eth0: waiting for DHCPv6 DAD to complete eth0: DHCPv6 DAD completed eth0: executing `/usr/lib/dhcpcd-run-hooks' REBIND6 forking to background forked to background, child pid 2130 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/14/2016 01:10 AM, Andrei Borzenkov wrote:

It does not show anything related to PD. At this point I would be curious to see actual packet capture on client from the very beginning.

Here's what's captured immediately after starting dhcpcd: No. Time Source Destination Protocol Length Info 1 0.000000000 fe80::214:d1ff:fe2b:edea ff02::1:2 DHCPv6 251 Rebind XID: 0xd07562 CID: 0 00100011ec21b8a0014d12bedea IAA: 2607:f798:804:93:4c11:38f0:afc:dd1b Frame 1: 251 bytes on wire (2008 bits), 251 bytes captured (2008 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::1:2 (ff02::1:2) User Datagram Protocol, Src Port: 546 (546), Dst Port: 547 (547) DHCPv6 No. Time Source Destination Protocol Length Info 2 0.022977000 fe80::217:10ff:fe91:41f fe80::214:d1ff:fe2b:edea DHCPv6 306 Reply XID: 0xd07562 CID: 000100011ec21b8a0014d12bedea IAA: 2607:f798:804:93:4c11:38f0:afc:dd1b Frame 2: 306 bytes on wire (2448 bits), 306 bytes captured (2448 bits) on interface 0 Ethernet II, Src: Casa_91:04:1f (00:17:10:91:04:1f), Dst: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea) Internet Protocol Version 6, Src: fe80::217:10ff:fe91:41f (fe80::217:10ff:fe91:41f), Dst: fe80::214:d1ff:fe2b:ede a (fe80::214:d1ff:fe2b:edea) User Datagram Protocol, Src Port: 547 (547), Dst Port: 546 (546) DHCPv6 No. Time Source Destination Protocol Length Info 3 0.029390000 fe80::214:d1ff:fe2b:edea ff02::16 ICMPv6 170 Multicast Listener Report M essage v2 Frame 3: 170 bytes on wire (1360 bits), 170 bytes captured (1360 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_16 (33:33:00:00:00:16) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::16 (ff02::16) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 4 0.099893000 fe80::214:d1ff:fe2b:edea ff02::2 ICMPv6 70 Router Solicitation from 00 :14:d1:2b:ed:ea Frame 4: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_02 (33:33:00:00:00:02) ^Cfirewall:~ # cat dhcpcd No. Time Source Destination Protocol Length Info 1 0.000000000 fe80::214:d1ff:fe2b:edea ff02::1:2 DHCPv6 251 Rebind XID: 0xd07562 CID: 000100011ec21b8a0014d12bedea IAA: 2607:f798:804:93:4c11:38f0:afc:dd1b Frame 1: 251 bytes on wire (2008 bits), 251 bytes captured (2008 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::1:2 (ff02::1:2) User Datagram Protocol, Src Port: 546 (546), Dst Port: 547 (547) DHCPv6 No. Time Source Destination Protocol Length Info 2 0.022977000 fe80::217:10ff:fe91:41f fe80::214:d1ff:fe2b:edea DHCPv6 306 Reply XID: 0xd07562 CID: 000100011ec21b8a0014d12bedea IAA: 2607:f798:804:93:4c11:38f0:afc:dd1b Frame 2: 306 bytes on wire (2448 bits), 306 bytes captured (2448 bits) on interface 0 Ethernet II, Src: Casa_91:04:1f (00:17:10:91:04:1f), Dst: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea) Internet Protocol Version 6, Src: fe80::217:10ff:fe91:41f (fe80::217:10ff:fe91:41f), Dst: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea) User Datagram Protocol, Src Port: 547 (547), Dst Port: 546 (546) DHCPv6 No. Time Source Destination Protocol Length Info 3 0.029390000 fe80::214:d1ff:fe2b:edea ff02::16 ICMPv6 170 Multicast Listener Report Message v2 Frame 3: 170 bytes on wire (1360 bits), 170 bytes captured (1360 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_16 (33:33:00:00:00:16) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::16 (ff02::16) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 4 0.099893000 fe80::214:d1ff:fe2b:edea ff02::2 ICMPv6 70 Router Solicitation from 00:14:d1:2b:ed:ea Frame 4: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_02 (33:33:00:00:00:02) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::2 (ff02::2) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 5 0.745368000 fe80::214:d1ff:fe2b:edea ff02::16 ICMPv6 170 Multicast Listener Report Message v2 Frame 5: 170 bytes on wire (1360 bits), 170 bytes captured (1360 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_16 (33:33:00:00:00:16) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::16 (ff02::16) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 6 1.017378000 :: ff02::1:fffc:dd1b ICMPv6 78 Neighbor Solicitation for 2607:f798:804:93:4c11:38f0:afc:dd1b Frame 6: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_ff:fc:dd:1b (33:33:ff:fc:dd:1b) Internet Protocol Version 6, Src: :: (::), Dst: ff02::1:fffc:dd1b (ff02::1:fffc:dd1b) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 7 2.018755000 2607:f798:804:93:4c11:38f0:afc:dd1b ff02::fb MDNS 202 Standard query response 0x0000 PTR, cache flush firewall.local AAAA, cache flush fe80::214:d1ff:fe2b:edea Frame 7: 202 bytes on wire (1616 bits), 202 bytes captured (1616 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: 2607:f798:804:93:4c11:38f0:afc:dd1b (2607:f798:804:93:4c11:38f0:afc:dd1b), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (response) No. Time Source Destination Protocol Length Info 8 2.025393000 fe80::214:d1ff:fe2b:edea ff02::16 ICMPv6 90 Multicast Listener Report Message v2 Frame 8: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_16 (33:33:00:00:00:16) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::16 (ff02::16) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 9 2.037400000 fe80::214:d1ff:fe2b:edea ff02::16 ICMPv6 90 Multicast Listener Report Message v2 Frame 9: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_16 (33:33:00:00:00:16) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::16 (ff02::16) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 10 2.174521000 2607:f798:804:93:4c11:38f0:afc:dd1b ff02::fb MDNS 214 Standard query 0x0000 ANY b.1.d.d.c.f.a.0.0.f.8.3.1.1.c.4.3.9.0.0.4.0.8.0.8.9.7.f.7.0.6.2.ip6.arpa, "QM" question ANY firewall.local, "QM" question Frame 10: 214 bytes on wire (1712 bits), 214 bytes captured (1712 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: 2607:f798:804:93:4c11:38f0:afc:dd1b (2607:f798:804:93:4c11:38f0:afc:dd1b), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (query) No. Time Source Destination Protocol Length Info 11 2.425498000 2607:f798:804:93:4c11:38f0:afc:dd1b ff02::fb MDNS 214 Standard query 0x0000 ANY b.1.d.d.c.f.a.0.0.f.8.3.1.1.c.4.3.9.0.0.4.0.8.0.8.9.7.f.7.0.6.2.ip6.arpa, "QM" question ANY firewall.local, "QM" question Frame 11: 214 bytes on wire (1712 bits), 214 bytes captured (1712 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: 2607:f798:804:93:4c11:38f0:afc:dd1b (2607:f798:804:93:4c11:38f0:afc:dd1b), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (query) No. Time Source Destination Protocol Length Info 12 2.676536000 2607:f798:804:93:4c11:38f0:afc:dd1b ff02::fb MDNS 214 Standard query 0x0000 ANY b.1.d.d.c.f.a.0.0.f.8.3.1.1.c.4.3.9.0.0.4.0.8.0.8.9.7.f.7.0.6.2.ip6.arpa, "QM" question ANY firewall.local, "QM" question Frame 12: 214 bytes on wire (1712 bits), 214 bytes captured (1712 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: 2607:f798:804:93:4c11:38f0:afc:dd1b (2607:f798:804:93:4c11:38f0:afc:dd1b), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (query) No. Time Source Destination Protocol Length Info 13 2.877679000 2607:f798:804:93:4c11:38f0:afc:dd1b ff02::fb MDNS 202 Standard query response 0x0000 PTR, cache flush firewall.local AAAA, cache flush 2607:f798:804:93:4c11:38f0:afc:dd1b Frame 13: 202 bytes on wire (1616 bits), 202 bytes captured (1616 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: 2607:f798:804:93:4c11:38f0:afc:dd1b (2607:f798:804:93:4c11:38f0:afc:dd1b), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (response) No. Time Source Destination Protocol Length Info 14 3.983582000 2607:f798:804:93:4c11:38f0:afc:dd1b ff02::fb MDNS 202 Standard query response 0x0000 PTR, cache flush firewall.local AAAA, cache flush 2607:f798:804:93:4c11:38f0:afc:dd1b Frame 14: 202 bytes on wire (1616 bits), 202 bytes captured (1616 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: 2607:f798:804:93:4c11:38f0:afc:dd1b (2607:f798:804:93:4c11:38f0:afc:dd1b), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (response) No. Time Source Destination Protocol Length Info 15 4.100982000 fe80::214:d1ff:fe2b:edea ff02::2 ICMPv6 70 Router Solicitation from 00:14:d1:2b:ed:ea Frame 15: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_02 (33:33:00:00:00:02) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::2 (ff02::2) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 16 6.089818000 2607:f798:804:93:4c11:38f0:afc:dd1b ff02::fb MDNS 202 Standard query response 0x0000 PTR, cache flush firewall.local AAAA, cache flush 2607:f798:804:93:4c11:38f0:afc:dd1b Frame 16: 202 bytes on wire (1616 bits), 202 bytes captured (1616 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: 2607:f798:804:93:4c11:38f0:afc:dd1b (2607:f798:804:93:4c11:38f0:afc:dd1b), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (response) No. Time Source Destination Protocol Length Info 17 8.102563000 fe80::214:d1ff:fe2b:edea ff02::2 ICMPv6 70 Router Solicitation from 00:14:d1:2b:ed:ea Frame 17: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_02 (33:33:00:00:00:02) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::2 (ff02::2) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 18 12.104186000 fe80::214:d1ff:fe2b:edea ff02::2 ICMPv6 70 Router Solicitation from 00:14:d1:2b:ed:ea Frame 18: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_02 (33:33:00:00:00:02) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::2 (ff02::2) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 19 12.106979000 fe80::214:d1ff:fe2b:edea ff02::fb MDNS 202 Standard query response 0x0000 PTR, cache flush firewall.local AAAA, cache flush 2607:f798:804:93:4c11:38f0:afc:dd1b Frame 19: 202 bytes on wire (1616 bits), 202 bytes captured (1616 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (response) No. Time Source Destination Protocol Length Info 20 12.113401000 fe80::214:d1ff:fe2b:edea ff02::16 ICMPv6 110 Multicast Listener Report Message v2 Frame 20: 110 bytes on wire (880 bits), 110 bytes captured (880 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_16 (33:33:00:00:00:16) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::16 (ff02::16) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 21 12.330772000 fe80::214:d1ff:fe2b:edea ff02::fb MDNS 214 Standard query 0x0000 ANY a.e.d.e.b.2.e.f.f.f.1.d.4.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa, "QM" question ANY firewall.local, "QM" question Frame 21: 214 bytes on wire (1712 bits), 214 bytes captured (1712 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (query) No. Time Source Destination Protocol Length Info 22 12.369357000 fe80::214:d1ff:fe2b:edea ff02::16 ICMPv6 110 Multicast Listener Report Message v2 Frame 22: 110 bytes on wire (880 bits), 110 bytes captured (880 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_16 (33:33:00:00:00:16) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::16 (ff02::16) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 23 12.581672000 fe80::214:d1ff:fe2b:edea ff02::fb MDNS 214 Standard query 0x0000 ANY a.e.d.e.b.2.e.f.f.f.1.d.4.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa, "QM" question ANY firewall.local, "QM" question Frame 23: 214 bytes on wire (1712 bits), 214 bytes captured (1712 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (query) No. Time Source Destination Protocol Length Info 24 12.832762000 fe80::214:d1ff:fe2b:edea ff02::fb MDNS 214 Standard query 0x0000 ANY a.e.d.e.b.2.e.f.f.f.1.d.4.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa, "QM" question ANY firewall.local, "QM" question Frame 24: 214 bytes on wire (1712 bits), 214 bytes captured (1712 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (query) No. Time Source Destination Protocol Length Info 25 13.033777000 fe80::214:d1ff:fe2b:edea ff02::fb MDNS 202 Standard query response 0x0000 PTR, cache flush firewall.local AAAA, cache flush fe80::214:d1ff:fe2b:edea Frame 25: 202 bytes on wire (1616 bits), 202 bytes captured (1616 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (response) No. Time Source Destination Protocol Length Info 26 14.207116000 fe80::214:d1ff:fe2b:edea ff02::fb MDNS 202 Standard query response 0x0000 PTR, cache flush firewall.local AAAA, cache flush fe80::214:d1ff:fe2b:edea Frame 26: 202 bytes on wire (1616 bits), 202 bytes captured (1616 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (response) No. Time Source Destination Protocol Length Info 27 16.381999000 fe80::214:d1ff:fe2b:edea ff02::fb MDNS 202 Standard query response 0x0000 PTR, cache flush firewall.local AAAA, cache flush fe80::214:d1ff:fe2b:edea Frame 27: 202 bytes on wire (1616 bits), 202 bytes captured (1616 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::fb (ff02::fb) User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) Domain Name System (response) No. Time Source Destination Protocol Length Info 28 89.287617000 fe80::217:10ff:fe91:41f ff02::1 ICMPv6 90 Multicast Listener Query Frame 28: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) on interface 0 Ethernet II, Src: Casa_91:04:1f (00:17:10:91:04:1f), Dst: IPv6mcast_01 (33:33:00:00:00:01) Internet Protocol Version 6, Src: fe80::217:10ff:fe91:41f (fe80::217:10ff:fe91:41f), Dst: ff02::1 (ff02::1) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 29 89.291534000 fe80::217:10ff:fe91:41f ff02::1 ICMPv6 86 Multicast Listener Query Frame 29: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface 0 Ethernet II, Src: Casa_91:04:1f (00:17:10:91:04:1f), Dst: IPv6mcast_01 (33:33:00:00:00:01) Internet Protocol Version 6, Src: fe80::217:10ff:fe91:41f (fe80::217:10ff:fe91:41f), Dst: ff02::1 (ff02::1) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 30 90.556962000 fe80::c6e9:84ff:fe82:7238 ff02::16 ICMPv6 90 Multicast Listener Report Message v2 Frame 30: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) on interface 0 Ethernet II, Src: Tp-LinkT_82:72:38 (c4:e9:84:82:72:38), Dst: IPv6mcast_16 (33:33:00:00:00:16) Internet Protocol Version 6, Src: fe80::c6e9:84ff:fe82:7238 (fe80::c6e9:84ff:fe82:7238), Dst: ff02::16 (ff02::16) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 31 91.109368000 fe80::214:d1ff:fe2b:edea ff02::1:ff00:0 ICMPv6 86 Multicast Listener Report Frame 31: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_ff:00:00:00 (33:33:ff:00:00:00) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::1:ff00:0 (ff02::1:ff00:0) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 32 91.221363000 fe80::214:d1ff:fe2b:edea ff02::1:ff2b:edea ICMPv6 86 Multicast Listener Report Frame 32: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_ff:2b:ed:ea (33:33:ff:2b:ed:ea) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::1:ff2b:edea (ff02::1:ff2b:edea) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 33 91.461368000 fe80::214:d1ff:fe2b:edea ff02::fb ICMPv6 86 Multicast Listener Report Frame 33: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_fb (33:33:00:00:00:fb) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::fb (ff02::fb) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 34 92.181369000 fe80::214:d1ff:fe2b:edea ff02::2 ICMPv6 86 Multicast Listener Report Frame 34: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface 0 Ethernet II, Src: Trendnet_2b:ed:ea (00:14:d1:2b:ed:ea), Dst: IPv6mcast_02 (33:33:00:00:00:02) Internet Protocol Version 6, Src: fe80::214:d1ff:fe2b:edea (fe80::214:d1ff:fe2b:edea), Dst: ff02::2 (ff02::2) Internet Control Message Protocol v6 No. Time Source Destination Protocol Length Info 35 92.256985000 fe80::c6e9:84ff:fe82:7238 ff02::1:ff82:7238 ICMPv6 86 Multicast Listener Report Frame 35: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) on interface 0 Ethernet II, Src: Tp-LinkT_82:72:38 (c4:e9:84:82:72:38), Dst: IPv6mcast_ff:82:72:38 (33:33:ff:82:72:38) Internet Protocol Version 6, Src: fe80::c6e9:84ff:fe82:7238 (fe80::c6e9:84ff:fe82:7238), Dst: ff02::1:ff82:7238 (ff02::1:ff82:7238) Internet Control Message Protocol v6 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/15/2016 12:25 AM, Andrei Borzenkov wrote:

15.05.2016 00:44, James Knott пишет:

...

On 05/14/2016 01:10 AM, Andrei Borzenkov wrote:

...

It does not show anything related to PD. At this point I would be curious to see actual packet capture on client from the very beginning. Here's what's captured immediately after starting dhcpcd:

There is no trace of prefix delegation request in output you posted.

I recreated dhcpcd.conf from scratch, as shown: # cat /etc/dhcpcd.conf duid # DHCP Unique Identifier noipv6rs # No IPv6 router solicitation waitip 6 #Wait for IPv6 address # Uncomment this line if you are running dhcpcd for IPv6 only. ipv6only #Run dhcpcd for IPv6 only # use the interface connected to WAN interface eth0 # WAN ipv6rs # IPv6 router solicitation for WAN interface iaid 1 # Set the Interface Association Identifier for WAN ia_na 1 # Request an IPv6 address for WAN interface ia_pd 2 eth1/0 # Request prefix for LAN Sometimes it works and sometimes it doesn't. When it works, I get <prefix>::1 on the LAN port, as it should for a gateway. However, when it fails, I get the following: # dhcpcd --debug dhcpcd-6.10.1 starting eth0: executing `/usr/lib/dhcpcd-run-hooks' PREINIT eth0: executing `/usr/lib/dhcpcd-run-hooks' CARRIER eth1: executing `/usr/lib/dhcpcd-run-hooks' PREINIT eth1: executing `/usr/lib/dhcpcd-run-hooks' CARRIER DUID 00:01:00:01:1e:c2:1b:8a:00:14:d1:2b:ed:ea eth0: IAID d1:2b:ed:ea eth1: IAID 17:a7:f2:d3 timed out forking to background forked to background, child pid 2204 When this happens, Wireshark doesn't show any DHCPv6 activity, so it's not even trying to get an address. Very frustrating! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/08/2016 11:17 AM, Jeremy Baker wrote:

the contents of my dhcpcd.conf were:

denyinterfaces eth1 noipv6rs interface ppp0 ipv6rs ipv6only iaid 1 ia_pd 1 eth2/5 duid persistent option rapid_commit option classless_static_routes option interface_mtu

Hope this helps you out.

What's your radvd.conf? tnx jk -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/08/2016 11:26 AM, Per Jessen wrote:

James Knott wrote:

...

On 04/19/2016 10:35 AM, Jeremy Baker wrote:

...

On 04/18/2016 10:30 PM, James Knott wrote:

...

My ISP is finally rolling out IPv6. One thing that's required is for the router to make a DHCPv6-PD request to get the prefix info etc. I don't know if my router/firewall, based on openSUSE 13.1 is doing that. I don't see anything in Wireshark that would indicate it's making that sort of request. I'm also not aware of any configuration that would enable it. Does anyone know anything about this?

tnx jk

dhcpcd after 6.4.0 will request and disposition a ia-pd prefix. I'm not sure what version 13.1 has, but opensuse 13.2 only has version 3.2.3. I installed dhcpcd-6.10.1 from source on leap and have been using it to get a delegation from my isp for 3 months or so.

I just installed Leap 42.1 and found it can't even get an IPv6 address for itself, let alone a prefix for the network. This is a step back from 13.1, which at least could get it's own IPv6 address via dhcp. I have Leap421 running fine on IPv6, with dhcp etc. I don't recall having to change any config.

...

I'll try installing dhcpcd 6.10 and see what happens. Any configuration required?

I have put in a request for dhcpv6-pd to be added, but I shouldn't have had to. This is something that's becoming essential. Why are the developers missing the boat on this??? It is odd, but obviously you're one of the very first to encounter this issue.

Actually, no. Jeremy Baker also had this and installed a later version of dhcpcd to get around the problem. More and more people are running IPv6 and more and more carriers are switching to it. I've been getting IPv6 via tunnel for 6 years and my ISP is now providing it. These days, dhcpv6-pd is being used to provide the prefixes and must be supported by anything that's being used as a firewall/router and that includes Linux. A friend is experiencing a similar issue with a Trendnet TEW-812DRU router which supports IPv6 but apparently not dhcpv6-pd. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/08/2016 11:56 AM, Per Jessen wrote:

...

More and more people are running IPv6 and more and more carriers are

...

switching to it. I've been getting IPv6 via tunnel for 6 years and my ISP is now providing it. These days, dhcpv6-pd is being used to provide the prefixes and must be supported by anything that's being used as a firewall/router and that includes Linux. Sure - I guess most people have a router/modem with the appropriate PD support. I've never needed it, always had static configs.

Manual configuration is used for business customers, where the prefix is configured into the router and routing protocols, such as OSPF or EIGRP, set up routing to the network. However, ISPs serving consumers want to avoid that and use something that works automagically. That something is dhcpv6-pd, just as dhcp repalced manual configuration. With my tunnel, the client I use sets up the prefix on my firewall/router. Fortunately it still works with Leap. So, at the moment, I have to get dhcpcd 6.10.1 to work for this. Manually starting it doesn't do the trick for IPv6. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/08/2016 12:14 PM, Per Jessen wrote:

I can build a dhcpcd 6.10 for you for Leap, no trouble at all. I wonder how to make wicked understand that we're using a separate dhcpcd binary.

I've already install 6.10 from rpm. I have no idea about wicked, as I've never used it before. So, I have to get dhcpcd to start, get the prefix and then start up radvd with the IPv6 prefix. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 05/08/2016 12:14 PM, Per Jessen wrote:

...

I can build a dhcpcd 6.10 for you for Leap, no trouble at all. I wonder how to make wicked understand that we're using a separate dhcpcd binary.

I've already install 6.10 from rpm. I have no idea about wicked, as I've never used it before.

You've always used NetworkManager?

So, I have to get dhcpcd to start, get the prefix and then start up radvd with the IPv6 prefix.

The thing is - when you're not using NetworkManager, you're using wicked, and wicked runs its own dhcp client. Maybe you can configure the interface for dhcpv4 only, then run dhcpd manually next to it. I wonder how you get radvd updated. -- Per Jessen, Zürich (22.3°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 05/08/2016 02:00 PM, Per Jessen wrote:

...

James Knott wrote:

...

On 05/08/2016 12:14 PM, Per Jessen wrote:

...

I can build a dhcpcd 6.10 for you for Leap, no trouble at all. I wonder how to make wicked understand that we're using a separate dhcpcd binary. I've already install 6.10 from rpm. I have no idea about wicked, as I've never used it before. You've always used NetworkManager?

No. I only use it on my notebook. My desktop & firewall use ifup.

Since 13.1, ifup/ifdown == wicked.

...

...

So, I have to get dhcpcd to start, get the prefix and then start up radvd with the IPv6 prefix. The thing is - when you're not using NetworkManager, you're using wicked, and wicked runs its own dhcp client. Maybe you can configure the interface for dhcpv4 only, then run dhcpd manually next to it. I wonder how you get radvd updated.

This is what I'm trying to figure out. Since wicked is fairly new, it should have included this "out of the box". One curious thing I just noticed is the IPv6 address I'm getting on my firewall appears on the LAN side, not WAN. Routers normally communicate via link local address, but can use global unicast. I'm not sure if the address I see on the LAN side is supposed to be there or not.

According to the RFC, dhcpv6-pd has been around since 2003. I'm really surprised it hadn't been implemented in openSUSE years ago.

Well, if it wasn't implemented in dhcp clients until recently, I suspect all the distros are late with this. /Per -- Per Jessen, Zürich (14.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2016-05-09 08:25, Per Jessen wrote:

...

James Knott wrote:

...

...

No. I only use it on my notebook. My desktop & firewall use ifup.

Since 13.1, ifup/ifdown == wicked.

No no, 13.1 has no wicked. Only ifup/ifdown.

You're right, wicked was introduced in 13.2, I must have been looking the wrong system. -- Per Jessen, Zürich (22.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/23/2016 12:49 PM, James Knott wrote:

<rant> [snip] What matters to me is that I won't be moving any of my systems from 13.1 any time soon. </rant>

Thank you for this. Although I'm a KDE user I'm finding myself turning off the eye candy for a variety of reasons. I, too, think I'll stick with 13.1 for the foreseeable future. I might, however, consult you about IPv6 someday :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

23.05.2016 20:18, James Knott пишет:

Does your ISP provide native IPv6? I'm on Rogers and they started providing it a few weeks back. Failing that, you could use a tunnel, as I did for about 6 years.

Is IPv6 tunnel possible without permanent public IPv4 address? I briefly tried one of tunneling solutions but it did not work. I am behind NAT here ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

23.05.2016 20:34, James Knott пишет:

On 05/23/2016 01:29 PM, Andrei Borzenkov wrote:

...

23.05.2016 20:18, James Knott пишет:

...

Does your ISP provide native IPv6? I'm on Rogers and they started providing it a few weeks back. Failing that, you could use a tunnel, as I did for about 6 years.

Is IPv6 tunnel possible without permanent public IPv4 address? I briefly tried one of tunneling solutions but it did not work. I am behind NAT here ...

That depends. The tunnel I used had a client that managed things. but it may be shutting down in the not too distant future. How stable is your address?

No idea. I do not even see it - it actually double NAT (provider box gets private address as well).

My IPv4 address, while DHCP, changes so seldom, it's virtually static. I could easily configure a tunnel using it.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/23/2016 02:34 PM, Anton Aylward wrote:

# traceroute www.microsoft.com traceroute to www.microsoft.com (72.246.108.157), 30 hops max, 60 byte packets ... CPE00146c049fe7-CM00195ee35528.cpe.net.cable.rogers.com (99.225.198.63) 25.968 ms 26.520 ms 27.070 ms

That is the DHCP assigned address that my ISP hands out to my NAT firewall.

Since you're on Rogers, you should have IPv6 available, though you might have to change your modem. I did that and my bill dropped by about $50/month!

Sidebar: Rogers actually have a /23 but the /11 seems to be for Toronto customers. James, what address has Rogers given you?

IPv4 or IPv6? I have a single public IPv4 address with a /23 subnet mask and a /64 prefix on IPv6. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-05-24 00:20, Carlos E. R. wrote:

On 2016-05-23 21:09, James Knott wrote:

...

Since you're on Rogers, you should have IPv6 available, though you might have to change your modem. I did that and my bill dropped by about $50/month!

I'm curious. Why would that be (about the bill, I mean). Maybe because you could drop the tunnel?

Scrap that. I saw that you explained already. :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 05/23/2016 02:18 PM, Andrei Borzenkov wrote:

No idea. I do not even see it - it actually double NAT (provider box gets private address as well).

That's a killer. It's also an excellent example of why NAT is so bad and why IPv6 is essential. I currently get a /64 prefix from my ISP, though it may be increased later. That provides 2^64 addresses, so every IPv6 capable device I have gets a global unicast address and then some. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, May 24, 2016 at 2:45 PM, Anton Aylward wrote:

On 05/23/2016 03:05 PM, James Knott wrote:

...

On 05/23/2016 02:18 PM, Andrei Borzenkov wrote:

...

No idea. I do not even see it - it actually double NAT (provider box gets private address as well).

That's a killer. It's also an excellent example of why NAT is so bad and why IPv6 is essential.

??? I'm fine with IPv4 so far and do not feel like I miss anything. So I am not sure how you came to this conclusion. ...

Andrei, did you try that?

Try what? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, May 24, 2016 at 4:10 PM, Anton Aylward wrote:

...

Try what?

The traceroute I suggested in the earlier email that I referenced:

What for? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, May 24, 2016 at 5:21 PM, Anton Aylward wrote:

On 05/24/2016 09:45 AM, Andrei Borzenkov wrote:

...

On Tue, May 24, 2016 at 4:10 PM, Anton Aylward wrote:

...

...

Try what?

The traceroute I suggested in the earlier email that I referenced:

What for?

Go back though the thread. You said you couldn't.

No. I did not.

IIR it was about finding your IP address.

-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/24/2016 08:41 AM, Andrei Borzenkov wrote:

...

...

That's a killer. It's also an excellent example of why NAT is so bad

...

...

and why IPv6 is essential. ??? I'm fine with IPv4 so far and do not feel like I miss anything. So I am not sure how you came to this conclusion.

NAT was designed to get around the IPv4 address shortage. Unfortunately it breaks things. For example, if you want to access a computer behind your firewall, you have to use port forwarding. That's fine for 1 computer, but what if you have 2 or more you want to access? It also gets in the way of some games and VoIP. It also breaks part of IPSec called Authentication Headers. AH are use to verify the headers are not tampered with, but guess what NAT does? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/24/2016 07:45 AM, Anton Aylward wrote:

NAT is a piece of ingenuity layered on what was originally a private non-routable subnet that was really for "internal testing" . Yes a distortion of intent but also a display of ingenuity on the part of engineers and a gift to marketing. That it has delayed IPv6 is .... yes, I'll grant you, an 'evil".

It's a hack that breaks many things. It was created to extend the life of IPv4, by getting around the address shortage. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/24/2016 08:16 PM, Anton Aylward wrote:

On 05/24/2016 07:07 PM, James Knott wrote:

...

On 05/24/2016 07:45 AM, Anton Aylward wrote:

...

NAT is a piece of ingenuity layered on what was originally a private non-routable subnet that was really for "internal testing" . Yes a distortion of intent but also a display of ingenuity on the part of engineers and a gift to marketing. That it has delayed IPv6 is .... yes, I'll grant you, an 'evil". It's a hack that breaks many things. It was created to extend the life of IPv4, by getting around the address shortage. Ahm, not quite. NAT is an untended consequence of RFC1918, "Address Allocation for Private Internets"

To quote the original "Motivation

...

With the proliferation of TCP/IP technology worldwide, including outside the Internet itself, an increasing number of non-connected enterprises use this technology and its addressing capabilities for sole intra-enterprise communications, without any intention to ever directly connect to other enterprises or the Internet itself. The intent of the NAT was secondary and was originally concerned with simplifying an exponential explosion of routing.

Please don't confuse private addresses with NAT. The idea of private addresses existed long before NAT. A private address is just that, it doesn't connect to anything. NAT then took advantage of those address blocks. Private addresses are not the problem (there are some with IPv6 too), NAT is.

As it happened, route aggregation, so as to manage the size & complexity of routing tables, was solved by other means.

Whether you have one address or a block of addresses, the routing is much the same. Aggregation was necessary because no thought was given to routing efficiency when the IPv4 address blocks were handed out. The current trend of selling surplus IPv4 address blocks will only make this worse. On the other hand, IPv6 addresses are handed out geographically, so that all the addresses in one part of the world will have a common route from another part.

The wholesale adoption by service providers might be termed an "emergent property" rather than the original planned intent.

Your explanation of "why NAT is evil" is way, way to complicated. You could simply say that it breaks the supposition of many profols of reciprocal point to point addressing.

Personally, I think that RFC1918 is poorly written and tries to say two, perhaps three or more things at once without clearly differentiating them. Its motivation and its conclusion are at odds with one another.

Your list of the things that NAT "breaks" is correct but for the mass of users are irrelevant.

Funny you should mention that. I recently watched a video by someone on Microsoft's XBOX team, talking about the problems NAT causes for games and how the XBOX will always try to use IPv6, even if it has to set up a tunnel to do so. It will only use IPv4 as a last resort.

Mike Palpinsky, in other writings as well as his RFCs, advocated point to point IPv4 so as to avoid 'translators'. As afar as the Ethernet LAN is concerned, the IP protocol is less efficient than so e of the LAN protocols of history: Novell's. "Lantastic" and other. But they are LAN protocols and not rotatable. Yes, gateways were written for some of them, particularly for email. In many ways those gateways or protocol translators served the same function as NAT, they hid an internal, non-routable network from the Internet at large.

Ummm... Novell's IPX, not Lantastic was routable, along with Apple Talk.

You see NAT as something that breaks the Internet, James, since it uses non-routeable addresses which, by definition, cannot permit host to host addressing. Other people see it as the magic which allows their private networks to make use of the Internet.

It allows their private networks to share one address and that's all it does, in it's favour.

Others here have advocated DHCP loudly. For Joe Sixpack, a NAT router is the definitive configuration plug and play. All his LAN devices get DHCP addresses and the router itself gets a DHCP address from the ISP. The issues you raise, IPSEC and setting up a server behind the NAT with port forwarding are not for the Joe Sixpack. Anyone doing that kind of thing is more technically sophisticated.

All IPv6 devices can use SLAAC or DHCPv6. No configuration either way.

Any anyway, every NAT firewall I have also has VPN capability. Strange that .... eh?

Actual VPN support? Or just pass through? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-05-25 04:56, Anton Aylward wrote:

On 05/24/2016 09:40 PM, James Knott wrote:

I'm not your enemy/opponent in this, James. I'm just saying there is a good reason why people are hanging on to IPv4 and NAT despite the validity of all you say. calling them fools or idiots or short-sighted doesn't help. It just alienates them.

I think most users don't hang onto IPv4. Me, I will simply use IPv6 when my provider uses it... I would like having IPv6, but I don't /need/ it. I don't understand why my provider doesn't use it, but the routers they give their users are IPv6 ready, it seems. Sooner or later they will do it. An anecdote. Initially my provider handed out static IPv4 addresses by default to everybody. At some point they /upgraded/ to dynamic addresses. Yes, they sold it as an upgrade! With NAT. They only considered web browsing. They even had the idea of charging per email and per distance. They were bewildered when clients told them that they were doing user to user things over Internet, and these clients were angry at them for /upgrading/ to dynamic addressing. It is kind of funny the sales people parlance. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-05-25 15:26, Anton Aylward wrote:

On 05/25/2016 08:20 AM, Carlos E. R. wrote:

...

how much you actually loaded that width (say 16K on a T3). I saw one of these pricing spreadsheets and actually found some inconsistencies in it, a mode where customers could exploit a path and get cheap(er) service. That upset a few people! It upset them more when they found the number of people actually exploiting it.

LOL! :-)) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Wed, 2016-05-25 at 16:58 -0400, James Knott wrote:

Of course the big improvement for users is the ability to directly access a computer behind the firewall, without messing with port forwarding

To me, one of the advantages of NAT is that it makes it more difficult to attack my machines because they can't be addressed. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-05-26 08:27, Per Jessen wrote:

Dave Howorth wrote:

...

To me, one of the advantages of NAT is that it makes it more difficult to attack my machines because they can't be addressed.

Yes, NAT implicitly prevents that, and with IPv6 your firewall will still do so. Even without one, anyone attempting to gain access will have an impossible job to do - you will (typically) have a /64 network, a mind-boggling 18'446'744'073'709'551'616 addresses.

But a rogue web server would know the address and run an attack on it. Also, we can find the IP on mails. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-05-26 14:20, James Knott wrote:

On 05/26/2016 06:41 AM, Carlos E. R. wrote:

...

On 2016-05-26 08:27, Per Jessen wrote:

...

But a rogue web server would know the address and run an attack on it. Also, we can find the IP on mails.

Well, whether you use NAT or just a firewall, the attack will still be the same.

No, with NAT there is no possibility of directly connecting to the hosts inside, unless the router sends some ports inside, to a server inside. Or game.

Also, as I mentioned in another note, privacy addresses are usually used. These addresses have a fairly short lifetime, so are useless long term for attacks.

Well, that's good. How does that work? The router hands them, or the computer autoassigns them? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 05/26/2016 09:17 AM, Carlos E. R. wrote:

...

Also, as I mentioned in another note, privacy addresses are

...

usually used. These addresses have a fairly short lifetime, so are useless long term for attacks. Well, that's good.

How does that work? The router hands them, or the computer autoassigns them?

The computer or other device generates a 64 bit random number to be used as the host portion of the address. When your computer is on for a while, you'll see a list of previously used addresses, which are still valid, but eventually those addresses will fall off the end of the list. Only the newest one is used for outgoing connections. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 01:34 PM, Carlos E. R. wrote:

...

The computer or other device generates a 64 bit random number to be used

...

as the host portion of the address. When your computer is on for a while, you'll see a list of previously used addresses, which are still valid, but eventually those addresses will fall off the end of the list. Only the newest one is used for outgoing connections. Where do you see them, in ifconfig, ip addr?

Either ifconfig or ip -6 address show

Let me see, I have:

inet6 addr: fe80::221:85ff:fe16:2d0b/64 Scope:Link inet6 addr: fc00::14/64 Scope:Global

The second one I recognize as having created it myself, manually. And the first one is constructed from the MAC. Maybe the address you mean is only generated when the router hands over a prefix? (which it doesn't, as I don't have IPv6)

You don't have any global unicast addresses. Those generally start with 2. The unicast addresses, either random or MAC based are created with "SLAAC", which relies on router advertisements. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-05-26 21:44, Per Jessen wrote:

Carlos E. R. wrote:

Yes, unless you have radvd (or equivalent) running on your router, your devices will not configure any ipv6 addresses.

Well, as my ISP doesn't provide IPv6, so I don't think the router hands out IPv6 addresses. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Carlos E. R. wrote:

On 2016-05-26 08:27, Per Jessen wrote:

...

Dave Howorth wrote:

...

...

To me, one of the advantages of NAT is that it makes it more difficult to attack my machines because they can't be addressed.

Yes, NAT implicitly prevents that, and with IPv6 your firewall will still do so. Even without one, anyone attempting to gain access will have an impossible job to do - you will (typically) have a /64 network, a mind-boggling 18'446'744'073'709'551'616 addresses.

But a rogue web server would know the address and run an attack on it. Also, we can find the IP on mails.

What is a "rogue webserver" ? As for finding addresses in mails, they are typically random. By default in openSUSE. See "IPv6 privacy extensions". -- Per Jessen, Zürich (22.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 09:20 AM, Carlos E. R. wrote:

But if you want to make use of things like VoIP you would need a fixed address, non private, because you do want to do things needing being accessible.

That is not the case from the end user's POV. I have a NAT and Vop "router" behind it. Whether I was using a NAT or not the ATA box needs to have the address of the ISP. How the ISP implement things, load balancing or otherwise, is their decision. My setup is going to be the same, NAT or not, IPv4 or IPv6. Yes, the service provider needs a static address, but the providers needs static addresses (or at least a good DNS and update) for their a web service, email service (SMTP or POP/IMAP) and a host of other things. "That's not what I meant" ? Well, please make it clear, then, whether you are talking about a client or a service provider, an ISP that is providing a raft of services with full support, possibly commercially, and an 'at home' that has opened a port-forwarder to provide a 'service' that is not supported like the ISP (yamma yamma). You said in the above "make use of". I took that to mean "make use of a service provider offering ..". In that contest, no you don't need a fixed address as a client. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

James Knott wrote:

On 05/26/2016 09:35 AM, Anton Aylward wrote:

...

On 05/26/2016 09:20 AM, Carlos E. R. wrote:

...

...

But if you want to make use of things like VoIP you would need a fixed address, non private, because you do want to do things needing being accessible. That is not the case from the end user's POV. I have a NAT and Vop "router" behind it. Whether I was using a NAT or not the ATA box needs to have the address of the ISP. How the ISP implement things, load balancing or otherwise, is their decision. My setup is going to be the same, NAT or not, IPv4 or IPv6.

Actually, with NAT, you have to use an STUN server to communicate the real address to the other end. Otherwise, it would try to use the NAT address, which wouldn't be reachable. This is just one example of a hack made necessary by NAT.

You make it out to be a big deal, James. We have had a STUN server running alongside Asterisk for years. In my office, anyone who's working from home has a VoIP telephone set (or uses a laptop client), whatever internet connection they're on at home is of no concern, they are reachable by VoIP. -- Per Jessen, Zürich (21.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 05:09 PM, Carlos E. R. wrote:

...

You make it out to be a big deal, James. We have had a STUN server

...

running alongside Asterisk for years. In my office, anyone who's working from home has a VoIP telephone set (or uses a laptop client), whatever internet connection they're on at home is of no concern, they are reachable by VoIP. But that STUN server is probably set on a fixed address, so that it can be reached by the clients. That's the problem, normal people can't set up that lacking that fixed address. Yes, of course, there is dyndns and such, but...

It's not the fixed address or lack of that's the problem. The phone only "knows" the address it has on the local network, not the public address on the other side of the firewall. STUN is used to provide the real address. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2016-05-26 21:40, Per Jessen wrote:

...

James Knott wrote:

...

...

Actually, with NAT, you have to use an STUN server to communicate the real address to the other end. Otherwise, it would try to use the NAT address, which wouldn't be reachable. This is just one example of a hack made necessary by NAT.

You make it out to be a big deal, James. We have had a STUN server running alongside Asterisk for years. In my office, anyone who's working from home has a VoIP telephone set (or uses a laptop client), whatever internet connection they're on at home is of no concern, they are reachable by VoIP.

But that STUN server is probably set on a fixed address, so that it can be reached by the clients. That's the problem, normal people can't set up that lacking that fixed address. Yes, of course, there is dyndns and such, but...

Carlos, you're loosing me - what does a normal person need a STUN server for? Unless that normal person wants to provide VoIP services, he or she has no need. A STUN server has one single reason for being - to enable clients on a NAT'ed network to be reached from the outside. -- Per Jessen, Zürich (19.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2016-05-27 09:08, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

But that STUN server is probably set on a fixed address, so that it can be reached by the clients. That's the problem, normal people can't set up that lacking that fixed address. Yes, of course, there is dyndns and such, but...

Carlos, you're loosing me - what does a normal person need a STUN server for? Unless that normal person wants to provide VoIP services, he or she has no need. A STUN server has one single reason for being - to enable clients on a NAT'ed network to be reached from the outside.

Two meanings. One, that a normal client has to use a STUN server that somebody else creates,

Right. It's one of the options.

and that a person that tries to setup asterisk will probably also have to setup a STUN.

Depends on what that person wants to do. If he wants to establish calls _to_ SIP-clients behind NAT routers, something is required to keep the client-side NAT table up-to-date. STUN, keep-alive, Andrei mentioned SIP NAT traversal (I have no experience with the latter). -- Per Jessen, Zürich (21.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/27/2016 03:08 AM, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2016-05-26 21:40, Per Jessen wrote:

...

James Knott wrote:

...

...

Actually, with NAT, you have to use an STUN server to communicate the real address to the other end. Otherwise, it would try to use the NAT address, which wouldn't be reachable. This is just one example of a hack made necessary by NAT.

You make it out to be a big deal, James. We have had a STUN server running alongside Asterisk for years. In my office, anyone who's working from home has a VoIP telephone set (or uses a laptop client), whatever internet connection they're on at home is of no concern, they are reachable by VoIP.

But that STUN server is probably set on a fixed address, so that it can be reached by the clients. That's the problem, normal people can't set up that lacking that fixed address. Yes, of course, there is dyndns and such, but...

Carlos, you're loosing me - what does a normal person need a STUN server for? Unless that normal person wants to provide VoIP services, he or she has no need. A STUN server has one single reason for being - to enable clients on a NAT'ed network to be reached from the outside.

And, as is the case for most home consumers, it's not even that, as its not about PTP; they are just using it as a POTS replacement. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 03:40 PM, Per Jessen wrote:

James Knott wrote:

...

On 05/26/2016 09:35 AM, Anton Aylward wrote:

...

On 05/26/2016 09:20 AM, Carlos E. R. wrote:

...

...

But if you want to make use of things like VoIP you would need a fixed address, non private, because you do want to do things needing being accessible. That is not the case from the end user's POV. I have a NAT and Vop "router" behind it. Whether I was using a NAT or not the ATA box needs to have the address of the ISP. How the ISP implement things, load balancing or otherwise, is their decision. My setup is going to be the same, NAT or not, IPv4 or IPv6. Actually, with NAT, you have to use an STUN server to communicate the real address to the other end. Otherwise, it would try to use the NAT address, which wouldn't be reachable. This is just one example of a hack made necessary by NAT. You make it out to be a big deal, James. We have had a STUN server running alongside Asterisk for years. In my office, anyone who's working from home has a VoIP telephone set (or uses a laptop client), whatever internet connection they're on at home is of no concern, they are reachable by VoIP.

If they're behind NAT, they need some means to tell the other end what their real address is. STUN does that. It also wouldn't be necessary if NAT wasn't in the way. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-05-27 09:05, Per Jessen wrote:

James Knott wrote:

...

If they're behind NAT, they need some means to tell the other end what their real address is. STUN does that. It also wouldn't be necessary if NAT wasn't in the way.

Yep, like I said you make it out to be a big deal. The STUN server took about 5mins to set up and it runs and runs and runs. The telephone is configured to enable STUN when it's provisioned. NAT is a fact of life, likely will be for quite some time to come. When everyone has public addresses, we can stop the STUN server, woohoo.

Well, it is a blocker if /I/ want to play with asterisk at home. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 05/27/2016 03:05 AM, Per Jessen wrote:

...

...

If they're behind NAT, they need some means to tell the other end what their real address is. STUN does that. It also wouldn't be necessary if NAT wasn't in the way. Yep, like I said you make it out to be a big deal. The STUN server took about 5mins to set up and it runs and runs and runs. The telephone is configured to enable STUN when it's provisioned. NAT is a fact of life, likely will be for quite some time to come. When everyone has public addresses, we can stop the STUN server, woohoo.

The deal is it's still a hack to get around problems caused by NAT. Of course, NAT is a hack to get around the address shortage, so STUN is a hack on top of a hack. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 01:28 PM, James Knott wrote:

On 05/26/2016 09:35 AM, Anton Aylward wrote:

...

On 05/26/2016 09:20 AM, Carlos E. R. wrote:

...

...

But if you want to make use of things like VoIP you would need a fixed address, non private, because you do want to do things needing being accessible. That is not the case from the end user's POV. I have a NAT and Vop "router" behind it. Whether I was using a NAT or not the ATA box needs to have the address of the ISP. How the ISP implement things, load balancing or otherwise, is their decision. My setup is going to be the same, NAT or not, IPv4 or IPv6.

Actually, with NAT, you have to use an STUN server to communicate the real address to the other end. Otherwise, it would try to use the NAT address, which wouldn't be reachable. This is just one example of a hack made necessary by NAT.

I'm sorry, no you don't need a STUN server. Perhaps some service providers configure their systems so to make it necessary, but mine certainly doesn't! In fact they insist that a STUN is NOT to be configured. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 05:06 PM, Carlos E. R. wrote:

On 2016-05-26 22:51, Anton Aylward wrote:

...

On 05/26/2016 01:28 PM, James Knott wrote:

...

I'm sorry, no you don't need a STUN server.

Perhaps some service providers configure their systems so to make it necessary, but mine certainly doesn't!

In fact they insist that a STUN is NOT to be configured.

Because you have a router that understands VoIp. Or the form of VoIp that your ISP uses.

No I do NOT have a VoIP aware router. And as far as my service provider goes, didn't I say that? As far as I understand what they tell me, its Asterix (?sp?) and its just a matter of how its configured. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 10:40 AM, Carlos E. R. wrote:

With IPv6 you need neither. In fact, you could address someone's phone by something like "phone://IP-Addres" instead of or "protocol://who@server_provider", where the directory server does a directory search to translate your given name to the IP where you can be found.

Ie, IPv6 allows non-anonymous peer to peer services without intermediaries.

And what could possibly go wrong? :-) Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 01:40 PM, Carlos E. R. wrote:

With IPv6 you need neither. In fact, you could address someone's phone by something like "phone://IP-Addres" instead of or "protocol://who@server_provider", where the directory server does a directory search to translate your given name to the IP where you can be found.

Ie, IPv6 allows non-anonymous peer to peer services without intermediaries.

That would depend on the protocol you're using, not IPv6. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 02:09 PM, Carlos E. R. wrote:

...

...

That would depend on the protocol you're using, not IPv6. Well, it has to be IPv6 if you want to address a device from outside, not a house.

In principle IPv4 and IPv6 work the same way in this respect. They're only the transport. Higher protocols determine how they're used. Of course, with IPv4 and NAT, other issues arise. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 05:12 PM, Carlos E. R. wrote:

Well, IPv4 would work, of course, but normal people don't get internet v4 addresses for inside the home. You have to pay extra for them. With IPv6 you get those routable addresses at the same price.

Actually, I get a real address from my ISP and have for years. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 02:09 PM, Carlos E. R. wrote:

On 2016-05-26 19:59, James Knott wrote:

...

On 05/26/2016 01:40 PM, Carlos E. R. wrote:

...

With IPv6 you need neither. In fact, you could address someone's phone by something like "phone://IP-Addres" instead of or "protocol://who@server_provider", where the directory server does a directory search to translate your given name to the IP where you can be found.

Ie, IPv6 allows non-anonymous peer to peer services without intermediaries.

That would depend on the protocol you're using, not IPv6.

Well, it has to be IPv6 if you want to address a device from outside, not a house.

I often use IP connectivity that isn't IPv6 outside my house. Libraries, malls, conference centres, hotels, ... And yes, most of them are using a NAT'd service. And just to rub the point in, one of the thing I do using this 'outside the house' NAT'd IP service is make phone calls from my tablet using a softphone AND NO STUN. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 09:54 PM, James Knott wrote:

On 05/26/2016 05:14 PM, Anton Aylward wrote:

...

I often use IP connectivity that isn't IPv6 outside my house.

Libraries, malls, conference centres, hotels, ... And yes, most of them are using a NAT'd service.

And just to rub the point in, one of the thing I do using this 'outside the house' NAT'd IP service is make phone calls from my tablet using a softphone AND NO STUN.

Then you must be using a server for the duration of the call. With VoIP, the server is supposed to be used only for setting up a peer to peer call and then drops out of the picture.

James: I DON"T CARE! MOST HOME USERS DON'T CARE! We're talking about POTS replacement for home users, for most SMB users and even for most office users with a simple, straight forward PBX that doubled as a intercom service within a single office. its only a great technology and cost reducer in some cases. The home users use 'phone numbers', not SIP-SIP. Here in Toronto, Rogers and bell converted their dial-up analogue line customers to internet based "home phone" service by installing a independently powered, independently addressed ATA on the incoming line (cable, DSL, fibre) and patching it in to the house (analogue) wiring. Unfortunately they didn't massively reduce the charge to the customer although this did massively reduce their costs. I had this setup for a while. Its only advantage was that it had batter backup so survived power outages. I now have my own ATA and an 3rd part VoIP service (operating out of Montreal but with a local node here in Toronto as well as local nodes though North America and western Europe) for about 12% of what Rogers was charging me for the "Home Phone". Calls are flat rate; it doesn't matter if I'm calling my next door neighbour or a friend in new Zealand, so long as its near somewhere they have a node or their business peers have a node. (There's a premium for contacting cell phones in some counties.) So long as phones are a mass consumer item then they will be emulating the POTS system, just as cell phones are. Consumers (as well as most businesses) don't care about the stuff you care about so long as "it works" and the costs stay down. Part of the reason the telcos have to convert to VoIP and are, like Rogers and Bell and others, slowly pushing their cable service prices up, is that most businesses are moving away from voice service. Web based services for bill payment, complaints, sign-up, cancellation, problem reporting are taking over from the voice-phone based. Its economics; many of these services can be automated. Some. like power/hydro are automatically serviced with 'smart meters'. I'm not saying that vice telephone will vanish. There are always going to be teenage girls. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-05-26 23:11, Anton Aylward wrote:

On 05/26/2016 01:40 PM, Carlos E. R. wrote:

...

With IPv6 you need neither. In fact, you could address someone's phone by something like "phone://IP-Addres" instead of or "protocol://who@server_provider", where the directory server does a directory search to translate your given name to the IP where you can be found.

That's nice, I'm sure, but my set-up behave just like the analogue POTS I had before. (i.e. you dial a 7 or 10 digit number if you're in north America, add a "1" international prefix if you're not)

Yes, I also have that service. Except that it is done at a box closer to the fibre, before it gets to the router (the ONT). No user configurable at all, and not documented. To get "softphone" we have to reverse engineer it to get the configuration data. And yes, it does not need STUN. But it works on a 10.*.*.* network that bypasses the NAT, that's why.

...

Ie, IPv6 allows non-anonymous peer to peer services without intermediaries.

That's good. Does that mean that when IPv6 is universal that the telcos will get out of the phone business as its no longer needed?

They might :-) But I doubt it. Anyway, the "services" in that sentence is not only for "phone". Anything. File sharing. Concurrent work on a document without Google. For instance. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 05/26/2016 05:36 PM, Anton Aylward wrote:

Oh, a slight difference. If I travel outside North America the delay across the Atlantic I suppose, introduce a bit of an echo if I use the north America nodes, so I change the settings to use of of their European nodes (or is it 'peers'?)

Isn't DNS wonderful?

Another feature of IPv6 is "anycast" addresses, where you connect to the nearest server, without having to change anything. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/27/2016 02:38 AM, Per Jessen wrote:

Anton Aylward wrote:

...

I can only say that my tablet softphone uses the same settings as my behind-the NAT ATA.

Right - they probably both have STUN or keep-alive enabled.

I keep telling you: NO THEY DON"T -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/27/2016 07:47 AM, Per Jessen wrote:

Anton Aylward wrote:

...

On 05/27/2016 02:38 AM, Per Jessen wrote:

...

Anton Aylward wrote:

...

I can only say that my tablet softphone uses the same settings as my behind-the NAT ATA.

Right - they probably both have STUN or keep-alive enabled.

I keep telling you: NO THEY DON"T

Then you won't be receiving any calls.

That is not the case.. If I choose not to answer after seeing the incoming number, or of I'm not in to answer the call anyway, that doesn't mean the phone doesn't ring. Neck, I get enough calls in the early evening, the kitchen phone ringing when I'm cooking dinner that I REFUSE to answer since if I'm nattering on the phone dinner will spoil/burn. When I collect VM later it turns out it was always some salesman. Friends&relative now the ebst times to call me and don't make blunders like that. So BAH! I refute your assertion that I can't get incoming calls even though I don't use STUN. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-05-27 14:05, Per Jessen wrote:

Maybe you're just using black magic or maybe you're not behind a NAT router or maybe you are using STUN or keep-alive, but you don't know.

Yes. In my case, it is done on a little box placed before the router, and it uses a 10.*.*.* network. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 05/27/2016 08:36 AM, Carlos E. R. wrote:

On 2016-05-27 14:05, Per Jessen wrote:

...

Maybe you're just using black magic or maybe you're not behind a NAT router or maybe you are using STUN or keep-alive, but you don't know.

Yes.

In my case, it is done on a little box placed before the router, and it uses a 10.*.*.* network.

Back in the days of the Rogers Home Phone it was like that for me too. But now my ATA is on the inside of my cable router and on the inside of my NAT firewall. And it works for incoming calls even thought the STUN is blank, as my service provider <strike>recommends</strike> insists. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-05-27 23:25, James Knott wrote:

On 05/27/2016 08:36 AM, Carlos E. R. wrote:

...

On 2016-05-27 14:05, Per Jessen wrote:

...

Maybe you're just using black magic or maybe you're not behind a NAT router or maybe you are using STUN or keep-alive, but you don't know. Yes.

In my case, it is done on a little box placed before the router, and it uses a 10.*.*.* network.

So, that little box connects to an STUN server or uses other keep alive.

I think neither, because it does not use NAT. It is a 10.*.*.* VPN, different from the house LAN at 192.168.1.* -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-05-28 14:48, James Knott wrote:

On 05/27/2016 05:48 PM, Carlos E. R. wrote:

...

On 2016-05-27 23:25, James Knott wrote:

...

On 05/27/2016 08:36 AM, Carlos E. R. wrote:

...

On 2016-05-27 14:05, Per Jessen wrote:

...

Maybe you're just using black magic or maybe you're not behind a NAT router or maybe you are using STUN or keep-alive, but you don't know. Yes.

In my case, it is done on a little box placed before the router, and it uses a 10.*.*.* network.

So, that little box connects to an STUN server or uses other keep alive. I think neither, because it does not use NAT. It is a 10.*.*.* VPN, different from the house LAN at 192.168.1.*

Well, that explains it. I don't think you mentioned anything earlier that would indicate your VoIP wasn't via NAT. You'd have a non NAT route to the server.

Yes, I did. But the thread is long, easy to miss a point.

However, you still can't talk peer - peer to someone running VoIP at the other end. You have to keep that server on the call for the duration.

Assuming I can use a SIP phone on that (I haven't been able to, the company changes parameters so that it fails, intentionally), I would have to do NAT on some router on my ISP premises. Or the registrar would have to do things on it. At least to phone via SIP to people outside that network. The intention of that network is to replace POTs transparently, not for people to use VoIP. And charge per call and per minute. Notice that Asterisk doesn't behave always "peer to peer". Sometimes it handles the call, changing to another codec in its CPU, and sends forward to the destination. Asterisk might thus also handle NAT without STUN if it sits on both networks. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-05-28 20:41, Per Jessen wrote:

Carlos E. R. wrote:

...

Notice that Asterisk doesn't behave always "peer to peer". Sometimes it handles the call, changing to another codec in its CPU, and sends forward to the destination. Asterisk might thus also handle NAT without STUN if it sits on both networks.

It's not about Asterisk, it's about the SIP client. Any properly configured SIP client can connect to Asterisk and make calls, but if the client is on a NAT'ed network, something has to keep the NAT entry "open" - keep-alive or STUN. I'm not really sure what the big difference is.

Well, I'm considering a slightly different case here (based on mine). I'm (my phone is) on a 10.*.*.* network, as would be the asterisk server on the ISP. Both on the same network. And then thinking how would I make a call to a SIP phone on internet. If the asterisk server sits on both networks, it would handle it completely, I think. Just thinking out loud :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-05-28 21:24, Per Jessen wrote:

Carlos E. R. wrote:

...

Well, I'm considering a slightly different case here (based on mine). I'm (my phone is) on a 10.*.*.* network, as would be the asterisk server on the ISP. Both on the same network.

Right.

...

And then thinking how would I make a call to a SIP phone on internet. If the asterisk server sits on both networks, it would handle it completely, I think.

A SIP-call is typically done with a URL sip://someone@domain - from <domain>, the SIP client determines which server to contact and that's pretty much it. With a SIP-client on 10/8, you could do the same, but only if your telco has a NAT facility. Which I don't see any reason for them to have. If you do it from your normal internet connection (e.g. with a softphone), NAT'ed or otherwise, it should just work. (STUN and keep-alive don't matter). If you want to play with it, I'll be happy to set up a SIP account on our Asterisk.

Oh, thanks, but I'm not in a hurry to real test it :-) I'm just curious. You are right, the telco has no reason to do it. It would be incoming calls which would be more of a problem. I did some experimenting with asterisk on a lab few years back, we played a lot. But not this particular situation. One idea of mine is to figure out if it is possible to do SIP with my telco (emulating POTs), and then setup a little asterisk at home to do call screening. But I'm not on a hurry to try it out, either. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Anton Aylward wrote:

On 05/27/2016 08:05 AM, Per Jessen wrote:

...

Maybe you're just using black magic or maybe you're not behind a NAT router or maybe you are using STUN or keep-alive, but you don't know.

I am behind NAT, that I'm sure of :-) I an NOT using STUN, that I'm sure of ;-)

I have not sacrificed any chickens, virgins or made incantations from ancient and obscure books bound in human skin. That, too, I'm sure of :-)

What I do think, and Andrei seems to hint at this, is that there's more to this technology and its implementation than you (or I for that matter) seem to know about.

I still suspect a keep-alive enabled by default. Your device looks a lot like my Linksys SPA2102, just a more modern cousin. Mine has default 15 seconds keep-alive. -- Per Jessen, Zürich (24.7°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/27/2016 05:28 PM, James Knott wrote:

On 05/27/2016 08:44 AM, Anton Aylward wrote:

...

If the technologists that are behind my service provider say "no need for STUN" and the ATA I use works, and believe me I do get incoming calls, then there's something else going on.

Perhaps that little box is doing STUN. The way to be sure is to use something like wireshark to see what's being sent over the line.

It is not using STUN. It is configured not use STUN. That's not ticked off and the STUN Address field is blank. The service provider EXPLICITLY said not to use STUN. I've asked that a number of times and they insist. I'm not breaking open this box lest whatever magic makes it work without STUN leaks out :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 05/26/2016 01:40 PM, Carlos E. R. wrote:

...

On 2016-05-26 15:35, Anton Aylward wrote:

...

On 05/26/2016 09:20 AM, Carlos E. R. wrote:

...

But if you want to make use of things like VoIP you would need a fixed address, non private, because you do want to do things needing being accessible.

That is not the case from the end user's POV. I have a NAT and Vop "router" behind it. Whether I was using a NAT or not the ATA box needs to have the address of the ISP. How the ISP implement things, load balancing or otherwise, is their decision. My setup is going to be the same, NAT or not, IPv4 or IPv6.

You need a special router that is VoIp aware, and/or you need to connect to a STUN server, which helps traverse the NAT router.

This is NOT the case.

I'm not saying that people don't configure it that way, but it isn't how my provider works. I had to quite explicitly turn STUN OFF on my LinkSys ATA to get it to work.

STUN is needed for inbound calls. Many phones have a keep-alive option instead, but it boils down to the same thing. -- Per Jessen, Zürich (18.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 10:37 AM, Per Jessen wrote:

With ISDN being phased out by the end of next year

BRI? PRI? or both? In North America, BRIs aren't used much, but PRIs are still used a lot for PBXs. I've even seen SIP/PRI converters you connect an old PBX to VoIP trunks. Those converters are normally used the other way around. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-05-26 16:37, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2016-05-26 14:26, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

But a rogue web server would know the address and run an attack on it. Also, we can find the IP on mails.

What is a "rogue webserver" ?

A web server belonging to "bad guys", or hacked by them, that runs code using the found IPs to attack them.

Ah I see. Well, same answer as before, IPv6 privacy extensions.

I need an IPv6 for dummies book. :-)

...

...

As for finding addresses in mails, they are typically random. By default in openSUSE. See "IPv6 privacy extensions".

But if you want to make use of things like VoIP you would need a fixed address, non private, because you do want to do things needing being accessible.

No, you don't need a fixed address for a VoIP client. With ISDN being phased out by the end of next year, Swisscom will be switching everyone to VoIP. None of those will need a fixed IP, v4 or v6. Deutsche Telekom will be doing the same by the end of 2018.

Well, I have that. Silently. When I switched to fibre, I was switched to VoIp, but I wasn't told. I simply get a "thing" with a phone connector, to which is connected the house phone wiring, unchanged. In fact, people are using VoIp phones and computers by reverse engineering the connection data, because the company hides it. Which reminds me that I want to try it. I might route the connection to a computer that would do call filtering/screening. :-))

Only if you want to run a server will you need fixed addresses, just like now.

You need an intermediary where you register on each IP change so that others can phone you.

...

You get both type of addresses for a computer? How know applications which one to use?

/proc/sys/net/ipv6/conf/eth0/use_tempaddr

0 = privacy extensions disabled. 1 = privacy extensions enabled, but not preferred. 2 = privacy extensions enabled, preferred.

It is zero here. I see...

A network interface will have

a) link local address - fe80:<mac-addr based> b) a temporary address (assuming tempaddr!=0) = 2001:db8::random c) an address handed out by dhcp = your:pref::pooladdr d) a fixed address based on mac-addr = your:pref::macaddr-based.

I have a mac based address (don't know if 'a' or 'd'... correction, I know, it is 'a') and a fixed address I created, local if I remember correctly: inet6 addr: fe80::221:85ff:fe16:2d0b/64 Scope:Link inet6 addr: fc00::14/64 Scope:Global Type 'b', it is always "2001:db8..."? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-05-26 20:17, James Knott wrote:

On 05/26/2016 01:59 PM, Carlos E. R. wrote:

...

I need an IPv6 for dummies book. :-)

An excellent reference is "IPv6 Essentials".

http://shop.oreilly.com/product/0636920023432.do

$31.99? Way to expensive for me. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-05-29 19:32, James Knott wrote:

On 05/26/2016 05:38 PM, Carlos E. R. wrote:

...

On 2016-05-26 20:17, James Knott wrote:

...

On 05/26/2016 01:59 PM, Carlos E. R. wrote:

...

I need an IPv6 for dummies book. :-) An excellent reference is "IPv6 Essentials".

http://shop.oreilly.com/product/0636920023432.do $31.99? Way to expensive for me.

I see it's $14.74 on Google Play. https://play.google.com/store/books/details/Silvia_Hagen_IPv6_Essentials?id=...

Better :-) But it is an older edition. It says "24.72€", which is way more than "$14.74". Go figure. I knew a site that would comment on a book and then search at several seller sites, with prices. I can't locate the link. Might be "http://www.goodreads.com/" http://www.goodreads.com/book/show/27356626-ipv6-essentials-3rd-edition?from_search=true&search_version=service There are several editions, the current is the 6th but some sell older ones. The link to amazon is dead. But a search at amazon says 33.28€, much less if used, but some much more if used. Huh? It doesn't cite google play? 18.74 at Kobo. However, these are the type of books I prefer on paper. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Wed, 2016-06-01 at 15:32 -0400, James Knott wrote:

On 06/01/2016 02:12 PM, Carlos E. R. wrote:

...

...

I see it's $14.74 on Google Play.

...

https://play.google.com/store/books/details/Silvia_Hagen_IPv6_Essentials?id=... Better :-)

But it is an older edition. It says "24.72€", which is way more than "$14.74". Go figure.

The 3rd edition is the latest. I still see $14.74. I guess it costs more to ship ebooks to Spain. ;-)

Hmm, I see £20.39 for the kindle edition of the 3rd edition but I could buy a new paper copy for £14.49 (not directly from Amazon). I guess it costs a lot to ship electrons across the pond, especially when compared to the cost of shipping paper :) Cheers, Dave PS On .com I see paper for $35.35 from Amazon, $29.85 kindle. So I guess they're pretty keen on slicing the market. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

In this case, I want paper, and amazon.es wants 60€ for that, used.

https://www.amazon.es/s/ref=nb_sb_noss?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&url=search-alias%3Daps&field-keywords=+IPv6+Essentials%2C+3rd+Edition+by+Silvia+Hagen

Something must be driving up the price of books in Spain? On amazon.de, it's available for EUR28.95, new paperback. In Switzerland at exlibris.ch, it's CHF48.50 for a hardback, CHF30.90 for a paperback. -- Per Jessen, Zürich (19.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Daniel Bauer wrote:

Am 02.06.2016 um 14:07 schrieb Per Jessen:

...

Carlos E. R. wrote:

...

In this case, I want paper, and amazon.es wants 60€ for that, used.

https://www.amazon.es/s/ref=nb_sb_noss?__mk_es_ES=%C3%85M%C3%85%C5%BD%C3%95%C3%91&url=search-alias%3Daps&field-keywords=+IPv6+Essentials%2C+3rd+Edition+by+Silvia+Hagen

...

...

Something must be driving up the price of books in Spain?

this is geotargeting. More and more websites show different prices for different countries, first and foremost travel agencies and flight tickets.

That has been like that for more than twenty years. I used to work in the airline industry, I know quite well how to get the best car rental prices. Nothing new about it at all. Airlines tickets, yep - train tickets, they're catching up. However, inside the EU there is little reason for such big price differences on e.g. consumer goods, unless they're produced locallyor unless they;re subject to local taxation or price regulation. Read "little reason" == "it's illegal".

Also many sites now adjust the prices to your consumer behaviour, via your history on their site or via tracking you thru the web. If they think you like to purchase expensive goods, the prices go up for you.

That one is new to me, I guess it's possible, but I would hate to have to write te book-keeping system. -- Per Jessen, Zürich (17.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2016-06-02 20:59, Per Jessen wrote:

...

...

Also many sites now adjust the prices to your consumer behaviour, via your history on their site or via tracking you thru the web. If they think you like to purchase expensive goods, the prices go up for you.

That one is new to me, I guess it's possible, but I would hate to have to write te book-keeping system.

I did the search on two different browsers, so it was not the case.

I'm sure it wasn't - adjusting the price due to the user's shopping habits is seriously dodgy. It would also play merry hell with the book-keeping, I really don't see how it could be done. -- Per Jessen, Zürich (18.7°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 26 May 2016 20:17, James Knott wrote:

On 05/26/2016 01:59 PM, Carlos E. R. wrote:

...

I need an IPv6 for dummies book. :-)

An excellent reference is "IPv6 Essentials".

http://shop.oreilly.com/product/0636920023432.do

390 Pages? Oh! Not a short read. A "Dummy Book" would come in a 1/6 or even 1/8 of that. (50-65 Pages) - Yamaban -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-05-26 21:29, Per Jessen wrote:

Carlos E. R. wrote:

...

Well, I have that. Silently.

When I switched to fibre, I was switched to VoIp, but I wasn't told. I simply get a "thing" with a phone connector, to which is connected the house phone wiring, unchanged.

Yes, I expect that will be the case for most people. Whether the telco uses copper, fibre or carrier pigeons should be transparent to the consumer. An ISDN customer has an NTBA ("terminator box") installed, typically a grey box on the wall somewhere. It interfaces the telephone wires with the S0 bus. I expect Swisscom and Deutsche Telecom will simply replace that with another one, essentially an ADSL modem which interfaces the telephones wires with Ethernet.

The thing is that there are way many more features possible with VoIp terminals or softphones than with POTS. The telephone company hides the data and says it is not possible, but people have figured out how to do it, and do it. It is a 10.* network, probably a VPN on the same router, with no STUN needed (because there is no NAT). People do things like doing several simultanous phone calls, one on the POTs and several on the softphones. I don't know if they are charged or not. They manage to pick up the phone miles away, too. When the phone company catches up, they'll want to charge for all that, of course. Then people will catch up again and simply use the internet connection with a different registrar.

...

...

Only if you want to run a server will you need fixed addresses, just like now.

You need an intermediary where you register on each IP change so that others can phone you.

Yes, that's called a "VoIP provider". They also provide the interconnect to the POTS etc.

Well, interconnect to the POTS is an extra. The only service you need outside is the registrar, and there are free providers.

...

...

...

You get both type of addresses for a computer? How know applications which one to use?

/proc/sys/net/ipv6/conf/eth0/use_tempaddr

0 = privacy extensions disabled. 1 = privacy extensions enabled, but not preferred. 2 = privacy extensions enabled, preferred.

It is zero here. I see...

The default on openSUSE is 2, a sound choice for a client. I wonder how you got a 0.

Dunno. I will have to check on other machines, this one has been upgraded from 5.3 upwards. [...] Yes, another machine, more recently set up has a 2. But the only address is: inet6 addr: fe80::203:dff:fe05:17fc/64 Scope:Link (probably because my router doesn't hand out IPv6 addresses)

...

Type 'b', it is always "2001:db8..."?

"2001:db8::" is like "example.com", it's for documentation only. In real life, it will be one a prefix allocated by your provider.

Ah. :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-05-26 23:25, Anton Aylward wrote:

On 05/26/2016 01:59 PM, Carlos E. R. wrote:

...

I need an IPv6 for dummies book. :-)

https://www.wesecure.nl/upload/documents/tinymce/IPv6.pdf

Wow! Just the very thing :-) Copied to the tablet for reading. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Thu, 26 May 2016 23:25, Anton Aylward wrote:

On 05/26/2016 01:59 PM, Carlos E. R. wrote:

...

I need an IPv6 for dummies book. :-)

https://www.wesecure.nl/upload/documents/tinymce/IPv6.pdf

28 Pages, good for getting a basic overview, without getting lost in details. Thank you very much. - Yamaban -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/26/2016 10:37 AM, Per Jessen wrote:

Only if you want to run a server will you need fixed addresses, just like now.

Err no. In the days before my current cable provider clamped down on it, I ran a web server from home, even though the cable service provided a dynamic address. I registered a domain name and made use of the (then free) service that DynDNS (then) had. I had a small script, that DynDNS supplied, that looked to see what my DHCP address from the cable company was and if it changed sent a message to DynDNS updating its mapping for my domain entry. That way remote sites could access my web service. All this talk about IP address is a crock! Real people deal in domain names. I'm sure that there are similar services around even now. I only discontinued this when my cable provider changed policy so that only commercial customers could run servers. IIR DynDNS later suspended their free service. Perhaps I should change cable provider .... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org