- NANOG - lists.nanog.org

Re: Hotels/Airports with IPv6
by Oliver O'Boyle 10 Jul '15

10 Jul '15

32 bit connection with a 32 bit address will open up an three-dimensional portal under the hotel. They all know this and work around it by selecting a lower connection speed. On July 10, 2015, at 3:59 AM, Alan Buxey <A.L.M.Buxey(a)lboro.ac.uk> wrote: 2 mbit is still more than 32 bit ;) alan

1 0

Re: Dual stack IPv6 for IPv4 depletion
by andrew 09 Jul '15

09 Jul '15

Pardon my ignorance - what do you see missing in MPLS in regards to support for IP6?-------- Original message -------- From: Mel Beckman <mel(a)beckman.org> Date: 07/06/2015 9:44 AM (GMT-05:00) To: Lee Howard <Lee(a)asgard.org> Cc: Josh Moore <jmoore(a)atcnetworks.net>, nanog(a)nanog.org Subject: Re: Dual stack IPv6 for IPv4 depletion And let's all complain to the MPLS working group to get IPv6 support finished up! -mel beckman > On Jul 6, 2015, at 6:27 AM, Lee Howard <Lee(a)asgard.org> wrote: > > Some thoughts. . . > > ³Native dual-stack² is ³native IPv4 and native IPv6.² > > ³Dual-stack² might be native, or might by ³native IPv6 plus IPv4 address > sharing.² > > Your IPv4 address sharing options are CGN, DS-Lite, and MAP. There are > operational deployments of all three, in the order given. You need them > close enough to your customers that traffic will return over the same > path. You can¹t share state among a cluster of boxes, but that¹s not the > end of the world; a device failure sometimes causes loss of state. MAP is > the hot new thing all the cool kids are doing. > > Look to your router and load balancer vendors for devices that do these. > CGN is the only one that doesn¹t require updates to the home gateway. The > more IPv6 your customers use, the smaller your CGN/AFTR/MAP can be. > > Think about how you¹ll position it to customers. It¹s difficult to change > a customer¹s service mid-contract. At some point, a customer is no longer > profitable: if NAT costs and service calls add up, you may be better off > buying addresses or losing the customer. You may need to buy some IPv4 > addresses to give you time; contact a broker. > > You may be surprised how hard it is to root IPv4 out of the system. Don¹t > buy anything you can¹t manage over IPv6, including servers and > applications. Sorry, vendor, I can¹t buy your cluster, I don¹t have the > IPv4 address space to provision it. > > Lee > > On 7/4/15, 8:09 AM, "NANOG on behalf of Josh Moore" > <nanog-bounces(a)nanog.org on behalf of jmoore(a)atcnetworks.net> wrote: > >> Traditional dual stack deployments implement both IPv4 and IPv6 to the >> CPE. >> Consider the following: >> >> An ISP is at 90% IPv4 utilization and would like to deploy dual stack >> with the purpose of allowing their subscriber base to continue to grow >> regardless of the depletion of the IPv4 space. Current dual stack best >> practices seem to recommend deploying BOTH IPv4 and IPv6 to every CPE. If >> this is the case, and BOTH are still required, then how does IPv6 help >> with the v4 address depletion crisis? Many sites and services would still >> need legacy IPv4 compatibility. Sure, CGN technology may be a solution >> but what about applications that need direct IPv4 connectivity without >> NAT? It seems that there should be a mechanism to enable on-demand and >> efficient IPv4 address consumption ONLY when needed. My question is this: >> What, if any, solutions like this exist? If no solution exists then what >> is the next best thing? What would the overall IPv6 migration strategy >> and goal be? >> >> Sorry for the length of this email but these are legitimate concerns and >> while I understand the need for IPv6 and the importance of getting there; >> I don't understand exactly HOW that can be done considering the immediate >> issue: IPv4 depletion. >> >> >> Thanks >> >> Joshua Moore >> Network Engineer >> ATC Broadband >> 912.632.3161 > >

9 18

Telia <> Globalcrossing ASH peering issue
by Frederik Kriewitz 09 Jul '15

09 Jul '15

