Subject: RE: Review comments on IPv6 for Second and Third Generation Cellu lar Hosts

From: Craig Dunk <[email-masked]>
Date: Fri, 26 Apr 2002 18:05:31 -0400

I wanted to verify I understand the models that are being used in the
recommendation and ask about some parallels.

The draft recommends the GGSN assigning 64 bit prefixes to devices. For a
single mobile device this amounts to creating a link scope with only one
device on it. Would it be fair to say this is the source of the "you can
ignore DAD" arguments? 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? 

Some questions:

-is this similar to the idea of zero config home router set up (again the
home network analogy). and can the solution proposed within be applied to
that situation or can some common solution apply?

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

-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? 

-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:

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

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

Craig.

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]]
Sent: April 26, 2002 8:12 AM
To: [email-masked]
Subject: Review comments on IPv6 for Second and Third Generation
Cellular Hosts 

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]
--------------------------------------------------------------------
--------------------------------------------------------------------
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: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 29 Apr 2002 11:30:26 +0200

A couple of comments below for the benefit of the list.

  >I guess you feel strongly that it does.

=> Agree with John's comment. I'd like to add that
this is not the authors' opinion, we used (in this section)
the 3GPP specs which were modified based on the 
advice draft. 

  >   > > > to generate privacy addresses using randomly allocated 

=> Sure. This is still allowed when following the 
paragraph in the draft. The draft is referring to
the PPP negotiation, which is concerned with the 
interface id for link local addresses only. There is
no mandate to use the same iid for other scopes
of adresses. So privacy is still preserved for addresses
with scopes larger than the link scope. 

Hesham

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Mon, 29 Apr 2002 11:33:30 +0200

> The draft recommends the GGSN assigning 64 bit prefixes to 
 > devices.

Just to avoid confusion, the draft itself doesn't recommend it
but the prefix assignment is in the 3GPP specs.

 >  For a
 > ignore DAD" arguments?

Not sure if I understand what you mean. The laptop/device and GGSN
need link-locals and these can be ensured not to be duplicates by
using e.g. PPP in the laptop case (interface id configuration option).
Maybe that's what you meant anyway. The device is then assigned a
(global) prefix by the GGSN on which only that device configures
addresses. It's just like a router and a host connected over a PPP
link where the router delegates a /64 prefix to the host (i.e.
router does not configure addresses on the prefix). DAD would not
be necessary in this particular case and its suppression would be
a useful optimisation. Note that the GGSN will reply to NS for NUD.

 >  Additionally, if the device is going 
 > to have multiple

It could be just a multi-link modem (all identities have their own
/64) or it could be a router as you say. Clearly the router has
advantages but not all devices will have this functionality.

 > that situation or can some common solution apply?

I think the idea was to consider the non-router case first and
then apply the appropriate router solution which will hopefully be
an existing one. However not all devices will have this.

 > get the desired effects as 3GPP attempts to move to an IP 

Now it is most important to get IPv6 in 3GPP to be inline with
the IETF standards. The longer term architectural discussions
relating to the internals of the 3GPP network is probably something
that should be decided and done in 3GPP, where the detailed
knowledge of the architecture is, with the help of the ipv6wg etc.
However, since we're in the early stages of IPv6 in 3GPP it is too
soon to talk about architecture evolution.

 > is explicitly aware of the link technology? Is that true? 

True.

 > ppp or gprs could be applied more generally to both and it 

I think that it's appropriate to look at this case as a PPP link
where there is some form of RA-based prefix assignment/delegation.

 > allocation within that prefix). 

Agreed, due to the point-to-point wireless link-layer and other
considerations. More info on this in draft-ietf-ipv6-3gpp-recommend-02

/Karim

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Mon, 29 Apr 2002 16:33:03 +0200

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

The reference to the 3GPP docs which state this is in
draft-ietf-ipv6-3gpp-recommend-02. It's the TS 23.060 specs.

/Karim

---

From: Craig Dunk <[email-masked]>
Date: Mon, 29 Apr 2002 10:47:51 -0400

-----------

I saw a privacy comment in the past (sorry, can't source the original
author) that suggested that because of the procedure for address assignment
where only one host allocates addresses within the prefix that there was no
privacy benefit to regenerating interface identifier portion of the
addresses since (for example) traffic analysis would just be done on prefix
matching. 

Does this (paraphrased) assessment seem correct? I wouldn't want 3GPP to
mandate a behaviour that they would believe contributed to identity privacy
but, based on some other procedure, did not.

Craig.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 29 Apr 2002 17:07:29 +0200

> but, based on some other procedure, did not.

=> But the person tracking would have to know 
that the host is a 3GPP host. Otherwise, they
won't know that it has a prefix for itself. 
BTW, this is not specific to 3GPP, the same 
can be done with home networks. A house that
gets a /48 can also be tracked by the same method. 

Hesham