[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[rfc2462bis] a minor nit in creation of global addresses



I've been editing a new version of rfc2462bis, mainly addressing AD
comments, and I found one minor issue in Section 5.5.3 (creation of
global addresses using RA):

According to rfc2462bis-06, step (d) of the procedure can be
represented as follows:

d-1 check whether the prefix in RA is equal to the prefix of an address
    stateless autoconfiguration in the address list
d-2 if not, do some sanity checks, and form an address by concatenating
    the prefix with the interface identifier
d-3 add the new address to the list

But what if an address identical which is not configured by stateless
autoconfiguration (i.e., either manually or by DHCPv6) happens to be
identical to the address being configured?  The check in d-1 cannot
detect this since it only checks the prefix of a
stateless-autoconfigured address (note that this restriction is one of
rfc2462bis clarifications based on the wg consensus).  A naive
implementation would configure duplicated addresses, which should not
be the appropriate behavior (I actually made this mistake in my
initial attempt of implementing rfc2462bis).

Original RFC2462 also seems to have this issue, while the point is
vaguer due to its own unclear wording.

Such conflict should be rare, but I believe it makes sense to note
this explicitly in rfc2462bis.  The appropriate behavior in this case
might also be controversial, but I think the natural reaction is to
simply avoid configuring the duplicate address.

So, I'd like to propose to revise the last paragraph of bullet (d) of
Section 5.5.3 from:

      If an address is formed successfully, the host adds it to the list
      of addresses assigned to the interface, initializing its preferred
      and valid lifetime values from the Prefix Information option.

to:

      If an address is formed successfully and the address is not yet in
      the list, the host adds it to the list of addresses assigned to
      the interface, initializing its preferred and valid lifetime
      values from the Prefix Information option.  Note that the check
      against the prefix performed at the beginning of this step cannot
      always detect the address conflict in the list.  It could be
      possible that an address already in the list, configured either
      manually or by DHCPv6, happens to be identical to the newly
      created address whereas such a case should be atypical.

Comments?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@xxxxxxxxxxxxxxxxxxxxx

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------