ietf
[Top] [All Lists]

RE: [Softwires] Last Call: <draft-ietf-softwire-6rd-radius-attrib-07.txt> (RADIUS Attribute for 6rd) to Proposed Standard

2012-11-19 10:07:35
Hi, Roberta and Leaf,

Carefully checked RFC2131, the original text was right, but not clearly define 
the time that client enters REBINDING state. So Leaf's comments also right. New 
text will be the below. It would be added after AD's instruction for next 
update, maybe with other comments from IESG. 

If the DHCP server to which the DHCP Request message was sent at time 
   T1 has not responded "till T2", the DHCP client enters the REBINDING state 
and 
   attempts to contact any server.

Many thanks and best regards,

Sheng

-----Original Message-----
From: Maglione Roberta 
[mailto:roberta(_dot_)maglione(_at_)telecomitalia(_dot_)it]
Sent: Friday, November 16, 2012 10:09 PM
To: 'Leaf Yeh'; Sheng Jiang
Cc: softwires(_at_)ietf(_dot_)org; dhcwg(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)org
Subject: RE: [Softwires] Last Call: 
<draft-ietf-softwire-6rd-radius-attrib-07.txt>
(RADIUS Attribute for 6rd) to Proposed Standard

Leaf,
In my opinion current text is fine and inline with RFC2131, while the text you
are proposing is not completely accurate because it does not clarify "which
DHCP Server" has not replied.

'If the DHCP server has not replied the
DHCPREQUEST message till T2, the DHCP client enters into the REBINDING
state
and attempts to contact any possible server. '

Sheng,
As original author of this text, what do you think?

Thanks,
Roberta

-----Original Message-----
From: Leaf Yeh [mailto:leaf(_dot_)yeh(_dot_)sdo(_at_)gmail(_dot_)com]
Sent: Friday, November 16, 2012 2:58 PM
To: Maglione Roberta; ietf(_at_)ietf(_dot_)org
Cc: softwires(_at_)ietf(_dot_)org; dhcwg(_at_)ietf(_dot_)org
Subject: RE: [Softwires] Last Call: 
<draft-ietf-softwire-6rd-radius-attrib-07.txt>
(RADIUS Attribute for 6rd) to Proposed Standard

<Roberta> According to section 4.4.5 of RFC 2131:
" At time T1 the client moves to RENEWING state and sends (via unicast)
  a DHCPREQUEST message to the server to extend its lease."
[..]
" If no DHCPACK arrives before time T2, the client moves to REBINDING
  state and sends (via broadcast) a DHCPREQUEST message to extend its
  lease."
The DHCPREQUEST is sent at T1, in my opinion the current text is correct.
</Roberta>


Correct but not accurate. The client enters the rebinding state after T2
expired.

How about to update the text to be 'If the DHCP server has not replied the
DHCPREQUEST message till T2, the DHCP client enters into the REBINDING
state
and attempts to contact any possible server. '?


Best Regards,
Leaf



-----Original Message-----
From: Maglione Roberta 
[mailto:roberta(_dot_)maglione(_at_)telecomitalia(_dot_)it]
Sent: Friday, November 16, 2012 9:13 PM
To: 'Leaf Yeh'; ietf(_at_)ietf(_dot_)org
Cc: softwires(_at_)ietf(_dot_)org; <dhcwg(_at_)ietf(_dot_)org> WG
Subject: RE: [Softwires] Last Call:
<draft-ietf-softwire-6rd-radius-attrib-07.txt> (RADIUS Attribute for 6rd) to
Proposed Standard

Hi Leaf,
Section 3 - If the DHCP server to which the DHCP Request message was sent
at time  T1 has not responded, the DHCP client enters the REBINDING
state
and  attempts to contact any server.

Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'.
(http://www.rfc-editor.org/rfc/rfc2131.txt)

Why T2?
According to section 4.4.5 of RFC 2131:
" At time T1 the client moves to RENEWING state and sends (via unicast)
  a DHCPREQUEST message to the server to extend its lease."
[..]

" If no DHCPACK arrives before time T2, the client moves to REBINDING
  state and sends (via broadcast) a DHCPREQUEST message to extend its
  lease."

The DHCPREQUEST is sent at T1, in my opinion the current text is correct.
Thanks
Regards,
Roberta

-----Original Message-----
From: softwires-bounces(_at_)ietf(_dot_)org 
[mailto:softwires-bounces(_at_)ietf(_dot_)org] On
Behalf Of Leaf Yeh
Sent: Friday, November 16, 2012 1:44 PM
To: ietf(_at_)ietf(_dot_)org
Cc: softwires(_at_)ietf(_dot_)org
Subject: Re: [Softwires] Last Call:
<draft-ietf-softwire-6rd-radius-attrib-07.txt> (RADIUS Attribute for 6rd) to
Proposed Standard

Section 3 - After the BNG responds to the user with
  an Advertise message, the user requests for a DHCP 6rd Option by
  carrying a Parameter Request option (55) [RFC2132].

Per the Figure 1 in Section 3, the above 'Advertise message' sounds the
DHCPv4 message of 'DHCPOFFER (2)'.
(http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-para
meters
.xml)


Section 3 - If the DHCP server to which the DHCP Request message was sent
at
time
  T1 has not responded, the DHCP client enters the REBINDING state and
  attempts to contact any server.

Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'.
(http://www.rfc-editor.org/rfc/rfc2131.txt)


Best Regards,
Leaf





-----Original Message-----
From: softwires-bounces(_at_)ietf(_dot_)org 
[mailto:softwires-bounces(_at_)ietf(_dot_)org] On
Behalf Of The IESG
Sent: Friday, November 16, 2012 5:39 AM
To: IETF-Announce
Cc: softwires(_at_)ietf(_dot_)org
Subject: [Softwires] Last Call:
<draft-ietf-softwire-6rd-radius-attrib-07.txt> (RADIUS Attribute for 6rd) to
Proposed Standard


The IESG has received a request from the Softwires WG (softwire) to consider
the following document:
- 'RADIUS Attribute for 6rd'
 <draft-ietf-softwire-6rd-radius-attrib-07.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2012-11-29. Exceptionally, comments 
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the 
beginning
of the Subject line to allow automated sorting.

Abstract


  IPv6 Rapid Deployment (6rd) is one of the most popular methods to
  provide both IPv4 and IPv6 connectivity services simultaneously
  during the IPv4/IPv6 co-existing period. The Dynamic Host
  Configuration Protocol (DHCP) 6rd option has been defined to
  configure 6rd Customer Edge (CE). However, in many networks, the
  configuration information may be stored in Authentication
  Authorization and Accounting (AAA) servers while user configuration
  is mainly from Broadband Network Gateway (BNG) through DHCP
protocol.
  This document defines a Remote Authentication Dial In User Service
  (RADIUS) attribute that carries 6rd configuration information from
  AAA server to BNG.






The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballot
/


No IPR declarations have been submitted directly on this I-D.


_______________________________________________
Softwires mailing list
Softwires(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/softwires

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.