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

From: "Lipford, Mark" <[email-masked]>
Date: Fri, 12 Nov 1999 17:15:30 -0600

I support making reverse tunneling mandatory in the HA, but leave it as a
SHOULD in the FA.  I think that leaves the current implementations as being
compliant, but will also allow support of new FA's to support reverse
tunneling that TR45.6 is wanting.

As far as the timing I'm am not a familiar with this process as I should be
so I will leave that to others on this list to discuss.

Regards
Mark Lipford
                -----Original Message-----
                From:   Charles Perkins [mailto:[email-masked]]
                Sent:   Friday, November 12, 1999 2:56 PM
                To:     [email-masked]
                Subject:        [MOBILE-IP] Reverse Tunneling updates?

                Hello,

                During the recent Mobile IP working group meeting, I raised
the
                question about whether Reverse Tunneling should be
considered
                a mandatory feature for implementation by mobility agents.
There
                are several considerations that bear discussion.

                First, the question can be subdivided.  It would be simple
to
                require that all home agents support reverse tunneling.  I
think
                we should impose this requirement.  Very little additional
                implementation burden is created, and the payoff is
considerable.

                In addition, we could consider requiring foreign agents to
support
                reverse tunneling.  This is a bit more work.  I'm still in
favor
                of it, but on the other hand I'm sympathetic to the argument
that
                doing so would cause existing foreign agents to become
noncompliant.
                Perhaps reverse tunneling can be specified as a SHOULD.

                Secondly, there is a matter of timing for any such
additional
                specification.  If we cycle Mobile IP as a Proposed Standard
                with the recent clarifications, then I think that would be a
                good time to put in any upgrades for Reverse Tunneling.  If
this
                does not happen, then it would be difficult to put in at any
                later time, because doing so would insert yet another delay
as
                the Mobile IP base specification would again have to cycle
at
                Proposed Standard.

                Comments and discussion is invited.

                Your hard-typing editor,
                Charlie P.

---

From: Yingchun Xu <[email-masked]>
Date: Sat, 13 Nov 1999 11:04:43 -0600

Since reverse tunneling is mandatory in certain cases such as private network
access and ISP network access, we really need to make it mandatory in all cases
for the reason that it needs to be transparent to end user. Can you imagine poor
users scratching their heads trying to figure out what is reverse tunneling and
when it should be enabled/disabled for different network access.

Even for application developer, it would be almost impossible for them to figure
out when the reverse tunneling should be turned on/off just because some
wireless carriers may always want to have reverse tunneling being forced and the
others don't. It would be a roaming nightmare if that happens.

--Yingchun.

Charles Perkins <[email-masked]> on 11/12/99 02:55:44 PM

Please respond to [email-masked]

Sent by:  Charles Perkins <[email-masked]>

To:   [email-masked]
cc:    (Yingchun Xu/MW/US/3Com)
Subject:  [MOBILE-IP] Reverse Tunneling updates?

Hello,

During the recent Mobile IP working group meeting, I raised the
question about whether Reverse Tunneling should be considered
a mandatory feature for implementation by mobility agents.  There
are several considerations that bear discussion.

First, the question can be subdivided.  It would be simple to
require that all home agents support reverse tunneling.  I think
we should impose this requirement.  Very little additional
implementation burden is created, and the payoff is considerable.

In addition, we could consider requiring foreign agents to support
reverse tunneling.  This is a bit more work.  I'm still in favor
of it, but on the other hand I'm sympathetic to the argument that
doing so would cause existing foreign agents to become noncompliant.
Perhaps reverse tunneling can be specified as a SHOULD.

Secondly, there is a matter of timing for any such additional
specification.  If we cycle Mobile IP as a Proposed Standard
with the recent clarifications, then I think that would be a
good time to put in any upgrades for Reverse Tunneling.  If this
does not happen, then it would be difficult to put in at any
later time, because doing so would insert yet another delay as
the Mobile IP base specification would again have to cycle at
Proposed Standard.

Your hard-typing editor,
Charlie P.

---

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

