Margaret's e-mail and the following discussion raised a number of
questions about the cellular host document. In the following we try
summarize the feedback and propose modifications to the document
to address the concerns. The concerns were as follows:
1) Document status should be visible
2) DNS recursive query recommendation
3) Whether NUD needs to be done or not
4) Speculation of AH's fate should not be included
5) Correspondent node functionality to be discussed or not
6) Tunneling avoidance over air recommendation
7) Place of the 6to4 recommendation
8) Editorial comments
9) MLD issues (dealt in Hesham's e-mail)
Based on our understanding of the discussion on the list, we
have formulated proposed answers and new text to handle these
concerns. Please take a look at this and let us know if they
are acceptable:
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]."
2) DNS recursive query recommendation
We need to clarify that the use of the recursive queries is
not intended to limit the functionality of the cellular hosts
or restrict the service providers to deploy DNS servers
capable of answering recursive queries. The old text
"If DNS is used, a cellular host should perform DNS requests in the
recursive mode, to limit signaling over the air interface."
will be changed to
"If DNS is used, a cellular host can perform DNS requests
in the recursive mode, to limit signaling over the air
interface. Both the iterative and the recursive approach
should be supported, however, as the specifications require
implementation of the iterative approach, and allow the
recursive approach as an option. Furthermore, recursive
queries may not be supported by all DNS servers."
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.
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.
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."
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."
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.)
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.
7) Place of the 6to4 recommendation
We will leave this recommendation out, and to be handled by the
effort in the ngtrans WG.
8) Editorial comments
We have tried to correct the editorial comments.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
