February 2015 - Test - lists.nanog.org

v6 deagg
by Randy Bush 26 Feb '15

26 Feb '15

in a discussion with some fellow researchers, the subject of ipv6 deaggregation arose; will it be less or more than we see in ipv4? in http://archive.psg.com/jsac-deagg.pdf it was thought that multi-homing, traffic engineering, and the /24 pollution disease were the drivers. multi-homing seems to be increasing, while the other two were stable as a relative measure to total growth. so, at first blush, we thought v6 would be about the same as v4. but then we considered that v6 allocations seem to be /32s, and the longest propagating route seems to be /48, leaving 16 bits with which the deaggregators can play. while in v4 it was /24s out of a /19 or /20, four or five bits. this does not bode well. randy

14 20

Level 3 problems in Miami?
by Blair Trosper 26 Feb '15

26 Feb '15

Anyone else having massive trouble getting to endpoints beyond core routers in Miami on Level 3? I'm cut off (packets die) from Miami and Tampa after this specific router: po4-20g.ar1.mia2.gblx.net (67.16.134.218) If anyone from Level 3 could reach out, or if anyone knows what's going on and can say, I'd appreciate it. Thanks, Blair

1 3

reachability to AS3215 / AS5511
by Ryan DiRocco 26 Feb '15

26 Feb '15

Looking for a contact at orange 3215 / opentransit 5511 to resolve some reachability/blackhole issues for clients originating at 3215 reaching us at 46562. Please contact me off-list.

1 0

AOL Postmaster
by John Zettlemoyer 26 Feb '15

26 Feb '15

Could someone from AOL who deals with the email systems please contact me off-list. Thank you. John Zettlemoyer WCiT LLC 856.310.1375 x221 john(a)wcit.net

11 17

Comcast Support (from NANOG Digest, Vol 84, Issue 23)
by Brzozowski, John 25 Feb '15

25 Feb '15

Folks, The thread below was sent to me a few times, apologies for not catching it sooner. Janet, I sent you mail unicast with a request for some information. I am happy to help you out. For the larger NANOG audience, Comcast has recently launched IPv6 support for our BCI products, these are our DOCSIS based commercial offerings. This means that if you gateway device is in fact in RG mode you will be delegated a dynamic IPv6 prefix, by default customers are delegated a /56 prefix along with a single IPv6 address that is assigned to the WAN of the gateway device. IPv6 support applies to the following makes and models: SMC D3G CCR (http://mydeviceinfo.comcast.net/device.php?devid=216) Cisco BWG (http://mydeviceinfo.comcast.net/device.php?devid=347) Netgear CG3000D (http://mydeviceinfo.comcast.net/device.php?devid=347) For customers where you bring your own cable modem or have one of the above in bridge mode we have enabled IPv6 support for you as well. However, your router behind the modem must be running software and configured with IPv6 support. Specifically, your router needs to be support stateful DHCPv6 for IPv6 address and prefix acquisition. We have received a number of reports from customers that the Juniper SRX does not appear to properly support IPv6. We are working with Juniper and also recommend that you reach out to Juniper as well. Please keep checking http://www.comcast6.net for updates, we will post some additional information here in the next week or so. In the mean time if you have questions feel free to send me mail or post them here on the NANOG list. HTH, John ========================================= John Jason Brzozowski Comcast Cable p) 484-962-0060 w) www.comcast6.net e) john_brzozowski(a)cable.comcast.com ========================================= -----Original Message----- From: "nanog-request(a)nanog.org<mailto:nanog-request@nanog.org>" <nanog-request(a)nanog.org<mailto:nanog-request@nanog.org>> Reply-To: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>> Date: Friday, January 23, 2015 at 07:00 To: NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: NANOG Digest, Vol 84, Issue 23 Date: Thu, 22 Jan 2015 22:42:17 +0000 From: Janet Sullivan <janets(a)nairial.net<mailto:janets@nairial.net>> To: "'nanog(a)nanog.org<mailto:'nanog(a)nanog.org>'" <nanog(a)nanog.org<mailto:nanog@nanog.org>> Subject: Comcast Support Message-ID: <CY1PR0701MB1164F3448B35404BBAE671A8DC490(a)CY1PR0701MB1164.namprd07.prod.outlook.com<mailto:CY1PR0701MB1164F3448B35404BBAE671A8DC490@CY1PR0701MB1164.namprd07.prod.outlook.com>> Content-Type: text/plain; charset="us-ascii" I hate to use NANOG for this, but support has now ended a chat with me twice without fixing anything, they just kicked me off. I'm not getting an IPv6 address on the Comcast provided cable modem/router. I'm not getting a PD. My machines thus have no IPv6. I've hard reset my router 4 times while working with Comcast, and I've been told to do things like switch to a static IPv4 address, which shows a level of clue that is scary. And before that they were convinced it was a wireless problem even though I have a wired connection, and told them that multiple times. I've wasted two hours with Comcast today, and even when I asked for escalation I got nothing. Just hung up on. It's honestly the worst customer support I've ever received. I don't think I ever got them to understand the difference between IPv4 and IPv6.

10 12

RIPE-631: IPv6 Troubleshooting for Residential ISP Helpdesks
by Jason Fesler 25 Feb '15

25 Feb '15

https://www.ripe.net/ripe/docs/ripe-631 We hope anyone deploying IPv6, and consequently staffing a help desk, to find this document useful. Please feel free to borrow and adapt it for your organization's needs. I'm sharing it here on NANOG because this document is not RIPE region specific. Disclaimer: this documents the use of http://test-ipv6.com/helpdesk - which I'm perhaps a bit biased about. That said, the bulk of the body of this work is coming from the community at large. -jason

1 0

Re: AOL Postmaster
by Anne P. Mitchell, Esq. 24 Feb '15

24 Feb '15

For anyone having issues with AOL right now, if you would like, contact me offlist and I will see what I can do about getting it in front of our contact at AOL. Please be as specific as you can be about the issue, about who controls the IPs, about your own role and authority over the IPs and the email that flows through them, and please include at least one sample if possible. Anne Anne P. Mitchell, Esq. CEO/President ISIPP SuretyMail Email Reputation, Accreditation & Certification Your mail system + SuretyMail accreditation = delivered to their inbox! http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Author: Section 6 of the Federal CAN-SPAM Act of 2003 Member, California Bar Cyberspace Law Committee Ret. Professor of Law, Lincoln Law School of San Jose 303-731-2121 | amitchell(a)isipp.com | @AnnePMitchell | Facebook/AnnePMitchell

1 0

ARIN+NANOG On The Road
by Eric C. Miller 24 Feb '15

24 Feb '15

Thank you to all who put this event on! It was fun getting to meet everyone :) Eric Miller, CCNP Network Engineering Consultant (407) 257-5115

