Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?]

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 4 Mar 2002 17:30:31 +0100

The different threads is a good idea.
There is one unanswered issue below.

  > 
  > >   >          - Making ND optional on point-to-point links
  > >
  > >=> RFC 2461 MUST be implemented, the exceptions are
  > >things like the Link layer suboption which is not
  > >relevant for these links. Did we miss something else?
  > 
  > The cellular hosts document says:
  > 
  > "Therefore, Neighbor Solicitation and Advertisement messages MAY 
  > be implemented for the cellular interface."
  > 
  > However, these messages are mandatory in RFCs 2461 and 2462, both
  > for DAD and for the basic neighbor discovery mechanism, which needs
  > to be used to establish two-way connectivity before other messages
  > are exchanged.

=> Right, but would you agree that on a p2p link you
don't actually *need* NS and NA? 
It's not a shared link, the prefix is implicitly
delegated to the UE only. So I don't see why 
(apart from NUD) you would need NSs and NAs.
Hence the MAY. 

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 [email-masked]
--------------------------------------------------------------------

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 05 Mar 2002 00:48:52 -0500

>(apart from NUD) you would need NSs and NAs.

I understand the argument for why you would not need to 
use DAD.

However, you would need to use NS and NA messages to 
establish two-way reachability to the router, before
sending other IP packets to (or through) that router.  
This is the basic neighbor discovery mechanism, and
I don't believe that it is optional on point-to-point
links.

Margaret

---

From: [email-masked]
Date: Tue, 5 Mar 2002 10:13:02 +0200

Hi Margaret,

> I don't believe that it is optional on point-to-point

I've clipped the discussion on Neighbor Discovery from the draft.
Essentially, in the 3GPP environment, a layer 2 method is used
to obtain connectivity to the default router.

Do you feel that we should discuss this mechanism in more detail
in order to fully explain why NS and NA messages are only MAY,
or do you find fault with our reasoning?

thanks,
John

2.5 RFC2461 - Neighbor Discovery for IPv6 
         
   Neighbor Discovery is described in [RFC-2461] and, in general, MUST 
   be supported. 
    
   In cellular networks, some Neighbor Discovery messages can cause 
   unnecessary traffic and consume valuable (limited) bandwidth. All 
   current cellular links resemble a point-to-point link, hence, a 
   mobile terminal's only neighbour on the cellular link is the default 
   router which is already known through Router Discovery. This router 
   most likely will not be a final destination for the hostÆs traffic. 
   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, Neighbor 
   Solicitation and Advertisement messages MAY be implemented for the 
   cellular interface. In addition, a cellular host SHOULD NOT send the 
   link layer sub-option on its cellular interface, and SHOULD silently 
   ignore it if received on the same interface. 
         
2.5.1 Neighbor Discovery in 3GPP 
      
   3GPP terminals only need to support Router Solicitations and Router 
   Advertisements for 3GPP IPv6 Address Autoconfiguration. Neighbor 
   Solicitations and Advertisements MAY be used for Neighbor 
   Unreachability Detection (NUD). They are not needed for 3GPP IPv6 
   Stateless Address Autoconfiguration, since Duplicate Address 
   Detection is not needed in this address assignment mechanism (see 
   section 2.6.1). 
         
2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration 
    
   IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be 
   supported. 
    
2.6.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].  
    
   A cellular host SHOULD NOT perform Duplicate Address Detection on 
   its cellular interface, 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.

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 6 Mar 2002 10:33:30 +0100

