Re: [Nanog-futures] new corporation?
http://www.nanog.org/governance/corporate_documents.html On Thu, Sep 20, 2012 at 10:26 PM, Ryan Finnesey r...@finnesey.com wrote: I may be a bit late to the game but was there a new nanog corporation formed? Cheers Ryan ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
RE: Verizon IPv6 LTE
Justin M. Streiner On Thu, 20 Sep 2012, TJ wrote: My understanding, and experience (albeit with Android), is that all VZW LTE is IPv6-capable. I'd love to hear if Apple or VZW is at fault here, or if something weird is happening ... I don't know about Apple devices on VZW, but my Android phone definitely has IPv6 connectivity on VZW 4G LTE in Pittsburgh. Same in the DC Metro area. My RAZR is all v6 all the time on LTE. Jamie
Re: Real world sflow vs netflow?
http://www.plixer.com/blog/netflow/netflow-vs-sflow-for-network-monitoring-and-security-the-final-say/ Regards, Benoit. Can anyone on or off list give me some real world thoughts on sflow vs netflow for border routers? (multi-homed, BGP, straight v4 v6 only for web hosting, no mpls, vpns, vlans, etc.) Finding it hard to decipher the vendor version of the answer to that question. We use netflow v9 currently but are considering hardware that would be sflow. We don't use it for billing purposes, mostly for spotting malicious remote hosts doing things like scans, spotting traffic such as weird ports in use in either direction that warrant further investigation, watching for ddos/dos destinations to act on mitigation, or investigating the nature of unusual levels of traffic on switch ports that set off alarms. I'm concerned things like port scans, etc. won't be picked up by the NMS if fed by sflow due to the sampling nature, or similar concern if 500 ssh connections by the same remote host are sampled as 1 connection, etc. Of course these concerns were put in my head by someone interested in me continuing to use equipment that happens to output netflow data, hence me wanting some real people answers. :-) Thanks!
Throw me a IPv6 bone (sort of was IPv6 ignorance)
The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: Verizon IPv6 LTE
On Thu, Sep 20, 2012 at 10:15 PM, PC paul4...@gmail.com wrote: Please don't hack or ddos it :-) Unfortunately, while you do get an ipv6 address, mobile terminated data doesn't work, so you don't have to worry about this. It is firewalled by Verizon. T-Mobile USA allows mobile terminated data on IPv6 http://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select-devices-here-is-what-it-all-means-and-yes-no-more-nat/ CB I actually tried to set up a VPN on a LTE data card using the ipv6 address since the IPV4 one is behind carrier grade NAT. I found out the hard way that was a no-go, either. One more tip: IPv6 will work over the legacy 3g network. Don't ask me much about it, but it tunnels it using eHRPD to the same IP/IPv6 headend to enable seamless EVDO/LTE handover. On Thu, Sep 20, 2012 at 6:58 PM, Jared Mauch ja...@puck.nether.net wrote: On Sep 20, 2012, at 8:49 PM, Cameron Byrne cb.li...@gmail.com wrote: On Sep 20, 2012 5:45 PM, Jared Mauch ja...@puck.nether.net wrote: Oh... It works... Your IPv4 address on the public Internet appears to be 70.194.10.15 Your IPv6 address on the public Internet appears to be 2600:1007:b010:a057:d91a:7d40:9871:f1a3 10/11 tests run Cool! That is from an ipad on vzw LTE? Ios6? Yes... Please don't hack or ddos it :-) I'm guessing there will be a lot of new ipv6 traffic from LTE handsets on vzw tomorrow. Should be interesting if apple turned on their Phobos domains for App Store as v6 via akamai. I would expect a lot of traffic to shift then. - Jared
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 2012-09-21 15:31 , Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the same time. When that is not possible, as you ran out of IPv4 addresses, you should look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other such implementations. Depending on your business model you can of course also stick everybody behind a huge NAT or require them to use HTTP proxies to get to the Internet as most people define it... Do note that if you are asking any of these questions today you are years late in reading up and you missed your chance to be prepared for this in all kinds of ways. Greets, Jeroen
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On Sep 21, 2012, at 9:31 AM, Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? This all depends on how your manage your last-mile and terminate users now. I have a friend with a local WISP here and he gives everyone a /24 out of 172.16/12 and dumps them through his load-balancer for his few connections. His CGN box seems to handle this fine. Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? I would say you want to do dual-stack, but shift the users that don't *need* public IPs into 1918 space and deliver v6 native as feasible. If you have a server lan, you can do this with SLAAC, but to get the other information to your hosts, either via RA's and otherwise, it's just becoming easier to do. PPPo* you can get IPv6 IPCP up and going, but the device has to support it. The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. ASR1K and other devices can serve as nat64.. (I think Juniper does the same, but I don't recall their roadmap/product set). I'm sure you can do it with a Linux or *BSD box as well. What is current best practice? I would say there is none as it largely depends on how you terminate that transport, and there are a few ways one can do that. Hope this helps, - Jared
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
The folks that have done the most work in enabling IPv6-only end users seem to be CERNET2 in China. To let people get to v4, they're using what they call IVI (get it?), which is basically NAT64+DNS64. http://tools.ietf.org/html/rfc6219 http://en.wikipedia.org/wiki/NAT64 If you don't mind running IPv4 in a tunnel over that IPv6 network, you can do DSlite or 4rd http://tools.ietf.org/html/rfc6333 http://tools.ietf.org/html/draft-despres-intarea-4rd-01 http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#Dual-Stack_Lite_.28DS-Lite.29 On Friday, September 21, 2012, Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 9/21/12 6:40 AM, Jeroen Massar wrote: On 2012-09-21 15:31 , Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the same time. That's likely to be congruent with the expectations of residential customers but it's not the sole model we've seen, at some point IPv4 backward compatibility plays second fiddle to your ipv6 deployment. the alternatives do get discussed, e.g. http://tools.ietf.org/html/rfc6180 When that is not possible, as you ran out of IPv4 addresses, you should look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other such implementations. Depending on your business model you can of course also stick everybody behind a huge NAT or require them to use HTTP proxies to get to the Internet as most people define it... Do note that if you are asking any of these questions today you are years late in reading up and you missed your chance to be prepared for this in all kinds of ways. Greets, Jeroen
Re: Verizon IPv6 LTE
So I'm back at the office this morning and the iPad is *not* getting an IPv6 address but is showing LTE service. It did do IPv6 over LTE at home so it's not a device problem. So I suppose the closest tower to my office is not IPv6 enabled. Is this an expected behavior in some areas or something that needs fixing? ~Seth
Re: Big Temporary Networks
On Thu, Sep 20, 2012 at 11:54 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Tony Hain wrote: where an IPv6 multicast RA allows all the devices to configure based on reception of a single packet. You miss multicast storm caused by DAD. This is a long solved issue. First, it already occurs with ARP broadcasts which the AP in principle resends out to everybody else on the wlan. Second, in the hotspot scenarios where this is likely to be a problem (in IPv4 -or- IPv6) it's addressed by the AP isolation feature that's getting close to omnipresent even in the low end APs. With this feature enabled, stations are not allowed to talk to each other over the wlan; they can only talk to hosts on the wired side of the lan. The DAD packets are simply never sent to the other stations. In theory there are some problems with this. In practice, it's in wide deployment and has been demonstrated to work just fine. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
TWTC BGP IPv6 /40 prefix
I am trying to add a /40 prefix to be accepted by a couple of TWTC circuits we have in Louisiana (Shreveport and Baton Rouge). My only options available are /32, /48, /56, /64 in the web portal. Is there somebody from TWTC that could contact me off list? Thanks. -bb
Re: The Department of Work and Pensions, UK has an entire /8
On 21/09/2012 00:47, Tony Hain wrote: You are comparing IPv6 to the historical deployment of IPv4. Get with the times and realize that CGN/LSN breaks all those wonderful location-aware apps people are so into now, not to mention raising the cost for operating the network which eventually get charged back to the user. Address translation (already commonplace on many networks) is the consequence of the lack of a scalable addressing model. Yup, NAT breaks lots of things. Piles. It sucks. Nanog in general has a problem taking the myopic viewpoint 'the only thing that matters is the network'. Networking people build and (in some cases) care about networks. It's not the job of nanog people to fret about software development. The real costs are in app development and support It's certainly one of the costs. And application developers have only just begun to realise that they now need to be aware of the network. Previously, they could just open up sockets and fling data around. Now they need to handle protocol failover and multiple connectivity addresses and the like. Yep, it's an extra cost point - one which has been studiously ignored by most ipv6 evangelists over the lifetime of ipv6. That depends on your time horizon and budget cycles. If your org suffers from the short-term focus imposed by Wall Street, Most organisations are in this category, not just those beholden to the whims of Wall Street. If operators would put less effort into blocking transition technologies and channel that energy into deploying real IPv6, the sorry state wouldn't be there. There are never shortages of fingers when failures happen, whether they be used for wagging or pointing. For all the complaints about 6to4, it was never intended to be the mainstay, it was supposed to be the fall back for people that had a lame ISP that was not doing anything about IPv6. 6to4 is full of fail. Inter-as tunnelling is a bad idea. Asymmetric inter-as tunnelling is worse, and asymmetric inter-as tunnelling based on anycast addresses with no hope of tracing blackholes is complete protocol fail. Despite the total failure that it causes the ipv6 world, we couldn't even agree on v6ops@ietf that 6to4 should be recategorised as historical. My facepalm ran over my wtf. But really, 6to4 is a minor player. All the complaining about 6rd-waste is just another case of finding excuses because an ISP-deployed-6to4-router with a longer than /16 announcement into the IPv6 table does a more efficient job, and would not have required new CPE ... Yes that violates a one-liner in an RFC, but changing that would have been an easier fix than an entirely new protocol definition and allocation policy discussion. I'm not understanding the 6rd hate here. Intra-as tunnelling is fine, because the network operator has control over all points along the way. It fixes the problem of having eyeball access devices which don't support v6 properly. Don't hate it - it's useful for some operators, and quite good for deploying v6 over an older infrastructure. So far neither MSFT or AAPL has been willing to push hard on the app development community. This is a generic awareness problem in the developer community and it's not microsoft's or apple's business to tell them what to do about it. Deprecating historic APIs is fine, but you cannot force an application developer to do what they don't want to do. Software didn't get ported from ipx and decnet to ipv4 just because the compiler manufacturers nagged the developers about it. IPv6 will become commonplace when there is a compelling reason for it to do so. History tells us that it won't happen before this point. Nick
Re: the economies of scale of a Worldcon, and how to make this topic relevant to Nanog
- Original Message - From: Jo Rhett jrh...@netconsonance.com Those of us who feel Internet access is mission critical carry LTE network devices or make other arrangements. Obviously the growth of smartphones and tablets is starting to change that equation, but at the moment none of the Worldcons have done a very good job of providing useful online interaction so there's no actual use for onsite data related to the conference itself. Obviously I would love to see this change. And this is pretty much precisely why I'm hammering the nail; there's *lots* of stuff that could -- and properly should -- be technology assisted at the world's largest gathering of science fiction enthusiasts. Now, if we want to make this topic relevant to Nanog, the operative question is the feasability of a data provider putting good wireless gear near these facilities and selling data access to attendees. For a useful comparison, the 2010 Worldcon in Melbourne had an expensive wifi service in the building that kept falling over. A cell provider across the street put up banners advertising cheap data service, and put people on the sidewalk in from of the convention selling pay as you go SIM cards with data service. They made brisk business. *THIS* is where us network operators can provide good networking service to a large facility, and pretty much kill the expensive data plans operated by the facility. Assuming you can get close enough -- which won't be geographically practical for ... oh, wait; you're envisioning 3G, not WLAN. Yeah, I suppose that might work... until you consider that I will, personally, be bringing both laptops, my tablet, and my phone, all of which want to talk to the outside world. I would bet that I'm not all *that* unusual in that, at a Worldcon, based on some attendee conversations I've had at Anticipation and the much less well attended NASfic 10, ReConstruction. A lot of this, too, depends on what the concom negotiated with the property about wifi access already. Instead of building up and tearing down a network for each convention, put an LTE tower near the facility and sell to every group that uses the convention center. Can I get 12000 sessions on a single LTE tower? That's my benchmark for the moment, in the absence of real numbers. :-) Alas, this property has already just rebuilt it's wifi, I'm told. Course, the con is in 2015, so they may rebuild *again* by then. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Real world sflow vs netflow?
On Thu, Sep 20, 2012 at 11:21 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: Most of the platforms I know of do sampled netflow at 1:100-1:1000 or so, and then I don't really see the fundamental difference in doing the flow analysis on the router itself (classic netflow) or doing the same but at the sFlow collector. There is no difference in the flow records you would obtain in either case. However, moving the flow generation out of the router gives a lot of flexibility. You can now choose how you want to generate flows, rather than depend on the router vendor. You are also guaranteed multi-vendor interoperability since problems associated with differences in how each vendor generates flows are eliminated. For a real world example on the need for flexibility in monitoring, consider the challenge posed by IPv6 migration and virtualization as they greatly increase the amount of layer 2, 3 and 4 tunneled traffic. With an external software based flow generation you can easily upgrade the software to report flows within the tunnels etc. http://blog.sflow.com/2012/05/tunnels.html There are many other things you can do with packet oriented (sFlow) data besides flow generation and analysis that I think are worth being aware of: 1. Route analytics. Packet forwarding decisions are made on a packet by packet basis and sFlow accurately captures the forwarding decision made for each sampled packet (flows are not a good way to report forwarding decisions since you are forced to assume that the all packets in the flow took the same forwarding path, which may not be the case). With packet oriented measurements you can build a route cache and use it to understand traffic forwarding based on AS-path, next hop router etc. 2. Analysis of multi-path forwarding. Detailed visibility into per-packet forwarding lets you diagnose issues with unbalanced LAG groups, ECMP paths, TRILL paths etc. 3. Packet sizes. With packet oriented data you can easily calculate packet size distributions by protocol, DSCP class, egress port etc. 4. DDoS detection and mitigation. Analysis of the sampled packet stream can detect DDoS attacks within seconds and an automatic response can be constructed using packet forwarding and header information to find a signature for the attack, point of ingress etc. You can also use packet analyzers like Wireshark and tcpdump to look at the sFlow packet header records, http://blog.sflow.com/2011/11/wireshark.html 5. Packet counters. MIB-2 interface counters are included in the set of measurements that sFlow exports. Eliminating SNMP polling reduces CPU load on the router (I have seen very high router CPU loads associated with SNMP) and provides much faster updates on link utilizations, packet discard rates etc. I think Nick Hilliard put it well: Flows are good for measuring some things; raw packet sampling is good for measuring others. Decide on what you're trying to measure, then pick the best tool for the job. However, to choose intelligently requires an understanding of the fundamental differences between packet oriented and flow oriented measurements, particularly as to how those differences relate to the problem you are trying to solve. The two types of measurement are related, but not the same.
Re: Verizon IPv6 LTE
Quoting Randy Carpenter rcar...@network1.net: Safari is definitely preferring IPv4. In a happier note, if you tether a device via hotspot on an IOS6 iPad, the clients get native IPv6. Strangely, they get addresses out of the same /64 as the iPad's LTE interface. Anyone know how that is working? I would have thought they would use prefix-delegation, and there would be a separate routed /64. I assume they're doing the same thing I am. The cell network interface is just a p2p interface, and the whole /64 is routed to the phone/tablet. You can configure the p2p interface address as a /128 and configure the /64 on the wifi interface. My understanding of the 3gpp specs is that the cell provider won't have an address in that /64, so you won't conflict with anything upstream of the phone/tablet. Here's a screenshot of my (wifi-only) tablet getting v6 while tethered through my phone: http://dan.drown.org/android/clat/IMG_20120425_105124.jpg
RE: The Department of Work and Pensions, UK has an entire /8
-Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Friday, September 21, 2012 9:13 AM To: Tony Hain Cc: nanog@nanog.org Subject: Re: The Department of Work and Pensions, UK has an entire /8 On 21/09/2012 00:47, Tony Hain wrote: You are comparing IPv6 to the historical deployment of IPv4. Get with the times and realize that CGN/LSN breaks all those wonderful location-aware apps people are so into now, not to mention raising the cost for operating the network which eventually get charged back to the user. Address translation (already commonplace on many networks) is the consequence of the lack of a scalable addressing model. Yup, NAT breaks lots of things. Piles. It sucks. Nanog in general has a problem taking the myopic viewpoint 'the only thing that matters is the network'. Networking people build and (in some cases) care about networks. It's not the job of nanog people to fret about software development. The real costs are in app development and support It's certainly one of the costs. And application developers have only just begun to realise that they now need to be aware of the network. Previously, they could just open up sockets and fling data around. Now they need to handle protocol failover and multiple connectivity addresses and the like. Yep, it's an extra cost point - one which has been studiously ignored by most ipv6 evangelists over the lifetime of ipv6. App developers have never wanted to be aware of the network. As far as they are concerned it is the network managers job to get bits from the endpoint they are on to the endpoint they want to get to. Making them do contortions to figure out that they need to, and then how to, tell the network to do that adds complexity to their development and support. This is not an IPv6 issue, it is historic reality. The only place IPv6 gets involved is that it offers a way back to the transparent end-to-end consistent addressing model. The actual path may have firewalls which prevent communication, but that happens on both versions and has nothing to do with the simplicity of a consistent addressing model. That depends on your time horizon and budget cycles. If your org suffers from the short-term focus imposed by Wall Street, Most organisations are in this category, not just those beholden to the whims of Wall Street. If operators would put less effort into blocking transition technologies and channel that energy into deploying real IPv6, the sorry state wouldn't be there. There are never shortages of fingers when failures happen, whether they be used for wagging or pointing. For all the complaints about 6to4, it was never intended to be the mainstay, it was supposed to be the fall back for people that had a lame ISP that was not doing anything about IPv6. 6to4 is full of fail. Inter-as tunnelling is a bad idea. And something that is easy to fix by simply deploying a 6to4 relay in each AS and announcing the correct IPv6 prefix set to make it symmetric. Asymmetric inter-as tunnelling is worse, and asymmetric inter-as tunnelling based on anycast addresses with no hope of tracing blackholes is complete protocol fail. Despite the total failure that it causes the ipv6 world, we couldn't even agree on v6ops@ietf that 6to4 should be recategorised as historical. My facepalm ran over my wtf. But really, 6to4 is a minor player. All the complaining about 6rd-waste is just another case of finding excuses because an ISP-deployed-6to4-router with a longer than /16 announcement into the IPv6 table does a more efficient job, and would not have required new CPE ... Yes that violates a one-liner in an RFC, but changing that would have been an easier fix than an entirely new protocol definition and allocation policy discussion. I'm not understanding the 6rd hate here. Intra-as tunnelling is fine, because the network operator has control over all points along the way. It fixes the problem of having eyeball access devices which don't support v6 properly. Don't hate it - it's useful for some operators, and quite good for deploying v6 over an older infrastructure. There is no 6rd hate here. I personally spent many hours helping Remi tune up the original doc and get in into the IETF process. My point was that we didn't need to go through that entire process and have extended policy discussions about what size prefix each org needs when they are deploying 6rd. At the end of the day, a 6to4 relay at every point that has a 6rd router does exactly the same thing at the tunneling level (except that 6to4 always results in a /48 for the customer). It may have resulted in more prefixes being announced into the IPv6 table, but given the ongoing proliferation of intentional deaggretation for traffic engineering, there may eventually be just as many IPv6 prefixes announced with 6rd. So far neither MSFT or AAPL has been willing to
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, LacNOG, TRNOG, 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 22 Sep, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 427480 Prefixes after maximum aggregation: 178522 Deaggregation factor: 2.39 Unique aggregates announced to Internet: 208854 Total ASes present in the Internet Routing Table: 42150 Prefixes per ASN: 10.14 Origin-only ASes present in the Internet Routing Table: 33623 Origin ASes announcing only one prefix: 15762 Transit ASes present in the Internet Routing Table:5619 Transit-only ASes present in the Internet Routing Table:136 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 32 Max AS path prepend of ASN ( 48687) 24 Prefixes from unregistered ASNs in the Routing Table: 736 Unregistered ASNs in the Routing Table: 268 Number of 32-bit ASNs allocated by the RIRs: 3307 Number of 32-bit ASNs visible in the Routing Table:2908 Prefixes from 32-bit ASNs in the Routing Table:7789 Special use prefixes present in the Routing Table:9 Prefixes being announced from unallocated address space:170 Number of addresses announced to Internet: 2597807124 Equivalent to 154 /8s, 215 /16s and 100 /24s Percentage of available address space announced: 70.2 Percentage of allocated address space announced: 70.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.7 Total number of prefixes smaller than registry allocations: 150657 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 102817 Total APNIC prefixes after maximum aggregation: 32533 APNIC Deaggregation factor:3.16 Prefixes being announced from the APNIC address blocks: 103474 Unique aggregates announced from the APNIC address blocks:42726 APNIC Region origin ASes present in the Internet Routing Table:4760 APNIC Prefixes per ASN: 21.74 APNIC Region origin ASes announcing only one prefix: 1238 APNIC Region transit ASes present in the Internet Routing Table:768 Average APNIC Region AS path length visible:4.7 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table:316 Number of APNIC addresses announced to Internet: 708467008 Equivalent to 42 /8s, 58 /16s and 89 /24s Percentage of available APNIC address space announced: 82.8 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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:154454 Total ARIN prefixes after maximum aggregation:78148 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 155396 Unique aggregates announced from the ARIN address blocks: 69131 ARIN Region origin ASes present in the Internet Routing Table:15249 ARIN Prefixes per ASN:10.19 ARIN Region origin ASes
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 9/21/12 9:40 AM, Jeroen Massar wrote: On 2012-09-21 15:31 , Mark Radabaugh wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? The IETF BCP is to deploy Dual Stack, thus both IPv4 and IPv6 at the same time. When that is not possible, as you ran out of IPv4 addresses, you should look at Dual Stack Lite (DS Lite) eg as supplied by ISC's AFTR and other such implementations. Depending on your business model you can of course also stick everybody behind a huge NAT or require them to use HTTP proxies to get to the Internet as most people define it... Do note that if you are asking any of these questions today you are years late in reading up and you missed your chance to be prepared for this in all kinds of ways. Greets, Jeroen We can already do dual stack - that's not really a problem. I was really rather hoping to avoid the giant NAT box. I'll take a look at DS Lite and or NAT64/DNS64 and see if that makes any sense. Dual stack isn't all that hard to deploy in the enterprise, perhaps even IPv6 only with NAT for backward compatibility. Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. I don't think saying we missed the boat really applies - and the consumer CPE ship is sinking at the dock. -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
http://www.isc.org/software/aftr
-- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: http://www.isc.org/software/aftr
On Fri, Sep 21, 2012 at 3:48 PM, Mark Radabaugh m...@amplex.net wrote: I see your url and raise you a youtube video ... http://youtu.be/bqi-_d4C5xg
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
Op 21-9-2012 21:42, Mark Radabaugh schreef: Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. I don't think saying we missed the boat really applies - and the consumer CPE ship is sinking at the dock. Enable dual stack per default, the old routers ignore it anyhow. The new ones that do support it, and really, Linksys and D-Link as well as Netgear do support it now will use it and should just work. I recommend DHCP-PD, it seems to work well with relatively low overhead. AVM seems to know just how to make these relatively cheap all-in-ones with a great feature set and reasonable quality. There is a lot of room for improvement, there always have been. It's not like the original Linksys WRT54G was really _that_ good, was it? The other good news is that there is a new Wifi standard! You'll see a new surge of people swapping out 30$ routers because they are convinced that the new 30$ router will be a lot better then the previous one. Maybe it is. I know it's a chicken and egg problem, and shoving it out further means you just decided for the ISP that you need a far beefier CGN box in the future. I am not totally convinced that was your long term plan. Most ISPs in asia that are now pouring significant monetary resources into a CGN box that might be almost pointless in 5 years is not the investment they were looking for.
Re: the economies of scale of a Worldcon, and how to make this topic relevant to Nanog
On Sep 21, 2012, at 10:00 AM, Jay Ashworth wrote: And this is pretty much precisely why I'm hammering the nail; there's *lots* of stuff that could -- and properly should -- be technology assisted at the world's largest gathering of science fiction enthusiasts. No point in building fast access to nothing (related to the con) ;-) I'm not saying that's right, but it is what is. And don't forget that right now hard SF is a pretty mean minority. The vast majority of sci-fi fans are into steampunk and other alt history these days. (and don't get me started about that) iPhones are not generally strapped to their victorian outfits. Assuming you can get close enough -- which won't be geographically practical for ... oh, wait; you're envisioning 3G, not WLAN. Yeah, I suppose that might work... until you consider that I will, personally, be bringing both laptops, my tablet, and my phone, all of which want All of which can use LTE either natively or with a dongle. to talk to the outside world. I would bet that I'm not all *that* unusual in that, at a Worldcon, based on some attendee conversations I've had at Anticipation and the much less well attended NASfic 10, ReConstruction. You aren't unusual, but you aren't the average by a long shot. A lot of this, too, depends on what the concom negotiated with the property about wifi access already. And this is where you're going to hit some very hard walls. One of which I forgot to mention. Many of the hotels (I believe all Hilton properties at this time) have sold the facilities space for their wifi network to another company. They CAN'T negotiate it with you, because they don't own it any more. And most of these wifi networks have stealth killers enabled, so that they spoof any other wifi zone they see and send back reject messages to the clients. So you can't run them side by side. Try having a conversation with the hotel rep in charge of selling convention space about these kind of technical bits about wifi networks sometime. If you don't mind tearing your hair out at the time. Or tearing it out later, after you've been assured that the hotel will make it all work and then find that none of this equipment is within their control. (they don't care, you're already there and can't go anywhere else) Sorry I'm being so negative on this topic. Got more than a few burnt fingers on this one :) Can I get 12000 sessions on a single LTE tower? Yes. Can you get 12000 sessions through any single POE gateway? ;-) -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.
Re: The Department of Work and Pensions, UK has an entire /8
On 20-Sep-12 20:51, George Herbert wrote: On Thu, Sep 20, 2012 at 5:13 PM, Stephen Sprunk step...@sprunk.org wrote: Actually, they're not any different, aside from scale. Some private internets have hundreds to thousands of participants, and they often use obscure protocols on obscure systems that were killed off by their vendors (if the vendors even exist anymore) a decade or more ago, and no source code or upgrade path is available. The enterprise networking world is just as ugly as, if not uglier than, the consumer one. I haven't worked much on the commercial private internets, but I did work for someone who connected on the back end into numerous telco cellphone IP data networks. For all of those who argue that these applications should use 1918 space, I give you those networks, where at one point I counted literally 8 different 10.200.x/16 nets I could talk to at different partners (scarily enough, 2 of those were the same company...). And hundreds and hundreds of other space conflicts. That's all? I consulted for one customer that had several (six? eight?) instances of 10/8 within their own enterprise, simply because they needed that many addresses. That doesn't include the dozens of legacy /16s they used in their data centers--plus the hundreds of legacy /24s they used in double-sided NAT configurations between them and various business partners, COINs, etc. Yet all that was exposed to the consumer internet was a couple of /24s for their web servers, email servers and VPN concentrators. Yes, you can NAT all of that, but if you get network issues where you need to know the phone end address and do end to end debugging on stuff, there are no curse words strong enough in the English language. That's the truth. To get from a credit card terminal to the bank involved _at least_ three layers of NAT on our side, and I don't know how many layers of NAT there were in total on the bank's side, but it was at least two. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On Fri, 21 Sep 2012 15:42:20 -0400, Mark Radabaugh said: Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. You *do* realize that the reason my site runs like 60% IPv6 traffic *now* is because we spend the resources 5 and 10 years ago getting ready for when Microsoft and Apple shipped stuff that worked for the end user, right? Of course, if you want to wait to get *started* on the deployment curve until everybody's replaced their stuff, that's fine by me. But I'd double-check if you have any competitors that have an earlier schedule. pgpWeTzEVALKZ.pgp Description: PGP signature
Re: The Department of Work and Pensions, UK has an entire /8
On 21/09/2012 19:23, Tony Hain wrote: App developers have never wanted to be aware of the network. By not sitting down and thinking about the user experience of a dual-stacked network, we have now forced them to be aware of the network and that's not a good thing because they are as clued out about networking as most network operators are about programming. If we had designed a portable and consistent happy-eyeballs API 10 years ago, it would be widely available for use now. But we didn't do that because we were thinking about the network rather than the users. So now, each dual stack developer is going to have to sit down and reimplement happy eyeballs for themselves. What a waste. As far as they are concerned it is the network managers job to get bits from the endpoint they are on to the endpoint they want to get to. Making them do contortions to figure out that they need to, and then how to, tell the network to do that adds complexity to their development and support. This is not an IPv6 issue, it is historic reality. No, it's a current reality for early venturers into ipv6. It may become a future reality in the mainstream if ipv6 takes off in a way that I can't foresee at the moment. One day in the future, maybe, it will become less of an issue if people go back to a single-stack endpoint system. And something that is easy to fix by simply deploying a 6to4 relay in each AS and announcing the correct IPv6 prefix set to make it symmetric. In theory yes. In practice no. event. Those that are doing so intentionally, while providing the long term path in parallel, can be described as weaning their customers off the legacy. Those that are doing so inadvertently, because they don't care about anything but their tiny part of the overall system, will lose customers to the provider offering the long term path. So long as the cost of that is less than the cost of deploying ipv6 and pushing people in that direction, it's a good business plan in the short term. Which is what most people care about. I'm with you that it's a hopeless long term business plan, but that's not the world we live in. Nick
The Cidr Report
This report has been generated at Fri Sep 21 21:13:04 2012 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 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
14-09-12429020 246442
15-09-12429325 246777
16-09-12429508 246698
17-09-12429346 246899
18-09-12429763 247243
19-09-12430009 247144
20-09-12429920 247029
21-09-12430248 247406
AS Summary
42264 Number of ASes in routing system
17619 Number of ASes announcing only one prefix
3311 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
113672416 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
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').
--- 21Sep12 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 430328 247263 18306542.5% All ASes
AS6389 3311 191 312094.2% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS28573 2136 57 207997.3% NET Servicos de Comunicao S.A.
AS4766 2982 941 204168.4% KIXS-AS-KR Korea Telecom
AS22773 1884 141 174392.5% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS17974 2356 616 174073.9% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS7029 3164 1485 167953.1% WINDSTREAM - Windstream
Communications Inc
AS18566 2084 423 166179.7% COVAD - Covad Communications
Co.
AS2118 1399 14 138599.0% RELCOM-AS OOO NPO Relcom
AS10620 2164 801 136363.0% Telmex Colombia S.A.
AS4323 1579 392 118775.2% TWTC - tw telecom holdings,
inc.
AS7303 1559 447 111271.3% Telecom Argentina S.A.
AS1785 1919 828 109156.9% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4755 1620 547 107366.2% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS7552 1136 205 93182.0% VIETEL-AS-AP Vietel
Corporation
AS8151 1594 704 89055.8% Uninet S.A. de C.V.
AS18101 1015 172 84383.1% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS4808 1119 350 76968.7% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS13977 859 120 73986.0% CTELCO - FAIRPOINT
COMMUNICATIONS, INC.
AS15557 1229 563 66654.2% LDCOMNET Societe Francaise du
Radiotelephone S.A
AS6458 680 42 63893.8% Telgua
AS855685 52 63392.4% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS3356 1107 478 62956.8% LEVEL3 Level 3 Communications
AS17676 711 86 62587.9% GIGAINFRA Softbank BB Corp.
AS36998 772 148 62480.8% SDN-MOBITEL
AS22561 1039 435 60458.1% DIGITAL-TELEPORT - Digital
Teleport Inc.
AS19262 1002 404 59859.7% VZGNI-TRANSIT - Verizon Online
LLC
AS24560 1041 447 59457.1% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS3549 1009 437 57256.7% GBLX Global Crossing Ltd.
AS30036 1379 819 56040.6% MEDIACOM-ENTERPRISE-BUSINESS -
Mediacom Communications Corp
AS4804 643 97 54684.9% MPX-AS Microplex PTY LTD
Total 45177124423273572.5% Top 30 total
BGP Update Report
BGP Update Report Interval: 13-Sep-12 -to- 20-Sep-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS840250791 1.7% 24.9 -- CORBINA-AS OJSC Vimpelcom 2 - AS982936316 1.2% 27.2 -- BSNL-NIB National Internet Backbone 3 - AS22561 29726 1.0% 27.8 -- DIGITAL-TELEPORT - Digital Teleport Inc. 4 - AS24560 28930 1.0% 27.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 5 - AS27947 28720 0.9% 37.7 -- Telconet S.A 6 - AS10620 22031 0.7% 10.2 -- Telmex Colombia S.A. 7 - AS13118 20062 0.7% 418.0 -- ASN-YARTELECOM OJSC Rostelecom 8 - AS755218689 0.6% 16.3 -- VIETEL-AS-AP Vietel Corporation 9 - AS638917986 0.6% 5.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 10 - AS27738 15727 0.5% 28.2 -- Ecuadortelecom S.A. 11 - AS28573 15693 0.5% 7.2 -- NET Servicos de Comunicao S.A. 12 - AS17974 15024 0.5% 6.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 13 - AS702914898 0.5% 4.6 -- WINDSTREAM - Windstream Communications Inc 14 - AS211812565 0.4% 9.0 -- RELCOM-AS OOO NPO Relcom 15 - AS45595 12535 0.4% 25.0 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 16 - AS754512508 0.4% 7.1 -- TPG-INTERNET-AP TPG Internet Pty Ltd 17 - AS21599 12065 0.4% 67.8 -- NETDIRECT S.A. 18 - AS25620 11640 0.4% 55.4 -- COTAS LTDA. 19 - AS815111619 0.4% 7.3 -- Uninet S.A. de C.V. 20 - AS163711601 0.4% 59.5 -- DNIC-AS-01637 - Headquarters, USAISC TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS44410 10148 0.3%3382.7 -- ENTEKHAB-AS ENTEKHAB INDUSTRIAL GROUP 2 - AS150533188 0.1%3188.0 -- ROLL-GLOBAL-LLC - Roll Global LLC 3 - AS146807488 0.2%2496.0 -- REALE-6 - Auction.com 4 - AS417337040 0.2%1005.7 -- ZTELECOM-AS JSC Z-Telecom 5 - AS48696 962 0.0% 962.0 -- TEMP-AS TEMP Ltd. 6 - AS29126 792 0.0% 792.0 -- DATIQ-AS Datiq B.V. 7 - AS38142 10593 0.3% 662.1 -- UNAIR-AS-ID Universitas Airlangga 8 - AS388571117 0.0% 558.5 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 9 - AS57201 550 0.0% 550.0 -- EDF-AS Estonian Defence Forces 10 - AS25911 502 0.0% 502.0 -- TALISMAN-CH3 - TALISMAN ENERGY INC. 11 - AS29398 449 0.0% 449.0 -- PETROBALTIC Petrobaltic S.A. 12 - AS532055338 0.2% 444.8 -- 13 - AS238614865 0.2% 442.3 -- ETRADING-AS-ID-AP PT eTrading Securities 14 - AS9223 426 0.0% 426.0 -- INDUS-TOWERS Spreaded across 35 locations in india 15 - AS13118 20062 0.7% 418.0 -- ASN-YARTELECOM OJSC Rostelecom 16 - AS32529 405 0.0% 405.0 -- CGI-FEDERAL-ASN-1 - CGI Federal 17 - AS21023 405 0.0% 405.0 -- UPB-AS Joint Stock Company Ural Industrial Bank 18 - AS2 385 0.0% 637.0 -- BIORAD-AP 1000 Alfred Nobel Drive US 19 - AS52118 373 0.0% 373.0 -- GU-YAO-AS GU YaO Yaroslavl Centre for Telecommunications and Information Technologies in Education 20 - AS36948 737 0.0% 368.5 -- KENIC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 19841 0.6% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 184.159.130.0/23 12486 0.3% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 3 - 184.157.224.0/19 10562 0.3% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 4 - 200.46.0.0/19 10207 0.3% AS21599 -- NETDIRECT S.A. 5 - 202.41.70.0/24 7856 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 6 - 122.161.0.0/16 7475 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 7 - 5.16.0.0/167010 0.2% AS41733 -- ZTELECOM-AS JSC Z-Telecom 8 - 190.60.31.0/24 6676 0.2% AS18747 -- IFX-NW - IFX Communication Ventures, Inc. 9 - 202.56.215.0/246509 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 10 - 182.64.0.0/16 6419 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 11 - 12.139.133.0/246028 0.2% AS14680 -- REALE-6 - Auction.com 12 - 166.137.184.0/22 5566 0.2% AS20057 -- ATT Wireless Service 13 - 78.111.6.0/24 5539 0.1% AS44410 -- ENTEKHAB-AS ENTEKHAB INDUSTRIAL GROUP AS48159 -- TIC-AS Telecommunication Infrastructure Company 14 - 49.248.72.0/21 5083 0.1% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 15 - 192.58.2.0/24
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. Note: Some of us regular, residential customers can and do have native IPv6 at home ... off the shelf gear, default configs, etc.
Re: Big Temporary Networks
William Herrin wrote: You miss multicast storm caused by DAD. Second, in the hotspot scenarios where this is likely to be a problem (in IPv4 -or- IPv6) it's addressed by the AP isolation feature As you stated : I think Masataka meant to say (and said previously) that the DHCP : request from the wifi station is, like all packets from the wifi : station to the AP, subject to wifi's layer 2 error recovery. that is not a problem for IPv4 ARP and DHCP. that's getting close to omnipresent even in the low end APs. With this feature enabled, stations are not allowed to talk to each other over the wlan; they can only talk to hosts on the wired side of the lan. The DAD packets are simply never sent to the other stations. You are saying to disable DAD, which is a violation of SLAAC. In theory there are some problems with this. In practice, it's in wide deployment and has been demonstrated to work just fine. Tell it to IETF to modify SLAAC to exclude DAD. Masataka Ohta
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On Fri, 21 Sep 2012 19:22:18 -0400, TJ said: Running dual stack to residential consumers still has huge issues with CPE. It's not an environment where we have control over the router the customer picks up at Walmart. There is really very little point in spending a lot of resources on something the consumer can't currently use. Note: Some of us regular, residential customers can and do have native IPv6 at home ... off the shelf gear, default configs, etc. But you have to admit it works a lot better if you're a customer of an ISP that isn't waiting to spend the resources... :) pgpUScnDkORu5.pgp Description: PGP signature
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
Dhcpv6, radius .. take your pick --srs (htc one x) On Sep 21, 2012 7:04 PM, Mark Radabaugh m...@amplex.net wrote: The part of IPv6 that I am unclear on and have not found much documentation on is how to run IPv6 only to end users. Anyone care to point me in the right direction? Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? The Interwebs are full of advice on setting up IPv6 tunnels for your house (nice but...). There is lots of really old documentation out there for IPv6 mechanisms that are depreciated or didn't fly. What is current best practice? -- Mark Radabaugh Amplex m...@amplex.net 419.837.5015
Re: Throw me a IPv6 bone (sort of was IPv6 ignorance)
On 22/09/2012, at 12:04 AM, Jared Mauch ja...@puck.nether.net wrote: Can we assign IPv6 only to end users? What software/equipment do we need in place as a ISP to ensure these customers can reach IPv4 only hosts? I would say you want to do dual-stack, but shift the users that don't *need* public IPs into 1918 space and deliver v6 native as feasible. If you have a server lan, you can do this with SLAAC, but to get the other information to your hosts, either via RA's and otherwise, it's just becoming easier to do No. Use RFC 6598 space which was allocated for this purpose. Mark
Re: Real world sflow vs netflow?
On Sep 22, 2012, at 12:40 AM, Peter Phaal wrote: However, moving the flow generation out of the router gives a lot of flexibility. Actually, moving it out of the router creates huge problems and destroys a lot of the value of the flow telemetry - it nullifies your ability to traceback where traffic is ingressing your network, which is key for both security as well as traffic engineering, peering analysis, etc. It is far, far better to get your flow telemetry from your various edge routers, if at all possible, rather that probes. Scales better, too - and is less expensive in terms of both capex and opex. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