1 0

Wisdom of using 100.64/10 (RFC6598) space in an Amazon VPC deployment
by Eric Germann 24 Feb '15

24 Feb '15

Currently engaged on a project where they’re building out a VPC infrastructure for hosted applications. Users access apps in the VPC, not the other direction. The issue I'm trying to get around is the customers who need to connect have multiple overlapping RFC1918 space (including overlapping what was proposed for the VPC networks). Finding a hole that is big enough and not in use by someone else is nearly impossible AND the customers could go through mergers which make them renumber even more in to overlapping 1918 space. Initially, I was looking at doing something like (example IP’s): Customer A (172.28.0.0/24) <—> NAT to 100.127.0.0/28 <——> VPN to DC <——> NAT from 100.64.0.0/18 <——> VPC Space (was 172.28.0.0/24) Classic overlapping subnets on both ends with allocations out of 100.64.0.0/10 to NAT in both directions. Each sees the other end in 100.64 space, but the mappings can get tricky and hard to keep track of (especially if you’re not a network engineer). In spitballing, the boat hasn’t sailed too far to say “Why not use 100.64/10 in the VPC?” Then, the customer would be allocated a /28 or larger (depending on needs) to NAT on their side and NAT it once. After that, no more NAT for the VPC and it boils down to firewall rules. Their device needs to NAT outbound before it fires it down the tunnel which pfSense and ASA’s appear to be able to do. I prototyped this up over the weekend with multiple VPC’s in multiple regions and it “appears” to work fine. From the operator community, what are the downsides? Customers are businesses on dedicated business services vs. consumer cable modems (although there are a few on business class cable). Others are on MPLS and I’m hashing that out. The only one I can see is if the customer has a service provider with their external interface in 100.64 space. However, this approach would have a more specific in that space so it should fire it down the tunnel for their allocated customer block (/28) vs. their external side. Thoughts and thanks in advance. Eric

12 18

routing issue? could someone from verizon FiOS please take a look?
by Gordon Cook 24 Feb '15

24 Feb '15