Hello, is someone from GBLX/Level 3/Telia around? It looks like there's a problem with one of your peerings/LAGs. The problem exists since 00:36 UTC working path: traceroute from 71.80.34.222 to 151.248.24.61 (151.248.24.61), 30 hops max, 40 byte packets 1 192.168.30.1 (192.168.30.1) 0.416 ms 0.917 ms 1.085 ms 2 192.168.1.2 (192.168.1.2) 0.620 ms 0.520 ms 0.468 ms 3 71-80-34-193.static.kgpt.tn.charter.com (71.80.34.193) 1.342 ms 1.538 ms 2.180 ms 4 71-80-34-152.static.kgpt.tn.charter.com (71.80.34.152) 1.835 ms 2.001 ms 2.061 ms 5 dtr02lncytn-tge-0-6-1-2.lncy.tn.charter.com (96.34.68.84) 1.774 ms 1.787 ms 1.860 ms 6 crr02kgpttn-tge-0-7-0-4.kgpt.tn.charter.com (96.34.69.27) 5.485 ms crr02kgpttn-tge-0-7-0-6.kgpt.tn.charter.com (96.34.71.100) 5.222 ms crr02kgpttn-tge-0- -0-5.kgpt.tn.charter.com (96.34.69.29) 5.257 ms 7 crr12spbgsc-bue-100.spbg.sc.charter.com (96.34.93.200) 11.958 ms 11.962 ms 11.988 ms 8 bbr01spbgsc-bue-4.spbg.sc.charter.com (96.34.2.50) 11.864 ms 12.505 ms 14.984 ms 9 cha-b1-link.telia.net (62.115.12.125) 11.356 ms 11.370 ms 11.391 ms 10 ash-bb3-link.telia.net (80.91.252.100) 19.172 ms 19.211 ms 19.210 ms 11 ash-b1-link.telia.net (62.115.113.207) 19.439 ms 21.042 ms 20.627 ms 12 globalcrossing-ic-150675-ash-bb1.c.telia.net (213.248.90.122) 19.593 ms 19.223 ms 19.291 ms 13 lag9.csr1.dca3.gblx.net (67.16.146.25) 28.340 ms 19.095 ms 19.117 ms 14 ae3.scr4.wdc2.gblx.net (67.16.166.229) 19.894 ms 19.936 ms 19.929 ms 15 xe10-1-0-10g.scr4.lon3.gblx.net (67.16.166.81) 94.114 ms 94.124 ms 94.428 ms 16 lag2.ar9.lon3.gblx.net (67.17.106.149) 95.592 ms 93.098 ms 93.086 ms 17 avanti-hylas-2-cyprus-ltd.ethernet23-1.ar9.lon3.gblx.net (159.63.52.6) 95.534 ms 92.612 ms 92.568 ms 18 88.210.183.37 (88.210.183.37) 168.082 ms 181.644 ms 181.669 ms 19 88.210.186.77 (88.210.186.77) 169.436 ms 168.871 ms 168.895 ms 20 static-151-248-24-61.nynex.de (151.248.24.61) 169.285 ms 169.200 ms 169.151 ms Broken path to a neighboring IP using another interconnect: traceroute from 71.80.34.222 to 151.248.24.62 (151.248.24.62), 30 hops max, 40 byte packets 1 192.168.30.1 (192.168.30.1) 0.409 ms 0.903 ms 1.073 ms 2 192.168.1.2 (192.168.1.2) 0.488 ms 0.581 ms 0.529 ms 3 71-80-34-193.static.kgpt.tn.charter.com (71.80.34.193) 1.512 ms 2.005 ms 2.305 ms 4 71-80-34-152.static.kgpt.tn.charter.com (71.80.34.152) 2.807 ms 2.753 ms 3.027 ms 5 dtr02lncytn-tge-0-6-1-2.lncy.tn.charter.com (96.34.68.84) 1.809 ms 1.814 ms 1.815 ms 6 crr02kgpttn-tge-0-7-0-4.kgpt.tn.charter.com (96.34.69.27) 5.551 ms crr02kgpttn-tge-0-7-0-6.kgpt.tn.charter.com (96.34.71.100) 4.802 ms 4.837 ms 7 crr12spbgsc-bue-100.spbg.sc.charter.com (96.34.93.200) 10.341 ms 10.681 ms 10.593 ms 8 bbr01spbgsc-bue-4.spbg.sc.charter.com (96.34.2.50) 16.036 ms 10.018 ms 10.780 ms 9 cha-b1-link.telia.net (213.248.86.173) 21.081 ms 21.124 ms 21.121 ms 10 ash-bb4-link.telia.net (213.155.132.178) 19.049 ms 19.051 ms 19.041 ms 11 ash-b1-link.telia.net (213.155.130.73) 19.414 ms 19.434 ms 19.545 ms 12 globalcrossing-ic-130167-ash-bb1.c.telia.net (213.248.84.154) 19.239 ms 19.182 ms 19.279 ms 13 * 14 * 15 * 16 * 17 * 18 * 19 * 20 * 21 * 22 * 23 * 24 * 25 * 26 * 27 * 28 * 29 *

1 0

How to build an IPv6-only internal network?
by Cryptographrix 09 Jul '15

09 Jul '15

