RE: New (-02) version of IPv6 CPE Router draft is available for review

["Hemant Singh (shemant)" <shemant@cisco.com>]

David,

Here is my response to the rest of your email. Please see in line below
between <hs> and </hs>. 

-----Original Message-----
From: David Miles [mailto:davidm@thetiger.com] 
Sent: Friday, July 18, 2008 12:16 AM
To: Hemant Singh (shemant)
Cc: v6ops WG
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
review

Hemant and Wes,

Some comments on draft-02:

------- snip ---------------------------

I think we need a new section that describes CPE behaviour on reload/
WAN up, thoughts below:

<hs>
WAN up is already described in the document in various sections.  A
reload section may make sense to add to the document.  If I and Wes are
convinced, we'll add such a TBD to a "TBD list" for the document that we
maintain.  For all of our sanities, I will publish this TBD list every
Friday so that everyone is aware what is TBD.  We clearly have ignored
some people's comments and requests because they didn't make sense to
us.  Folks are welcome to contact us if they still want their request to
be kept in our TBD list with give proper justification.  
</hs>

-----
5.4 Prefix Delegation Rebinding
Whenever the CPE WAN link changes state, addresses passed through
DHCPv6 must be revalidated. Conditions that should trigger a Rebind
include:
- When the CPE reboots
- When the CPE WAN interface transitions to an up state

Prior to completing a Rebind, the CPE should continue to use addresses
and lifetimes previously assigned to its LAN interface(s) that are
derived from IA_PD Prefix options. These may be subsequently invalidated
through the Rebind process.

On reload, a routing CPE may not be able to validate any IA_PD Prefix
option lifetimes. Certain parameters must be stored in persistent memory
to avoid a situation where hosts in the LAN segments consider previously
advertised prefixes valid that the CPE does not know of or that may not
be permitted by the upstream ISP.
These persistent parameters are:
- DHCPv6 PD
	- IAID
	- Prefix Options
- A register of subnets assigned to each interface with associated IAID,
IA_PD Prefix option and AdvPrefixList.
- Interface address assignments and lifetimes

The CPE MUST NOT advertise any RA PIO for prefixes derived from IA_PD
Prefix Options until the prefixes have been validated through a DHCP
Rebind message exchange.

Once the WAN interface initialises, the reloading CPE SHOULD issue a
DHCPv6-PD Rebind message, including the stored IAID and Prefix Options
in the message. The DHCP Reply message will indicate whether the
prefixes are valid (the valid lifetime is > 0) or invalid (the valid
lifetime is 0). If there is no reply within CNF_MAX_RD [RFC 3315] the
CPE MUST initiate DHCPv6 Address Acquisition. It should continue to use
addresses and lifetimes previously assigned to its LAN interface(s).

For each invalid prefix, the CPE MUST transmit unsolicited RA to LAN
segments that contain PIO with the invalid prefix and the lifetime set
to zero to immediately invalidate these addresses from hosts on the LAN.
The CPE MUST then initialise DHCPv6 Address Acquisition.
For each valid prefix, the CPE MUST transmit unsolicited RA to LAN
segments that contain PIO with the valid prefix and lifetimes set to the
values is the DHCP Reply IA_PD Prefix option.

-----
- I'd suggest text in the DHCPv6 Address Acquisition section that
clarifies IA_PD prefix options received by the CPE are an explicit list
of valid prefixes. All prefixes in the CPE AdvPrefixList that originated
from previous IA_PD and that are not contained in the DHCP- PD Reply
MUST be immediately expired. 

<hs>
Most of your text above is already mentioned in RFC3633 that is a RFC
referenced in our document.  Like text from section 12.1 of RFC3633
describes some of your text above.  Further, we have added this text to
the end of 2nd paragraph of section 5.5 in our -02 version document
(shown in square brackets below):

