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

From: Bob Hinden <[email-masked]>
Date: Fri, 17 May 2002 12:32:30 -0700

This is a IPv6 working group last call for comments on advancing the 
following document as an Informational RFC:

      	Title		: IPv6 for Some Second and Third Generation Cellular
                          Hosts
	Author(s)	: Jari Arkko, Peter Hedman, Gerben Kuijpers,
                          Hesham Soliman, John Loughney, Pertti Suomela,
                          Juha Wiljakka
	Filename	: <draft-ietf-ipv6-cellular-host-02.txt>
	Pages		: 22
	Date		: May 17, 2002

This document has been submitted as an Internet Draft and should be 
available in the internet draft directories shortly.  Until then it can be 
found at:

   http://standards.ericsson.net/Hesham/draft-ietf-ipv6-cellular-host-02.txt

Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors.  This last call period will on May 30, 2002.

Bob Hinden / Steve Deering / Margaret Wasserman

--------------------------------------------------------------------
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: Bob Hinden <[email-masked]>
Date: Fri, 17 May 2002 13:50:19 -0700

The last call for this document will end on May 27, 2002.

The Internet Area Directors requested shortening the working group last 
call to allow time for the IESG to discuss the document to meet a 3GPP 
deadline.

Bob

---

From: [email-masked]
Date: Mon, 20 May 2002 08:43:13 +0900

>call to allow time for the IESG to discuss the document to meet a 3GPP 

	not objecting to this particular change, but is it usual thing to
	shorten deadline?

itojun

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 May 2002 11:07:35 +0300 (EEST)

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

---

From: [email-masked]
Date: Wed, 22 May 2002 17:34:53 +0900

>==> s/link local/link-local/

	actually, even for these well-known addresses MLD is used (otherwise
	switches cannot snoop these MLDs).  i could find no text that permits
	omission of MLD.  what is the reasoning behind the text?

itojun

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 May 2002 11:06:15 -0400

Hi All,

I have several comments on this document, all offered as an
individual WG member (not as a WG co-chair).

Although I understand that the 3GPP would like us to complete
this document quickly, I still have some significant issues with
this document.  I know that there is some resistance to any delay
at this point, but I believe that it is more important for us to 
produce a correct, high-quality document that actually reflects
the consensus of the group, than it is to be responsive to an
externally imposed deadline.

My issues can be broken down into two categories:

	- Technical/content issues
	- Editorial comments

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.

