March 2017 - Test - lists.nanog.org

google ipv6 routes via cogent
by Aaron 08 Mar '17

08 Mar '17

Hi, I'm new to the nanog list, hope this isn't out of scope for what is usually discussed here. Cogent is telling me that I can't route through cogent to get to google ipv6 routes (particularly the well known dns addresses 2001:4860:4860::88xx) because google decided not to advertise those route to one of their mutual peers. Anyone know anything about this ? .and why it happened and when it will be resolved ? -Aaron

13 18

scalematrix network access
by Mark Stevens 08 Mar '17

08 Mar '17

Good Morning, Is anyone having access issues into sites within scalematrix.net network? Our traces make it out of Cogent and into Level3 and either die in Level3 or a couple hops past Level3 into scalematrix.net network. If someone from Scalmatrix or Level3 reads this, can you email me offline to discuss? Thanks Mark

1 0

RE: WEBINAR TUESDAY: Can We Make IPv4 Great Again?
by Jakob Heitz (jheitz) 08 Mar '17

08 Mar '17

1.1.1.1.e.f and 2.2.2.2.e.f both get translated to 192.168.e.f. Some higher layer protocols embed IP addresses into their data. These points make changing IP so difficult. In addition, IPv6 has link local addresses. This one seemingly insignificant detail causes so much code churn and is probably responsible for 10 years of the IPv6 drag. Thakfully, site local was deprecated. Thanks, Jakob. > Date: Mon, 6 Mar 2017 22:00:45 +0100 > From: Baldur Norddahl <baldur.norddahl(a)gmail.com> > To: nanog(a)nanog.org > Subject: Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again? > Message-ID: <5645714e-e468-4655-34cf-6e70aa7cfa26(a)gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > That proposal is far too wordy. Here is the executive summary: > > Encode extra address bits in extension headers. Add a network element > near the destination that converts such that the destination IP of a > packet to IP a.b.c.d with extension header containing e.f is translated > to 192.168.e.f. In the reverse direction translate source address > 192.168.e.f to a.b.c.d and add option header with e.f. > > Executive summary end. > > As far as I can tell, the only advantage of this proposal over IPv6 is > that the network core does not need to be changed. You could communicate > with someone that had an EZIP address regardless that your ISP did > nothing to support EZIP. > > The disadvantage is that every single server out there would need to be > changed so it does not just drop the option headers on the reply > packets. All firewalls updated so they do not block packets with option > headers. All applications updated so they understand a new address format. > > Servers and applications could also confuse TCP or UDP streams that are > apparently from the same source, same port numbers, only thing that > differentiates the streams is some option header that the server does > not understand. > > The customers of the ISP that deploys EZIP would not need to update > anything (unless they need to communicate with other poor souls that got > assigned EZIP addresses), however everyone else would. This is not a > good balance. The customers would experience an internet where almost > nothing works. It would be magnitudes worse than the experience of an > IPv6 only network with NAT64. > > It is a fix for the wrong problem. Major ISPs have IPv6 support now. It > is the sites (=servers) that are lacking. If Twitter did not deploy IPv6 > why would you expect them to deploy EZIP? Why would some old forgotten > site with old song texts in some backwater country somewhere? > > We already have better solutions such as CGN with dual stack, NAT64, > DS-Lite, MAP etc. > > None of that is discussed in the RFC. Is the author aware of it? > > Regards, > > Baldur >

5 5

WEBINAR TUESDAY: Can We Make IPv4 Great Again?
by Joly MacFie 07 Mar '17

07 Mar '17

To say that Mr. Chen's EZIP proposal has not, thus far, been received with open arms by the networking community would be an understatement. It is seen as delaying the inevitable and introducing an impractical extra routing hardware layer that will be hit & miss. Nevertheless, since much of the world is still IPv4 dependent, it just could take off. ISOC-NY is happy to give him the opportunity to expound on its merits. We'd welcome some expert respondents. See: https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space… ================================================================== WEBINAR TUESDAY: Can We Make IPv4 Great Again? w/ @AbrahamYChen On Tuesday March 8 2017 at noon EST the Internet Society New York Chapter (ISOC-NY) presents a webinar Can We Make IPv4 Great Again?. Abraham Y. Chen, VP of Engineering, Avinta Communications, will present his EzIP proposal to reinvigorate the diminishing pool of IPv4 addresses. Optional registration at the link below. This will be recorded. What: WEBINAR: Can We Make IPv4 Great Again? When: Tuesday March 8 2017 Noon EST | 17:00 UTC Register + info: https://www.meetup.com/isoc-ny/events/238164448/ Computer: https://zoom.us/j/914492141 Phone: http://bit.ly/zoomphone ID: 914 492 141 Twitter: #ezip ==================================================================== Permalink http://isoc-ny.org/p2/9031 -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- -

11 15

Re: google ipv6 routes via cogent
by Baldur Norddahl 07 Mar '17

07 Mar '17

That will have the effect of prioritizing Cogent routes as that would be more specific than the default routes from the other providers. Cogent are not that good that you would want to do that. Den 2. mar. 2017 20.16 skrev "Jeff Waddell" <jeff+nanog(a)waddellsolutions.com >: Or at least ask for a full view from Cogent - then you won't get any routes they don't have On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay <alarig(a)swordarmor.fr> wrote: > On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote: > > Well, I asked my (3) upstream providers to only send me a ipv6 default > > route and they sent me ::/0...here's one of them... > > Why did you don’t ask for a full view? With that, you can easily deal > with that kind of problem. > > -- > alarig >

13 15

Re: WWV Broadcast Outages
by Hal Murray 06 Mar '17

