[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MEXT] [Technical Errata Reported] RFC5648 (1904)
- To: ryuji.wakikawa at gmail.com, vijay at wichorus.com, Tsirtsis at gmail.com, thierry.ernst at inria.fr, nagami at inetcore.com, rdroms at cisco.com, jari.arkko at piuha.net, marcelo at it.uc3m.es, julienl at qualcomm.com
- Subject: [MEXT] [Technical Errata Reported] RFC5648 (1904)
- From: RFC Errata System <rfc-editor at rfc-editor.org>
- Date: Thu, 8 Oct 2009 07:56:52 -0700 (PDT)
- Cc: ah at TR-Sys.de, rfc-editor at rfc-editor.org, mext at ietf.org
- Delivered-to: mext at core3.amsl.com
- List-archive: <http://www.ietf.org/mail-archive/web/mext>
- List-help: <mailto:mext-request@ietf.org?subject=help>
- List-id: Mobile IPv6 EXTensions WG <mext.ietf.org>
- List-post: <mailto:mext@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
The following errata report has been submitted for RFC5648,
"Multiple Care-of Addresses Registration".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5648&eid=1904
--------------------------------------
Type: Technical
Reported by: Alfred Hoenes <ah at TR-Sys.de>
Section: 6.2, pg.25
Original Text
-------------
a)
In Section 4.3, the description of the 'Care-of Address' field
in the Binding Identifier Mobility Option specifies:
Care-of Address
If a Binding Identifier mobility option is included in a Binding
Update for the home registration, either IPv4 or IPv6 care-of
addresses for the corresponding BID can be stored in this field.
For the binding registration to correspondent nodes (i.e., route
optimization), only IPv6 care-of addresses can be stored in this
field. If no address is specified in this field, the length of
! this field MUST be zero (i.e., not appear in the option). If the
! option is included in any messages other than a Binding Update,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
! the length of this field MUST also be zero.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
b)
Contrary to the "MUST" in the last line, Section 6.2 of the RFC says,
on mid-page 25, where it elaborates on Binding Acknowledgement messages:
If all the above operations are successfully completed and the 'A'
flag is set in the Binding Update, a Binding Acknowledgement
containing the Binding Identifier mobility options MUST be sent to
! the mobile node. Whenever a Binding Acknowledgement is sent, all the
^^^^^^^^^^^^^^^^^^^^^^^
! Binding Identifier mobility options stored in the Binding Update MUST
! be copied to the Binding Acknowledgement except the Status field.
! The Care-of Address field in each Binding Identifier mobility option,
| however, MAY be omitted, because the mobile node can match a
^^^
! corresponding Binding Update List entry using the BID.
Corrected Text
--------------
a)
<< no change >>
b)
If all the above operations are successfully completed and the 'A'
flag is set in the Binding Update, a Binding Acknowledgement
containing the Binding Identifier mobility options MUST be sent to
the mobile node. Whenever a Binding Acknowledgement is sent, all the
Binding Identifier mobility options stored in the Binding Update MUST
be copied to the Binding Acknowledgement except the Status field.
The Care-of Address field in each Binding Identifier mobility option,
| however, MUST be omitted, because the mobile node can match a
corresponding Binding Update List entry using the BID.
Notes
-----
Rationale:
The inconsistency is described with the Original Text.
The Corrected Text proposed gives preference to the requirement
from Section 4.3, which seems to be reasonable for efficiency
and consistent with other parts of the specification.
Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC5648 (draft-ietf-monami6-multiplecoa-14)
--------------------------------------
Title : Multiple Care-of Addresses Registration
Publication Date : October 2009
Author(s) : R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami
Category : PROPOSED STANDARD
Source : Mobility EXTensions for IPv6
Area : Internet
Stream : IETF
Verifying Party : IESG