Це було б зручно з кількох причин: Це дозволить Tor краще працювати з новими протоколами, такими як VoIP. Це могло б вирішити всю потребу в синхронізації сокетів застосунків. Вихідним реле також не потрібно було б виділяти багато файлових дескрипторів для всіх вихідних з'єднань.

Ми рухаємося в цьому напрямку. Деякі зі складних проблем:

1. IP-пакети розкривають характеристики ОС. Нам все одно потрібно буде виконати нормалізацію пакетів на рівні IP, щоб зупинити такі речі як атаки з використанням відбитків TCP. Враховуючи різноманітність і складність стеків TCP, а також атаки з використанням цифрових відбитків на пристроях, схоже, що найкращий вибір — це постачання власного стека TCP для користувацького простору.
2. Потоки на рівні програми все ще потребують очищення. Нам все одно знадобляться програми на стороні користувача, такі як Torbutton. Тому це не стане лише питанням захоплення пакетів та їх анонімізації на рівні IP.
3. Деякі протоколи все одно мають витік інформації. Наприклад, ми повинні переписати запити DNS, щоб вони доставлялися на не зв'язаний DNS-сервер, а не на DNS-сервер у постачальника послуг інтернету користувачу; таким чином, ми повинні розуміти протоколи, які ми транспортуємо.
4. DTLS (Датаграма TLS) здебільшого не має користувачів, а IPsec безсумнівно великий. Після того, як ми виберемо механізм транспортування, нам потрібно розробити новий наскрізний протокол Tor, щоб уникнути атак за типом привласнення міток та інших потенційних проблем з анонімністю та цілісністю оскільки відтепер ми дозволяємо скидання, повторне надсилання тощо.
5. Політика виходу для довільних IP-пакетів означає створення захищеної системи виявлення вторгнень (СВВ). Наші оператори вузлів кажуть нам, що політики вихідного трафіку є однією з головних причин, чому вони хочуть запустити Tor. Додавання СВВ для обробки політик виходу підвищить складність безпеки Tor і, швидше за все, не спрацює, про що свідчить увесь масив документів про СВВ та протидію СВВ. Багато потенційних проблем зловживання усуваються завдяки тому, що Tor транспортує лише дійсні потоки TCP (на відміну від довільного IP, включаючи неправильно сформовані пакети та IP-флуд.) Політики виходу стають ще важливішими, оскільки ми отримуємо можливість транспортувати IP-пакети. Нам також потрібно стисло описати політики виходу в каталозі Tor, щоб клієнти могли передбачити, які вузли дозволять вихід їхнім пакетам. Клієнти також мають передбачити всі пакети, які вони хочуть надіслати під час сеансу, перш ніж вибрати свій вихідний вузол!
6. Внутрішній простір імен Tor потрібно буде переробити. Ми підтримуємо адреси сервісу «.onion», перехоплюючи їх, коли вони передаються клієнту Tor. Для цього на рівні IP буде потрібний складніший інтерфейс між Tor і локальним DNS інтерпретатором.