Subject: [v6ops] socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 26 Jul 2011 12:23:03 -0500

Hi Ted,

In the latest version of the document which is

http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router-bis/?in
clude_text=1

Please note this new section which is something we'd like to socialize
with the DHC folks.   The idea is since DHC tries forever, if a client
send the first SOLiCIT with say, two options, such as the IA_NA and the
IA_PD options,  then if the server replied to the first SOLICIT having
served only a IA_NA IA_Address and error for the IA_PD (due to server
mis-configuration), then if the client sends a SOLICIT at another time,
the client should not just include the IA_PD but  send both the options
as in the first SOLiCIT.   The reason is what if the server has changed
provisioning for the IA_NA in the meantime. 

5.7.  Additional DHCPv6 WAN Requirement

   When the WAN interface sends a DHCPV6 SOLICIT message, the CE router

   SHOULD request all mandatory information (IA_NA and IA_PD options) in

   the SOLICIT regardless of whether any partial information was

   received in response to previous SOLICITs.

Thanks,

Hemant

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Jul 2011 17:28:00 +0000

You should raise this on the DHCP mailing list.  The questions I'd want to see answered are why just waiting for the IA_NA to time out doesn't work, and why Reconfigure doesn't work.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 26 Jul 2011 15:38:57 -0500

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Tuesday, July 26, 2011 1:28 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: socializing new DHCPV6 req in the IETF IPV6 CE rtr bis doc

>You should raise this on the DHCP mailing list.  

Done - thanks.

>The questions I'd want to see answered are why just waiting for the
IA_NA to time out doesn't work, and why Reconfigure doesn't work.

The IPv6 CE router DHC6 client sent its first SOLICIT with IA_NA and
IA_PD options and the server replied back with a valid IA_NA but failure
for the IA_PD (due to a mis-configured server for IA_PD). So if the
client waits for the IA_NA to timeout before the client sends any
subsequent SOLICIT for both IA_NA and IA_PD.  The IA_NA IA_Address Valid
Lifetime is one week and thus the home LAN has no PD assigned for a
week.  Note also that if a server is mis-configured for IA_PD, when the
mis-configuration is fixed, the IA_NA is may change as well. Thus it
makes sense to send both IA_NA and the IA_PD options is subsequent
SOLICITs.  Agreed, when the IA_NA changes a Reconfigure can be sent from
the server to the client.  But there is no automated means to detect the
mis-configuration and when does the server send the Reconfigure?   

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 27 Jul 2011 08:04:01 -0500

From: Andre Kostur [mailto:[email-masked]] 
Sent: Tuesday, July 26, 2011 4:55 PM
To: Hemant Singh (shemant)
Cc: Ted Lemon; [email-masked]; IPv6 Operations
Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr
bis doc

>Why would the server necessarily wait for the IA_NA to expire before
talking about the IA_PD again?  Those two should be on separate timers.
The preferred/valid/T1/T2 timers are all per IA, and the IA_NA is
separate from the IA_PD.

I am discussing the client since Ted asked why not wait for the IA_NA to
timeout.   If a CPE router has failed IA_PD acquisition, the IA_NA is
not much use for the CPE and then CPE should try DHCPv6 forever to get
both an IA_NA and IA_PD.  The CPE router DHCv6 client hasn't even
completed DHCPv6 to consider a client renewal/rebind or the server to
send a Reconfigure.

Hemant

---

From: Andre Kostur <[email-masked]>
Date: Tue, 26 Jul 2011 13:54:54 -0700

Why would the server necessarily wait for the IA_NA to expire before talking
about the IA_PD again?  Those two should be on separate timers.  The
preferred/valid/T1/T2 timers are all per IA, and the IA_NA is separate from
the IA_PD.

On Tue, Jul 26, 2011 at 13:38, Hemant Singh (shemant) <[email-masked]>wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

-- 
<http://www.incognito.com>

Andre Kostur
Senior Software Design Engineer
P: 604-678-2864
SIP: [email-masked]

<http://www.incognito.com>

---

From: Andre Kostur <[email-masked]>
Date: Wed, 27 Jul 2011 08:32:13 -0700

(Whups... I meant "Why would the _client_ necessarily wait....")