> From: BINAR, Simon [mailto:[email-masked]]
> Sent: Tuesday, November 16, 1999 4:48 PM
> Subject: Re: [MOBILE-IP] Reverse Tunneling updates?
>
>
> I totally agree with you about this problem, and I already pointed out
> this problem a few months ago (in the attached mail message). The
> questions I had and I still have now are:
>
> - If the decision to use reverse tunneling or not lies with the mobile
> node, which criteria should the MN use to perform such a decision? If
> the MN is from a home network using private addresses, then I
> guess the
> MN will always use reverse tunnelling. However, if this is
> not the case
> and the MN is located in a visited network that has deployed
> a firewall
> that uses ingress filtering, how should the MN decide when to use
> reverse tunnelling? Send several registration requests, and after
> several time-outs try it again using a reverse tunnel?
It is solved in defualt in mobileIPv6!
Since the mn gets a CoA via nd locally it has no problems with ingress
filering firewalls.
The binding update is also authenticated (this of course because every mn
MUST support IPsec in IPv6).

>
> - I guess that usage of firewalls will be a quite common
> scenario in the
> future "wireless Internet". If the MN is configured to always use
> reverse tunnels, in order to ensure "global roaming", how
> does this fit
> together with the goals of route optimisation? If a correspondent node
> can communicate directly with me using an "optimal route"
> (whatever that
> means) but I can't do it because I am "forced" to use a
> reverse tunnel,
> why bother at all about optimising routes? (just being a little
> provocative here... :-))
And I'm being more (perhaps?) provocative.
Use mobile IPv6.

When I observe the discussion on the mailing lists I dont think that people
have read and understood mobileIPv6 and the difference between mobile ipv4
and v6...

/Thomas Eklund

>
> I think there is a dilemma here...
> ----------------------------------------------
> Simon Binar
> NEC Europe Ltd.
> Tel:   +44 (0)1753 606933
> Fax:   +44 (0)1753 606901
> EMail: [email-masked]
> -----------------------------------------------
> DISCLAIMER:  Any views or opinions expressed in
> this E-Mail message should be considered as the
> personal views/opinions of the author.  They do
> not  necessarily  represent  the  views  of the
> author's employer.
>
>
>
> > From: Yingchun Xu [mailto:[email-masked]]
> > Sent: 13 November 1999 17:05
> > Subject: Re: [MOBILE-IP] Reverse Tunneling updates?
> >
> >

---

From: Karl Freter <[email-masked]>
Date: Tue, 16 Nov 1999 10:42:41 -0600

Pat and Co., This is an interesting idea.  If you abstract it up a level, you
come up with the idea of policy distribution.  Like key distribution, one could
disseminate policy information to the respective nodes (reverse tunneling
support, IPSec requirements, route optimization supported,  routable or private
IP address assignment (for certain routing decisions), etc.).  Once an
implementation for policy distribution is in place, one could easily
enhance/extend/modify policy information amongst all the nodes.

Where to do this, how to do this, manageability, etc. is certainly open to (a
lot of) discussion.

Thanks,

Karl

"pcalhoun/@eng.sun.com" <Pat.Calhoun on 11/16/99 10:20:18 AM

Please respond to "[email-masked]" <[email-masked]>

Sent by:  "[email-masked]" <Pat.Calhoun

To:   [email-masked]
cc:    (Karl Freter/MW/US/3Com)
Subject:  Re: [MOBILE-IP] Reverse Tunneling updates?

I just started thinking about an idea that may have some potential. In the
PPP world, the PPP client has very little knowledge about the services that
will be provided by the NAS, as most of the service description comes in
the form of authorization information from the AAA infrastructure.

Is there anyway that we could have the AAA dictate to the HA and FA that the
Mobile Node requires reverse tunneling? This would allow the feature to be
turned on/off by the network administrator, and would require less intelligence
(read: minimize configuration problems) on the mobile.

if no AAA is present, then the mobile needs to request reverse tunneling.

Comments?

PatC

> the MN is from a home network using private addresses, then I guess the
> MN will always use reverse tunnelling. However, if this is not the case
> and the MN is located in a visited network that has deployed a firewall
> - I guess that usage of firewalls will be a quite common scenario in the
> reverse tunnels, in order to ensure "global roaming", how does this fit
> can communicate directly with me using an "optimal route" (whatever that
> means) but I can't do it because I am "forced" to use a reverse tunnel,

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 16 Nov 1999 08:52:16 -0800

I think that we've pretty much concluded, at least in some Working Groups,
that  Inter-Domain "policy" distribution isn't going to happen. The current
model is to send an authentication and authorization request to some home AAA
server, which returns service related authorization information, in this case
being Mobile IP.

Where to do this (etc), specifically as it relates to access, is the AAA WG.
It is within their charter, and the WG is moving ahead.