> Karim El-Malki wrote:
 > > This special router is called a GGSN and it knows it MUST NOT
 > > configure
 > > itself with a unicast address on that prefix. That means there's no
 > > conflict. Does that make sense?
 > 
 > I will grant you that I don't know (or want to know) the 
 > inner workings
 > of a GGSN, but what is the point of a link with only one node? Where
 > does an origin send data if there is no other device to 
 > receive it? If
 > there is another device (assuming for a moment that the GGSN is the
 > second device), how does the origin find it unless that 
 > device uses an
 > address in the range the origin considers to be in this 
 > prefix? If that
 > second device uses an on-link address, how do the nodes at either end
 > know that there will never be a conflict (easy with out-of-band
 > coordination)? If either end generates RFC-3041 addresses, 
 > how does that
 > node ensure that the other end hasn't already used that bit pattern
 > (easy if only one end generates, and the other only uses EUI-64s with
 > bit 6 set)? If a GGSN really MUST NOT configure itself into a prefix
 > that is allocated to a client device, what is the point of a GGSN?
 > 
 > Does that make sense?

Sorry but what you're saying doesn't make sense to me. Let's just use a
generic example. A host discovers a router using RAs. The router uses a
link-local address for the RAs. A host and a router on a point-to-point
link can use the link-local to communicate. They don't need to use a global
for example. The link-local is not in conflict if you use PPP where you can
negotiate the interface id and specifically not run DAD on it.
If the host is "delegated" a global prefix, it can run RFC3041 and doesn't need
to do DAD on the cellular link since there is nobody else using that prefix.
Yes, there is someone else on that link of course, the router. But the
router doesn't configure any address on this delegated prefix so no conflict.

This applies to any point-to-point link.

/Karim

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 6 Mar 2002 10:46:55 +0100

It would be good if we kept 3G radio network architecture discussions
off this list.
/Karim

