Difference between revisions of "IPv4 cleanup"

Revision as of 04:00, 15 June 2009

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

Public API needed to look at or manipulate the ARP cache
- Proposal: Defer to ns-3.6 or later
Ipv4StaticRouting: split into unicast and multicast separate objects?
- Another issue is whether this abstract base class is sufficient to implement Netlink-based unicast routing (or how it will be extended in the future): http://qos.ittc.ku.edu/netlink/html/node9.html
No way to remove an IP address from an interface
- Proposal: Fix this for ns-3.5. bugfix patch is in tracker.
Ipv4RoutingProtocol::RouteOutput() may require Ptr<Packet> for supporting Nix vector routing (and perhaps other use cases)
- Proposal: Fix this for ns-3.5.
Ipv4StaticRouting multicast mrouted API does not support VIFs and TTLs
- For reference, see http://tldp.org/HOWTO/Multicast-HOWTO-7.html, MRT_ADD_MFC, MRT_DEL_MFC
- Proposal: Defer to ns-3.6 or later
GlobalRouteManager static API could be moved to a helper API
- Proposal: ?? how to deal with API breakage
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

IpForward attribute (ipv4.cc) doesn't do anything (bug 63)
Ipv4L3Protocol needs a unit test or a module test
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
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).

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

@@ Line 24: / Line 24: @@
 * IpForward attribute (ipv4.cc) doesn't do anything (bug 63)
-* in general, Ipv4L3Protocol needs a lot of cleanup, and bugs/limitations documented in the tracker
+* Ipv4L3Protocol needs a unit test or a module test
-* Ipv4L3Protocol needs a unit test
 * some XXXs remain around the multi-address (ip aliasing) code
-* case 4) of Ipv4L3Protocol::Send() is not implemented
+** Ipv4L3Protocol::LocalDeliver
-* should some of the routing protocol interfaces be aggregated to node?  Not clear.
+** 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
+* 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 ==