|
Bugzilla – Full Text Bug Listing |
| Summary: | IPv6CP implementation, was: IPv6 link-local address on non-ARP interfaces | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Fabian Mauchle <f1mauchl> |
| Component: | ipv6 | Assignee: | Tommaso Pecorella <tommaso.pecorella> |
| Status: | PATCH WANTED --- | ||
| Severity: | enhancement | CC: | faker.moatamri, moijes12, ns-bugs, tomh, tommaso.pecorella |
| Priority: | P5 | Keywords: | feature-request |
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | patch | ||
OK no problem for me to add this. 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)
OK,
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 ?
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. Workaround commited in df27945958ff. I left bug open to remember of the IPv6CP implementation. Is this bug still open or is fixed and closed ? I ask because from Sebastian Vincent's last comment, it seems like the fix has been committed. (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. 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 ? 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). |
Created attachment 685 [details] patch 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.