P.S. As a note the RNC, Node B, SGSN have nothing to do with what we're
discussing and they're not involved in any of the IPv6 mechanisms
discussed so far.

 > -----Original Message-----
 > From: FIELD,GEOFF (A-Australia,ex1) [mailto:[email-masked]]
 > Sent: den 6 mars 2002 01:04
 > To: 'Margaret Wasserman'; [email-masked]
 > Cc: [email-masked]
 > Subject: RE: Making ND Optional [Was RE:
 > draft-ietf-ipv6-cellular-host-00. txt -> wg last call?]
 > 
 > 
 > I don't think I've popped up here before, but I've been
 > following the conversations for a while.
 > 
 > I'm currently working in the 3G field, so I'd just like
 > to present my view on the matter.
 > 
 > Just a gentle reminder or two first:
 > Cellular phones - 3G or otherwise - tend to be *mobile*.
 > People use them in moving vehicles, as well as while
 > just walking.
 > 
 > In the 3G infrastructure, there are a number of nodes
 > between a given terminal (phone) and the network -
 > the base station (aka Node B in 3G terminology) which
 > is moderately "dumb" w.r.t network protocols, the
 > Radio Network Controller (RNC), which is a massive
 > rack of powerful processors, and the SGSN or MSC, which
 > are the choices of interconnect to the Core Network.
 > The RNC, SGSN and MSC exhibit router-like behaviour.
 > 
 > What can really confuse the issue is the mobility of
 > the terminal - at any given moment it may be talking
 > to two or more Node Bs, each of which may be connected
 > to a separate RNC.  If a terminal is on a cell's edge
 > and swapping between Node Bs, does it have to perform
 > ND each time it swaps?  There's a hell of a lot of
 > other protocol stuff going on at the same time during
 > handover, particularly if it's between different RNCs.
 > 
 > What about the situation where a terminal is in a fast-
 > moving vehicle (a car on a highway, a train, an aircraft)?
 > Does each and every handover have to have ND added to
 > it as well as all the other stuff that's going on?  It's
 > a thorny issue, particularly for a handheld phone where
 > price of manufacture and battery life are already being
 > squeezed hard.
 > 
 > As for security, remember that 3G phones use CDMA variants
 > that are inherently nearly impossible to crack.  Further,
 > encryption is available already on the higher layers.
 > 
 > I'm not arguing that the code for handling ND and security
 > should be omitted for these terminals.  I *am* saying it
 > could possibly be simplified to silently ignore some things.
 > OTOH, if a terminal is to be used as a router, it *must*
 > be able to act like a proper router, so everything required
 > must be fully implemented.  I can envisage a mobile router
 > in a fast-moving vehicle (an in-train Internet connection
 > system, perhaps) that would complicate issues.  For this,
 > I'm glad that I (probably) won't be involved in working
 > out the nightmare of handover issues.
 > 
 > Geoff - further replies in the body.
 > 
 > 
 > > Hi John,
 > > 
 > [snip]
 > > We have defined a mechanism to locate and maintain reachability 
 > > information about neighbours in IPv6, called "Neighbor 
 > Discovery".  
 > > This isn't an optional part of IPv6 that it would be appropriate 
 > > to disable on a particular link type.
 > > 
 > > However, it is expected for ND to receive "advice" from 
 > other layers
 > > regarding the "reachability" of another host -- so it would be
 > > great if the L2 mechanism gave ongoing advice to IPv6 regarding
 > > the reachability of the router, which would result in suppressing
 > > IPv6 NS messages.
 > 
 > This may or may not happen.  In the 3G stacks, IP runs over
 > AAL-5, which is not a complex protocol.  As far as I can see,
 > it just treats the IP traffic as a set of bytes to be transmitted.
 >  
 > > I don't believe that your conclusion is sound...
 > > 
 > > >Therefore, Neighbor 
 > > >    cellular interface. 
 > > An implementor could read this and believe that it was acceptable
 > > to build a 3GPP cell phone (with only one cellular interface) that
 > > didn't even contain the _code_ necessary to generate IPv6 NS and
 > > NA messages.
 > 
 > To *generate* them?  Why would it want to?
 > 
 > > What happens when that host receives an NS message?
 > 
 > If the RNC chooses to generate one, it had better be certain
 > that the phone can handle it.  The terminal may just silently
 > ignore the NS message.
 > 
 > > Do you think that people may ever want to set-up redundant
 > > 3GPP networks, or make a choice between two possible 3GPP
 > > routers, based on their current reachability?  If you don't
 > > use ND, how will this information be available for IPv6
 > > routing decisions?
 > 
 > In point of fact, the terminals will be handed over frequently.
 > 3G specifies control-plane protocols to handle this separately
 > to IP.  I would suspect that the RNCs or other upstream hardware
 > would have to maintain the IP reachability information.
 > 
 > > There seems to be a mis-perception in the 3GPP community that
 > > ND will result in a lot of extra traffic.  The idea of ND is
 > > to locate the other node _once_ and maintain reachability 
 > > information about that node on an ongoing basis, using advice
 > > from other layers, _without_ sending additional ND messages
 > > unless absolutely necessary.
 > 
 > This is fine if the terminal is stationary and well within the
 > cell's boundaries and the characteristics of the air interface
 > aren't changed by interference, rain or a truck parking in the
 > way.
 > 
 > > Are there reasons why you think that this won't work on 3GPP
 > > hosts?
 > 
 > It probably would, but there are other mechanisms already in
 > place.  It strikes me as a duplication of effort.
 > 
 > [snip]
 > > This should be a MUST.  IPv6 hosts MUST support address 
 > > autoconfiguration,
 > > although it is possible for the routers to be configured so 
 > > that it isn't
 > > used (if desired).
 > 
 > And, in fact, mobile hosts should support auto-configuration
 > anyway, by virtue of the fact that they're mobile.
 > 
 > [snip]
 > 
 > There's my simple, non-expert spin on this debate.
 > 
 > Geoff

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 6 Mar 2002 10:55:28 +0100

> FIELD,GEOFF wrote:
 > > ...
 > Depends on how the device (terminal) views those different 
 > connections
 > to RNCs. If they appear as interfaces that are somewhat 
 > persistent, then
 > NO you would not have to do a new ND unless your timer had 
 > expired. If
 > on the other hand they appeared to be interfaces that were 
 > new/removed,
 > then YES ND would be required because there is no local 
 > state about the
 > L3/L2 mapping. This is a very specific implementation issue, 
 > but there
 > is no inherent reason for a terminal to violate the architecture.

