A few comments.
2.2 RFC2373 - IP Version 6 Addressing Architecture
The IPv6 Addressing Architecture [RFC-2373] is a mandatory part of
IPv6. Currently, this specification is being updated by
[ADDRARCHv3]; therefore, this specification may be made obsolete by
the new one, in which case the new specification must be supported.
==> Procedural question: how could a Standard Track document have a
normative, "must be supported" reference to a work-in-progress?
2.3 RFC2460 - Internet Protocol Version 6
[...]
The cellular host must always be able to receive and reassemble
fragment headers. It will also need to be able to send a fragment
header in cases where it communicates with an IPv4 host through a
translator.
==> I don't understand your argument about sending fragment headers. Do
you have some specific translator mechanism in mind? Could you elaborate?
2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6
Multicast Listener Discovery [RFC-2710] may be supported, if the
cellular host is supporting applications that require the use of
multicast services.
==> Bad wording: "may be supported ... if ..."? Of course all kinds of
specifications may be supported anyway. "Should"? "may have to be"?
There is no need for MLD if the host only
supports the well-known (hard coded in IPv6 implementations) link
local multicast addresses. MLD is not used for listening on such
addresses.
==> s/link local/link-local/
2.11 RFC2893 - Transition Mechanisms for IPv6 Hosts and Routers
[RFC-2893] specifies a number of transition mechanisms for IPv6
hosts. Cellular hosts may support the dual stack mechanism mentioned
in this specification. This also includes resolving addresses from
the DNS and selecting the type of address for the correspondent host
(IPv4 vs. IPv6). Cellular hosts should not support configured or
automatic tunnels to avoid unnecessary tunneling over the air
interface, unless there are no other mechanisms available. Tunneling
can lead to poor usage of available bandwidth.
==> Has the interaction between this and Appandix C: Transition Issues
been coordinated? It seems there may be some overlap here.
2.15 Default Address Selection for IPv6
Default Address Selection for IPv6 [DEFADDR] is needed for cellular
hosts with more than one address.
==> Isn't this statement completely empty of meaning. All IPv6 hosts have
more than one address (link-local + global/site-local/whatever)..? Also
DEFADDR considers IPv4 addresses.
2.16 DNS
Cellular hosts should support DNS, as described in [RFC-1034], [RFC-
1035] and [RFC-1886].
If DNS is used, a cellular host should perform DNS requests in the
recursive mode, to limit signaling over the air interface.
==> I completely agree, but this requires the servers support (or rather:
haven't disabled the support for) recursive queries. I guess this only
depends on the network topology. If DNS servers are managed by the
cellular operator, this should be no problem.
3.8 RFC2407 - The Internet IP Security DoI for ISAKMP
[...]
It is likely that several simplifying assumptions can be made in the
cellular environment, with respect to the mandated parts of the IP
Security DoI, ISAKMP, and IKE. Although work on such simplifications
would be useful, is not described here.
==> s/useful, is/useful, it is/ ? (Otherwise, the sentence sounds a bit
awkward too.)
Appendix B Cellular Host IPv6 Addressing in the 3GPP Model
[...]
In order to support the standard IPv6 stateless address
autoconfiguration mechanism, as recommended by the IETF, the GGSN
shall assign a prefix that is unique within its scope to each
primary PDP context that uses IPv6 stateless address
autoconfiguration.
==> 'unique within its scope' sounds rather scary, but I guess this was
written vaguely intentionally to allow the use of site-local addresses.
(Note: this also allows for the use of link + site-local addresses without
global addresses, but I guess that's ok.)
The GGSN always provides an Interface Identifier to
the mobile host.
==> Is that IID trackable? If so, this might be worth mentioning in
security considerations' second "bullet": If IID is trackable (like EUI64
is), changing the prefix doesn't help with privacy.
Appendix C Transition Issues
[...]
The tunneling mechanism specified by [RFC-2529] is not relevant for
a cellular host. [RFC-2529] allows isolated IPv6-only hosts to
connect to an IPv6 router via an IPv4 domain. The scenario of an
IPv6-only host in an IPv4-only cellular network is considered
unlikely.
==> I feel this may be redundant: the draft _could_ list a lot of other
mechanisms like DSTM but doesn't (Actually DSTM could be highly usable for
cellular hosts of this kind if the only network connectivity they have is
v6 but do have dual-stack). The use of 'IPv6-only' is also confusing
here: IPv6-only often refers to a host which has _no_ IPv4 support.
RFC2529 does require IPv4 support when sending and receiving Neighbor
Discovery packets using IPv4 multicast.
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
