Bug 757 - IPv6CP implementation, was: IPv6 link-local address on non-ARP interfaces
IPv6CP implementation, was: IPv6 link-local address on non-ARP interfaces
Product: ns-3
Classification: Unclassified
Component: ipv6
All All
: P5 enhancement
Assigned To: Tommaso Pecorella
: feature-request
Depends on:
  Show dependency treegraph
Reported: 2009-12-02 08:50 EST by Fabian Mauchle
Modified: 2015-07-08 17:33 EDT (History)
5 users (show)

See Also:

patch (834 bytes, patch)
2009-12-02 08:50 EST, Fabian Mauchle
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Mauchle 2009-12-02 08:50:56 EST
Created attachment 685 [details]

IPv6 does not configure a link-local address on interfaces that don't need ARP (eg. PointToPoint). Some IPv6 components however expect every interface to have a link-local address. 
I can't see any reason why a non-ARP interface should not have a link-local address.
Comment 1 Sebastien Vincent 2009-12-16 12:57:54 EST
OK no problem for me to add this.
Comment 2 Fabian Mauchle 2009-12-17 05:05:09 EST
I just tumbled over another issue about this:
The patch suggests to create a NdiscCache only for ARP devices (which are the only ones who really need it), but ICMPv6 assumes that there exists a cache for every interface.

Sebastien: what would you prefer?
1. create a NdiscCache for all interfaces (including non-ARP)
   (simple, but may result in including link-layer options in ICMP messages
    where they are not needed (not allowed?))
2. modify ICMPv6 to check for non-ARP device and use the cache only if really
   needed (lots of changes in ICMPv6 required)
Comment 3 Sebastien Vincent 2009-12-18 08:18:01 EST

Personnaly I prefer option 2 but at ns-3.7 stage ("bug fixing only")), I would not make too much changes and rather wait for ns-3.8 for it.

In real world, PPP device does not have a link-layer address, their IPv6 link-local address are determined by IPv6CP. Look at RFC5072 and RFC5172.

So maybe we should implement IPv6CP first before fully support IPv6 over PPP devices. WDYT ?
Comment 4 Fabian Mauchle 2009-12-18 11:43:26 EST
This might also require to alter the PPP implementation, since it configures Mac48Address at moment.

IPv6CP would be nice. Additionally there should be methods to generate IPv6Address from Mac64Address or from 'void' if the NetDevice has no address at all (eg. VirtualNetDevice)

It's clear that this won't fit in ns-3.7.
I'm fine if we plan these things for ns-3.8, and define the patch as a quick work-around for all those who want to use IPv6 over PPP right now.
Comment 5 Sebastien Vincent 2009-12-28 08:13:16 EST
Workaround commited in df27945958ff.

I left bug open to remember of the IPv6CP implementation.
Comment 6 moijes12 2012-09-15 15:49:13 EDT
Is this bug still open or is fixed and closed ?
Comment 7 moijes12 2012-09-15 15:50:51 EDT
I ask because from Sebastian Vincent's last comment, it seems like the fix has been committed.
Comment 8 Tom Henderson 2012-09-17 10:04:34 EDT
(In reply to comment #7)
> I ask because from Sebastian Vincent's last comment, it seems like the fix has
> been committed.

This bug is left open to request that someone provide an IPv6CP implementation, but the patch was previously committed.
Comment 9 moijes12 2013-07-03 13:59:21 EDT
Ok. Just to keep this going. Where should this be implemented ? As far as I can guess, ns-3-dev/src/internet/model should now contain ipv6-control.h and ipv6-control-part.cc with the implementation of the RFC 5072 and RFC 5172. Would this be the right way to proceed on this one ?
Comment 10 Tommaso Pecorella 2013-07-03 16:05:49 EDT
I'd say yes, no, maybe.

IPv6Cp is, to my best knowledge, a PPP sub-protocol, so it might be wiser (and needed) to define a new module: PPP.
The other problem is the logical layer. PPP is similar to 6LoWPAN: they're Leyer 2.5 protocols, as is they are sitting in between IP (L3) and the NetDevice (L2). For 6LoWPAN I did a "trick" (check the 6LoWPAN repository), basically fooling the NetDevice and the IP layer and having a new model in between. Maybe it's wise to adopt the very same method for both.
Hence, if we can agree on the best way to do it it could save some time. 

By the way, I'm keen on modifying the 6LoWPAN code if we find a better way to accomplish this. However we have to take care also of "impossibru" setups, like IP+PPP+6LoWPAN+NetDevice (dunno who would try this and why, but it's technically possible).