IPv4 cleanup

From Nsnam
Jump to: navigation, search

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers

This page lists things that need to be done for IPv4 and routing protocols.

API issues

  1. Public API needed to look at or manipulate the ARP cache
    • Proposal: Defer to ns-3.6 or later
  2. Ipv4StaticRouting: split into unicast and multicast separate objects? Or just remove Impl class?
  3. No way to remove an IP address from an interface
    • Proposal: Fix this for ns-3.5. bugfix patch is in tracker.
  4. Ipv4RoutingProtocol::RouteOutput() may require Ptr<Packet> for supporting Nix vector routing (and perhaps other use cases)
    • Proposal: Fix this for ns-3.5.
  5. Ipv4StaticRouting multicast mrouted API does not support VIFs and TTLs
  6. GlobalRouteManager static API could be moved to a helper API
    • Proposal: ?? how to deal with API breakage
  7. Tunneling net device (Ipv4 in ipv4) will require a public entry point into Ipv4 so that packets can be looped back through
    • Proposal: Defer class Ipv4's API extension until we have working example
  8. Ipv4RoutingHelper API could be created and delegated the task of creating routing protocols, and passed into InternetStackHelper
  9. Multicast API for hosts (setting group membership, setting TTL, setting loopback behavior) needs to be completed
    • Proposal: Defer to ns-3.6 or later.

Bugs and cleanup

  • IpForward attribute (ipv4.cc) doesn't do anything (bug 63)
  • Ipv4L3Protocol needs a unit test or a module test <- this has been started
  • some XXXs remain around the multi-address (ip aliasing) code
    • Ipv4L3Protocol::LocalDeliver
    • IPv4L3Protocol::IpForward
    • ArpL3Protocol::Receive
    • ArpL3Protocol::SendArpRequest
    • ArpL3Protocol::SendArpReply
    • Ipv4StaticRoutingImpl::LookupStatic
    • Ipv4EndPointDemux::Lookup
  • case 4) of Ipv4L3Protocol::Send() is not implemented, but this case is for currently non-existent on-demand ad-hoc routing protocol
    • n.b. this may be an invalid case anyway
  • should some of the routing protocol interfaces be aggregated to node, or to Ipv4ListRouting? Not clear.
  • TcpL4Protocol::Send () probably needs to be passed a route from TcpSocketImpl() instead of looking up the route again
  • Ipv4StaticRoutingImpl is not robust enough to be added as a standalone routing protocol (e.g. for hosts and not routers, to perform local delivery).

New features needed

  • Multicast
    • add VIF (virtual interface) and better TTL handling logic, for multicast forwarding
    • for multicast hosts, the API for group membership, TTL, loopback (multicast sockets)
  • Ability to dump routing tables for logging/output
  • helpers to provide iproute2-like interface