Bug 2236

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 ?