Hypothetically, I want to build an internal network that runs just IPv6 and apply stateless ACLs at redundant external connections. How do users access the current v4 address space?

4 3

Re: Dual stack IPv6 for IPv4 depletion
by Seth Mos 09 Jul '15

09 Jul '15

Residential users just buy another router for wifi coverage at the local wall mart. They have no clue about anything internet. That is why isp CPE devices should always perform dhcp-pd on their own to provide a prefix to the downstream devices so those have globally routed ipv6 too. For that to work you need concepts like route aggregation in the form of a /48 for the CPE so it can hand out a /56 to the customer bought CPE. Seth -------- Oorspronkelijk bericht -------- Van: Mike Hammett <nanog(a)ics-il.net> Datum: 09-07-2015 04:03 (GMT+01:00) Aan: nanog(a)nanog.org Onderwerp: Re: Dual stack IPv6 for IPv4 depletion I wasn't aware that residential users had (intentionally) multiple layers of routing within the home. I'm also not sure what address length has to do with routability, other than networks filtering prefix lengths. If that's an issue, that customer is covered by the ISP's larger allocation, or they get their own PI space if they're BGPing. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Karl Auer" <kauer(a)biplane.com.au> To: nanog(a)nanog.org Sent: Wednesday, July 8, 2015 8:36:41 PM Subject: Re: Dual stack IPv6 for IPv4 depletion On Wed, 2015-07-08 at 19:57 -0500, Mike Hammett wrote: > Isn't /56 the standard end-user allocation? No - it's just a common one. And a bad one. /48s for all opens up a whole different world of end-user reachability, routability and flexibility that a mere /56 does not. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer(a)biplane.com.au) http://www.biplane.com.au/kauer http://twitter.com/kauer389 GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4 Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

1 0

Re: Dual stack IPv6 for IPv4 depletion
by Owen DeLong 09 Jul '15

09 Jul '15

> On Jul 8, 2015, at 15:34 , Israel G. Lugo <israel.lugo(a)lugosys.org> wrote: > > > On 07/05/2015 06:26 PM, Owen DeLong wrote: >>> On Jul 4, 2015, at 23:51 , Valdis.Kletnieks(a)vt.edu wrote: >>> >>> Put their IPv4 behind a NAT and a globally routed /56. >>> >>> There, FTFY. :) >> Or better yet globally routed /48. >> >> /56 is still a bad idea. >> >> Owen > I've read this many times and am aware it's the standard recommendation. > Makes perfect sense for the customer side, as it would be hard for him > to subnet properly otherwise. > > Doesn't seem to make sense at all for the ISP side, though. Standard > allocation /32. Giving out /48s. Even if we leave out proper subnet > organization and allocate fully densely, that's at most 65,536 subnets. > Not a very large ISP. If you’re trying to build a decent sized ISP in a /32, you’re doing it wrong. /32 is not the “standard size” — It’s the MINIMUM size. > > You can say "get more blocks", or "get larger blocks". Sure, let's give > each ISP a /24. That lets them have up to 16M customers (and that's > still subnetting densely, which sucks rather a lot). Doesn't leave that > many allocation blocks for the RIRs to hand out, though. If you really think we have 16.7 Million ISPs on the planet, I think you badly miscounted. In fact, if you think we have 1 million ISPs that have more than 1 million customers, I’d say you’ve badly miscounted something. What am I missing? In terms of ISPs that need to support 16M customers, let’s assume everyone on the planet has 32 ISP subscriptions of some form or another. (work, home, tablet, phone, dongle, whatever… I’m pretty sure 32 is generous). Let’s assume EVERYONE on the planet is connected. That’s 7 Billion * 32 = 224 Billion total customers. Now let’s sparse-allocate 24s at the rate of 4 million customers per /24. 224,000,000,000 / 4,000,000 = 56,000 We need a total of 56,000 /24s to cover the total population. That still leaves us with 16,721,216 /24s. We barely made a dent in the number of /24s. Please explain to me again where the problem is with handing out /48s? > People usually look at IPv6 and focus on the vast numbers of individual > addresses. Naysayers usually get shot down with some quote mentioning > the number of atoms in the universe or some such. Personally, I think > that's a red herring; the real problem is subnets. At this rate I > believe subnets will become the scarce resource sooner or later. I’ve done the math on the prefix side. See above… Clearly you haven’t. > Sure, in the LAN side we'll never have to worry about address scarcity. > But what's the point of having addresses to spare, if it just means > you've got to start worrying about subnet scarcity? If the goal was > never having to worry about counting anymore, I propose that 128 bits is > far too little. Should've gone a full 256 and be done with it. Respectfully, I think that the math above shows that you are not correct in this assertion. Owen

