Subject: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Genera tion Cellular Hosts"

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 22 May 2002 17:30:25 +0200

> First, I'll deal with the technical/content issues:
  > 
  > (1) I think that this document should explicitly state, in the 
  > introduction, that it is not a standard and is not intended to
  > modify or contradict any IPv6 standard documents.  I thought that
  > we had agreed to something like this earlier.

=> This was in the document, then we received another
comment stating that since the RFC states whether
it is informational, standards ...etc, there is no
need to say this in the doc. 

  > 
  > (2) The document states:
  > 
  >     "Additionally, due to special characteristics of the 
  > cellular link, 
  >     lower layer connectivity information should make it 
  > unnecessary to 
  >     track the reachability of the router. Therefore, while 
  > the host must 
  >     support Neighbor Solicitation and Advertisement 
  > messages, their use 
  >     is not necessary and the host may choose to not initiate them."
  > 
  > Although I understand the desire to supress NUD messages on 
  > point-to-point cellular links, this isn't how/why this should
  > be done.
  > 
  > IPv6 hosts must include a full implementation of Neighbor Discovery,
  > including NUD with the full ND state machine, etc.  Any compromise
  > on this effectively results in two different types of IPv6 hosts,
  > each with different behaviours/failure modes, etc.   That 
  > is something 
  > that we definitely want to avoid.
  > There is no magic (in 3GPP or any other network) that can 
  > guarantee that another node is always reachable, but it is 
  > certainly possible for other layers of the protocol stack 
  > (outside of IP) to maintain information about reachability, 
  > and to know, at a given time, that another node is reachable.
  > ND includes the ability for those other protocol layers to 
  > provide advice to the NUD code to indicate that a remote host 
  > is reachable (only when those layers have confirmed two-way
  > reachability), which results in the supression of NUD messages
  > when the network is operating properly.  The other layers of
  > 3GPP should provide this advice to ND.
  > 
  > In cases were the GGSN actually does become unreachable, NUD
  > messages will be sent.  But, in fact that NUD actually 
  > _reduces_ the 
  > amount of traffic that will sent over the air interface 
  > while the GGSN is 
  > unreachable, so this is actually a good thing for 3GPP.
  > 
  > Instead of indicating that parts of ND are optional, or that
  > 3GPP hosts may "choose to not" use them, we should be indicating
  > what layers of 3GPP should provide reachability advice to ND at
  > what points.  If those other layers can confirm two-way reachability
  > on an ongoing basis, they can provide frequent advice that will
  > result in the supression of all NUD messages when things are
  > operating properly.

=> I understand your points, however, we cannot say
that 3GPP 'should' do anything. We are dealing with
existing 3GPP and IETF specs. Luckily, for this particular
case, the information is already available to those
who can use it, so we can add more text to 
highlight that hosts should use  the lowe layers'
reachability information.

  > 
  > (3) The document states:
  > 
  >     "This specification [RFC-2402] must be supported. 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."
  > 
  > I don't like the idea of writing a document today that tells 
  > implementors that it is possible that something will be made
  > optional in the future.  Today it is mandatory.  Period.

=> OK.

  > 
  > (4) The document states:
  > 
  > "4. Mobility  
  >      
  >     For the purposes of this document, IP mobility is not 
  > relevant. When 
  >     Mobile IPv6 specification is approved, a future update to this 
  >     document may address these issues, as there may be some 
  > effects on 
  >     IPv6 hosts due to Mobile IP. The movement of cellular 
  > hosts within 
  >     3GPP networks is handled by link layer mechanisms."
  > 
  > There is a portion of mobility -- I believe that is is called the
  > "correspondent node option", or something like that -- that must be
  > implemented in all IPv6 hosts, in order to allow optimal routing
  > to mobile nodes that are away from their home networks.  
  > This document
  > should indicate that support for that feature is required.

=> Within the current MIPv6 spec, this CN portion is 
nothing. I.e. nothing to add to a standard IPv6
host.

I'll send a separate reply for editorials. 

Thanx,
Hesham

  > Now, for the editorial issues:
  > 
  > (5) In section "1 Introduction", the only paragraph is not
  > properly laid out -- not clear if it is meant to be one or
  > two paragraphs.
  > 
  > (6) The document states:
  > 
  >     "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. "
  > 
  > The "should not support...unless there are no other" construct
  > is somewhat confusing, since there probably isn't any way for
  > a host to know whether there are other mechanisms available.
  > 
  > Although I understand why tunneling should be avoided over the
  > air interface if possible, I don't understand why this is a host
  > implementation issue.  Isn't this more of an issue for the
  > operators?  If so, it probably doesn't belong in this document.
  > 
  > (7) As someone else mentioned, the following sentence is 
  > similarly confusing:
  > 
  >     "Multicast Listener Discovery [RFC-2710] may be 
  > supported, if the 
  >     cellular host is supporting applications that require 
  > the use of 
  >     multicast services."
  > 
  > (8) I also think that the following sentence is more advice for 3GPP
  > network operators, than it is specific to cellular hosts:
  > 
  >     "Hence, 
  >     intermediate 6to4 routers should carry out 6to4 
  > tunneling, instead 
  >     of cellular hosts."
  > 
  > There is an ongoing effort in the ngtrans WG to discuss transition
  > scenarios for 3GPP (run by Jonne Soininen), and it is expected that
  > that group will define what type of transition mechanisms are most
  > applicable to 3GPP networks.  So, perhaps it is best to leave this
  > operator advice for that group?  
  > 
  > (9) I don't think that you should put "Manyfolks" in the footers,
  > in the place of the author name.  List the first author with et.al.
  > Or, better yet, switch to listing an editor in the footer and at
  > the top of the document, and list the authors in a section at the
  > end.
  > 
  > Margaret
  > 
  > 
  > 
  > 
  > 
  > 
  > --------------------------------------------------------------------
  > 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]
  > --------------------------------------------------------------------
  > 
--------------------------------------------------------------------
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: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 May 2002 08:53:08 -0700

Hello folks,

> nothing. I.e. nothing to add to a standard IPv6

That is under discussion.  In fact, I strongly believe that EVERY
IPv6 correspondent node MUST implement return routability procedures.
Furthermore, every IPv6 node already MUST implement Home Address Option.

Here is the current text:

========================================================================

8.1. Requirements for All IPv6 Hosts and Routers
   
   Since any IPv6 node may at any time be a correspondent node of a
   mobile node, either sending a packet to a mobile node or receiving a
   packet from a mobile node, the following requirements apply to ALL
   IPv6 nodes (whether host or router, whether mobile or stationary):

    -  Every IPv6 node MUST be able to process a Home Address option
       received in any IPv6 packet.

    -  Every IPv6 node SHOULD be able to participate in a return
       routability procedure, process Binding Update messages, and to
       return a Binding Acknowledgement option if the Acknowledge (A)
       bit is set in the received Binding Update.

    -  Every IPv6 node SHOULD be able to maintain a Binding Cache of the
       bindings received in accepted Binding Updates.

========================================================================

Furthermore, even if those SHOULDs remain SHOULDs (a mistake, in
my opinion), a _cellular_ host is a case where it MUST be a MUST.
Such nodes are even more likely than generic IPv6 nodes to be
maintaining communications with mobile nodes -- for instance with
VoIP.

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 22 May 2002 10:35:20 -0700

Charlie,

> maintaining communications with mobile nodes -- for instance with

I agree with the level of "required to implement" as specified in the
text above.

            jak