Re: draft-ietf-mpls-ldp-ipv6-16
On (2015-02-19 11:06 -0500), Tim Durack wrote: What is the chance of getting working code this decade? I would quite like to play with this new fangled IPv6 widget... (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last piece for me.) Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to accept IPv6 next-hop in BGP LU, but probably does not work out-of-the-box? Isn't Segment Routing implementation day1 IPV4+IPV6 in XR? -- ++ytti
Re: v6 deagg
On Fri, 20 Feb 2015, Saku Ytti wrote: Correct solution is not to use some so called 'strict' ipv6 filters, which break Internet, by not allowing discontinuous pops having connectivity. Before, the practical level of de-agg was at /24 for IPv4. This meant only larger organisations could do it. With automation in the network space increasing, and with /48 being justifiable to any site, and with /48 being the typical DFZ routing filter, we now have the possibility of a lot more entities seeing IP address based multihoming and PI being possible. I don't like where this is headed. There are millions of entities that are justifiable to announce a /48 into DFZ. Do we want this to happen? By allowing it, we're not putting any pressure to invent solutions for graceful address migration with continous services, and instead putting the pressure on the DFZ infrastructure. Is this the correct tradeoff? How many smaller than /32 in the IPv6 DFZ do we allow before we need to start to worry? In these discussions I frequently interact with people who don't want to limit things until they are actually a problem. So when will this become a problem? 100k de-agged routes? 200k? 500k? 1M? From a technical point of view, I have little interest in my router handling the fact that an office at the other side of the planet shut down their router, and learning this via DFZ. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: v6 deagg
On 20/02/15 12:42, Mikael Abrahamsson wrote: I don't like where this is headed. There are millions of entities that are justifiable to announce a /48 into DFZ. Do we want this to happen? rfc6115 have good overview and recommendation. IPv6 clearly need separation of identification of endpoints and routing information to that endpoint. We already have broadband operators who fully deagg their IPv4 space. And just one ISP IPv6 with /32 deagg will take 65536 routes.
Re: draft-ietf-mpls-ldp-ipv6-16
On 20/Feb/15 02:36, George, Wes wrote: The document has come out the other side of the IETF sausage grinder now: https://tools.ietf.org/html/rfc7439 Unfortunately, it's just a list of the gaps. It is worth leaning on your vendors of choice to ensure that they have people focused on addressing these issues, as not all of them have volunteers to write the documents necessary to close those gaps yet. Looking at how long it has taken the community to react to the LDPv6 draft (been chasing everyone since 2007, personally), my priority to get a working MPLSv6 domain has gone from 1 to a lot lower. I'd like to see it get done, but I'm going to be focusing on getting better native IPv6 in the code/hardware before I chase the vendors for a working MPLSv6 solution. They just have no interest because there is no incremental revenue - and given the community are focused on other things, threatening not to buy kit due to lack of MPLSv6 support is not a practical avenue, unfortunately. Mark.
Re: v6 deagg
From: Saku Ytti s...@ytti.fi Is deaggregation inherently undesirable? I'd say yes when the only limit to deaggregation is /48. Given the opportunity people will do whatever they see fit at everyone elses expense What is the correct solution here? Deaggregate or allocate space you don't need? Whichever comes with sensible deagg control. The desired effect is people advertise exactly sufficient prefixes and, I'd say, a simple universal mechanism for everyone else to limit them to that so they don't feel the need to advertise more to prevent hijacks etc. Or some others solution, should route object creation be limited to LIR and be controlled by specific policy? It would allow inject information about the reason for it. There is always a good reason to the person doing it. Correct solution is not to use some so called 'strict' ipv6 filters, which break Internet, by not allowing discontinuous pops having connectivity. Yes, strict would be best if based on good data. With no prefix length police there is no good data, RIPE gave up and said /48 everywhere removing the simpler mechanism to do this (I've not noticed what the others are doing) brandon
Re: v6 deagg
On (2015-02-20 12:07 +0900), Randy Bush wrote: Hey, in a discussion with some fellow researchers, the subject of ipv6 deaggregation arose; will it be less or more than we see in ipv4? Is deaggregation inherently undesirable? In some RIR LIR will not get new allocation, just because LIR lacks INET connectivity between their datacenter or pop. This wasn't issue in IPv4, because you actually could reasonably fill your IPv4 allocation and were eligible for another allocation for your discontinuous locations. Clearly there are valid routing reasons why 1 network from single company has to appears in DFZ. Having RIR allocate another network or having LIR deaggregate have exact same cost to RIB/FIB, yet they are different. Multiple allocation gives additional scrutiny, network must pass RIR policy to be able to exist. Deagrregation is entirely uncontrolled, we don't know from route object the reason for it, valid reasons and invalid reasons are grouped in same pool. What is the correct solution here? Deaggregate or allocate space you don't need? Or some others solution, should route object creation be limited to LIR and be controlled by specific policy? It would allow inject information about the reason for it. Correct solution is not to use some so called 'strict' ipv6 filters, which break Internet, by not allowing discontinuous pops having connectivity. -- ++ytti
Re: draft-ietf-mpls-ldp-ipv6-16
On Fri, Feb 20, 2015 at 6:39 AM, Saku Ytti s...@ytti.fi wrote: On (2015-02-19 11:06 -0500), Tim Durack wrote: What is the chance of getting working code this decade? I would quite like to play with this new fangled IPv6 widget... (Okay, I'd like to stop using IPv4 for infrastructure. LDP is the last piece for me.) Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to accept IPv6 next-hop in BGP LU, but probably does not work out-of-the-box? Isn't Segment Routing implementation day1 IPV4+IPV6 in XR? -- ++ytti I would gladly take OSPFv2/OSPFv3/ISIS+SR over LDP, but I'm seeing that is not all that is needed. I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) working over IPv6. IPv6 control plane this decade may yet be optimistic. -- Tim:
Re: An Easy way to build a server cluster without top of rack switches (MEMO)
BTW: This scenario's combination has another portion for us like as below. High Availability Server Clustering without ILB(Internal Load Balancer) (MEMO) http://slidesha.re/1vld6uB -- Naoto MATSUMOTO On Mon, Feb 16, 2015 at 12:23 PM, NAOTO MATSUMOTO naoto...@gmail.com wrote: Hi Dan and ken. I respect your great works. Certainly, our scenario was network classics and it just does not one size fits all network architecture. Many people tried to built centralized and decentralized networks many years ago, some guys output implementation like this. Interconnect of K computer (torus fusion) https://www.fujitsu.com/global/Images/fujitsu-hpc-roadmap-beyond-petascale-computing.pdf I agree with you point. Our approach have to do more simple way on physical and logical network engineering, and change the mindset, I think. (e.g. network cabling procedure and troubleshooting and handling) But, some guys need more cost effective server cluster environment and they does't care network latency like Low-End Web Hosting. e.g. Intel Diversity of Server workloads http://bit.ly/1BgFH65 [JPG]. Now, Many people do not use Dijkstra and automaton theory on the server side, but it is great mechanism for network durability if they controlled. The Ethernet NIC's bandwidth is increasing day by day, the cost is decreasing too. I say again, our scenario is not one size fits all network architecture, but we believe that something will happen for some guys works. ;-) best regards, -- Naoto MATSUMOTO On Sat, Feb 14, 2015 at 7:08 AM, Dan Eckert daniel.eck...@microsoft.com wrote: I'm having a hard time seeing how this reduces cable costs or increases network durability. Each individual server is well connected to 3-4 other servers in the rack, but the rack still only has two uplinks. For many servers in the rack you're adding 3-4 routing hops between an end node and the rack uplink. Additionally, with only 2 external links tied to 2 specific nodes, you introduce more risks. If one of the uplink nodes fails, you've got to re-route all of the nodes that were using it as the shortest path to now exit through the other uplink node -- the worst case in the example then increases from the original 4-hops-to-exit to now 7-hops-to-exit. As far as cable costs go, you might have slightly shorter cables, but far more complex wiring pattern -- so in essence you're trading off a small amount of cable cost for a higher amount of installation and troubleshooting cost. Also, using this layout, you dramatically reduce the effective bandwidth available between devices, since per-device links now have to be used for backhaul/transport in addition to device-specific traffic. Finally, you have to manage per-server routing service configurations to make this work -- more points of failure and increased setup/troubleshooting cost. In a ToR switch scenario, you do one config on one switch, plug in the cables, and you're done -- problems happen, you go to the one switch, not chasing a needle through a haystack of interconnected servers. If your RU count is worth more than the combination of increased installation, server configuration, troubleshooting, latency, and capacity costs, then this is a good solution. Either way, it's a neat idea and a fun thought experiment to work through. Thanks! Dan -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of NAOTO MATSUMOTO Sent: Wednesday, February 11, 2015 11:32 PM To: nanog@nanog.org Subject: FYI: An Easy way to build a server cluster without top of rack switches (MEMO) Hi all! We wrote up TIPS memo an easy way to build a server cluster without top of rack switches concept. This model have a reduce switches and cables costs and high network durability by lightweight and simple configuration. if you interest in, please try to do yourself this concept ;-) An Easy way to build a server cluster without top of rack switches (MEMO) http://slidesha.re/1EduYXM Best regards, -- Naoto MATSUMOTO
Re: draft-ietf-mpls-ldp-ipv6-16
On 20/Feb/15 13:39, Saku Ytti wrote: Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to accept IPv6 next-hop in BGP LU, but probably does not work out-of-the-box? Isn't Segment Routing implementation day1 IPV4+IPV6 in XR? The last time I checked, MPLS support in SR for IPv6 is not a high priority, compared to TE for IPv4 MPLS. My thoughts that SR would automatically mean native label signaling in IS-IS and OSPFv3 were otherwise ambitious. Mark.
Re: draft-ietf-mpls-ldp-ipv6-16
For L2VPN if you could make it work - go with EVPN day 1, it solves most of the issues present in both LDP and BGP VPLS implementations. Be aware of differences in PBB vs plain EVPN and platform support. EVPN, specifically multhoming/split horizon/some other stuff as well as presence of L3 (type 2/5) and complications of above brings lots of complexity into fast path processing and not every platform/NPU can do full spec. Regards, Jeff On Feb 20, 2015, at 1:19 PM, Saku Ytti s...@ytti.fi wrote: On (2015-02-20 09:00 -0500), Tim Durack wrote: Hey Tim, I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) working over IPv6. L3VPN uses BGP exclusively for VPN label signalling, no need for LDP. For L2VPN only Martini uses LDP, but if you have choice, why wouldn't you choose Kompella, the scaling factor is superior, as you only have 2 signalling connection, instead of n*(n-1)/2 signalling sessions. And you get to capitalize on instantly available backuo path. Of course I know that in CSCO land Kompella isn't available on every platform where Martini is, so you indeed may need LDP for some time until old platforms are phased out. 'Luckily' these older platforms have dubious IPv6 anyhow, so you might opt them out from IPv6 deployment anyhow. IPv6 control plane this decade may yet be optimistic. For greenfield it's doable today (only Kompella pseudowires), but IPv6-only would require 4PE, I don't know if that works/exists. -- ++ytti
Re: DNS Admin at Comcast
Sent a note off-list. - Jason On 2/20/15, 1:38 PM, Mark Stevens mana...@monmouth.com wrote: If a DNS Admin at Comcast could contact me offline it would be great. This is concerning your IPV6 configured mail servers. Thanks, Mark
Re: Interesting BFD discussion on reddit
On (2015-02-17 06:11 +0530), Glen Kent wrote: I think the hardware used was Broadcom. They have a few chipsets which do MD5 and (possibly) SHA in hardware for BFD -- which i have been told is pretty much useless when you start scaling. While I don¹t fully understand the context of this particular test and the scaling limitation, there are merchant silicon, NPUs and even CPUs that do support MD5 and SHA at transport line rate requirements. BFD requirements are just a fraction of these capabilities. The option to negotiate capabilities should be available independent of scaling/cost/inefficiencies at present time. It is a matter of implementation/product design choice. Sudeep Khuraijam
Re: draft-ietf-mpls-ldp-ipv6-16
From market prospective v6 SR is definitely lower priority. Comcast and few more are looking into native rather than v6 with MPLS encap. Wrt v4 - 2 weeks ago at EANTC in Berlin we have tested 3 implementations of ISIS SR v4 MPLS with L3VPN and 6VPE over SR tunnels. Worked very well, very few issues. So there's production quality code and interoperability - given the timeframe we have done a really good job in IETF :) Regards, Jeff On Feb 20, 2015, at 2:09 PM, Mark Tinka mark.ti...@seacom.mu wrote: On 20/Feb/15 13:39, Saku Ytti wrote: Is there 4PE implementation to drive IPv4 edges, shouldn't be hard to accept IPv6 next-hop in BGP LU, but probably does not work out-of-the-box? Isn't Segment Routing implementation day1 IPV4+IPV6 in XR? The last time I checked, MPLS support in SR for IPv6 is not a high priority, compared to TE for IPv4 MPLS. My thoughts that SR would automatically mean native label signaling in IS-IS and OSPFv3 were otherwise ambitious. Mark.
Re: draft-ietf-mpls-ldp-ipv6-16
On (2015-02-20 09:00 -0500), Tim Durack wrote: Hey Tim, I also need some flavor of L2VPN (eVPN) and L3VPN (VPNv4/VPNv6) working over IPv6. L3VPN uses BGP exclusively for VPN label signalling, no need for LDP. For L2VPN only Martini uses LDP, but if you have choice, why wouldn't you choose Kompella, the scaling factor is superior, as you only have 2 signalling connection, instead of n*(n-1)/2 signalling sessions. And you get to capitalize on instantly available backuo path. Of course I know that in CSCO land Kompella isn't available on every platform where Martini is, so you indeed may need LDP for some time until old platforms are phased out. 'Luckily' these older platforms have dubious IPv6 anyhow, so you might opt them out from IPv6 deployment anyhow. IPv6 control plane this decade may yet be optimistic. For greenfield it's doable today (only Kompella pseudowires), but IPv6-only would require 4PE, I don't know if that works/exists. -- ++ytti
The Cidr Report
This report has been generated at Fri Feb 20 21:14:25 2015 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
13-02-15538035 294739
14-02-15538453 294684
15-02-15538305 294704
16-02-15538359 294312
17-02-15538588 294957
18-02-15538600 295168
19-02-15538555 295850
20-02-15538805 296396
AS Summary
49708 Number of ASes in routing system
19851 Number of ASes announcing only one prefix
3121 Largest number of prefixes announced by an AS
AS10620: Telmex Colombia S.A.,CO
120442368 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street,CN
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 20Feb15 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 539262 296349 24291345.0% All ASes
AS22773 2985 170 281594.3% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.,US
AS6389 2891 98 279396.6% BELLSOUTH-NET-BLK -
BellSouth.net Inc.,US
AS17974 2826 77 274997.3% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia,ID
AS39891 2473 14 245999.4% ALJAWWALSTC-AS Saudi Telecom
Company JSC,SA
AS28573 2306 312 199486.5% NET Serviços de Comunicação
S.A.,BR
AS4755 1976 247 172987.5% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP,IN
AS4766 2891 1323 156854.2% KIXS-AS-KR Korea Telecom,KR
AS7303 1788 279 150984.4% Telecom Argentina S.A.,AR
AS7545 2599 1107 149257.4% TPG-INTERNET-AP TPG Telecom
Limited,AU
AS9808 1546 67 147995.7% CMNET-GD Guangdong Mobile
Communication Co.Ltd.,CN
AS6147 1589 161 142889.9% Telefonica del Peru S.A.A.,PE
AS10620 3121 1699 142245.6% Telmex Colombia S.A.,CO
AS20115 1850 514 133672.2% CHARTER-NET-HKY-NC - Charter
Communications,US
AS8402 1329 26 130398.0% CORBINA-AS OJSC Vimpelcom,RU
AS4323 1630 409 122174.9% TWTC - tw telecom holdings,
inc.,US
AS8452 1783 578 120567.6% TE-AS TE-AS,EG
AS9498 1300 111 118991.5% BBIL-AP BHARTI Airtel Ltd.,IN
AS18566 2040 869 117157.4% MEGAPATH5-US - MegaPath
Corporation,US
AS7552 1146 57 108995.0% VIETEL-AS-AP Viettel
Corporation,VN
AS22561 1329 251 107881.1% AS22561 - CenturyTel Internet
Holdings, Inc.,US
AS34984 1965 891 107454.7% TELLCOM-AS TELLCOM ILETISIM
HIZMETLERI A.S.,TR
AS3356 2569 1502 106741.5% LEVEL3 - Level 3
Communications, Inc.,US
AS6849 1196 243 95379.7% UKRTELNET JSC UKRTELECOM,UA
AS7738 1000 84 91691.6% Telemar Norte Leste S.A.,BR
AS38285 983 113 87088.5% M2TELECOMMUNICATIONS-AU M2
Telecommunications Group
Ltd,AU
AS4538 1776 939 83747.1% ERX-CERNET-BKB China Education
and Research Network
Center,CN
AS4780 1103 309 79472.0% SEEDNET Digital United Inc.,TW
AS26615 922 134 78885.5% Tim Celular S.A.,BR
AS8151 1547 763 78450.7% Uninet S.A. de C.V.,MX
AS24560 1212 429 78364.6% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services,IN
Total 5567113776
Re: [j-nsp] draft-ietf-mpls-ldp-ipv6-16
On Fri, Feb 20, 2015 at 6:02 PM, Adam Vitkovsky adam.vitkov...@gamma.co.uk wrote: Alright so would you mind sharing the business drivers that would make you migrate your current production infrastructure to this new unproven possibly buggy LDPv6 and 4PE/4VPE setup please? adam Businesses bigger than me think there is a business driver for IPv6: http://meetings.ripe.net/ripe-54/presentations/IPv6_management.pdf http://www.internetsociety.org/deploy360/wp-content/uploads/2014/04/WorldIPv6Congress-IPv6_LH-v2.pdf IPv6 management of equipment is relatively easy. Once you've started down that path, you start looking at the protocol stuff, and wondering what to do about that. Maybe I should leave it alone until the business people figure it out for me :-) Tim:
NYC Metro Ethernet Providers
Hi all, We're currently a UK based managed service provider looking to open up in the New York area. Part of our service model involves buying quite a lot of L2 ethernet tails from customer prems back to our DCs, usually 100Mb and 1Gb, but sometimes smaller 10-50Mb services for backups. I was wondering if anyone on the list would be able to recommend reliable providers in that region, we'd essentially just want pure Layer 2 so we can run our own VLANs etc across them, with a number of circuits aggregated and handed off in a DC as a trunk, each circuit as an SPVLAN that we can then strip. Thanks in advance for any feedback, Bryn Sadler
What would you do about questionable domain pointing A record to your IP address?
All, We have a rather strange situation (well, strange to me, at least). We have an email reputation accreditation applicant, who otherwise looks clean, however there is a very strange and somewhat concerning domain being pointed to one of the applicant's IP addresses Let's call the domain example.com, and the IP address 127.0.0.1, for these purposes. Applicant is assigned 127.0.0.1. the rDNS correctly goes to their own domain. However, example.com (which in reality is a concerning domain name) claims 127.0.0.1 as their A record. Of course, example.com is registered privately, and their DNS provider is one who is...umm... known to provide dns for domains seen in spam. As I see it, the applicant's options are: a) just not worry about it and keep an eye on it b) publish a really tight spf record on it, so if they are somehow compromised, email appearing to come from example.com and 127.0.0.1 should be denied c) not use the IP address at all (it's part of a substantially larger block) d) two or more of the above. Thoughts? What would you do? Thanks! 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 | amitch...@isipp.com | @AnnePMitchell | Facebook/AnnePMitchell
Re: v6 deagg
On 2/20/2015 4:13 AM, Nikolay Shopik wrote: rfc6115 have good overview and recommendation. IPv6 clearly need separation of identification of endpoints and routing information to that endpoint. I'm not overly familiar, but I'm always good for new things if one process is supported. deagg X network to Y provider, ask provider to blackhole XY address in X. Not every provider has a good blackhole system. Sometimes you desire to move a subset of data to a single provider for purposes of discarding data. I believe some of the protocols allow multiple sub-identifiers for load balancing purposes, but I'm unsure how strictly they are adhered to or if they might be ignored. I know BGP blackholing is a coincidental abuse of how BGP works, but it is a commonly used one; especially when some city endusers now have more bandwidth than entire rural ISPs. DDOS/amplification isn't always necessary these days. :( Jack
Re: What would you do about questionable domain pointing A record to your IP address?
Hi, On Fri, Feb 20, 2015 at 12:08 PM, Anne P. Mitchell, Esq. amitch...@isipp.com wrote: All, We have a rather strange situation (well, strange to me, at least). We have an email reputation accreditation applicant, who otherwise looks clean, however there is a very strange and somewhat concerning domain being pointed to one of the applicant's IP addresses Let's call the domain example.com, and the IP address 127.0.0.1, for these purposes. Applicant is assigned 127.0.0.1. the rDNS correctly goes to their own domain. However, example.com (which in reality is a concerning domain name) claims 127.0.0.1 as their A record. I don't think having an A record in the DNS is really a claim. Let's say I want to send mail to company.example.com but I don't like them so much so I set up companySUCKS.foo.example.com pointing at their mail server either through an A record or a CNAME... Then, I believe, inside my mail, the mail could appear to be to per...@companysucks.foo.example.com if it wasn't blocked by some security mechanism. Perhaps this is protected speech or, with a few changes, a parody or something. See Section 4.1.3 You Can't Control What Names Point At You in my RFC http://tools.ietf.org/html/rfc3675 A somewhat similar thing is in Section 4.1.4.1 of that RFC where I was on social mailing list with an innocuous name and someone had long set up a forwarder so that if you sent email to cat-torturers@other.example (real left hand side, obviously not the real right hand side). It would get sent to the social mailing list and the that address would appear in the to: line inside the mail. For that particular crowd, most people thought this was pretty funny, but it is the same sort of thing. Of course, example.com is registered privately, and their DNS provider is one who is...umm... known to provide dns for domains seen in spam. As I see it, the applicant's options are: a) just not worry about it and keep an eye on it b) publish a really tight spf record on it, so if they are somehow compromised, email appearing to come from example.com and 127.0.0.1 should be denied c) not use the IP address at all (it's part of a substantially larger block) d) two or more of the above. Thoughts? What would you do? If it isn't actually causing a problem, a) seems viable but you could certainly do b) or c) or both if you feel like it. Anyway, I'm not a lawyer... :-) Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Thanks! 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 | amitch...@isipp.com | @AnnePMitchell | Facebook/AnnePMitchell
BGP Update Report
BGP Update Report Interval: 12-Feb-15 -to- 19-Feb-15 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS61894 367710 7.2% 122570.0 -- FreeBSD Brasil LTDA,BR 2 - AS23752 271684 5.3%1983.1 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - AS27194 218890 4.3% 109445.0 -- REALLYFAST - ReallyFast.net,US 4 - AS9829 119288 2.3% 70.5 -- BSNL-NIB National Internet Backbone,IN 5 - AS577109681 2.1% 40.6 -- BACOM - Bell Canada,CA 6 - AS36947 71643 1.4% 312.9 -- ALGTEL-AS,DZ 7 - AS53563 57400 1.1%5740.0 -- XPLUSONE - X Plus One Solutions, Inc.,US 8 - AS13188 40017 0.8% 38.1 -- BANKINFORM-AS CONTENT DELIVERY NETWORK LTD,UA 9 - AS840230288 0.6% 21.7 -- CORBINA-AS OJSC Vimpelcom,RU 10 - AS845227196 0.5% 14.1 -- TE-AS TE-AS,EG 11 - AS381625388 0.5% 27.4 -- COLOMBIA TELECOMUNICACIONES S.A. ESP,CO 12 - AS42337 23301 0.5% 143.0 -- RESPINA-AS Respina Networks Beyond PJSC,IR 13 - AS10620 22359 0.4% 7.2 -- Telmex Colombia S.A.,CO 14 - AS23342 22359 0.4% 588.4 -- UNITEDLAYER - Unitedlayer, Inc.,US 15 - AS28573 21680 0.4% 8.9 -- NET Serviços de Comunicação S.A.,BR 16 - AS197914 21019 0.4%7006.3 -- STOCKHO-AS Stockho Hosting SARL,FR 17 - AS273418761 0.4% 694.9 -- CORESITE - CoreSite,US 18 - AS42081 18413 0.4% 312.1 -- SPEEDY-NET-AS Speedy net EAD,BG 19 - AS28024 18284 0.4% 304.7 -- Nuevatel PCS de Bolivia S.A.,BO 20 - AS14709 17921 0.3% 779.2 -- Telefonica Moviles Panama S.A.,PA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS61894 367710 7.2% 122570.0 -- FreeBSD Brasil LTDA,BR 2 - AS27194 218890 4.3% 109445.0 -- REALLYFAST - ReallyFast.net,US 3 - AS61039 16564 0.3% 16564.0 -- ZMZ OAO ZMZ,RU 4 - AS463368839 0.2%8839.0 -- GOODVILLE - Goodville Mutual Casualty Company,US 5 - AS501047629 0.1%7629.0 -- SATORP-AS SAUDI ARAMCO TOTAL Refining and Petrochemical Company,SA 6 - AS197914 21019 0.4%7006.3 -- STOCKHO-AS Stockho Hosting SARL,FR 7 - AS53563 57400 1.1%5740.0 -- XPLUSONE - X Plus One Solutions, Inc.,US 8 - AS25563 16309 0.3%4077.2 -- WEBLAND-AS Webland AG, Autonomous System,CH 9 - AS337213832 0.1%3832.0 -- CCL-ASN2 - CARNIVAL CRUISE LINES,US 10 - AS33440 12758 0.2%3189.5 -- WEBRULON-NETWORK - webRulon, LLC,US 11 - AS621742979 0.1%2979.0 -- INTERPAN-AS INTERPAN LTD.,BG 12 - AS1980532641 0.1%2641.0 -- AMTEL VECTRA S.A.,PL 13 - AS23752 271684 5.3%1983.1 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 14 - AS476809237 0.2%1847.4 -- NHCS EOBO Limited,IE 15 - AS2011491660 0.0%1660.0 -- ITSNS ITS Network Solution sp z o o,PL 16 - AS9581 1565 0.0%1565.0 -- TELSTRAGLOBAL-ID-AS-AP TTPL,HK 17 - AS561691560 0.0%1560.0 -- SCOMM-AS-AP SEDCO COMMUNICATIONS SDN BHD,MY 18 - AS1979571539 0.0%1539.0 -- KERBB Ker Broadband Communications Ltd,IE 19 - AS2621494046 0.1%1348.7 -- Sistemas Fratec S.A.,CR 20 - AS456066636 0.1%1327.2 -- TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 177.10.158.0/24 367707 7.0% AS61894 -- FreeBSD Brasil LTDA,BR 2 - 202.70.88.0/21 136788 2.6% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 3 - 202.70.64.0/21 134332 2.5% AS23752 -- NPTELECOM-NP-AS Nepal Telecommunications Corporation, Internet Services,NP 4 - 162.246.92.0/22 109482 2.1% AS27194 -- REALLYFAST - ReallyFast.net,US 5 - 162.208.40.0/22 109408 2.1% AS27194 -- REALLYFAST - ReallyFast.net,US 6 - 105.96.0.0/22 64808 1.2% AS36947 -- ALGTEL-AS,DZ 7 - 199.38.164.0/23 57376 1.1% AS53563 -- XPLUSONE - X Plus One Solutions, Inc.,US 8 - 64.29.130.0/2422287 0.4% AS23342 -- UNITEDLAYER - Unitedlayer, Inc.,US 9 - 130.0.192.0/2121017 0.4% AS197914 -- STOCKHO-AS Stockho Hosting SARL,FR 10 - 23.34.208.0/2118151 0.3% AS577 -- BACOM - Bell Canada,CA 11 - 91.235.169.0/24 16564 0.3% AS61039 -- ZMZ OAO ZMZ,RU 12 - 184.84.32.0/2016281 0.3% AS577 -- BACOM - Bell Canada,CA 13 - 23.34.220.0/2316254 0.3% AS577 -- BACOM - Bell Canada,CA 14 - 184.84.184.0/22 16222 0.3% AS577 -- BACOM - Bell Canada,CA 15 - 23.34.216.0/2216213 0.3% AS577 -- BACOM - Bell Canada,CA 16 - 184.28.42.0/2316203 0.3% AS577 -- BACOM - Bell Canada,CA
Re: What would you do about questionable domain pointing A record to your IP address?
On 2/20/2015 11:08 AM, Anne P. Mitchell, Esq. wrote: a) just not worry about it and keep an eye on it If they have held the netblock for awhile and are already using the IP Address in question, this is fine. I presume that the servers don't actually respond for that domain (name-based web or domain based acceptance on a mail server). b) publish a really tight spf record on it, so if they are somehow compromised, email appearing to come from example.com and 127.0.0.1 should be denied You must control a domain to control its SPF. This is not an option if they don't control the bad domain. DKIM or similar might be the more appropriate protocol? SPF protects domains, some of the other protocols protect the mail servers themselves. c) not use the IP address at all (it's part of a substantially larger block) If it's a recently acquired netblock, then it may have a bad reputation due to prior use. Investigating the reputation and possibly avoiding that particular IP Address might be warranted. Jack
Re: [j-nsp] draft-ietf-mpls-ldp-ipv6-16
On Fri, Feb 20, 2015 at 11:33 AM, Adam Vitkovsky adam.vitkov...@gamma.co.uk wrote: Of Tim Durack Sent: 20 February 2015 14:00 IPv6 control plane this decade may yet be optimistic. And most importantly it's not actually needed it's just a whim of network operators. adam -- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com -- I don't consider unique addressing of infrastructure a whim. -- Tim:
Re: What would you do about questionable domain pointing A record to your IP address?
On Fri, Feb 20, 2015 at 12:08 PM, Anne P. Mitchell, Esq. amitch...@isipp.com wrote: We have an email reputation accreditation applicant, who otherwise looks clean, however there is a very strange and somewhat concerning domain being pointed to one of the applicant's IP addresses Let's call the domain example.com, and the IP address 127.0.0.1, for these purposes. Applicant is assigned 127.0.0.1. the rDNS correctly goes to their own domain. However, example.com (which in reality is a concerning domain name) claims 127.0.0.1 as their A record. Howdy, How does 127.0.0.1 behave when you access it and declare yourself to be seeking example.com? If it's a mail server, what happens when you try to mail postmas...@examplecompany.com? Do you get a no-relaying message or one of the other errors appropriate to a server not configured to handle mail for example.com? If it's a web server, what happens when your browser asks for Host: www.example,com? Do you get example.com's web page? Also check 3rd party databases to the extent possible. Can you find examples of dastardly example.com activity from 127.0.0.1 during a time the whois records say applicant had control of 127.0.0.1? You get the general idea. Check for things you know to be under the applicant's control. If they come up clean, they're clean. If they're dirty and they're sloppy enough to not clean up the example.com DNS zone file then they'll be sloppy elsewhere too. Regards, Bill Herrin -- William Herrin her...@dirtside.com b...@herrin.us Owner, Dirtside Systems . Web: http://www.dirtside.com/
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 21 Feb, 2015 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 533255 Prefixes after maximum aggregation (per Origin AS): 204025 Deaggregation factor: 2.61 Unique aggregates announced (without unneeded subnets): 259930 Total ASes present in the Internet Routing Table: 49437 Prefixes per ASN: 10.79 Origin-only ASes present in the Internet Routing Table: 36458 Origin ASes announcing only one prefix: 16285 Transit ASes present in the Internet Routing Table:6273 Transit-only ASes present in the Internet Routing Table:171 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 107 Max AS path prepend of ASN ( 55644) 100 Prefixes from unregistered ASNs in the Routing Table: 1334 Unregistered ASNs in the Routing Table: 436 Number of 32-bit ASNs allocated by the RIRs: 8646 Number of 32-bit ASNs visible in the Routing Table:6706 Prefixes from 32-bit ASNs in the Routing Table: 24396 Number of bogon 32-bit ASNs visible in the Routing Table: 5 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:400 Number of addresses announced to Internet: 2732253284 Equivalent to 162 /8s, 218 /16s and 224 /24s Percentage of available address space announced: 73.8 Percentage of allocated address space announced: 73.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 97.2 Total number of prefixes smaller than registry allocations: 180436 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 131658 Total APNIC prefixes after maximum aggregation: 38372 APNIC Deaggregation factor:3.43 Prefixes being announced from the APNIC address blocks: 137114 Unique aggregates announced from the APNIC address blocks:55712 APNIC Region origin ASes present in the Internet Routing Table:5024 APNIC Prefixes per ASN: 27.29 APNIC Region origin ASes announcing only one prefix: 1220 APNIC Region transit ASes present in the Internet Routing Table:872 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible:107 Number of APNIC region 32-bit ASNs visible in the Routing Table: 1310 Number of APNIC addresses announced to Internet: 747396800 Equivalent to 44 /8s, 140 /16s and 94 /24s Percentage of available APNIC address space announced: 87.3 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 131072-135580 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:176104 Total ARIN prefixes after maximum aggregation:87045 ARIN Deaggregation factor: 2.02 Prefixes being announced from the ARIN address blocks: 178169 Unique aggregates announced from the ARIN address blocks: 83527 ARIN Region origin ASes present in the Internet Routing Table:16498 ARIN Prefixes per
DNS Admin at Comcast
If a DNS Admin at Comcast could contact me offline it would be great. This is concerning your IPV6 configured mail servers. Thanks, Mark
