Esto sería práctico por un número de razones: Haría que Tor fuera más capaz de manejar nuevos protocolos, como VoIP. Resolvería la necesidad completa de socksificar las aplicaciones. Salir de repetidores además no necesitaría asignar muchos de descriptores de archivo para todas las conexiones de salida.

Nos estamos encaminando en esta dirección. Algunos de los problemas más tenaces son:

1. Los paquetes IP revelan características del SO. Aún necesitaríamos hacer normalización de paquetes a nivel de IP, para detener cosas como ataques de huella digital TCP. Dada la diversidad y complejidad de los stacks TCP, junto con los ataques de huella digital de dispositivo, parece como que nuestra mejor apuesta es hacer un paquete con nuestro propio stack TCP de espacio de usuario.
2. Los streams a nivel de aplicación aún necesitan un restregado. Aún necesitaremos aplicaciones del lado de usuario, como Torbutton. Por lo que no se convertirá solo en un asunto de capturar paquetes y anonimizarlos en la capa IP.
3. Ciertos protocolos aún filtrarán información. Por ejemplo, debemos reescribir las solicitudes DNS de manera que sean entregadas a un servidor DNS no vinculable, en vez de al servidor DNS en el ISP del usuario; por lo tanto, debemos entender los protocolos que estamos transportando.
4. DTLS (TLS en datagramas) básicamente no tiene usuarios, y seguro que IPsec es grande. Una vez que hayamos elegido un mecanismo de transporte, necesitamos diseñar un nuevo protocolo Tor de extremo a extremo, para evitar ataques de etiquetado y otras dificultades potenciales con el anonimato y la integridad, ahora que permitimos caídas, reenvíos, etcétera.
5. Las políticas de salida para paquetes IP arbitrarios significan construir un Sistema de Detección de Intrusión (SDI) seguro. Nuestros operadores de nodos nos dicen que las políticas de salida son una de las razones principales por las que están dispuestos a correr Tor. Agregar un SDI para manejar políticas de salida incrementaría la complejidad de seguridad de Tor, y de cualquier manera probablemente no funcionaría, como es evidenciado por el campo entero de boletines de SDI y contra SDI. Muchas dificultades potenciales de abuso son resueltas por el hecho de que Tor solamente transporta streams TCP válidos (en oposición a IP arbitrario, incluyendo paquetes malformados e inundaciones IP.) Las normativas de salida se vuelven aún más importantes en la medida en que somos capaces de transportar paquetes IP. También necesitamos describir compactamente las políticas de salida en el directorio Tor, de manera que los clientes puedan predecir cuáles nodos les permitirán salir a sus paquetes. ¡Los clientes también necesitan predecir todos los paquetes que querrán enviar en una sesión antes de elegir su nodo de salida!
6. Los espacios de nombres internos de Tor necesitarían ser rediseñados. Soportamos las direcciones ".onion" del servicio cebolla mediante la intercepción de las direcciones cuando son pasadas al cliente Tor. Hacer eso al nivel IP requerirá una interfaz más compleja entre Tor y el resolvedor DNS local.