Subject: (resend) [rfc2462bis] prefix length check for existing addresses

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 08 Jun 2004 10:07:41 +0900

(Hmm, I thought I sent this via the issue tracker, but I seem to have
failed...so I'm resending it my local mailer).

I've just noticed another minor issue on RFC2462.

In short, the issue is it's not clear in RFC2462 whether we should
check the advertised prefix length when updating the lifetimes of an
existing address.

RFC2462 has the following organization in Section 5.5.3:

For each Prefix-Information option in the Router Advertisement:

a) Check for the Autonomous flag
b) Ignore the link-local prefix
c) Check for the case of preferred lifetime > valid lifetime
d) If the prefix advertised does not match the prefix of an address
   already in the list, check if the advertised prefix length is
   valid for the receiving interface (i.e. the prefix length must
   be 128 - N where N is the length of the interface identifiers
   on that link), and if valid, make a new address from the prefix.
e) If the prefix advertised does match the prefix of an address
   already in the list, update the lifetimes of the address
   (without checking the prefix length)

It seems to me that this specification allows (e.g.,) the prefix
"::/0" to update the lifetimes all existing addresses (which may even
include link-local addresses), since ::/0 matches any addresses.

Is this the intended behavior? I believe not, and if not, shouldn't
the specification be clearer to avoid this case? I believe it should.

Assuming I'm correct for both the questions, I'd like to propose to
revise the logic in Section 5.5.3 as follows:

a) Check for the Autonomous flag
b) Ignore the link-local prefix
c) Check for the case of preferred lifetime > valid lifetime
d) Check if the prefix length is valid for the receiving interface.
   If it is not valid, ignore the prefix.
e) If the prefix advertised does not match the prefix of an address
   already in the list, make a new address from the prefix
f) If the prefix advertised does match the prefix of an address
   already in the list, update the lifetimes of the address

Comments?

					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: Pekka Savola <[email-masked]>
Date: Tue, 8 Jun 2004 08:38:19 +0300 (EEST)

>    If it is not valid, ignore the prefix.

How do you check that the length is valid for the *receiving 
interface*?  I guess you make the assumption, based on IPv6 over Foo 
documents, that for each interface, it's clear which kind of prefix 
lengths for SLAAC are used?

>    already in the list, update the lifetimes of the address

Note that you can avoid the wording nit above if you just checked the 
prefix and length explicitly both in e) and f) -- that is, don't 
configure a new address if it doesn't have the right prefix length 
(this already happens today), and don't update the prefix lifetimes 
unless the prefix *and* the length matches an existing prefix 
completely.

So, would a more straightforward change be a modification in f) above?
(The code might be a bit cleaner with a common rule before e or f 
though.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 08 Jun 2004 15:03:06 +0900

>>>>> On Tue, 8 Jun 2004 08:38:19 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

> lengths for SLAAC are used?

Yes, and this is the assumption in rfc2462bis for resolving issue 281
"Requirement for 64bit I/F ID".  See
https://rt.psg.com/Ticket/Display.html?id=281
for more details (user/passwd=ietf/ietf).

The next revision of rfc2462bis will explicitly clarify this point.

> unless the prefix *and* the length matches an existing prefix 

That's right.  This is another way to resolve this issue.

> (The code might be a bit cleaner with a common rule before e or f 

I don't mind either resolution between

1. add a new check 'd' just for validating the prefix length (and
   renumber the succeeding items)
2. add the validation for prefix length in the original item 'e' (and
   do not touch the other items)

I'm not sure which one is better...if the majority in this list
prefers 2, I'll simply take this option.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 08 Jun 2004 22:33:55 +0900

>>>>> On Tue, 08 Jun 2004 10:07:41 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> the specification be clearer to avoid this case? I believe it should.

After private e-mail exchanges, I realized I sort of misunderstood the
original text, but then found another possible issue...

RFC2462 actually says "If the advertised prefix matches ***the
prefix*** of an autoconfigured address", so the most likely
interpretation of this should be "If the advertised prefix equals to
the prefix of an autoconfigured address".  In this sense, the original
text does not have the problem I pointed out, and the meaning of
"match" is quite clear in this context.

However, there's still a possible issue with this spec in RFC2462.  It
targets addresses statefully autoconfigured addresses as well as
stateless ones:

    e) If the advertised prefix matches the prefix of an autoconfigured
       address (i.e., one obtained via stateless or stateful address
       autoconfiguration)...

and we know the stateful address autoconfiguration is DHCPv6.
However, DHCPv6 does not carry the information of prefix for addresses
being configured, so the host does not know the corresponding prefix
if the address was obtained via DHCPv6 (stateful autoconfiguration).
In this case, how can we check if "the advertised prefix matches the
prefix of an autoconfigured address"?

(BTW: I hope DHCPv6 specialists will correct me if my understanding of
DHCPv6 on this point is wrong)

Regarding rfc2462bis, the issue is a bit more subtle.  As a result of
clarifying the semantics of the M/O flags, we agreed on removing
specific behavior about the flags from rfc2462bis, and we are going to
revise the above text as follows:

    e) If the advertised prefix matches the prefix of an address
      configured by stateless autoconfiguration in the list of addresses
      associated with the interface, ...

