Subject: Review comments on IPv6 for Second and Third Generation Cellular Hosts

From: Margaret Wasserman <[email-masked]>
Date: Fri, 26 Apr 2002 08:11:43 -0400

Hi All,

I've attached my comments on "IPv6 for Second and Third Generation Cellular Hosts" with
responses from John Loughney.  This came out of a more private discussion, but John and
I both thought it would be useful to send this to the whole list.

Margaret

>From: [email-masked]
>Subject: RE: Preview of IPv6 for Second and Third Generation Cellular Hosts 
>Date: Fri, 26 Apr 2002 10:42:40 +0300
>Margaret,
>
>I've been creating a list of issues raised here & possible resolutions - 
>I hope you send this (or a version) to the list so I can answer there.
>
>Trimming the recipient list ...
>
> > General Comment:  Document needs some text editing, particularly to 
> > eliminate run-on sentences and poorly formed paragraphs.
>
>Can do (I usually save this kind of editing for last ..)
>  
> > Technical Comments:
> > 
> > Section 1.1:
> > 
> > This section should explicitly state that this document is not
> > a standard and is not intended to modify the existing IPv6
> > standards.
>
>Will do.
>  
> > Section 2.1:
> > 
> > Path MTU discovery is a mechanism to save bandwidth, so it may
> > be very desireable to implement for cellular hosts.
>
>Will add text about this, suggesting this with comments.
>  
> > Section 2.4.1:  
> > 
> > Neighbor Solicitations and Neighbor Advertisements are not optional 
> > parts of Neighbor Discovery, and they should not be considered optional 
> > for cellular hosts.  Cellular hosts should implement all of the
> > required portions of ND, and use the state machine described in 
> > the ND specification.  If you really believe that these parts of
> > ND should be optional, then the ND spec should be re-visited.  We
> > should not just declare them optional here.
> > 
> > The link layer sub option is link-specific, and it is fine that it
> > does not apply to this type of link.
>
>This we need to add clarifying text as why we think using NA & NS may
>be optional in some cases.  Hopefully you can comment on this
>after we write the text.
>  
> > Section 2.5.1:
> > 
> > DAD is not an optional part of Stateless Address Autoconfiguration,
> > and it should not be considered optional for cellular hosts.
> > If you really believe that DAD should be optional for some link
> > types, we need to re-visit the Stateless Autoconfiguration spec.
> > We should not just declare DAD to be optional here.
>
>I think we (the authors) need to do some thinking on this, as there
>is the feeling that 2462 does not apply to the 3GPP network, but
>I guess you feel strongly that it does.
>  
> > Section 2.7.1:
> > 
> > The document says:
> > 
> >     "To avoid any duplication in link-local addresses 
> >     between the TE and the GGSN, the MT must always reject other 
> >     suggested interface identifiers by the TE. This results in the TE 
> >     always using the interface identifier suggested by the GGSN for its 
> >     link-local address."  
> > 
> > What does this mean?  I thought that laptops would be able
> > to generate privacy addresses using randomly allocated identifiers.
> > If not, we have a serious problem.  Is this done to avoid the
> > need for DAD?
>
>We may need to fix this text, I think it is not quite right.
>  
> > Section 2.11 (and 2.13):
> > 
> > The document says:
> > 
> >     "Cellular hosts should not support configured or automatic 
> >     tunnels to avoid unnecessary tunneling over the air interface."
> > 
> > Why would we want to make this recommendation?  There may be
> > good reasons for tunneling over the air interface.
>
>We need to fix the text, we intend to say that tunneling should be
>avoided, as it may waste bandwidth - especially if there are other
>mechanisms available.
>
> > Section 2.14:
> > 
> > The document says:
> > 
> >     "The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] may be 
> >     used. DHCPv6 is not needed when IPv6 stateless 
> > autoconfiguration is 
> >     used, and no other functions of DHCPv6 are used."
> > 
> > I don't understand this paragraph.  Can a cellular host use DHCP
> > to get it address(es)?  I would think DHCP would only be useful on
> > a cellular host for other types of information.
>
>We will fix this, stating that DHCPv6 is not needed for stateless auto.
>config, but may be useful for configuring othyer types of info.
>  
>Thanks,
>John 

--------------------------------------------------------------------
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: [email-masked]
Date: Mon, 29 Apr 2002 12:55:53 +0300

Hi all,

> I guess you feel strongly that it does.
   
I think a possible resolution to this is to state something like the
following:

  2.5.1 Stateless Address Autoconfiguration in 3GPP  
 
   A 3GPP cellular host must process a Router Advertisement as stated 
   in chapter 5.5.3 of [RFC-2462].  
    
   These cellular hosts can set DupAddrDetectTransmits equal to zero,
   as each delegated prefix is unique within its scope when allocated 
   using the 3GPP IPv6 Stateless Address Autoconfiguration. 
    
   See appendix B for more details on 3GPP IPv6 Stateless Address 
   Autoconfiguration. 