Verizon Fios cannot connect me to lavra.spb.ru This is the Russian site of the second most important monastery in Russia. It is reachable from Boston avra.spb.ru (91.218.229.131), 64 hops max, 52 byte packets 1 192.168.100.1 (192.168.100.1) 2.293 ms 0.815 ms 0.764 ms 2 100.64.0.129 (100.64.0.129) 1.108 ms 3.013 ms 1.068 ms 3 10.16.28.1 (10.16.28.1) 1.411 ms 1.277 ms 1.068 ms 4 10.16.13.1 (10.16.13.1) 4.796 ms 2.301 ms 5.207 ms 5 69.46.226.129.lightower.net (69.46.226.129) 4.380 ms 3.138 ms 4.630 ms 6 ae2.bstpmallj42.lightower.net (64.72.64.113) 3.768 ms 6.008 ms 3.888 ms 7 xe-4-0-2.bar2.boston1.level3.net (4.53.56.153) 6.030 ms 4.890 ms 7.058 ms 8 ae-231-3607.edge4.london1.level3.net (4.69.166.25) 91.525 ms 81.571 ms ae-232-3608.edge4.london1.level3.net (4.69.166.29) 81.327 ms 9 ae-231-3607.edge4.london1.level3.net (4.69.166.25) 78.121 ms ae-232-3608.edge4.london1.level3.net (4.69.166.29) 79.734 ms 78.890 ms 10 195.50.122.186 (195.50.122.186) 173.491 ms 133.054 ms 198.495 ms 11 * * * 12 oversun-gw.transtelecom.net (217.150.54.25) 210.399 ms 138.519 ms 139.291 ms 13 mr-o-rtc1-rsw-2.oversun.ru (94.198.48.154) 131.070 ms 131.007 ms 129.553 ms 14 mr-o-rtc5-rsw-2.oversun.ru (94.198.48.110) 140.012 ms 208.023 ms 145.352 ms 15 vip-h5.ihc-ru.net (91.218.229.131) 131.485 ms 133.319 ms 129.822 ms and from comcast and other locations apparently it has v6 routing info as well ..someone much more knowledgable than i suggested that this can be a source of reachability problems but here is what happens on my machine ordons-mac-pro:~ gordoncook$ traceroute lavra.spb.ru traceroute to lavra.spb.ru (92.242.140.21), 64 hops max, 52 byte packets 1 wireless_broadband_router (192.168.1.1) 0.654 ms 0.351 ms 0.295 ms 2 l100.cmdnnj-vfttp-26.verizon-gni.net (98.110.50.1) 4.607 ms 4.326 ms 7.869 ms 3 g0-1-0-0.cmdnnj-lcr-22.verizon-gni.net (130.81.223.100) 12.172 ms 9.502 ms 7.242 ms 4 xe-9-1-6-0.ny5030-bb-rtr2.verizon-gni.net (130.81.199.226) 15.080 ms xe-9-1-2-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.144) 8.986 ms xe-4-1-8-0.ny5030-bb-rtr2.verizon-gni.net (130.81.209.84) 22.085 ms 5 * * * 6 0.ae1.br2.nyc4.alter.net (140.222.229.91) 79.467 ms 77.046 ms 74.729 ms 7 204.255.168.114 (204.255.168.114) 85.591 ms 86.899 ms 204.255.168.110 (204.255.168.110) 87.011 ms 8 be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69) 96.323 ms be2060.ccr41.jfk02.atlas.cogentco.com (154.54.31.9) 84.779 ms be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69) 85.063 ms 9 be2482.ccr21.cle04.atlas.cogentco.com (154.54.27.157) 31.562 ms 31.990 ms be2483.ccr22.cle04.atlas.cogentco.com (154.54.29.201) 27.548 ms 10 be2351.ccr41.ord01.atlas.cogentco.com (154.54.44.85) 37.087 ms be2185.ccr42.ord01.atlas.cogentco.com (154.54.43.177) 42.273 ms be2351.ccr41.ord01.atlas.cogentco.com (154.54.44.85) 39.590 ms 11 be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117) 49.793 ms be2156.ccr21.mci01.atlas.cogentco.com (154.54.6.85) 50.583 ms be2157.ccr22.mci01.atlas.cogentco.com (154.54.6.117) 49.492 ms 12 be2133.ccr22.sfo01.atlas.cogentco.com (154.54.30.65) 77.446 ms be2132.ccr21.sfo01.atlas.cogentco.com (154.54.30.53) 77.060 ms be2133.ccr22.sfo01.atlas.cogentco.com (154.54.30.65) 77.001 ms 13 be2164.ccr21.sjc01.atlas.cogentco.com (154.54.28.34) 74.999 ms 74.569 ms be2165.ccr22.sjc01.atlas.cogentco.com (154.54.28.66) 74.852 ms 14 be2063.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.1.162) 74.377 ms be2095.rcr21.b001848-1.sjc01.atlas.cogentco.com (154.54.3.138) 77.126 ms 89.476 ms 15 c1.sj.mpt.fiberinternetcenter.net (66.201.58.2) 82.483 ms 86.964 ms 80.094 ms 16 sanjose2.barefruit.co.uk (66.201.32.134) 125.112 ms 106.932 ms 124.778 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * 31 * * * 32 * * * 33 * * * 34 * * * 35 * * * 36 * * * 37 * * * 38 * * * 39 * * * 40 * unallocated.barefruit.co.uk (92.242.140.21) 111.898 ms * gordons-mac-pro:~ gordoncook$ PS: my FIOS contract is up in april. Any suggestion of how to avoid a $30 per month price increase would be greatly appreciated OFF list of course many thanks Gordon Cook COOK Report on Internet Protocol

2 1