so, the possible issue apparently disappears, while it will still
appear when we consider the effect of this for statefully configured
addresses, probably in a separate document.

Now, what should we do with this situation?  Possible actions would
include (but there may be more):

1. do nothing.  we'll consider the hidden possible issue with
   statefully configured addresses when we are ready to specify it.
2. introduce the change I proposed at the beginning of this thread (or
   a similar change Pekka mentioned).  this can apply to statefully
   configured addresses even if we decide to use the same rule
   for statefully configured addresses later.

I can live with either way, but slightly prefer option 1, since option
2 implicitly requires existing implementations to be modified (though
the implementations won't actually have to be changed because external
behavior will be the same).

I'll be listening to others for a while.  If no particular opinion is
provided, I'll simply take option 1, and close this issue without any
change on rfc2462bis (after all, this is quite a minor issue).

Thanks,

					JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 8 Jun 2004 11:19:24 -0700 (PDT)

> the specification be clearer to avoid this case? I believe it should.

I don't think this was the intent, thus it makes sense to clarify the
specification.

My take in this is that there is basically two levels:
1. Maintaining the set of addrconf prefixes based on what is received
   in router advertisements and timeouts.
2. Configure addresses from those prefixes (which have a lifetime based
   on the lifetime of the underlying prefix).
I don't know if it makes sense to structure the text that way.

BTW: Is there a separate issue about the interaction of the lifetime
in the advertised prefixes and addresses that are not configured
using stateless? (For instance, would these lifetimes affect
the addresses configured manually or with DHCP?)
The resultion of such an issue will affect this text as well.

>    already in the list, update the lifetimes of the address

I still think this is underspecified since you haven't defined
what "match the prefix" means. You'd need to state that two prefixes
match when the length of the prefixes is identical and the "length"
first bits are identical.
Otherwise folks might read this the same as "prefix advertised
matches an address"

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 09 Jun 2004 11:00:00 +0900

>>>>> On Tue, 8 Jun 2004 11:19:24 -0700 (PDT), 
>>>>> Erik Nordmark <[email-masked]> said:

> the addresses configured manually or with DHCP?)

As I stated in a previous message (the latest one in this thread),
there *was* an issue in RFC2462 but rfc2462bis would be able to avoid
it since rfc2462bis will concentrate on the stateless part of the
address configuration (as a result of clarifying the M/O flags).

> Otherwise folks might read this the same as "prefix advertised

I first would like to know your opinion, if any, on my latest question
(in the separate message).  If we choose option 1 (i.e., basically do
nothing on this), we still might want to clarify what "match the
prefix" means to avoid possible confusion.

Thanks,

					JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 9 Jun 2004 07:20:06 -0700 (PDT)

> prefix" means to avoid possible confusion.

I think we should clarify this. The word "match" is unfortunate.
Either just saying "identical" or also stating that prefixes are
identical when their length as well as content are the same would
be good.

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 10 Jun 2004 11:41:52 +0900

>>>>> On Wed, 9 Jun 2004 07:20:06 -0700 (PDT), 

> identical when their length as well as content are the same would

Okay, so the desired resolution (which is basically just a
clarification) would be as follows:

    d) If the prefix advertised is not equal to the prefix of an address
      already in the list of addresses associated with the interface
      (where "equal" means the two prefix lengths are the same and the
      first prefix-length bits of the prefixes are identical), and the
      Valid Lifetime is not 0, form an address (and add it to the list)
      by combining the advertised prefix with the link's interface
      identifier as follows:
      [...]

    e) If the advertised prefix is equal to the prefix of an address
      configured by stateless autoconfiguration in the list, the
      preferred lifetime of the address is reset to the Preferred
      Lifetime in the received advertisement.  [...]

The additional note on the meaning of "equal" might be trivial and
redundant, but it'll do no harm.

