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

From: "FIELD,GEOFF (A-Australia,ex1)" <[email-masked]>
Date: Wed, 6 Mar 2002 09:03:50 +0900

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 
> >    Solicitation and Advertisement messages MAY be 
> implemented for the 
> >    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]
> >2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration 
> >     
> >    IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be 
> >    supported. 
> 
> 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
--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Tue, 5 Mar 2002 16:36:58 -0800

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.

> encryption is available already on the higher layers.

This is a frequent point from the 3G community, and if the only node I
wanted to talk to was the GGSN it would be fine. Problem is that
security needs to be from the origin all the way across the Internet, so
whatever magic encryption is happening on the air link is really
irrelevant.

> out the nightmare of handover issues.

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.

Tony