Subject: Re: [MOBILE-IP] Reverse Tunneling updates?

From: Thomas Eklund <[email-masked]>
Date: Tue, 16 Nov 1999 17:04:17 +0100

Using HC comp over the air the headers are the same! IPv6 dont add any
overhead!

The traffic headers can be compressed down to:
A typical IPv6/UDP header can be compressed down to 4 octets including the
UDP checksum and a typical IPv6/TCP header can be compressed down to 4-6
bytes including the TCP checksum.
And for your type of network you probably want to use ROCCO style HC...
which is the same for v6 and v4.
So I dont understand what you are talking about.

And when we speak of the mobility signalling they can be sent over native IP
in mobileipv6 with a home address option in an destination option extension
header which in most cases will be encrypted, so you send a IP header + ah +
dest op ext header
And for mobile ipv4 you typically use reverse tunneling so you will send the
mobiltity message with an ah tunneled over ipv4 in other words:
IP header + ah + ip header + udp header
So the signalling messages will actually be bigger in IPv4 compared to IPv6!
... And mobility signalling is serious over Wide Area Radio if you have
millions of users...
Even though they are just in IDLE mode....

And I dont agree with you that IPv6 will not be used in private networks...
IPv6 will give you the oppurtunity to have a private IPaddress which you
probaly want in the future cellular systems like CDMA2000, UMTS, GPRS etc...
And with IPv6 you can have a personal ipaddress assigned to you and whats
even more important is that you will not have any problems with ingress
filtering routers etc...

So if your driving force is to minimize the usage over the air why do even
use PPP at all? Then it would be more cheap to terminate ip in the
basestations and tunnel the packets over ip the last hop over the air (from
the bs to the mobile), in other words you send ip packets directly over the
MAC radio link... (If you also would optimize the mac layer for IP traffic
then it would be even greater...).

Supporting CoLocated addresses via PPP by using DHCP dont solve the problem,
if so then I wonder how you roam between two operators that both have
private addresses that is assigned dynamically with DHCP? It will be very
difficult to support this very easy scenario, and if supported with a very
bad performance... Your design does not optimize anything for always
connected ip hosts.

I'm just telling you that I think it would be even a lower risk to go for
IPv6 from start because it solves so many things in default for you.

Best Regards
 Thomas Eklund

