Hi Jari,
Here is my feedback on your suggested changes. I've only included the
changes that were related to my feedback. Most of them look good.
>1) Document status should be visible
>
> We will put the status back to the document.
> The following statement will be added to the
> introduction chapter:
>
> "This document is informational in nature, and it
> is not intended to replace, update, or contradict
> any IPv6 standards documents [RFC-2026]."
Looks good to me.
>3) Whether NUD needs to be done or not
>
> Based on the discussion on the list, 3GPP connections appear to
> be able to ensure host - GGSN e2e two-way reachability,
> all the way up to ensuring that GGSN IP layer is reachable.
I am not sure about this... What I understood from the discussion is that
the SGSN will know if the GGSN becomes unreachable. Although this
may be over the SGSN <-> GGSN IP layer, this is all at layer 2 WRT the IP
link between the handset and the GGSN.
The absense of third-party (SGSN) notification that there is a problem can
not be considered positive proof of reachability. Also, I don't understand
how anything involving the SGSN can prove two-way reachability at the IP
layer between the GGSN and the handset.
Could someone elaborate on this mechanism, or give me a pointer to the
specification that explains it?
NUD should only be updated to indicate that a neighbor is reachable when
two-way reachability can be confirmed at or above the IPv6 layer -- for instance,
a TCP acknowledgement received for previously unacknowledged data will
prove that there was two way reachability at the time that data was sent.
I think that we should be fairly explicit in defining what 3GPP layers could
be used to update NUD, if any.
Regardless, though, of whether a 3GPP layer can update NUD, the TCP layer
and some UDP applications should be able to do so. So, if the TCP layer is
implemented properly, NUD messages can be supressed for all TCP applications
(i.e. web browsing, e-mail, etc.).
Therefore, I think that it is most useful to state that 3GPP host stacks should
include a TCP that provides reachabilty advice to NUD.
> The text has been clarified to state that it is mandatory to
> implement not just ND in general but also NUD. Requirements for
> NUD the advice information from other layers have been listed,
> and their use has been strongly recommended.
>
> "2.4 RFC2461 - Neighbor Discovery for IPv6
>
> Neighbor Discovery is described in [RFC-2461]. This
> specification is a mandatory part of IPv6.
>
> 2.4.1 Neighbor Discovery in 3GPP Networks
>
> In GPRS and UMTS networks, some Neighbor Discovery
> messages can cause unnecessary traffic and consume
> valuable (limited) bandwidth. GPRS and UMTS links
> resemble a point-to-point link; hence, the host's
> only neighbor on the cellular link is the default
> router that is already known through Router Discovery.
> Therefore, while the host must support Neighbor
> Solicitation and Advertisement messages, their use
> in address resolution and next-hop determination is
> not necessary and the host may choose to not initiate
> them.
I don't think that we should include the last sentence of this paragraph.
> The host must support the Neighbour Solicitation and
> Advertisement messages for neighbour unreachability
> detection as specified in [RFC-2461]. However, it
> is strongly recommended that forward progress
> information from other layers is made available to the
> IP layer. This is done in order to suppress the sending of these
> messages when two-way reachability between the peer IP
> layers has been already assured using other means."
I would much prefer a section that read:
2.4.1 Neighbor Discovery in 3GPP Networks
The host must support the Neighbor Solicitation and
Advertisement messages for neighbor unreachability
detection as specified in [RFC-2461].
In GPRS and UMTS networks, it is very desireable to
conserve bandwidth. Therefore, hosts stacks used in
these environments should include a mechanism in
upper layer protocols (such as TCP) to provide
reachability confirmation when two-way reachability
can be confirmed (see RFC-2461, section 7.3.1).
These confirmations will allow the suppression of
most NUD-related messages.
[If there are any upper-layer 3GPP protocols that can
provide reachability confirmation, meeting the definition
in the ND spec, we should mention them here.]
Please note that the IPv6 specs consistenly misspell neighbour as
"neighbor" :-). We should also use that spelling in this specification.
>4) Speculation of AH's fate should not be included
>
> The following part of the text will be deleted: "The
> IPsec WG has discussed the role of AH in the future,
> and it is possible that it will be made optional in
> the future versions of the IPsec protocol set.
> Implementers are recommended to take this in account."
Fine.
>5) Correspondent node functionality to be discussed or not
>
> Based on the e-mail discussion and input from the ADs,
> it would be inappropriate to refer to an I-D in a normative
> way, hence it is hard to add anything. (Note: we are
> working hard to complete the MIPv6 specification -- even
> if it is not ready today, it will get done sooner or
> later. At that point a bis cellular host draft and/or
> general ipv6 node requirements document can be issued
> with MIPv6 included.)
Okay.
>6) Tunneling avoidance over air recommendation
>
> The intention was to talk about use, not
> implementation. However, it is perhaps best that
> both this and the 6to4 recommendation are dealt with
> by the ngtrans WG team, and we can thus leave both
> 2.11 and 2.13 out of the document.
Sounds good.
>7) Place of the 6to4 recommendation
>
> We will leave this recommendation out, and to be handled by the
> effort in the ngtrans WG.
Sounds good.
>8) Editorial comments
>
> We have tried to correct the editorial comments.
Thanks,
Margaret
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