btw, I try to stay away from ambiguous terminology, such as policy. What is
policy anyway?

PatC

> come up with the idea of policy distribution.  Like key distribution, one
> could disseminate policy information to the respective nodes (reverse
> tunneling support, IPSec requirements, route optimization supported,
> routable or private IP address assignment (for certain routing decisions),
> etc.).  Once an implementation for policy distribution is in place, one
> could easily enhance/extend/modify policy information amongst all the nodes.
>
> turned on/off by the network administrator, and would require less
> intelligence (read: minimize configuration problems) on the mobile.
>

---

From: "BINAR, Simon" <[email-masked]>
Date: Tue, 16 Nov 1999 16:53:36 -0000

I have then another question. Is it likely that IPv6 will be so widely
deployed in the Internet in, say, 2 to 3 years from now, that it would
be feasible for carriers/ISPs to base their mobile networks entirely on
MIPv6?

I would like to also point out that one attraction of MIP is its ability
to support both *wireless* and *fixed* terminals. Some users might be
connecting to the Internet just via regular fixed lines (e.g., using an
Ethernet connection in the office, meeting room, at home, etc...). I
believe it is quite likely that there will be a large number of IPv4
"semi-mobile" terminals (connecting via fixed lines) to support and this
will require use of MIPv4. This is to say that, while MIPv6 may solve
all the problems pointed out in this discussion, a solution for MIPv4
probably needs to be found as well... What do you think?

> From: Thomas Eklund [mailto:[email-masked]]
> Sent: 16 November 1999 16:15

---

From: Yingchun Xu <[email-masked]>
Date: Tue, 16 Nov 1999 14:38:39 -0600

Pat,
I agreed with you that this is one way to solve the MN reverse tunneling
selection. But still this would require reverse tunneling being mandatory in FA,
which was one of the issue we have being discussed.

--Yingchun

Comments?

PatC

---

From: "Lipford, Mark" <[email-masked]>
Date: Tue, 16 Nov 1999 20:01:40 -0600

I am not an expert on IP v6 so I won't even attempt to discuss the impacts
over the RF.

What the main issue is however, is the number of IP v4 users currently in
use.  Since we are building an architecture that will allow a user (IP v4
initially) to access their services and features we would be limiting
ourselves to only support IP v6 over our network.  It is that simple.

Regards

                -----Original Message-----
                From:   Thomas Eklund [mailto:[email-masked]]
                Sent:   Tuesday, November 16, 1999 10:04 AM
                To:     [email-masked]
                Subject:        Re: [MOBILE-IP] Reverse Tunneling updates?

                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

                > From: Tom Hiller [mailto:[email-masked]]
                > Sent: Tuesday, November 16, 1999 3:54 PM
                > To: Thomas Eklund
                > Cc: [email-masked]
                > 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
                > >
                > > > From: Tom Hiller [mailto:[email-masked]]
                > > > Sent: Tuesday, November 16, 1999 2:46 PM
                > > > 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: Basavaraj Patil <[email-masked]>
Date: Tue, 16 Nov 1999 22:50:51 -0600

Having followed this thread for a while now I believe that mandating
reverse tunnelling support at an FA as a MUST is not
justified. Some of the problems that have been raised as to how does a
MN decide to request reverse tunnelling by a FA are valid concerns,
but I do not think mandating FA support for reverse tunnels
effectively solves the problem. Pat suggested a solution to the
dilemma using the AAA entity. There needs to be more thought into this
fracas and a better solution if one is required at all.

So my opinion is that mandating reverse tunnelling support at the HA
is okay but should be optional at the FA.

-Basavaraj

---

From: Thomas Eklund <[email-masked]>
Date: Wed, 17 Nov 1999 11:27:33 +0100

As always, I think that people (and I'm not reffering to you Tom, people in
General) that are very skilled on IPv4 related protocols, very often dont
know the diffrences between v4 and v6 and what IPv6 will give you in
default, especially in mobile systems where IPv6 is a killer app.

> Sent: Tuesday, November 16, 1999 11:22 PM
> To: Thomas Eklund
> Cc: [email-masked];
> [email-masked]'
> 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.
By the time CMDA2000 is ready, IPv6 has been deployed already perhaps not
everywhere, but you have to understand that one of IPv6 biggest business
case and technical case is for mobile systems.
IPv6 aligns very well with the time scedule for 3gen. You argue that because
mobile IPv4 is there, you take.
But I would argue that there is a lot to do, both for mobile IPv4 and v6, so
the protocol details we discuss are currently being standardized, that means
that I dont understand your statement in the first place, because what you
standardize now is not either supported by the carriers.
My point was that because you define new things which is not part of the
standards yet or deployed you can as easily go for ipv6 based solution, and
if you did, you would probably gain 50% of your estimated time to develop
CMDA2000.