> -----Original Message-----
> From: Tom Hiller [mailto:[email-masked]]
> Sent: Tuesday, November 16, 1999 3:54 PM
> To: Thomas Eklund
> Cc: [email-masked]
> Subject: Re: [MOBILE-IP] Reverse Tunneling updates?
>
>
> cdma2000 wireless data does not pursue IPv6 support initially
> for a couple of
> reasons.  (1) There is not a lot of IPv6 deployed and we're
> not sure when we'll
> see significant use of IPv6 in private networks. (2) Mobile
> IP with IPv6 will
> require more overhead than with IPv4 on the scarce and expensive air
> interfaces.  The need to minimize overhead on air interfaces
> is one of the
> driving forces behind our including support for FA COA in
> cdma2000. (Note: We
> also support collocated COA via the user simply acquiring a
> dynamic address via
> PPP).
>
> Tom Hiller
>
>
> Thomas Eklund wrote:
> >
> > If you use mobileIPv6 this is not a problem in default.
> > Mobile IPv6 use of binding caches/binding update list/home
> address option is
> > a superior solution compared to mobileIPv4's reverse tunneling.
> >
> > So why not use MobileIPv6 instead where its solved?
> >
> > /Thomas E
> >
> > > -----Original Message-----
> > > From: Tom Hiller [mailto:[email-masked]]
> > > Sent: Tuesday, November 16, 1999 2:46 PM
> > > To: [email-masked]
> > > Subject: Re: [MOBILE-IP] Reverse Tunneling updates?
> > >
> > >
> > > Hi,
> > >
> > > If all mobiles never use reverse tunneling then reverse
> > > tunneling is a waste to
> > > eever implement, or even specify.  The point I am making
> > > regards SHOULD versus
> > > MUST is that the cdma2000 camp thinks reverse tunneling will
> > > be used often
> > > because it is useful for private network access, i.e. to
> > > tunnel to HAs in
> > > private networks; reverse tunneling will also be useful if
> > > ingress filtering is
> > > deployed by ISPs or by networks attached to the Interent.
> > >
> > > Having FAs that do not support reverse tunneling will pose
> > > problems for users
> > > (and Mobile IP) if either or both of these are true.
> > >
> > >
> > > Tom
> > >
> > >
> > > Wolfgang Schoenfeld wrote:
> > > >
> > > > Tom Hiller wrote:
> > > > >
> > > > > Hi everyone -
> > > > >
> > > > > Comments on reverse tunneling and the FA:
> > > > >
> > > > > As a data point from a Mobile IP user, TR45.6 requires
> > > that the FAs to be
> > > > > deployed in cdma2000 networks (i.e. our so called PDSN)
> > > MUST support reverse
> > > > > tunneling.  The decision to invoke reverse tunneling
> > > remains with the mobile. We
> > > >
> > > > If the mobile may choose to invoke reverse tunneling or not ....
> > > >
> > > > > considered that reverse tunneling is important when the
> > > HA is in a private
> > > > > network due to private addresses of correspondent nodes
> > > as well as security
> > > > > associations existing between the FA and HA necessary to
> > > traverse a firewalls.
> > > > > Reverse tunneling is also important if ingress filtering
> > > is deployed by ISPs or
> > > > > other networks attached to the Internet.
> > > > >
> > > > > If the MIP WG leaves the requirement as a SHOULD, some
> > > users will experience
> > > > > problems when they roam to an "RFC compliant" FA when
> > > their HA is in a private
> > > > > network, or if ingress filtering becomes widely deployed.
> > > > >
> > > > > To promote ubiquitousness, the reverse tunneling
> > > requirement for the FA should
> > > > > be a MUST.
> > > >
> > > > is a SHOULD for the FA not just a logical consequence?
> > > > Assume that all mobiles choose never to invoke reverse
> tunneling,
> > > > why then have it supported by the foreign agents?
> > > > Or do I miss something in Tom's arguments?
> > > >
> > > > Regards
> > > > --
> > > > Wolfgang Schoenfeld
> > > > GMD-IPSI, Dolivostr. 15, Room 118, D-64293 Darmstadt
> > > > +49-6151-869-865 (Phone), -818 (FAX)
> > > > +49-170-2285450 (Mobile Phone)
> > >
>

---

From: Tom Hiller <[email-masked]>
Date: Tue, 16 Nov 1999 16:22:13 -0600

Regards IPv6 in private networks, I wrote that in our initial timeframe, IPv6
does not appear to be widely deployed.  So cdma2000 wireless data carriers are
not motivated to deploy IPv6 Mobile IP, presently. That is why TR45.6 does not
pursue it at this time.

One can view Mobile IP with FA COA as a form of IP header compression that
allows the mobile to avoid sending an IP header, which it would if it were using
collocated COA. Given cdma2000 is already using Mobile IP, it is natural for us
to use FA COA.  We are not in a position to use an algorithm like RObust
Checksum-based header COmpression (ROCCO) because we have to reference RFCs, not
IETF drafts (if I understand the status or ROCCO). Question:  As I glanced
through ROCCO, it appeares to be oriented to RTP, so what happens if RTP is not
used by the mobile's applications?

Also, we plan to support IPsec between the HA and FA, to allow the MN the option
of not having to support and send IPsec overhead on the air interface. (Note:
The cdma2000 air interface also will supply encryption). FA COA works well for
this scenario.

I am not sure what you meant by "signaling messages".

PPP was included because there are a lot of PPP devices, and because TR456
members did not agree upon an alternative standard data link protocol.  PPP can
negotiate compression, has extensions for multiple links, does not take long to
initialize, has relatively short headers. TR45.6 plans to investigate
alternative standard data link protocol (i.e in addition to PPP) in a next major
standard version.

PPP address assignment provides the mobile in a serving cdma2000 network with an
address that it can use as a collocated COA. This works fine if the carrier
assigned address is public. We support FA COA, as well as dynamically assigned
home addresses, to help conserve IPv4 addresses.

Tom Hiller