[Ns-developers] Design Review of ns-3-ipv6-1st (ns-3.3 newfeature)

craigdo@ee.washington.edu craigdo at ee.washington.edu
Fri Oct 10 12:26:13 PDT 2008


> At this point, my main concern is that I would like to know what the
> plan is to deal with the ipv4 API rework under way in tom's 
> tree.

I agree completely.  I just spoke to Tom about this.  We agree that the approach to take is to have Tom "adopt" Sebastien's changes
and merge them into his IPv4 work.  This will ensure that the two feature sets work together consistently, and will allow reviewing
them as one consistent whole (which makes reviewer's lives easier).

Logistically, this seems to mean that we "withdraw" the ns-3-ipv6-1st feature proposal and allow Tom and Sebastien to coordinate how
to merge it into the IPv4 rework feature proposal.  We will then see an IPv4, IPv6 rework feature proposal appear Real Soon Now.

Back to ns-3-ipv6-1st, an area that concerns me is that I really don't want to see IPv6 look like a "bag hung on the side" of the
current system  It needs to be (and appear) integrated.  For example, in the csma device we have methods that look like:

class CsmaNetDevice ...
  virtual Address GetMulticast (void) const;
  virtual Address GetMulticast6() const;
  virtual Address MakeMulticastAddress (Ipv4Address multicastGroup) const;
  virtual Address MakeMulticast6Address(Ipv6Address addr) const;

It makes IPv6 appear as a second-class citizen or something stuck in as an afterthought.  If at all possible, I think we should have
a situation that looks more like,

class CsmaNetDevice ...
  virtual Address GetIpv4DefaultMulticastAddress (void) const;
  virtual Address GetIpv6DefaultMulticastAddress (void) const;
  virtual Address MakeMulticastAddress (Ipv4Address multicastGroup) const;
  virtual Address MakeMulticastAddress (Ipv6Address multicastGroup) const;

We can deprecate the original non-specific methods.

Regards,

-- Craig



More information about the Ns-developers mailing list