>
> 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?
The second goal is also to support TCP traffic... So you might help them in
defining that.
Anyway, why it is specified for RTP is of course because it is designed to
optimize carrying VoIP (SIP/H.323). And that would probably take up 80-90
percent of your capacity in the network if you move to ipbased networks....

>
> 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".
The mobility management! Reg update, binding updates etc.

>
> 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.
How can you say that there is a lot of devices out there! You are going to
design new devices that support CDMA2000...

Ok PPP can do compression, but still it intruces  overhead!!! Both
signalling overhead and dataoverhead! And dont forget the setup time for PPP
which is very heavy.

> TR45.6 plans to investigate
> alternative standard data link protocol (i.e in addition to
> PPP) in a next major
> standard version.
Sound very interesting.

>
> 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
But this is the problem, where do he get those public addresses. In Sweden
for instance, it is very difficult to get a C network from your ISP. And in
Sweden there are approx 3-4 million (out 8 millions) that has a cellular
phone. And to get addresses to give to that many people - I would argue is
impossible. And this is just in Sweden which is a very small country, 3gen
is supposed to work around the world...

> dynamically assigned
> home addresses, to help conserve IPv4 addresses.
>
>
> Tom Hiller
>
>
>
> Thomas Eklund wrote:
> >
> > 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
> > mobiltity message with an ah tunneled over ipv4 in other words:
> > use PPP at all? Then it would be more cheap to terminate ip in the
> > private addresses that is assigned dynamically with DHCP?
> It will be very
> > bad performance... Your design does not optimize anything for always
> > connected ip hosts.
> >
> > IPv6 from start because it solves so many things in default for you.
> >
> > Best Regards
> >  Thomas Eklund
> >
> > > 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
> > > interfaces.  The need to minimize overhead on air interfaces
> > > is one of the
> > > also support collocated COA via the user simply acquiring a
> > > dynamic address via
> > > PPP).
> > >
> > > Tom Hiller
> > >
> > >
> > > Thomas Eklund wrote:
> > > >
> > > > Mobile IPv6 use of binding caches/binding update list/home
> > > address option is
> > > > a superior solution compared to mobileIPv4's reverse tunneling.
> > > >
> > > > > 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
> > > > > > > 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
> > > > > > 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
> > > > > > > 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.
> > > > > > >
> > > > > > is a SHOULD for the FA not just a logical consequence?
> > > > > > Assume that all mobiles choose never to invoke reverse
> > > tunneling,

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 17 Nov 1999 07:44:16 -0800

I, for one, am not claiming any real understanding of IPv6, but I do have
some concerns.

TIA's TR45.6 has been working on an architecture for quite some time now,
and they have a rather strict deadline (end of this year). This architecture
must be supported by existing clients (read: mobile nodes).

Given that we haven't quite mapped out how Mobile IPv6 can/will interface with
AAA (give the lack of an FA), there is some research work necessary in this
area before a standards body decides to roll out a service.

Your point about packet compression is taken. If a good compression algorithm
is used, we cannot use that as an excuse. I think that the only excuse we have
at this time is simply a shortage of time on our hands before deployment, lack
of install base (clients) and the uncertainty of how Mobile IPv6 and AAA can
interact.

Perhaps once we've worked out the details, the cellular carriers can start
supporting IPv6 clients, which would benefit the Internet at large.

PatC

---

From: Thomas Eklund <[email-masked]>
Date: Wed, 17 Nov 1999 17:23:33 +0100

> From: Patrice Calhoun [mailto:[email-masked]]
> Sent: Wednesday, November 17, 1999 4:44 PM
Ok, Which commercial networks use mobile ip today, and in which clients do
you see commercial use of mobile ipv4 that you refer to? Please enlight me

> area before a standards body decides to roll out a service.

This is actually one of the reasons why I strongly supported Charlies Idea
of having a new working group that would work on IPv6 based solutions.

.. Then I guess that you also support this?

> of install base (clients) and the uncertainty of how Mobile
I help you with that because we worked on it when I worked at Ericsson. I
have a solution that might be one way of doing it.

