[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts"
> 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
> ==> 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
> ==> 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
> ==> 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.
=> 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
> 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
> ==> '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
> ==> 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
> here: IPv6-only often refers to a host which has _no_ IPv4
> 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,
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@example.com