Subject: [v6ops] RFC6204bis-03

From: Wuyts Carl <[email-masked]>
Date: Wed, 23 Nov 2011 10:58:57 +0100

I must say I'm a bit surprised to already see the SOL_MAX_RT req popping up as a "MUST" into this version of RFC6204bis as it's still quite heavily discussed (and by the looks of it, not really commonly accepted).  Isn't it a bit too early to do this already ?

This is the req I'm talking about:
WAA-8:  The CE Router MUST parse the DHCPv6 SOL_MAX_RT option
           [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6
           Advertise or Reply message and set its internal SOL_MAX_RT
           parameter to the value contained in the SOL_MAX_RT option.

Appendix message:
9.   Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so
        that if an service provider does not have DHCPv6 service enabled
        CE routers do not send too frequent DHCPv6 requests to the
        service provider DHCPv6 server

Carl Wuyts
GCD System Architect Networking
Connect Division

[email-masked]<mailto:[email-masked]>
tel.: +32 3 443 65 90
<http://twitter.com/#!/TechnicolorIPv6>
<http://www.technicolor.com/>
Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium

Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

Help preserve the color of our world - Think before you print.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Nov 2011 04:29:39 -0600

Carl,

Not a surprise.  Even the -02 version includes the MAX_SOL_RT text as
shown below.  We changed the text a little since Ralph's draft has been
published and we could reference the document.

[WAA-8:  The IPv6 CE router MUST set SOL_MAX_RT (specified by

           [RFC3315]) to 7200 seconds.]

During the IETF in Taipei the MAX_SOL_RT was discussed in the v6ops WG
and also the DHC WG.  We  have rough consensus to move forward with this
requirement to alleviate a DHCPv6 server storm. 

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Wuyts Carl
Sent: Wednesday, November 23, 2011 4:59 AM
To: [email-masked]
Subject: [v6ops] RFC6204bis-03

I must say I'm a bit surprised to already see the SOL_MAX_RT req popping
up as a "MUST" into this version of RFC6204bis as it's still quite
heavily discussed (and by the looks of it, not really commonly
accepted).  Isn't it a bit too early to do this already ?

Appendix message:

 

Carl Wuyts

Connect Division

[email-masked] <mailto:[email-masked]> 

tel.: +32 3 443 65 90

Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650
Edegem, Belgium

Company registration number (ondernemingsnummer): 0428837295 - RPR
Antwerpen

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 23 Nov 2011 11:53:03 +0100

Correct, but the req is quite different to implement from CPEs point-of-view and, as you mention, discussed in DHC WG.  You mention a "rough consensus"; I must say I did not really see a real consensus in the big load of emails on the topic. So might have missed that one.

Carl Wuyts

From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: woensdag 23 november 2011 11:30
To: Wuyts Carl; [email-masked]
Subject: RE: [v6ops] RFC6204bis-03

Carl,

Not a surprise.  Even the -02 version includes the MAX_SOL_RT text as shown below.  We changed the text a little since Ralph's draft has been published and we could reference the document.

During the IETF in Taipei the MAX_SOL_RT was discussed in the v6ops WG and also the DHC WG.  We  have rough consensus to move forward with this requirement to alleviate a DHCPv6 server storm.

Hemant

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: Wednesday, November 23, 2011 4:59 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [v6ops] RFC6204bis-03

Appendix message:

Carl Wuyts

---

From: Ole Troan <[email-masked]>
Date: Wed, 23 Nov 2011 12:04:49 +0100

Carl,

> Correct, but the req is quite different to implement from CPEs point-of-view and, as you mention, discussed in DHC WG.  You mention a “rough consensus”; I must say I did not really see a real consensus in the big load of emails on the topic. So might have missed that one.

indeed. this is work in progress. there are other changes needed in DHCP too.

cheers,
Ole

> CONNECT DIVISION
> [email-masked]
> tel.: +32 3 443 65 90
> Not a surprise.  Even the -02 version includes the MAX_SOL_RT text as shown below.  We changed the text a little since Ralph’s draft has been published and we could reference the document.
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Wuyts Carl
> I must say I’m a bit surprised to already see the SOL_MAX_RT req popping up as a “MUST” into this version of RFC6204bis as it’s still quite heavily discussed (and by the looks of it, not really commonly accepted).  Isn’t it a bit too early to do this already ?
>  
> This is the req I’m talking about:
> CONNECT DIVISION
> [email-masked]
> tel.: +32 3 443 65 90
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Nov 2011 05:16:02 -0600

From: Wuyts Carl [mailto:[email-masked]] 
Sent: Wednesday, November 23, 2011 5:53 AM
To: Hemant Singh (shemant); [email-masked]
Subject: RE: [v6ops] RFC6204bis-03

>Correct, but the req is quite different to implement from CPEs
point-of-view and, as you mention, discussed in DHC WG.  You mention a
"rough consensus"; I must say I did not really see a >real consensus in
the big load of emails on the topic. So might have missed that one.

The req changed between the -02 and the -03 versions of rfc6204bis
because at first we were given the 7200 value to change to for the
MAX_SOL_RT.  Then when the draft

http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00

was published the value change to 3600.  It's RFC3315 that will be
updated by the maxsolrt-update draft for the 3600 value.   See section
2 of the maxsolrt-update draft.   Thereafter the maxsolrt-update draft
defines a new MAX_SOL_RT option in section 3 and that is what the -03
version of rfc6204bis focused on.

Hemant