Ok, I will give you a draft how AAA is handled in IPv6 before Christmas.

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 17 Nov 1999 08:34:29 -0800

>you see commercial use of mobile ipv4 that you refer to? Please enlight me

There are at least 3 commercially available Mobile IPv4 clients that I know of.
None for IPv6. Nextel's network makes use of Mobile IPv4, and that is a
commercial network.
>.. Then I guess that you also support this?
of course! I really believe that IPv6 will happen, and we need to figure out
how to tie in AAA with it.

>Ok, I will give you a draft how AAA is handled in IPv6 before Christmas.
Looking forward to read the draft.

PatC

---

From: Vipul Gupta <[email-masked]>
Date: Thu, 18 Nov 1999 08:56:54 -0800

> is okay but should be optional at the FA.

  I agree. I also don't understand the stance that because some
  feature is felt to be important for mobile ip deployment in
  one scenario (TR45.6 in this case), it become an absolute
  requirement for the protocol itself. For wireless LANs within
  an organization (think of a company network that has many
  802.11 cells), mandatory reverse tunneling represents an
  unnecessary processing burden.

  It is perfectly ok for TR45.6 specs to call out requirements
  that are more stringent than RFC 2002.

  vipul

---

From: Qiang Zhang <[email-masked]>
Date: Thu, 18 Nov 1999 13:05:04 -0500

Hi, Vipul,
>  that are more stringent than RFC 2002.

I belive that this *mandatory* is for FA's implementation(FA needs to
support this feature), not in the sense that FA still does the Reverse
Tunneling even the MN doesn't acquire it.

Correct me if wrong

BR,
Qiang

---

From: Vipul Gupta <[email-masked]>
Date: Thu, 18 Nov 1999 12:14:09 -0800

> Tunneling even the MN doesn't acquire it.

   Yes, I realize this but the point is FAs that do not implement
   reverse tunneling are still useful and I don't see the need to
   make this a requirement.

   vipul

---

From: Yingchun Xu <[email-masked]>
Date: Thu, 18 Nov 1999 17:49:27 -0600

Vipul
The concern is dual mode device roaming between wireless WAN and wireless LAN.
This wont work.

--Yingchun

Vipul Gupta <[email-masked]> on 11/18/99 02:14:09 PM

Please respond to Vipul Gupta <[email-masked]>

Sent by:  Vipul Gupta <[email-masked]>

   vipul

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 19 Nov 1999 09:47:08 -0600

>
>
>   If we take this sort of reasoning to the next level, we would
>   want to mandate that that *all* Mobile IP FA's *always* enable
>   reverse tunneling and always *require* mobile nodes to use
>   reverse tunneling. I hope we agree that an IETF standard should
>   not dictate such configuration.
>
>   Like I said before, it is perfectly ok for TR45.6 or another
>   consumer of Mobile IP technology to come up with a requirements
>   profile that is more stringent than the RFC. If tomorrow we
>   find a deployment scenario where support for simultaneous
>   bindings is very useful, is that justification enough to
>   make that a requirement for *all* HAs?
>
>   Am I the only one who feels this way :-)
>
>   vipul

TR45.6 and CDMA2000 wireless data and whoever else wishes to build an FA
with reverse tunnelling capability can do so at their will. The Mobile IP
standard
does not happen to be defined for just that specific segment and hence does
not
need to specify in the standards what happens to be a requirement of the
wireless
industry.

I hope you are'nt the only one who is thinking this way.

-Basavaraj

---

From: Patrik Flykt <[email-masked]>
Date: Mon, 29 Nov 1999 14:19:42 +0200

Hi there,

>area before a standards body decides to roll out a service.

These are just some ideas on the subject:

The situation with a v4 MN with a co-located care-of address is almost
identical to the MIPv6 case, in both situations the MN needs to allocate an
address before it can start using MIP. Perhaps the AAA interaction should be
tied to the address allocation mechanism, e.g. a DHCP (or a PPP) server ?
Fergal Ladley presented something similar in the Oslo IETF.

In IPv6 there is a possibility of stateless address autoconfiguration,
perhaps the v6 MN in the visited network can be notified by the router
advertisement to obtain more information from the DHCPv6 server. The DHCPv6
server could then state that the v6 MN should send its AAA tokens to the
DHCPv6 server in order to gain access to the Internet. That is, the DHCPv6
(and -v4) server does the same job as the FA in the MIP AAA requirements
draft.

Regards,

        Patrik Flykt <[email-masked]>