> 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?
=> Yes, this issue was raised by Thomas. We will fix it when we update the draft due to IESG last call or WG last call. > > 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? => RFC 2460 has some text on this, anticipating SIIT. I actually had the same thoughts (as you), but was told about this praragraph in 2460. > > 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"? > => OK we can reword it to: 'Cellular hosts may support MLD. MLD is needed if the cellular host is supporting applications that require the use of multicast services.' > 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/ => OK. > > 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. => OK. > > 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. > > => Your last statement is correct in our assumptions. So I don't think it's a 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.) =>OK. > > 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. => The IID for the _link-local_address_only. The host can use any other IIDs for addresses with scopes larger than the link-local one. No security issues here. > > 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. => There is another DT in NGTRANS that will address transition for 3GPP networks. So I'm not sure howuseful this appendix is right now. Thanks for your comments, Hesham -------------------------------------------------------------------- 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] --------------------------------------------------------------------
