Subject: draft-shirasaki-dualstack-service-02.txt CPE assigned Host Address Lifetime issue

From: "Green" <[email-masked]>
Date: Fri, 13 Feb 2004 21:41:24 +0800

Hi, all:

I have a question regarding the following paragraph in
draft-shirasaki-dualstack-service-02.txt:

==>
2.4. Address Assignment

   CPE assigns global-scope /64 prefixes subnetted from the delegated
   prefix to its downstream interfaces. In the case where the delegated
   prefix has infinite lifetimes, the preferred and valid lifetimes of
   assigned /64 prefixes should be their default values in [RFC2461].
==>

According to this draft, the CPE gets a (non-link-local) prefix (possibly
/48) using DHCP from the BRAS after successful PPoE initiation. The CPE then
delegate the prefix's subnet to its host-facing links. The subnet prefixes
is advertised on the links using RA, with the prefered and valid lifetime
using default values in rfc2461, which is 7days and 30 days.

Certainly I understand these default value could be overrided by manual
configuration on CPE router, but since CPE router is supposed to be an
unmanaged device installed in customer home, such assumption can be dropped.

Problem may arise when the PPPoE session is terminated between the CPE and
BRAs, in a case other than CPE powering off or customer disconnect the hosts
(PCs), and then the PPPoE session between the two gets re-established.

In this case, the CPE will get a new prefix using DHCP from the BRAS
(Although Radius extension can be configured to make sure the same customer
line, or CPE MAC address, or user id will be assigned the same prefix in
some cases, generally I think the CPE will just get a new Prefix just like
nowadays's dial-up getting a new IPv4 address everytime you dial), and the
CPE will delegate new subnet prefixes to its links.

So now the hosts (PCs) will have an old  non-link-local IPv6 address, with
its lifetime still valid for the next week or month, and receives a new
non-link-local IPv6 address. When sending out packets, it will have to make
a default address selection based on the two source addresses. It will have
good chance of selecting the old address, which the BRAS doesn't have a clue
when forwarding packet back to this (destination) address.

DHCPv6 can reclaim the assigned addresses from its clients, but stateless
auto-configuration can't do the same, unless the Router Advertisement from
which this Prefix Information option was obtained has been authenticated,
(quoting from RFC 2462 - IPv6 Stateless Address Autoconfiguration 5.5.3
Router Advertisement Processing) which is obviously not the case between CPE
and hosts (Home PC). So, the CPE can't force the hosts to make the old
address expire explicitly, the above mentioned problem will occur.

Please comment, I am eager to know the answer.

And, I am very curious of the CPE used in NTT's deployment, is there any
more information on that available?

Green Guo Limin
[email-masked]
Ericsson China

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Mon, 16 Feb 2004 10:51:31 +0900 (JST)

On Fri, 13 Feb 2004 21:41:24 +0800,
> CPE will delegate new subnet prefixes to its links.

We've been using a Framed-IPv6-Prefix radius attribute for a persistent
prefix assignment in our current service, so there has been no change
of delegating prefixes. This is what infinity lifetimes of prefixes
in the DHCPv6-PD means in our service. But we might need to think
about the problem you pointed out when we'll start prefix-pool based
service.

> when forwarding packet back to this (destination) address.

I've just checked two implementations and noticed a different behavior
against prefix changes. When the CPE changed advertising prefixes
in a flash, one implementation did the things as you mentioned,
but the another one has revoked an old prefix immidiately and started
communications with a new prefix only. If all hosts behave as
the latter implementation, we don't need any special treatment
with prefix changes...

Anyway, it's reasonable that CPEs have stable storage retain delegated
prefixes and advertise old prefixes with pltime = 0, vltime = 2hour,
when the delegated prefix was changed.

--
SHIRASAKI Yasuhiro @ NTT Communications
t: +81-3-6800-3262, f: +81-3-5365-2990

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 16 Feb 2004 11:37:51 +0900

(I've not fully been following this thread, but)

>>>>> On Mon, 16 Feb 2004 10:51:31 +0900 (JST), 
>>>>> SHIRASAKI Yasuhiro <[email-masked]> said:

> the latter implementation, we don't need any special treatment

Please let me check, are you talking about a host that behaves like
this?

- the host receives a prefix P via RA from a router, and configures an
  address P:A.
- then the router stops advertising the prefix P, and starts
  advertising another prefix Q.
- the host receives the new RAs with prefix Q, and configures a new
  address Q:A.  At this stage, the preferred and valid lifetimes of
  the old address does not expire.  However, the host never uses the
  old address as the source address even if RFC3484 suggests the
  old address be preferred.

If so, I'd say the host is not fully compliant (at least not compliant
to RFC3484), and network operators should not assume such a behavior.

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

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Mon, 16 Feb 2004 13:35:21 +0900 (JST)

On Mon, 16 Feb 2004 11:37:51 +0900,
> to RFC3484), and network operators should not assume such a behavior.

Exactly.

I got your point, but if so, in the situation where delegated prefix is
volatile (like PD with prefix-pool, as Green mentioned), how CPE should do?

- CPE sets preferred lifetime in RA with very small value (ex. 1 min)
  and advertises with a short period (20sec?).
- CPE has a stable storage and advertises an old prefix with pltime
  = 0, when CPE reboots accidentally and a delegated prefix is changed.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 16 Feb 2004 14:15:36 +0900

>>>>> On Mon, 16 Feb 2004 13:35:21 +0900 (JST), 

>   = 0, when CPE reboots accidentally and a delegated prefix is changed.

For the reboot case, perhaps a desirable behavior is:

- detect the old prefix is now invalid (as described in Section 12.1
  of RFC3633)
  
- advertise the old prefix with zero lifetimes for a while.  The zero
  preferred lifetime will deprecate the old address immediately.  The
  zero valid lifetime will at least reduce the corresponding valid
  lifetime to two hours, and the old address will be removed in two
  hours.

					JINMEI, Tatuya

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Mon, 16 Feb 2004 14:36:57 +0900 (JST)

On Mon, 16 Feb 2004 14:15:36 +0900,
>   lifetime to two hours, and the old address will be removed in two

Agreed. so that, CPE must have a stable storage to store the old prefix.