Again, why shouldn't the CPE wait the natural lifespan of the IA_NA before
talking about it again?  The CPE has lots of uses for the IA_NA.  Namely
it's own management, SNMP monitoring, source IP for syslog notifications,
whatever.  Otherwise why does it want an IA_NA at all?  The client device
shouldn't be tying the IA_NA together with the IA_PD.  They are separate
transactions that may travel together in a single DHCP packet.

Not to put words in Ted's mouth, but I believe he was asking the same
question.  Why should the device abandon the perfectly good IA_NA that it
has (or could have) already obtained just because the IA_PD was wrong.  If
the IA_NA stuff was changed on the DHCP server, the DHCP server knows who
already has a lease which may be affected by whatever configuration change
happened and either the admin can wait for the IA_NA to timeout (Renew,
Rebind, or expiry), or explicitly send a Reconfigure to the device.
 Prevents this errant device from endlessly pounding the DHCP server about
an IA_NA that it has already given the device.

PS: I slightly misspoke about the preferred/valid times being per IA, those
are per-iaddr, or prefix).

On Wed, Jul 27, 2011 at 06:04, Hemant Singh (shemant) <[email-masked]>wrote:

>  ** **
>
> *From:* Andre Kostur [mailto:[email-masked]]
> *Sent:* Tuesday, July 26, 2011 4:55 PM
> *To:* Hemant Singh (shemant)
> *Cc:* Ted Lemon; [email-masked]; IPv6 Operations
> *Subject:* Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr
> bis doc****
>
> ** **
>
> talking about the IA_PD again?  Those two should be on separate timers.  The
> the IA_PD.****
> timeout.   If a CPE router has failed IA_PD acquisition, the IA_NA is not
> much use for the CPE and then CPE should try DHCPv6 forever to get both an
> IA_NA and IA_PD.  The CPE router DHCv6 client hasn’t even completed DHCPv6
> to consider a client renewal/rebind or the server to send a Reconfigure.**
> **
>
> ** **
>
> Hemant****
>

Andre Kostur

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 27 Jul 2011 14:31:51 -0500

From: Andre Kostur [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 11:32 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; IPv6 Operations
Subject: Re: [dhcwg] socializing new DHCPV6 req in the IETF IPV6 CE rtr
bis doc

>The CPE has lots of uses for the IA_NA.  Namely it's own management,
SNMP monitoring, source IP for syslog notifications, whatever. 

The CPE rtr document supports both a managed CPE and a unmanaged CPE.
There is no SNMP in the unmanaged case, nor any syslog.  I don't
understand "own management".   Without the IA_PD no device in the home
will be able to obtain an IPv6 address that is globally routable via the
SP network.    Thus one broadband deployment in the cable one has
already specified a CPE rtr inside a cable modem deems IP address
acquisition as failed unless both of the IA_NA and IA_PD are obtained
from the DHCPv6 server. 

>Otherwise why does it want an IA_NA at all?  The client device
shouldn't be tying the IA_NA together with the IA_PD.  They are separate
transactions that may tr>avel together in a single DHCP packet.

The CPE rtr document supports an unnumbered WAN or a numbered WAN when
the WAN has an IA_NA assigned.   There are several uses for the IA_NA
that have been discussed during the past four years in the IETF.   Will
get to those later.  

Not to put words in Ted's mouth, but I believe he was asking the same
question.  Why should the device abandon the perfectly good IA_NA that
it has (or could have) already obtained just because the IA_PD was
wrong.  

The IA_PD  was responded to by a failure error code - it wasn't a wrong
PD.   Thus the CPE router resets and starts DHCPv6 again.   So why
should the CPE rtr not send both options in the new SOLICIT?

If the IA_NA stuff was changed on the DHCP server, the DHCP server knows
who already has a lease which may be affected by whatever configuration
change happened and either the admin can wait for the IA_NA to timeout
(Renew, Rebind, or expiry), or explicitly send a Reconfigure to the
device.  

Operator intervention is not acceptable in a SP broadband network and
also the intervention can be delayed.   I have already spoken to this
fact. 

Prevents this errant device from endlessly pounding the DHCP server
about an IA_NA that it has already given the device.

Each day in a cable SP deployment we see a failed DHCPv4 client try
forever.  I am not sold on endless pounding of the server.  Actually
some pounding at the server is a cue to the admin to look into their
server configuration.   

Hemant