Subject: Cellular host issues

From: Jari Arkko <[email-masked]>
Date: Fri, 24 May 2002 01:19:34 +0300

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-masked]
--------------------------------------------------------------------

---

From: Randy Bush <[email-masked]>
Date: Thu, 23 May 2002 17:55:42 -0700

>           queries may not be supported by all DNS servers."

[ feel free to ignore this, but ]

you may want to note that one can not trust (in the dnssec sense)
the result from a query that caused recursion.  one has to do the
traversal.  there has been some discussion of the device having a
trust association (see TSIG) with a (caching recursive) server
which does the checking for one, but it has not converged.

randy

---

From: Jari Arkko <[email-masked]>
Date: Fri, 24 May 2002 10:59:40 +0300

Randy Bush wrote:

> the result from a query that caused recursion.

Good point, thanks. I will add a note about this to the text:

          "... Furthermore, recursive queries may not be
           supported by all DNS servers, and may not be
           always possible with secure DNS."

Jari

---

From: Randy Bush <[email-masked]>
Date: Fri, 24 May 2002 06:46:37 -0700

>            always possible with secure DNS."

well, they're *possible*.  they're just not secure.

randy