This discussion started from an incorrect basis.
Please let's keep away from discussions on the 3g architecture details
which don't belong here.

 > The only way a mobile router works is if the GGSN expects 
 > all terminals
 > to act like proper IPv6 nodes. If a GGSN takes shortcuts based on an
 > expectation that the micro-handset will never do X, then no device
 > connecting to it will be able to do X because the GGSN will simply
 > ignore it.

No shortcuts, the 3G network will support a standard IPv6 host.

/Karim

---

From: [email-masked]
Date: Wed, 6 Mar 2002 13:14:14 +0200

Hi Keith,

> that's bizarre.  does that mean that apps on a host that's 
> connected to 
> a cell phone won't be able to communicate with apps on that 
> cell phone 
> unless the cell phone is talking to the network?    and that 
> communications
> between the host and the cell phone will have to go over the wireless
> network?

No, but they probably won't be using IP to communicate (or at least
not at first & probably not for awhile).  

Right now, my cell phone can use infrared or bluetooth for synching 
my calendar, phone book, creating ringtones (yup, big excitement).
My assumption would be that things would continue like that for some
time.

John

---

From: [email-masked]
Date: Wed, 6 Mar 2002 13:28:17 +0200

Hi Maragaret,

> There will be (at least) two prefixes in use on the link:  a
> global prefix (the delegated /64) and the link-local prefix.
> It is my understanding that the GGSN will use a link-local
> address on the link.  And, it is important that the link-local
> address in use by the GGSN _not_ conflict with the link-local
> address(es) in use on the host.  
> 
> This could definitely be achieved by other means than running
> DAD on the link, though, which is fine with me. 

So at least for this issue, I think we can agree that 

 1) DAD is must to implement 
 2) DAD may not always be needed to be sent 
    (need to explicitly state the conditions that apply)

Is it OK to document this - in some draft related to what
we've been doing?

John

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 06 Mar 2002 10:32:10 -0500

>Is it OK to document this - in some draft related to what

Yes, this should be documented.  I think that it should go in
an "IPv6 over <foo>" document.

Margaret

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 12:45:59 -0500

Margaret,

If you shutdown NA and NS there is no NUD.  Thats the discussion I think
not if NS and NA are on.

/jim

> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 10:24 AM
> To: [email-masked]
> >    This router 
> >    most likely will not be a final destination for the 
> host's traffic. 
> >    track the reachability of the router. 
> 
> information about neighbours in IPv6, called "Neighbor Discovery".  
> However, it is expected for ND to receive "advice" from other layers
> >In addition, a cellular host SHOULD NOT send the 
> This is fine, and would be an excellent piece of information
> to put in a standards-track "IP over <foo>" document.
>     
> Will the router end of the link allocate any addresses within the
> unique /64 assigned to the PDP context?  If so, what mechanism will
> be used to ensure that the host doesn't allocate the same address?
> 
> If it's actually true that a conflict can never occur, then we should
> indicate that DAD won't be used on these link types in an 
> "IPv6 over <foo>" document, as previously discussed.
> 
> Margaret
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 12:50:21 -0500

> The link is the PDP Context.  If more than one host is attached 
> via a cell phone (using the cell phone as a layer 2 "modem"), each
> attached host will establish a separate PDP context (and a separate
> IPv6 link), and receive a separate /64 delegation.  So, I agree
> that there won't be more than 2 nodes on a 3GPP cellular link, the 
> way things are currently specified.

The last sentence is key. In 3GPP that is how IT IS SPECIFIED.  The doc
addresses the current state of affairs not rel 6 or 7 or 4G.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 12:51:39 -0500

3041 is deemed unnecessary for this deployment.

/jim