06 Mar '17

"Majdi S. Abbas" <msa(a)latt.net> said: > That said, I and many others "still use" WWV -- there aren't exactly a > surplus of suitable backup methods to GPS these days. Any suggestions for gear and/or software that works with WWV (or CHU)? Or general suggestions for non GPS sources of time? Dave Mills had a driver in ntpd that used a PC audio port to listen to WWV. I don't know anybody who ever used it. I think there was code to tell some brand of receiver with a serial/USB port how to change frequencies so you could use the one that worked best for that time of day. There used to be WWVB (60 KHz) receivers. The good ones phase locked to the carrier. The general rise in EMI made those close to useless in most locations. NIST finished the job when they changed the modulation format a few years ago. As far as I know, there aren't any replacements for the old gear that take advantage of the new modulation format. GPS works too well. There are some boxes that recover the time from nearby cell phone towers. I think they will stop working as the towers get upgraded to the newer protocols that use a different form of timing. That will probably take many years. But the cell phone towers depend on GPS. (You can ususlly spot the conical antenna(s) if you look around a bit.) -- These are my opinions. I hate spam.

4 3

2nd call for presentations RIPE 74
by Benno Overeinder 05 Mar '17

05 Mar '17

Dear colleagues, Please note the approaching deadline of *12 March 2017* for RIPE 74 plenary programme submissions. You can find the CFP for RIPE 74 below or at https://ripe74.ripe.net/submit-topic/cfp/, for your proposals for plenary session presentations, tutorials, workshops, BoFs (Birds of a Feather sessions) and lightning talks. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://ripe74.ripe.net/programme/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 74 will take place from 8-12 May 2017 in Budapest, Hungary. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 74. See the full descriptions of the different presentation formats, https://ripe74.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 12 March 2017. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe74.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe74.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. Allocation of lightning talks will start a few days before the meeting, and will continue throughout the meeting. During the meeting, they may be announced on the day before the talk or even on the same day as the talk. - Lightning talks should also be submitted using the meeting submission system (https://ripe74.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

IANA IPv4 Recovered Address Space registry updated
by Paula Wang 04 Mar '17

04 Mar '17

Hi, An update has been made to the IANA IPv4 Recovered Address Space registry according to the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA (https://www.icann.org/resources/pages/allocation-ipv4-post-exhaustion-2012-…) The list of allocations can be found at: https://www.iana.org/assignments/ipv4-recovered-address-space/ Kind regards, Paula Wang IANA Services Specialist PTI

3 2

Re: google ipv6 routes via cogent
by Baldur Norddahl 04 Mar '17

04 Mar '17

In general I would not be single homed to a tier 1 ISP. You are better off using an ISP that has N upstream transit providers. That way they have multiple choices to select the best route. If you accept a default route from multiple upstreams you will be multi homed for inbound traffic but effectively single homed for outbound. Your router will select one default route and send 100% of the traffic that way. Instead of letting the router select a random default route, you should evaluate and rank your upstreams. Use a route map to set priority on the routes. Nobody has the best routes for all destinations, so you will have to find the one with the best average or perhaps the one that avoids bad routes. And that brings me to the point about Cogent. We used to have two upstreams. One was a local tier 2 ISP and the other was Cogent. Our quality was OK but if the tier 2 ISP link was down our customers would immediately call to claim downtime. We would not actually be down but quality was so low that people thought we were. The reason is that some major destinations from the Cogent network is routed from Europe to USA and back again. Latency go from a few milliseconds to 100 times worse. Available bandwidth is very reduced. Video from major streaming services will not play or only in lowest quality setting. I will claim that it is impossible to be single homed on Cogent in Denmark as an eyeball network. It is probably different if you are in the USA. This does not mean Cogent are useless. We were happy with the quality of the network and the price is good. What we experienced was bad peering. You just can't have them as your only transit. Regards Baldur Den 2. mar. 2017 21.02 skrev "Chuck Anderson" <cra(a)wpi.edu>: Define "good" vs. "bad" transport of bits. As long as there is adequate bandwidth and low latency, who cares? On Thu, Mar 02, 2017 at 08:30:37PM +0100, Baldur Norddahl wrote: > That will have the effect of prioritizing Cogent routes as that would be > more specific than the default routes from the other providers. Cogent are > not that good that you would want to do that. > > Den 2. mar. 2017 20.16 skrev "Jeff Waddell" <jeff+nanog@waddellsolutions. com > >: > > Or at least ask for a full view from Cogent - then you won't get any routes > they don't have > > On Thu, Mar 2, 2017 at 1:58 PM, Alarig Le Lay <alarig(a)swordarmor.fr> wrote: > > > On jeu. 2 mars 12:36:04 2017, Aaron Gould wrote: > > > Well, I asked my (3) upstream providers to only send me a ipv6 default > > > route and they sent me ::/0...here's one of them... > > > > Why did you don’t ask for a full view? With that, you can easily deal > > with that kind of problem.

1 0

FCC emergency waiver: Jewish Community Centers Calling Party Number Identification
by Sean Donelan 04 Mar '17

04 Mar '17

The FCC granted an emergency temporary waiver to telecommunication carriers serving Jewish Community Centers, allowing access to the Caller-ID (Calling Party Number Identification) normally blocked at the calling party's request (i.e. star-67). Although per call Call-Trace (i.e. star-57) and permanent Trap-and-Trace court orders also report the Caller-ID and other call information, such as ANI to law enforcement; the FCC occasionally granted similar waivers in the past. Obviously this doesn't help with spoofed calling numbers. https://www.fcc.gov/document/fcc-grants-emergency-waiver-help-protect-jewis…

1 0