The bits of this question that aren't around tooling are well answered in this question that @MichaelT already pointed to.
Agile is opposed to over-planning
As far as tooling to support long-range planning, though, the key point is that Agile recognizes that business conditions always change, and that long-range plans rarely make it to the end without significant change. Most organizations overplan, and waste huge amounts of time planning in great detail what will happen six months out, only to replan in three months, and in five months, etc.
Keep long-range plans high-level
Of course you have to do some long-range planning in any significant project, but the key is that because you will be replanning anyway, you should keep your plans high-level. Don't waste time making pointless estimates by the hour of what you are going to be doing in six months. Managers love to do this because it makes them feel in control, but it is an illusion. Unfortunately, many traditional project management tools lead you into doing exactly this.
In the idea case with Agile, you don't have a "deadline". You have a list of stuff you are going to do, and you release every sprint. The software is "done" when you get to the point where stakeholders say it is done. Your plan is the backlog. That's the list of the things you currently expect to do in the order you expect to do them in. Planning is just writing stories, and organizing them in your backlog. No extra tools are needed.
Of course, realistically, you are not working in this fantasy land as normally the suits want to know when it will be done. (Or worse, are telling you when it must be done.) Realistically, some sprint results are pointless to release while others are vital. Realistically, you will have other teams that need some of your stories finished before their stories can start.
In these cases, you will probably have to create a list of future sprints, and slot stories in each sprint, so you have a rough idea when you'll "finish".
The key: That is all you should do. Anything else is overplanning.
Given that, the results of your planning is just a list of sprints, with a bulleted list of stories for each sprint. That's it. Any tool that supports bulleted lists and tables will do. You could use Word. You could user PowerPoint. You could use Sharepoint. You could use Mediawiki. (My team uses Confluence.) You could even use a whiteboard with lines per sprint and sticky notes. (I've seen successful teams at my company do exactly that.)
Just don't do waterfall planning (and use waterfall planning tools), label milestones "sprints", have a daily scrum and pretend you are doing Agile.