Also note that I've given more detailed definition of "the list" in
item d), which was in item e) in RFC2462.  I think it's an error
during the migration from RFC1971 to RFC2462.  RFC1971 had the
following organization:

 d) If the advertised prefix matches the prefix of an autoconfigured
    address (i.e., obtained via stateless or stateful address
    autoconfiguration) in the list of addresses associated with the
    interface, [...]

 e) If the prefix advertised does not match the prefix of an address
    already in the list, [...]

and RFC2462 reversed the order (probably due to introducing the
"two-hour" rule, which made the corresponding item longer) without
touching the content (except the additional rules for DoS avoidance):

    d) If the prefix advertised does not match the prefix of an address
       already in the list, [...]

    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, [...]

With this text, the reader would wonder at item d what is "the list",
which is explained in the succeeding item.  This is unnatural.

I have one last question.  RFC2462 says just "an address already in
the list" in the case of no identical (or matched) prefix while it
says "an *autoconfigured* address in the list" in the case where there
is an identical prefix.  Does the former mean all addresses including
stateless-, stateful-, or manually- configured ones?  If so, is this
intentional?  And if so, we'll still see the problem that DHCPv6 does
not carry the information of prefix for assigned addresses...

					JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 10 Jun 2004 11:49:59 -0700 (PDT)

> not carry the information of prefix for assigned addresses...

I don't think there was an intent when 2462 was written that
it affect the lifetime for DHCP assigned addresses.
I don't think anybody knew at the time how DHCPv6 would manage lifetimes.
And I'm sure the intent was not to affect some lifetime on manually configured
addresses.

Given this I think it makes sense to explicitly state in RFC 2462 that "the
list" is the (per interface) list of stateless prefixes learned from
router advertisements (i.e. the prefixes with the A-bit set).

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 11 Jun 2004 13:54:54 +0900

>>>>> On Thu, 10 Jun 2004 11:49:59 -0700 (PDT), 

> I don't think anybody knew at the time how DHCPv6 would manage lifetimes.

Hmm, RFC2462 clearly says "stateless or stateful" in Section 5.5.3 (e):

    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, [... describe how to update the lifetimes]

and even though the RFC is not clear on "what is stateful" (probably
due to the immature statndardization status of DHCPv6), the intended
protocol was very likely DHCPv6.

But, it's okay for rfc2462bis anyway.  We're going to remove specific
behavior regarding DHCPv6 as a clarification.

> And I'm sure the intent was not to affect some lifetime on manually configured

I'm sure about that, too.  But it's not the main point whether the
intent was to affect "some lifetime" on manually configured addresses.
The point is whether the intent was to make a decision on a new
address to be auto-configured based on the existence of manually
configured addresses (as well as other automatically-configured ones).

And,

> router advertisements (i.e. the prefixes with the A-bit set).

after re-reading RFC1971 and RFC2462, I now have a similar conclusion
(but probably for a different reason).

RFC1971 (essentially) says:

 d) If the advertised prefix matches the prefix of an autoconfigured
    address in the list, update the lifetimes.

 e) If the prefix advertised does not match the prefix of an address
    already in the list, then form an address.

I think "an address" used in (e) actually meant "an autoconfigured
address" but the RFC simplified the text to avoid redundancy.

Then, as I pointed out in a previous message, RFC2462 reversed the
order of the rules without touching the text (related to this
discussion):

    d) If the prefix advertised does not match the prefix of an address
       already in the list, then form a new address.

    e) If the advertised prefix matches the prefix of an autoconfigured
       address in the list, update the lifetimes (with DoS avoidance)

and, probably unintentionally, made the meaning of "an address" in
bullet (d) a little bit ambiguous.

Having considered all the discussion so far, the final proposed text
in rfc2462 is as follows:

5.5.3 Router Advertisement Processing

[omitted, no change from RFC2462]

    d) If the prefix advertised is not equal to the prefix of an address
      configured by stateless autoconfiguration already in the list of
      addresses associated with the interface (where "equal" means the
      two prefix lengths are the same and the first prefix-length bits
      of the prefixes are identical), and the Valid Lifetime is not 0,
      form an address (and add it to the list) by combining the
      advertised prefix with the link's interface identifier as follows:

[snip]

    e) If the advertised prefix is equal to the prefix of an address
      configured by stateless autoconfiguration in the list, the
      preferred lifetime of the address is reset to the Preferred
      Lifetime in the received advertisement. [...omitted]

I'll submit the new revision with this change very soon, so if anyone
of you have an objection to this, please speak up right now.

Thanks,

					JINMEI, Tatuya