I base my reasoning on the following text:

From IPv6 Stateless Address Autoconfiguration (RFC2462)

      DupAddrDetectTransmits

                     The number of consecutive Neighbor Solicitation
                     messages sent while performing Duplicate Address
                     Detection on a tentative address. A value of zero
                     indicates that Duplicate Address Detection is not
                     performed on tentative addresses. A value of one
                     indicates a single transmission with no follow up
                     retransmissions.

                     Default: 1, but may be overridden by a link-type
                     specific value in the document that covers issues
                     related to the transmission of IP over a particular
                     link type (e.g., [IPv6-ETHER]).

From IPv6 over PPP (RFC2472):

5.  Stateless Autoconfiguration and Link-Local Addresses

   The Interface Identifier of IPv6 unicast addresses [6] of a PPP
   interface, SHOULD be negotiated in the IPV6CP phase of the PPP
   connection setup (see section 4.1). If no valid Interface Identifier
   has been successfully negotiated, procedures for recovering from such
   a case are unspecified.  One approach is to manually configure the
   Interface Identifier of the interface.

   As long as the Interface Identifier is negotiated in the IPV6CP phase
   of the PPP connection setup, it is redundant to perform duplicate
   address detection as a part of the IPv6 Stateless Autoconfiguration
   protocol [3].  Therefore it is recommended that for PPP links with
   the IPV6CP Interface-Identifier option enabled the default value of
   the DupAddrDetectTransmits autoconfiguration variable [3] be zero.

Does this sound reasonable?
John

---

From: [email-masked]
Date: Mon, 29 Apr 2002 14:15:04 +0300

Hi Craig,

Comments in-line.

> Additionally, if the device is going to have multiple
> identities (someone has used the Bluetooth Personal Area Network example)
> all of these will be effectively going through the device that has the gprs
> protocols, which means that it has taken on a sort of router function: Like
> a home network with a router hooked up over a dialup connection? 

This part is left out of the document.  It is concievable there there would
be a device attached to the phone, and using the phone as a bridge,
but we specifically used the word 'host' in the document in order
to make it clear that the device is not a router.  

> -some elements of the gprs network were correctly considered a "given" for
> this recommendation. Is there any reasonable opportunity to engage in other,
> higher impact, longer term discussions about opportunities and applicability
> of moving to a v6 core network (perhaps even engage in dialog on the
> applicability of mobileipv6?). It seems to me that pdp contexts create kind
> of a "circuit" in an otherwise packet switched network and ipng expertise
> may be able to assist with information on how to apply ipv6 technology to
> get the desired effects as 3GPP attempts to move to an IP core network.

This document does not intend to modify any specifications - 3GPP
or IETF - that is out of scope.  

> -some of the optimizations (e.g. DAD removal) will presumably not be
> available in the case of the laptop connecting to a device where the device
> acts just as a provider of the link layer unless the laptop protocol stack
> is explicitly aware of the link technology? Is that true? 

There is some work going on to specify an 'IPv6 over 3GPP PDP Contexts'
or something like that.  This could be used by a laptop, for example.
However, the recommendations in this draft are not meant to change default
IPv6 behavior, and it is assumed that the implementations of IPv6
will contain the code for this behavior - but discusses the specific needs
of the 3GPP addressing architecture and comments on some small optimizations
to work with the 3GPP network.
 
> -Would a way to avoid 3GPP appearing to be a special case to try to converge
> it with PPP in its approaches? That might mean that solutions that apply to
> ppp or gprs could be applied more generally to both and it might address
> comments like:
>
> As mentioned above, would it be fair to say stateless is only approximately
> stateless since prefixes are being statefully distributed and there is only
> one device using that prefix (or in more elaborate cases where there are
> multiple addresses or devices that a single device is managing the
> allocation within that prefix). 

I have sent a follow-up on this point, please check the text to see if it
better clarifies the issue.

thanks,
John

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 29 Apr 2002 10:05:41 -0400

Hi John,

>    See appendix B for more details on 3GPP IPv6 Stateless Address 

It seems reasonable, and consistent with RFC2462 and the PPP for IPv6 spec,
to avoid DAD for addresses where the remote side (GGSN) assigns the IID.

I am less certain about the privacy address case.  Privacy addresses post-date the
PPP spec, so it does not deal with them...  In fact, we know that the PPP spec 
will need to be updated, eventually, to match the newest addressing architecture.

Do the 3GPP specifications explicitly state that the GGSN must not allocate any
addresses within the allocated prefix?  If so, in which document?

Thanks,
Margaret