[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 
  > 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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------