> From: Tony Hain [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 12:27 PM
> To: Karim El-Malki (ERA); 'Margaret Wasserman'; 
> [email-masked]
> > No, the router doesn't allocate any addresses on the
> > "delegated" prefix.
> > That was the assumption behind our 3gpp-advice draft and has
> > been followed
> > by 3gpp.
> 
> The router has to allocate at least 1 address in the prefix, 
> even if it
> is just the all-routers address. It is also likely to create 
> another one
> that is unique to itself, so there has to be a mechanism in that which
> will ensure that the remote end doesn't collide when it chooses a 3041
> address. The only obvious choice is to make sure that bit 6 is set,
> which in turn means that the router is using an EUI-64 
> derived address.
> Since I don't have access to the 3G specs, is that all true?
> 
> Tony
>

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 12:53:44 -0500

Keith,

Yep.  Until we deploy wireless to wireline enablers which many of us are
working on.

/jim

> From: Keith Moore [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 12:57 PM
> To: Margaret Wasserman
> Cc: Karim El-Malki (ERA); [email-masked];
> [email-masked]
> Subject: Re: Making ND Optional [Was RE:
> > >It won't because a cellular host /e.g. 3gpp) is alone on its link.
> > 
> > On a point-to-point link, there must be at least two nodes...
> > In this case, one node is the cellular host and the other is
> > the 3GPP router (GGSN).
> > 
> Keith

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 6 Mar 2002 12:54:16 -0500

Yes.

/jim

> From: Karim El-Malki (ERA) [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 12:58 PM
> To: 'Tony Hain'; 'Margaret Wasserman'; [email-masked]
>  > that is unique to itself,
>

---

From: Delecki Andrew-Y10658 <[email-masked]>
Date: Tue, 5 Mar 2002 16:25:55 -0800

Hi all,

3GPP implementation of stateless address autoconfiguration is a superposition of "true" stateless and stateful address autoconfigurations.

The reason for this is that the "wireless equivalent link layer", which is "the PDP context pipe" extending from GGSN to the cellular host, has to be first established in order to convey any IPv6 messages.
This severely limits the use of many IPv6 protocol features, e.g. neighbor discovery, router advertisement etc.

In my view, the document in question (draft-ietf-ipv6-cellular-host-00. txt) omits this fact concentrating on the scenario in which "the PDP context" is established.

The entire 3GPP mobility, session and connection management happens outside the user plane (IPv6 over PDP context) where IPv6 is not used.

For this reason, the this document will have limited impact on the 3GPP and it does not fully explore many IPv6 protocol features.

Regards,

Andrew Delecki

Motorola

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]]
Sent: Tuesday, March 05, 2002 7:24 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Making ND Optional [Was RE:

Hi John,

>    This router 
>    most likely will not be a final destination for the host's traffic. 

    
>    IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be 

This should be a MUST.  IPv6 hosts MUST support address autoconfiguration,
although it is possible for the routers to be configured so that it isn't
used (if desired).

Margaret

---

From: "FIELD,GEOFF (A-Australia,ex1)" <[email-masked]>
Date: Thu, 7 Mar 2002 06:58:29 +0800

> It would be good if we kept 3G radio network architecture discussions

Fair enough, Karim, but this particular discussion is about IPv6 on
3G hosts.  I felt that a very brief reminder of the architecture
would help those (very) few on this list who aren't already
familiar with it.

> discussing and they're not involved in any of the IPv6 mechanisms

In point of fact, these three devices sit between the host (terminal)
and the Internet, so they have to at least carry the data.  I'm
reasonably certain that at least one of them (probably the SGSN)
will have to act as an IPv6 router for the purposes of connecting
to the terminal.

Geoff

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 6 Mar 2002 23:09:08 +0100

Sorry if this was already answered, but I'm
not keeping up with email.

  > I don't believe that it is optional on point-to-point

=> An RS and RA are used for this purpose. 
That's all you need in this particular scenario.
They (RSs and RAs) are of course mandated in 
the draft. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 7 Mar 2002 00:34:12 +0100

Geoff

  > will have to act as an IPv6 router for the purposes of connecting

=> No. The GGSN is the default router. Nothing else 
is seen by the end host. So in this discussion
we should be concerned with the Host (UE in 3GPP specs) 
and the default router (GGSN) for all link-local
issues.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 7 Mar 2002 00:31:00 +0100

> 3GPP implementation of stateless address autoconfiguration 
  > is a superposition of "true" stateless and stateful address 
  > autoconfigurations.
  > 
  > The reason for this is that the "wireless equivalent link 
  > layer", which is "the PDP context pipe" extending from GGSN 
  > to the cellular host, has to be first established in order 
  > to convey any IPv6 messages.
  > This severely limits the use of many IPv6 protocol 
  > features, e.g. neighbor discovery, router advertisement etc.

=> It doesn't limit anything to do with RAs. 
It only eliminates the need for ethernet-type
information like the link layer suboption. 
DAD is not needed, but people _can_ certainly
send DAD messages if they really want to.  
NUD is also possible. GGSNs should support NUD
as was mentioned earlier. 

  > In my view, the document in question 
  > (draft-ietf-ipv6-cellular-host-00. txt) omits this fact 
  > concentrating on the scenario in which "the PDP context" is 
  > established.

=> Which part of the document does that?

  > For this reason, the this document will have limited impact 
  > on the 3GPP and it does not fully explore many IPv6 
  > protocol features.
  > 

=> I'm not sure what mean. The document is not 
intended to affect 3GPP specs. The document
does not eliminate any IPv6 features. For the 
generic cellular host, almost all features are
included, but there are exceptions for 3GPP
hosts due to the _3GPP_system_ which makes 
some functions (like DAD) unnecessary. 

Hesham

---

From: [email-masked]
Date: Thu, 7 Mar 2002 06:41:28 +0200

Hi Geoff,

> would help those (very) few on this list who aren't already

Would it be helpful if we have additional information about what
the layer 2 is providing in this case - I don't know if heavy
architectural details are needed, but at least an explanation
of the mechanism - with references for those who want to read
more.

thanks,
John

---

From: "FIELD,GEOFF (A-Australia,ex1)" <[email-masked]>
Date: Thu, 7 Mar 2002 14:07:23 +0900

> of the mechanism - with references for those who want to read

In the 3G stacks, IP runs over AAL-5 (spec I.363.5), which runs over
ATM (spec I.361).  However, it's not as simple as that - each link
actually has *two* stacks - a User-Plane stack and a Control-Plane
stack.  In the Control Plane, it's RANAP (TS 25-413) over SCCP (Q.711)
over M3UA (RFC2719 I think) over SCTP (RFC2960) over IP.  In the User
Plane it's IuUP (TS25.415) over GTP-u (TS 29.060) over UDP over IP.
This is between the RNC and the SGSN.  To be honest, I'm not sure
where it occurs in between the RNC and the terminal/host - the Radio
Network stack on the User Plane is PDCP/RLC/MAC/FP.  (I don't have a
reference for the spec numbers handy at the moment.)  These sit on a
Transport stack of AAL-2/ATM between the Node B and the RNC.  I suspect
IP between the terminal and the Internet would sit on top of the User
Plane stacks.  There are others on this list with far more expertise
in this field than I.

Is this helpful to the discussion?  Only if we know what the lower
layers are providing to IP.  Virtually every layer provides addressing
for the point-to-point link.  FP provides encryption if desired.  The
RNC provides considerable intelligence for mapping connection IDs to
mobile terminals.  Based on what, I'm not entirely sure, but I suspect
it's more to do with the telephone number than the IP address.  Similarly,
the SGSN provides mapping between the connection ID and the RNC(s).  As
I said, both these devices provide router-like functionality.  Actually,
it's probably closer to a telephone exchange system - after all, most
of the companies making these products are telephony equipment
manufacturers.

I am coming to believe, however, that the manufacturers of 3G mobile
terminals will need to implement standard IPv6 host requirements in
the products, or at least a way of informing the fixed infrastructure
of what isn't implemented.  The problems of interoperability and mobile
routing systems contribute to this opinion.  I also agree with the
point about triggering a plethora of "IPv6 over <foo>" documents, each
listing an individual set of exceptions, and each based on a slightly
different draft of the base document - I'm sure you could do without
these nightmares as well.

Geoff

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 7 Mar 2002 07:30:54 +0100

Andrew,

  > Not true.
  > The host sees GGSN only through PDP context pipe if PDP 
  > context is set to IPv6/v4 type.
  > 
  > Through control plane it is talking only to SGSN, which 
  > handles entire call control and mobility management 
  > (distinct from mobile IP).
  > 

=> As far as the IP LAYER is concerned, we only
care about the GGSN as the default router. 
Anything else we can label L2! 
Let's not confuse the issues at hand.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 7 Mar 2002 07:32:52 +0100

> The main problem with using the Router Advertisement is 
  > that the cellular host shall have its knowledge before the 
  > PDP context is established.

=> What knowledge? will it know the global prefix
for example?

Hesham

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Thu, 7 Mar 2002 12:06:21 +0100

> will have to act as an IPv6 router for the purposes of connecting

That's wrong. But anyway, these are 3gpp architecture discussions
which are best kept in 3gpp.

/Karim

---

From: [email-masked]
Date: Fri, 8 Mar 2002 10:15:55 +0200

Karim,

> which are best kept in 3gpp.

It might be reasonable for us to check that our explanation in the
draft is clear enough, so that everyone who reads the draft understands
what we are suggesting.  Essentially, I think we want to ensure that
we advise that ND MUST be implemented, but to clearly state when
ND is not needed to be used; what are the conditions that need to
be met and what the 3G architecture does to meet those conditions.

If we can explain this well, perhaps we'll will close this issue.

John

---

From: Delecki Andrew-Y10658 <[email-masked]>
Date: Wed, 6 Mar 2002 16:17:25 -0800

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 3:34 PM
To: 'FIELD,GEOFF (A-Australia,ex1)'; Karim El-Malki (ERA); 'Margaret
Wasserman'; [email-masked]
Cc: [email-masked]
Subject: RE: Making ND Optional [Was RE:
draft-ietf-ipv6-cellular-host-00. txt -> wg last call?]

Geoff

Not true.

The host sees GGSN only through PDP context pipe if PDP context is set to IPv6/v4 type.

Through control plane it is talking only to SGSN, which handles entire call control and mobility management (distinct from mobile IP).

Andrew

---

From: Delecki Andrew-Y10658 <[email-masked]>
Date: Wed, 6 Mar 2002 16:46:33 -0800

The main problem with using the Router Advertisement is that the cellular host shall have its knowledge before the PDP context is established.
In this case, the host would know whether it is allowed to perform stateless address autoconfiguration or not from value
Stateful Configuration flag.
This information is needed by host before the PDP Context is established, i.e. before any IPv6 message can be sent.

Andrew D.

Motorola

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 3:31 PM
To: 'Delecki Andrew-Y10658'; 'Margaret Wasserman';
[email-masked]

Hesham

---

From: [email-masked]
Date: Fri, 8 Mar 2002 18:07:50 -0800

Hello Andrew,

> handles entire call control and mobility management (distinct 
> from mobile IP).
> 

I am sorry to say, but Hesham is totally right. GGSN is the default router. Everything else (Radio signaling, SM, and MM signaling) is 3GPP system dependent, and seen as part of layer 2 for IP. The IP host (Thus, layer 3 and up) does not see any other node from the 3GPP system.

Thus, GGSN _is_ the default router...

Cheers,

Jonne.