<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-parameters
.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.