Section 1
=========
Sure - no problem.
Section 2 Steps 1-4
===================
These steps are absolutely necessary. They derive from RFC2461, but are
spread throughout and implied by the RFC. Our goal is not to add new
requirements in this draft. Our goal is simply to reiterate, in one
place, all the rules pertaining to the IPv6 Subnet Model so that
implementers and testers will be able to look in one place and quickly
understand the implications of the IPv6 Subnet Model.
Tatuya Jinmei already commented on this draft, writing that the
statement in the Security Consideration section should be written
earlier in the draft. The statement in question is:
"As this document merely restates and clarifies RFC 4861, it does not
introduce any new security issues."
We will add it again in the introduction section in order to reiterate
our draft's intentions.
Section 2 Step 5.3
==================
RFC 4861 describes the proper use of the ICMP destination unreachable
indication (including the destination, if any):
"ICMP destination unreachable indication
- an error indication returned to the original sender of
a packet that cannot be delivered for the reasons
outlined in [ICMPv6]. If the error occurs on a node
other than the node originating the packet, an ICMP
error message is generated. If the error occurs on the
originating node, an implementation is not required to
actually create and send an ICMP error packet to the
source, as long as the upper-layer sender is notified
through an appropriate mechanism (e.g., return value
from a procedure call). Note, however, that an
implementation may find it convenient in some cases to
return errors to the sender by taking the offending
packet, generating an ICMP error message, and then
delivering it (locally) through the generic error-
handling routines."
This "SHOULD" came from Alain Durand's RFC 4943.
- Wes
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Suresh Krishnan
Sent: Monday, March 10, 2008 5:08 PM
To: [email protected]
Subject: Review of draft-wbeebee-on-link-and-off-link-determination-02
Hi Folks,
I read the latest version of the draft and it very clearly
articulates the problem it is trying to address. Thanks for doing this.
I have a few comments.
Section 1
=========
Change
"The reception of a Prefix Information Option (PIO) with the L-bit set
and a non-zero valid lifetime creates (or updates the valid lifetime
for an existing entry) in the prefix list. "
to
"The reception of a Prefix Information Option (PIO) with the L-bit set
and a non-zero valid lifetime creates an entry (or updates the valid
lifetime for an existing entry) in the prefix list."
Section 2 Steps 1-4
===================
It is not clear from the draft if steps 1-4 need to be followed by
RFC2461 compliant hosts. My understanding is no, but feel free to
correct me if I am wrong.
Section 2 Step 5.3
==================
"When address resolution fails, the host SHOULD send an ICMPv6
Destination Unreachable message."
Where should the node send this message. Isn't it enough to indicate to
the requesting application that the destination is not reachable using
some kind of indication?
Cheers
Suresh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
