Bugzilla – Bug 2236
Integer assumption in declaring Lifetime value of of an IPv6 address in Internet Module
Last modified: 2015-12-20 09:44:17 UTC
I found an oldish assumption in the Internet module, still lying. It is related to lifetime values of IPv6 address. The preferred and valid lifetime data type is declared as uint32_t, however it can be a different type. In RFC 4861, the minimum value of lifetime is specified as 3 seconds. People relies on the assumption that lifetime would be a very high value in the order of multiples of 10 and never contain a fraction. But, researchers working in the wireless mobility domain, for example in MIPv6 part, always assume a small value. The RFC 6275 of MIPv6 specifies 1 second as the lifetime value. The lifetime value is always greater than the max router advertisement interval. RFC 6275 specifies the interval as 70 msec. So, if anybody takes it as specified and takes the lifetime values as .2 or, .3 second, the ns-3 simulator converts it into zero (as it is an integer) and so the lifetime would expire just after the assignment of the address. So, declaring integer type is the main problem. So, changing data type is required. This bug has to be resolved immediately. It would faciliatete the wireless domain researchers who may set the lifetime in fraction. Regards Manoj Kumar Rana Phd Scholar Jadavpur University India
After carefully examining the problem, I'm not that sure it is a bug as it is. Unless we add support for some not-yet-supported option. RFC 4861 is pretty clear on this: Valid Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xffffffff) represents infinity. The Valid Lifetime is also used by [ADDRCONF]. Preferred Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration remain preferred [ADDRCONF]. A value of all one bits (0xffffffff) represents infinity. See [ADDRCONF]. the lifetimes are modeled assuming that they are used for an auto-configured address originating from a RA of this kind. Of course it could be possible to have smaller values, but they'll never be generated by a "classic" RA. Before we change the API (because that's what it will be needed, an API change), we'll need a reference to a test case where the address is auto configured by something AND its lifetimes are sub-second. As a side note, RFC 6275 is in perfect accordance with setting the lifetime to 1 second. The RA interval must be *shorter* than the address expiration time, not greater. If you set an address lifetime of 0.2 seconds, you'll need a RA interval of 0.1 seconds.
I agree to find out how this would actually be modified in practice before making a data type change. It is not just an API change but interoperability; these fields are carried in neighbor discovery messages and specified as integer there.
For this reason, I have resolved it changing the following classes: ipv6-l3-protocol.h/.cc [change AddAutoconfiguredAddress() method] ipv6-autoconfigured-prefix.h/.cc () [change const., get/set(), private members] radvd-prefix.h/.cc [change const., get/set(), private members] icmpv6-header.h/.cc [change const., get/set(), private members and the Serialize(), Deserialize() and GetSerializedSize() methods]. Note that my effort is to convert from uint32_t to double. Anybody may change it by declaring the lifetime as milliseconds, not as seconds. To do it, I think the above mentioned modifications are required. The problem of floating point value will never happen, as in the case of router advertisement interval.
Perhaps I was not crear. The problem is not in what we schould change in ns-3. I know that pretty well. The point is: is there any protocol allowing a to set the address lifetime to fractions of seconds ? Normal router advertisements can NOT do that. As a consequence, it must be some other protocol. The only other alternative is that you're faking RAs by setting up manually the addresses. Please explain. (In reply to Manoj Kumar Rana from comment #3) > For this reason, I have resolved it changing the following classes: > > ipv6-l3-protocol.h/.cc [change AddAutoconfiguredAddress() method] > ipv6-autoconfigured-prefix.h/.cc () [change const., get/set(), private > members] > radvd-prefix.h/.cc [change const., get/set(), private members] > icmpv6-header.h/.cc [change const., get/set(), private members and the > Serialize(), Deserialize() and GetSerializedSize() methods]. > > Note that my effort is to convert from uint32_t to double. Anybody may > change it by declaring the lifetime as milliseconds, not as seconds. To do > it, I think the above mentioned modifications are required. The problem of > floating point value will never happen, as in the case of router > advertisement interval.
One possible strategy is to decouple the Ipv6AutoconfiguredPrefix class from the RA PIO format. I.e., have the timers in Ipv6AutoconfiguredPrefix in Time (instead of integers) and leave to the PIO processing to handle the cases of infinite valid / preferred lifetimes. This can be easily accomplished by using a "reverse" notation: if we pass zero to the constructor, it can be interpreted as an infinite (right now it's all-one representing infinte). In this way, one can easily add a whatever-lifetime Ipv6AutoconfiguredPrefix (but not using a normal PIO, that would go against RFC 4861). Still, using a double is a no-no-no-please-no. Floating point values can not be serialized into packets, every kid in the kindergarten knows that. (In reply to Tommaso Pecorella from comment #4) > Perhaps I was not crear. The problem is not in what we schould change in > ns-3. I know that pretty well. > > The point is: is there any protocol allowing a to set the address lifetime > to fractions of seconds ? > Normal router advertisements can NOT do that. As a consequence, it must be > some other protocol. > The only other alternative is that you're faking RAs by setting up manually > the addresses. > > Please explain. > > > (In reply to Manoj Kumar Rana from comment #3) > > For this reason, I have resolved it changing the following classes: > > > > ipv6-l3-protocol.h/.cc [change AddAutoconfiguredAddress() method] > > ipv6-autoconfigured-prefix.h/.cc () [change const., get/set(), private > > members] > > radvd-prefix.h/.cc [change const., get/set(), private members] > > icmpv6-header.h/.cc [change const., get/set(), private members and the > > Serialize(), Deserialize() and GetSerializedSize() methods]. > > > > Note that my effort is to convert from uint32_t to double. Anybody may > > change it by declaring the lifetime as milliseconds, not as seconds. To do > > it, I think the above mentioned modifications are required. The problem of > > floating point value will never happen, as in the case of router > > advertisement interval.
(In reply to Tommaso Pecorella from comment #5) > One possible strategy is to decouple the Ipv6AutoconfiguredPrefix class from > the RA PIO format. I.e., have the timers in Ipv6AutoconfiguredPrefix in Time > (instead of integers) and leave to the PIO processing to handle the cases of > infinite valid / preferred lifetimes. > This can be easily accomplished by using a "reverse" notation: if we pass > zero to the constructor, it can be interpreted as an infinite (right now > it's all-one representing infinte). > > In this way, one can easily add a whatever-lifetime Ipv6AutoconfiguredPrefix > (but not using a normal PIO, that would go against RFC 4861). > > Still, using a double is a no-no-no-please-no. Floating point values can not > be serialized into packets, every kid in the kindergarten knows that. > > > (In reply to Tommaso Pecorella from comment #4) > > Perhaps I was not crear. The problem is not in what we schould change in > > ns-3. I know that pretty well. > > > > The point is: is there any protocol allowing a to set the address lifetime > > to fractions of seconds ? > > Normal router advertisements can NOT do that. As a consequence, it must be > > some other protocol. > > The only other alternative is that you're faking RAs by setting up manually > > the addresses. > > > > Please explain. > > > > > > (In reply to Manoj Kumar Rana from comment #3) > > > For this reason, I have resolved it changing the following classes: > > > > > > ipv6-l3-protocol.h/.cc [change AddAutoconfiguredAddress() method] > > > ipv6-autoconfigured-prefix.h/.cc () [change const., get/set(), private > > > members] > > > radvd-prefix.h/.cc [change const., get/set(), private members] > > > icmpv6-header.h/.cc [change const., get/set(), private members and the > > > Serialize(), Deserialize() and GetSerializedSize() methods]. > > > > > > Note that my effort is to convert from uint32_t to double. Anybody may > > > change it by declaring the lifetime as milliseconds, not as seconds. To do > > > it, I think the above mentioned modifications are required. The problem of > > > floating point value will never happen, as in the case of router > > > advertisement interval. Yes, You are right absolutely. I am facing problem from the Serialized method. It is OK. But, I have to change it. Is the Time data type a suitable alternative?
(In reply to Manoj Kumar Rana from comment #6) > (In reply to Tommaso Pecorella from comment #5) > > One possible strategy is to decouple the Ipv6AutoconfiguredPrefix class from > > the RA PIO format. I.e., have the timers in Ipv6AutoconfiguredPrefix in Time > > (instead of integers) and leave to the PIO processing to handle the cases of > > infinite valid / preferred lifetimes. > > This can be easily accomplished by using a "reverse" notation: if we pass > > zero to the constructor, it can be interpreted as an infinite (right now > > it's all-one representing infinte). > > > > In this way, one can easily add a whatever-lifetime Ipv6AutoconfiguredPrefix > > (but not using a normal PIO, that would go against RFC 4861). > > > > Still, using a double is a no-no-no-please-no. Floating point values can not > > be serialized into packets, every kid in the kindergarten knows that. > > > > > > (In reply to Tommaso Pecorella from comment #4) > > > Perhaps I was not crear. The problem is not in what we schould change in > > > ns-3. I know that pretty well. > > > > > > The point is: is there any protocol allowing a to set the address lifetime > > > to fractions of seconds ? > > > Normal router advertisements can NOT do that. As a consequence, it must be > > > some other protocol. > > > The only other alternative is that you're faking RAs by setting up manually > > > the addresses. > > > > > > Please explain. > > > > > > > > > (In reply to Manoj Kumar Rana from comment #3) > > > > For this reason, I have resolved it changing the following classes: > > > > > > > > ipv6-l3-protocol.h/.cc [change AddAutoconfiguredAddress() method] > > > > ipv6-autoconfigured-prefix.h/.cc () [change const., get/set(), private > > > > members] > > > > radvd-prefix.h/.cc [change const., get/set(), private members] > > > > icmpv6-header.h/.cc [change const., get/set(), private members and the > > > > Serialize(), Deserialize() and GetSerializedSize() methods]. > > > > > > > > Note that my effort is to convert from uint32_t to double. Anybody may > > > > change it by declaring the lifetime as milliseconds, not as seconds. To do > > > > it, I think the above mentioned modifications are required. The problem of > > > > floating point value will never happen, as in the case of router > > > > advertisement interval. > > Yes, You are right absolutely. I am facing problem from the Serialized > method. It is OK. But, I have to change it. Is the Time data type a suitable > alternative? No. Time is a class representing a... time with variable time resolution. I.e., you'd have to serialize the ticks, but how much time a tick is representing is depending on the specific simulation setup. Please note that if this issue (the sub-second lifetime) is something only affecting your own simulations, we'll probably mark the bug as invalid. Can you explain the context where the sub-second lifetime is used ?