[If the IA_PD changes, the CPE Router must reconfigure the LAN
interface(s) with new IPv6 addresses derived from the new IA_PD and then
also renumber the IPv6 ND RA configuration on the LAN interface(s).].

We will add a few more sentences at an appropriate place in our draft
that address your concerns above.
</hs>

This ensures a host will not try an communicate through the ISP with a
invalid source address. I'm not sure what we should do in the scenario
where DHCPv6 Address Acquisitions fails (ie, we get a response but no
IA_PD Options) but I would lean to doing nothing (ie, dont expire
prefixes but do not send any PIO, let the lifetime age away)  as we are
not going to forward anyway.

<hs>
After section 5.3.2, we have a paragraph in the draft that says the
router will not forward any traffic for the case you describe above.
That text is as follows (shown between square brackets): 

[At any instance in time of the CPE Router operation, the router does
not forward any traffic between its WAN and LAN interface(s) if the
router has not completed IPv6 provisioning process that involves the
acquisition of a global IPv6 address by the WAN or Loopback interface
and the acquisition of a global or Unique Local Address (ULA) [RFC4193]
by the LAN interface(s).]. 

Then in section 5.4 of our draft we say (show in square brackets below):

[When the CPE Router processes a DHCPv6 response from the server, if the
response message (e.g. ADVERTISE or REPLY) received does not include an
IA_PD option, or Reconfigure Accept option, then the CPE Router has
failed DHCPv6 address acquisition.].

I don't see why you had to mention your case when we have already
covered the case in the draft?
</hs>

- Some comments on the Unnumbered model with suggested text:

From:
5.3.2. Unnumbered Model
When the CPE router is configured for Unnumbered model, after the WAN
and Loopback interfaces have acquired a link-local address, the Loopback
interface initiates SLAAC or stateful DHCPv6 to obtain IA_PD option and
other configuration information. On receiving the DHCPv6 REPLY with
IA_PD option, the CPE Router sub-delegates one global IPv6 address from
the IA_PD option to the Loopback interface.
At any instance in time of the CPE Router operation, the router does not
forward any traffic between its WAN and LAN interface(s) if the router
has not completed IPv6 provisioning process that involves the
acquisition of a global IPv6 address by the WAN or loopback interface
and the acquisition of a global or Unique Local Address (ULA) by the LAN
interface(s).
---
To:
5.3.2. Unnumbered Model
In the unnumbered model the WAN interface will not acquire an interface
address through SLAAC or DHCPv6. When the CPE router is configured for
Unnumbered model and after interface initialisation, the WAN interface
initiates DHCPv6 to obtain IA_PD option and other configuration
information.

<hs>
No.  We don't want to prohibit the Loopback interface or any virtual
interface on the router from acquiring a global IPv6 address using SLAAC
or DHCPv6.  As I said in an earlier emails, we will add a third option
to the Unnumbered model where the third model will assign a global IPv6
address to the Loopback interface from the IA_PD acquired by the
Loopback interface.  We can also say that this third option is a
preferred option for some SP deployments or any other way that DSL folks
would like us to word the requirement.
</hs>

5.3.3. Both Models
  On receiving the DHCPv6 REPLY with a IA_PD option, the CPE Router
assigns a /64 prefix from within the bounds of the IA_PD Prefix Option
to all interfaces except the WAN interface. The interface addresses are
constructed using the /64 prefix and using EUI-64 on each interface for
the Interface-ID portion of the address.
At any instance in time of the CPE Router operation, the router does not
forward any traffic between its WAN and LAN interface(s) if the router
has not completed IPv6 provisioning process that involves the
acquisition or rebinding of addresses via DHCPv6-PD.

<hs>
The paragraph at the end of section 5.3.2 does apply to both models.
Your suggestion for putting this under a new sub-section makes perfect
sense - thanks!  What the text of the common sub-section is not
agreeable to me.  After we have added our third option to the Unnumbered
section, we will run any new text for the "Both Models" by you take it
from there.
</hs>

Hemant


Cheers,

-David