2 1

Fwd: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends
by Jay Ashworth 09 Jul '15

09 Jul '15

>From Lauren, a new "feature" in Windows 10 I think this community probably wants to know about, to the extent you don't already. I *knew* I didn't like W10. :-) Cheers, -- jra ----- Forwarded Message ----- > From: "PRIVACY Forum mailing list" <privacy(a)vortex.com> > To: privacy-list(a)vortex.com > Sent: Wednesday, July 1, 2015 8:03:06 PM > Subject: [ PRIVACY Forum ] Windows 10 will share your Wi-Fi key with your friends' friends > Windows 10 will share your Wi-Fi key with your friends' friends > > http://www.theregister.co.uk/2015/06/30/windows_10_wi_fi_sense/ > > In an attempt to address the security hole it has created, Microsoft > offers a kludge of a workaround: you must add _optout to the SSID (the > name of your network) to prevent it from working with Wi-Fi Sense. (So > if you want to opt out of Google Maps and Wi-Fi Sense at the same > time, > you must change your SSID of, say, myhouse to myhouse_optout_nomap. > Technology is great.) Microsoft enables Windows 10's Wi-Fi Sense by > default, and access to password-protected networks are shared with > contacts unless the user remembers to uncheck a box when they first > connect. Choosing to switch it off may make it a lot less useful, but > would make for a more secure IT environment. > > - - - > > --Lauren-- > Lauren Weinstein (lauren(a)vortex.com) http://www.vortex.com/lauren > Founder: > - Network Neutrality Squad: http://www.nnsquad.org > - PRIVACY Forum: http://www.vortex.com/privacy-info > Co-Founder: People For Internet Responsibility: > http://www.pfir.org/pfir-info > Member: ACM Committee on Computers and Public Policy > Lauren's Blog: http://lauren.vortex.com > Google+: http://google.com/+LaurenWeinstein > Twitter: http://twitter.com/laurenweinstein > Tel: +1 (818) 225-2800 / Skype: vortex.com > _______________________________________________ > privacy mailing list > http://lists.vortex.com/mailman/listinfo/privacy -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

17 24

Debian RWHOIS
by Josh Moore 08 Jul '15

08 Jul '15

Hello guys, What do you use for ARIN resource assignments? I am looking to setup a Debian-based RWHOIS server but don't see much information on it. Joshua Moore Network Engineer ATC Broadband 912.632.3161 - O | 912.218.3720 - M

11 13

Canada'a broadband technoogies
by Jean-Francois Mezei 08 Jul '15

08 Jul '15

The CRTC is embarking on a multi year study/consultation of what to do with our lagging broadband deployment. Just yesterday, the government bragged about a multi milliuon subsidy to give a community 3mbps service. Can't help but to participate ... So I would like some feedback/sanity checks on a few issues. There is of course a large disconnect between marketed speeds and actual capacity and delivered speeds. 1- Satellite internet I am aware of latest generation satellites that provide focused antennas allowing re-use of the same spectrum for different regions. What sort of bandwidth is realistic for service to customers ? Australia's original NBN has 12mbps service planned for those in remote regions via satellite. Is this realistic ? Or is 3mbps really the max that can reliably be expected ? In terms of latency, would the special routers that "proxy" the TCP acks at both ends of the satellite link be commonplace now ? Still custom jobs ? or do modern TCP stacks now deal effectively with very high latency such that streaming data via satellite no longer requires special equipment to use bandwidth effectively ? For other protocols such as UDP etc, is latency an issue to be concerned with ? 2- Underwater fibre. There has been a project to string fibre from Tokyo to London via the canadian arctic. http://arcticfibre.com/ One aspect of this project are landings are various island that have canadian communities (which rely exclusively on satellite for telephone/data). While dumping fibre underwater is common, landing it in arctic areas is less common (think ice pack movement scraping bottom of shores). The folks on web site say they had done research on this. Are there examples where this was done succcesfully ? Or is this still something that is new and untested ? 3- Permafrost Ok, not an issue in USA, but wondering if there is knowledge of string long fibre cables on land that is permafrost (think Dawson City to Inuvik, roughly 700km). Has Russia or other nordic countries done this ? or are microwave link at regular intervals still the only/best way with vew structures built on the unstable ground ? I'd appreciate any insight/opinions on what is realistic and what is pipe dream.

1 0

United Airlines is Down (!) due to network connectivity problems
by Marshall Eubanks 08 Jul '15

08 Jul '15

http://www.reuters.com/article/2015/07/08/us-ual-flights-idUSKCN0PI1IX20150… At least, that's what I just heard on the radio. I know no other details. Regards Marshall Eubanks

16 24