Subject: update lifetimes of statefully autoconfigured addresses

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 27 May 2004 14:42:50 +0900

I've found one more thing that may need a discussion on the
relationship between rfc2462bis and stateful address autoconfiguration
(DHCPv6).

RFC2462 currently says in Section 5.5.3 that

    e) If the advertised prefix matches the prefix of an autoconfigured
       address (i.e., one obtained via stateless or stateful address
                                                 ^^^^^^^^^^^^^^^^^^^
       autoconfiguration) in the list of addresses associated with the
       interface, the specific action to perform depends on the Valid
       Lifetime in the received advertisement and the Lifetime
       associated with the previously autoconfigured address (which we
       call StoredLifetime in the discussion that follows):

       1) If the received Lifetime is greater than 2 hours or greater
          than StoredLifetime, update the stored Lifetime of the
          corresponding address.

       [...snipped]

That is, the valid and preferred lifetimes of an address configured by
DHCPv6 (the "stateful" protocol) can be updated by succeeding RAs.
Does this really make sense?  For example, consider the following
scenario:

- a host configures an IPv6 address by DHCPv6.  The preferred and
  valid lifetimes of the address and the T1/T2 parameters for renewal
  are reasonably large (e.g., order of weeks).
- the host then receives an RA that contains a prefix information
  option matching the configured address with very small lifetimes (at
  least smaller than the T1 value).
- if the host does not see further RAs, the address will soon expire,
  since the host will not try to renew the address before the address
  expires.

Does RFC2462 really intend to allow this kind of scenario?  I don't
think so; this should usually be an undesirable scenario by accident.
On the other hand, if the site administrator wants sudden expiration
of the address, they can use the DHCPv6 reconfigure mechanism, at
least in theory.

Besides, this part of the specification seems a bit too specific about
stateful autoconfiguration, considering we are now going to separate
particular behavior on the stateful configuration part from
rfc2462bis.

So, I personally would like to propose removing "stateful" from the
above part, that is, revise the original text to:

    e) If the advertised prefix matches the prefix of an address
       configured by stateless autoconfiguration in the list of
       addresses associated with the interface, the specific action to
       perform depends on the Valid Lifetime in the received
       advertisement [...]

Note that this does not necessarily break existing implementations
that implement this part for statefully configured addresses; we could
mention this particular case in a separate document specific to the
use of stateful address autoconfiguration.

Does this proposal make sense to others?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Thu, 27 May 2004 08:50:45 +0200

Jinmei,

> Does this really make sense?  For example, consider the following
I personally think that it makes sense to keep this specification. The
scenario you describe (address assigned by DHCPv6 gets invalidated by
RA) can be relevant in cases where a DHCPv6 server infrastructure breaks
down for some reason and where you quickly want to react by sending
certain RAs so that you can "switch" a subnet so SLAAC. Sending RAs
might then be the only way to control addresses until a new DHCPv6
server is up. This would also help in cases where rogue DHCPv6 servers
assigned addresses you don't want. You can invalidate them by sending
RAs in this case.

> particular behavior on the stateful configuration part from
I understand what you mean, but we should make clear that all forms of
autoconfigured addresses can be influenced by RAs. Maybe it would make
sense to reword the section from

	... of an autoconfigured address (i.e., one obtained via
	stateless or stateful address autoconfiguration) in the list of
	addresses...

to

	... of all autoconfigured addresses in the list of addresses...

Do you think this wording would work while not being too specific?

Christian

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 29 May 2004 12:48:04 +0900

>>>>> On Thu, 27 May 2004 08:50:45 +0200, 
>>>>> "Christian Strauf (JOIN)" <[email-masked]> said:

> Do you think this wording would work while not being too specific?

Thanks for the suggestion, but I'm afraid the text you proposed will
simply make the specification unnecessarily ambiguous.

I'd like to repeat my points, which are:

1. I personally do not think it makes sense to update the lifetimes of
   statefully configured address by RAs.
2. as a separate issue, I think it's beyond the scope of rfc2462bis to
   describe specific details on this.

The proposed text of mine intended to resolve both the points, but
mainly focusing on the second point.  Even if we disagree on the first
point, the proposed text can still hold.

So, I personally still prefer the text I proposed.  But if we still
cannot agree on it, the following might be an alternative as a
compromise:

 	... of an autoconfigured address (including one obtained via
 	stateless address autoconfiguration) in the list of addresses...
 	
Which one can you live with?

1. the original proposed text of mine
2. the new proposed text of mine
3. the text you proposed

I can live with 1 and 2, but prefer 1 to 2.  I might live with 3,
particularly if others want this option, but would like to avoid it as
explained above.

					JINMEI, Tatuya