(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.

(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.

(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.

Can one of the MIP folks help me here?  What is it called, and where
is it defined? 

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 May 2002 20:32:49 +0300

Hi Margaret,

 > we had agreed to something like this earlier.

Yes, we had agreed this and we even had the note... until we were told
that we shouldn't re-state the type of the document in the text.

 > (snip)

Isn't this what we were trying to say? In 2.4. we state that ND
is a mandatory part of IPv6. Then the text you quoted above
was meant to say that lower layers do provide connectivity information,
leading to supression of NUD messages. Or did you want more details
as to exactly what layers, or the treatment of the error case?

But I'm not sure I understand why NUD should be sent when the
lower layers tell us that the GGSN is down -- the link is then
down, and nothing gets through. Or did I miss something?

 > optional in the future.  Today it is mandatory.  Period.

Ok, let's remove the note!

 > Can one of the MIP folks help me here?  What is it called, and where

Correspondent node functionality is in draft-ietf-mobileip-ipv6-17.txt,
section 8.1 and 9. Previous versions of cellular draft contained a more in-depth
discussion of MIPv6 functionality. However, we received again a comment that
we should remove the forward reference to the I-D.

I do agree about the correspondent node functionality part, though. However,
there's a couple of things we should observe. In the current design,
correspondent nodes do not need do anything special unless they want to
do Route Optimization. The exact keyword for Route Optimization is also being
debated. My interpretation of the discussion is that SHOULD is winning.
In any case, communications with e.g. old IPv6 nodes that do not yet
support MIPv6 are always possible without any other problems than
non-optimal routing.

Jari

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 May 2002 13:47:12 -0400

>that we shouldn't re-state the type of the document in the text.

In this case, the intended audience of the document primarily lies outside of the
IETF.  Do you think that they will really understand the difference between our
different document types?  My understanding is that the 3GPP wants this 
document to have an RFC number ASAP, so that they can use it as a 
normative reference in one of their standards... right?

>as to exactly what layers, or the treatment of the error case?

The text from the document (above) clearly indicates that hosts may choose
not to initiate NS and NA messages.  I read that to mean that a host may
choose _never_ to initiate these messages, even when NUD (or other parts
of ND) would require initiating these messages.

It would be much clearer to state that 3GPP nodes must inlcude a full
implementation of ND, including NUD, but that other parts of the 3GPP system 
may provide advice to the NUD code which result in supression of NUD messages,
and site the section of the ND specification that indicates how such advice
is used.

Please note that the layers that provide advice to NUD about connectivity
need to be able to ensure two-way IP-level connectivity.  If there are no
3GPP layers that can do that, occasional NUD traffic may result.  NUD
only happens when there is traffic to send, and when there has been no
recent confirmation of two-way connectivity (from TCP, for example), so
it is not expected to generate much traffic.

>down, and nothing gets through. Or did I miss something?

If the link is down, obviously no messages will be sent.  But, what if the
link is up, but the GGSN is down?  Or what if the GGSN is not forwarding 
packets and/or responding at layer 3?

Margaret

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 May 2002 21:17:56 +0300

Margaret Wasserman wrote:

> different document types?

I don't know. I'm happy to put the note back in if you think it is necessary
and no one else objects.

> and site the section of the ND specification that indicates how such advice

I think this was the intention. Perhaps we can reformulate the text to be
clearer in this respect. I'll send some text off-line to you to make sure
you are happy with the reformulation.

> it is not expected to generate much traffic.

Ok.

> packets and/or responding at layer 3?

In 3GPP, the SGSN keeps track of the status of the GGSN and will inform
hosts if their GGSN went down. The 'keeps track' mechanism involves an IP packet
exchange, so in order for the SGSN to think that the GGSN is up, the GGSN
must be responding at layer 3. If the GGSN is up but not forwarding, I
believe it would send ICMP errors.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 May 2002 21:25:35 +0300

Pekka Savola wrote:

> Are you sure these are the only problems?  It seems to me, that these old
> IPv6 nodes's, ie. no support for even HAO, cannot even talk to mobile
> nodes until receiving an ICMP message (one roundtrip).
> 
> Perhaps I missed something?

In order to use the HAO, you'll have to establish a BCE. In order
to establish a BCE, you'll have to complete the return routability
procedure. Any nodes is of course free to refuse participating the
return routability procedure or accepting a binding, say due to
lack of memory. If the MN can't establish a binding, it won't use
Route Optimization, won't use HAO, and from the point of view of
the CN, the MN looks like a stationary node.

Obviously mobile nodes would initiate/continue traffic in the
unoptimized way i.e. through the home agent until they have
established BCE at the CN. So I don't think there are any lost
roundtrips with the regular traffic, though of course they may
be few useless signaling messages if the MN tries to establish
a binding but the CN refuses. But I believe this should be
attempted in parallel with the regular IP traffic.

Jari

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 May 2002 14:27:01 -0400

> that we shouldn't re-state the type of the document in the text.

Since, I'm apparently the one who "told" you this, let me
clarify. What I thought I requested was taking out all references to a
particular RFC being a "standard" (vs. informational or something
else). Just referring to the RFCs as RFCs is preferred. As a general
rule, an RFC shouldn't be stating what the status of another RFC is,
since this can change over time.

My comments should not be interpreted as precluding making the changes
Margaret is requesting.

Thomas

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 May 2002 14:27:04 -0400

>believe it would send ICMP errors.

Does the SGSN inform the host of the fact that the GGSN is up on an ongoing basis?
Or only contact the host when the GGSN goes down?

If the former, whatever host process receives this notification could give advice to ND
to avoid NUD messages.

If the latter, then we probably don't want to supress NUD messages based on a lack
of bad news from the SGSN -- what if we can't reach either the SGSN or the GGSN?

Margaret

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 May 2002 14:41:10 -0400

Note: folk might want change some subject lines to aid followups on
the thread...

> Can one of the MIP folks help me here?  What is it called, and where

There is a basic problem with having this document specify any sort of
required behavior with respect to MIPv6. There is no RFC today for
MIPv6 (we are getting close, but we are not quite there yet).

Until the MIPv6 spec is finalized, it is a bit of a moving
target. Having this document say one must implement correspondant node
functionality as defined in draft-xxx leaves a dangling reference to
work-in-progress. This is what would be considered a normative
reference (i.e. you need to the other spec to correctly implement the
functionality that is being required).

I have a hard time seeing how this document can say anything
definitive about what parts of the MIP ID need to be implemented.

Plus, my understanding is that the target audience for the
celluar-requirements document is 3GPP and friends. They do not
currently have plans that involve using MIPv6. So I don't see the need
to say anything about MIPv6.

Thomas

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 22 May 2002 14:47:25 -0400

>MIPv6 (we are getting close, but we are not quite there yet).

Okay.  I agree, then, that we shouldn't specify any MIP behaviour in this
document.  I was under the (apparently mistaken) impression that we
were further along on MIPv6 than this...

Thanks,
Margaret

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 May 2002 21:07:02 +0300 (EEST)

That's because Destination Option code for HAO is 209 -- if the 
destination node does not recognize it, the packet is discarded and an 
ICMP message sent.

Actually, I'm not 100% sure from MIPv6 -17 draft that MN's are to process
and take account ICMP parameter problem code 2 messages sent by these old
nodes, in any way.

(Even though this wouldn't be a problem, additional cost of zero support 
in CN's would be that connections would break if MN moves.)

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 May 2002 22:30:48 +0300

> of bad news from the SGSN -- what if we can't reach either the SGSN or the GGSN?

The former. If the 2-way connection to the SGSN dies or the whole SGSN
dies, the air link is down in a manner that is observable to the host.

In conclusion, I think we should formulate the text to indicate that
lower layer connectivity information is available in this specific case,
and should be used to suppress NUD, as described in the original RFC.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 May 2002 19:14:59 +0300

Hi Margaret,

Correspondent node functionality is in draft-ietf-mobileip-ipv6-17.txt,
section 8.1 and 9. Previous versions of our draft contained a more in-depth
discussion of MIPv6 functionality. However, we received again a comment that
we should remove the forward reference to the I-D.

I do agree about the correspondent node functionality part, though. However,
there's a couple of things we should observe:

- In the current design, correspondent nodes do not need any special
   support unless they want to do Route Optimization.
- The exact keyword for Route Optimization is being debated. My interpretation
   of the discussion is that SHOULD is winning. In any case, communications
   with e.g. old IPv6 nodes that do not yet support MIPv6 are always possible
   without any other problems than non-optimal routing.
- Again, the forward reference... we could add a note describing that
   correspondent node functionality is something to be considered even
   if you don't use mobile node functionality, but of course it's hard to
   mandate an exact reference in a normative manner.

Jari