Subject: [MOBILE-IP] IPv6 Mobility Last Call Question

From: James Kempf <[email-masked]>
Date: Tue, 2 May 2000 07:27:15 -0700

Some of the options for fast handover we've been discussing recently may
call for an FA-like entity in IPv6. I've heard this variously referred
to as an "attendent". Is the IPv6 mobility draft last call the right
time to bring up this issue, or should it perhaps wait for a separate discussion
and a separate draft?

                jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 2 May 2000 07:53:27 -0700

Hello Jim,

Bottom line: I do NOT think this should be discussed in the
Mobile IPv6 draft.  In fact, I think we should do everything
possible to expedite the progress of that draft.  Adding new
functionality would be a mistake at this point.

The "attendant" function is as described in the AAA requirements
draft for Mobile IP.

A foreign agent was created to hand out care-of addresses.
If something does not hand out care-of addresses, I don't
think it resembles a foreign agent.

What is being proposed is not at all a foreign agent, but
an authorization agent.  While it is not coincidental that
the foreign agent in IPv4 makes a good locus for the authorization
agent ("attendant") function, it isn't logically necessary.
I think it is a matter of good engineering, efficiency, and
convenience, more than an absolute given, that causes us to
consider co-locating these functions.

In v6, the authorization functions need a new locus, since
the old one isn't available.  Furthermore, I don't believe
that the attendant functionality is purely a Mobile IP thing,
although Mobile IP certainly brings into clear focus the
need for such a thing.

Regards,
Charlie P.

PS. Do you have comments about our recent AAAv6 draft where
    some of these issues are discussed?  We will have a new
    revision soon, but it doesn't negate the discussion in
    our existing draft.

---

From: Fred Baker <[email-masked]>
Date: Tue, 2 May 2000 16:14:59 -0700

>time to bring up this issue, or should it perhaps wait for a separate

that's up to you. If you want the draft as it stands to be reviewed by the
IESG, pulling it back for additional features is probably not the best way
to do it.

One thing to consider is - no, I haven't written up the Internet draft yet
- IP6 mobility may have uses that you haven't thought about which do not
require this.

Consider something happening in various networks around the world,
including at elast a cable network in the US, a DSL network in the UK, a
proposed fiber plant in Sweden, and a proposal being developed in Taiwan.
The idea is that you have a number of homes and SOHO facilities connected
to a common infrastructure which could be perceived as giving one ISP an
advantage. So legislation comes into play that says "all ISPs must be able
to offer their services over this common infrastructure, and individuals in
the homes must be able to use different ISPs".

There are several ways to do this. Traditional ones include Frame Relay,
ISDN, and ATM. What is being proposed are IP networks where the individual
gets his/her IP Address from their ISP, magic happens in the middle, and
the ISP offers its services. There are many ways to do this in IP:

We could use the IP Source Address as a route discriminator and build a
separate route table per ISP, with neighborhood subnets from each ISP
scattered throughout.

We could say "forget it" and use a link layer network. Or we could use MPLS
and drag labeled paths from the ISP to the home (the reverse is
unnecessary, as normal routing would get traffic in the other direction).
We could do the same with other tunnel technologies. We wind up with a
phenomenal number of tunnels, and rerouting issues related to circuit
switching.

More manageably, we could use some variation on a BGP community to identify
folks belonging to the same ISP and set up MPLS labelled paths within
communities. This means a route table per community (ISP) at the edge, plus
an interchange/backbone community, and an MPLS core.

Each of these has scaling and single point of failure issues.

If we use IP4 mobility, that is really just another "tunnel from the ISP to
the home" with a scaling and single point of failure problem at the home
agent. But if we could use IP6 mobility and treat the device in the
home/SOHO as the special case of a mobile device which happens to move
infrequently or not at all, the solution does all the requirements, is
manageable, and scales fairly nicely. The "care-of router" even serves as a
one-way tunnel for us.

Adding a mandatory foreign agent could screw this up for us...

Just a thought.

---

From: Pete McCann <[email-masked]>
Date: Thu, 4 May 2000 11:00:06 -0500

James,

I've been thinking about this issue for some time.  I think there
are good reasons for creating an IPv6 FA, although I'm not sure
the current IPv6 draft is the right place to do it.

I am not saying that an IPv6 FA would serve as a tunnel endpoint,
but there is definitely a need for some sort of "attendant" function
and I think integrating that attendant with Mobile IP has advantages.
Note that the existing IPv6 already requires some sort of entity
sitting on the visited network to serve as a recipient of Binding
Updates when handoff takes place.  There is a need to develop a
security association with that entity at the time the MN first
registers.  Even if you believe that a PKI will exist I think
there are good reasons to involve a AAA infrastructure in the
development of such an association.

Such an entity would actually facilitate the kind of "ISP open access"
that Fred described, rather than hindering it.  It could make sure
that all traffic from a given user was tunneled back to a home
network, by integrating the Mobile IP registration process with some
kind of firewall features.  Mobile IP then would become the universal
"dial-tone" for Internet access.  This scenario requires that
registration requests be sent to an FA rather than directly to an HA,
which is in conflict with the current definition of MIPv6.

Remember, in MIPv4, we can set the "R" bit to require FA-routed
registration even when using a co-located COA.  Maybe some kind
of registration forwarding can be added to MIPv6.

-Pete

James Kempf <[email-masked]> (JK) writes:

JK> Some of the options for fast handover we've been discussing
JK> recently may call for an FA-like entity in IPv6. I've heard this
JK> variously referred to as an "attendent". Is the IPv6 mobility
JK> draft last call the right time to bring up this issue, or should
JK> it perhaps wait for a separate discussion and a separate draft?

JK>                 jak

---

From: Fred Baker <[email-masked]>
Date: Thu, 4 May 2000 11:10:37 -0700

At 11:00 AM 5/4/00 -0500, Pete McCann wrote:
>kind of firewall features.

Would that be an objective? I think the user would generally like to be
able to get his address from the ISP and access the services (which he pays
for) that the ISP offers, but in generally he has no desire that his
traffic go through the ISP. If they can go straight to the peer through the
intervening network, and avoid having a single point of failure or
congestion, he's happiest.

---

From: Pete McCann <[email-masked]>
Date: Mon, 8 May 2000 13:31:01 -0500

Hi, Fred,

Fred Baker <[email-masked]> (FB) writes:

>> kind of firewall features.

FB> Would that be an objective? I think the user would generally like to be
FB> able to get his address from the ISP and access the services (which he pays
FB> for) that the ISP offers, but in generally he has no desire that his
FB> traffic go through the ISP. If they can go straight to the peer through the
FB> intervening network, and avoid having a single point of failure or
FB> congestion, he's happiest.

It sounds really strange that I would be paying an ISP who doesn't
transit my traffic.

If you look at what ISPs are doing today with the wired telephony
plant (DSL), they are tunneling at link layer (through ethernet
bridging or PPP relay) from a CO to their point of Internet
connectivity.  Often this is done over an ATM network or some other
network, in a way that is completely transparent to the end customer.
Such tunnels have to be provisioned manually in cooperation with the
company that owns the co-located termination equipment at the CO.

Applying Mobile IP to this scenario, we *could* (and this is just
speculation) begin to use Mobile IP as a way to dynamically establish
these bindings, and as a uniform way to present credentials on any
kind of network (it's link layer independent).  Then we could
simultaneously tell the CO who we are, where our home network is, and
how to establish a tunnel to that home network with one round-trip of
messages.  In this case the equipment at the CO might be prohibited
(by law) from routing my packets directly on the Internet, or from
providing me any kind of Internet-like service (including DHCP).

-Pete

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 8 May 2000 11:59:59 -0700

Hello Pete,

> It sounds really strange that I would be paying an ISP who doesn't

It sounds even stranger to reroute traffic just to make busywork
for some router in a galaxy far, far away.

> providing me any kind of Internet-like service (including DHCP).

This could be done just as you say without requiring all traffic
to go down the tunnel to the home network.  So what is illegal
about doing it one way or another?

Regards,
Charlie P.

---

From: Pete McCann <[email-masked]>
Date: Mon, 8 May 2000 14:36:56 -0500

Hi, Charles,

"Charles E. Perkins" <[email-masked]> (CEP) writes:

CEP> Hello Pete,
>> It sounds really strange that I would be paying an ISP who doesn't

CEP> It sounds even stranger to reroute traffic just to make busywork
CEP> for some router in a galaxy far, far away.

The most straightforward approach is of course to get Internet service
directly from my point of connectivity at the CO - but then there is
no such thing as "open access."  I'm not sure this list is the place
for a public policy debate, but I was just trying to point out some
(silly) scenarios where I would be forced to pay a third party service
provider for providing essentially no service - if I could get some
services directly, why not just get them all?  Also, I was trying to
make a comparison to what is done today with transparent, layer-2
tunnels between a CO and an ISP.  Maybe these tunnels should all just
go away, since they are inefficient and legacies of the old circuit
world anyway? :)

>> providing me any kind of Internet-like service (including DHCP).

CEP> This could be done just as you say without requiring all traffic
CEP> to go down the tunnel to the home network.  So what is illegal
CEP> about doing it one way or another?

Nothing specifically - laws can be pretty arbitrary.  I was just
positing one state of the world where the law was written that way.
This state of the world is somewhat similar to what we have today with
distinct ISPs and telcos, but it could always change.

Note that there might be other more technical reasons (security
policies, as Alessio has been pointing out) for wanting to see all the
traffic that you, as a home network or ISP, are paying the visited
network to transit.  We can argue about whether such requirements are
"good" or "bad" from the end user's or network utilization point of
view, but as Pat points out those requirements still exist.

-Pete

---

From: Amanda Walker <[email-masked]>
Date: Mon, 8 May 2000 18:07:45 -0400

> We can argue about whether such requirements are

Indeed.  Many of the problems at hand are not technical.  They are policy
problems (both public and private) relating to things like liability,
billing, the responsibilities of common carriers vs. private carriers,
branding, and so on.

From a purely technical point of view, tunneling traffic around (at layer 2,
layer 3, or however else) is inefficient.  However, it is often the simplest
way to solve administrative problems, especially when raw bandwidth is not
the tightest constraint (which, often, it is not).

It's like wholesale vs. retail of phsyical goods.  It's more efficient, in
some sense, for me to buy food from the farms at which it is produced.
However, the farmer is equipped for production--not packaging, freshness
control, and accounting for taxes on individual sales.  Similarly, a carrier
may be quite well equipped to maintain a high performance network, but not
at all equipped to handle front-line consumer tech support, individual
billing and accounting, promotional deals, etc.  An ISP may want to
concentrate on supporting and maintaining a loyal customer base rather than
on whether they need to lease more fiber between Atlanta and New York.  So
they make a deal where each concentrates on what they do best.

To take a real-world example (one of many):

When John Q. Public dials up AOL, his traffic gets tunneled from a UUNET
POP, over UUNET's network to AOL, and then probably back out onto UUNET's
network to get to a web site he wants to visit: yes, this is in a network
traffic sense inefficient.  But that's OK with both UUNET and AOL.  It
solves business problems at the price of a little extra bandwidth.  UUNET
doesn't want consumer customers, and AOL doesn't want to have to maintain
POPs all over the world.  The consumer wins, because from an administrative
point of view, AOL does have POPs all over the world that he can dial up to
and be connected to his service.  The fact that the traffic is being
tunneled for part of its journey is irrelevant.

The same argument can be made about IP mobility reverse tunneling: yes, it
seems inefficient to people who are used to bandwidth being the scarce
resource.  However, that is often not the case.  Even with non-mobile IPv4,
a lot of network traffic is tunneled in various ways for purely
administrative and business purposes these days.  It is no longer at all the
case that physical connectivity and administrative connectivity are
isomorphic.

Amanda Walker <[email-masked]>
Lucent Technologies InterNetworking Systems

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 8 May 2000 15:48:03 -0700

Some time back I sent my comments on the above draft, and Charlie answered.
Well, further implementation experience has left a few concerns in my mind:

1. Advertisement of GFA.

The Internet Drafts states:

  "If the 'I' bit
   is set, and there are multiple care-of addresses, the first care-of
   address is the local FA, and the last care-of address is the GFA."

In my initial e-mail I asked why it wasn't possible to simply have a new
extension that contained the GFA's address, and the response (as I recall) was
to minimize packet bloat. Although I believe that this is a reasonable goal, I
would ask what occurs with a RFC2002 Mobile Node that receives an
advertisement, and decides, for some reason to use the LAST care-of address in
the advertisement? It seems to me like this could cause some problems (because
of #2 below).

2. new MN-GFA Extension

The Internet drafts introduces a new authentication extension, which is the
MN-GFA. First, I have concerns with this one primarily because (to me) the
whole idea behind the Regional draft is to try to hide alot of the internals
of the network, but this new authentication extension forces the Mobile Node
to KNOW that a GFA is being used. Certainly, the draft does state that the
local FA doesn't have to advertise it's care-of address, and could include
only the GFA, but HOW would the MN know that it should use the MN-GFA as
opposed to the MN-FA? Furthermore, what occurs with RFC2002 mobile nodes?

This extension does allow a mobile to share a secret with both the local FA
and the GFA, but I question how often this would EVER be used. It really is
too complex, IMHO.

3. Hierarchical FA extension

I question the use of this extension. Certainly all socket (and variant)
implementations that I know of allow an application to know the source of the
packet. If this wasn't the case, how would the FA know the source port?

The problem here is that this extension breaks network address translation.
The draft states that this extension contains the IP address of the Foreign
Agent, and this COULD be an address that eventually gets translated. In my
case, I have to write an ALG that handles this specific extension. Is there
anyway that we could simply require that the GFA know that IP address of the
sender through an API mechanism?

PatC

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 8 May 2000 15:57:19 -0700

All,

Last week I sent an e-mail stating that I was setting up a mailing list for
the discussion of cellular related technologies, specifically those that don't
really belong in the Mobile IP WG's mailing list.

Unfortunately, I still cannot use cdma-2000.org domain (thanks for those bozos
at... ok, I'll leave that one open). However, for now I set it up at:

[email-masked].

In order to register, simply send an e-mail to:

[email-masked]

with "subscribe cellular [e-mail]" in the body of the message.

This list is completely open, and can be used to discuss ANYTHING that has to
do with IP in cellular environments (and even other wireless technologies).

Enjoy,

PatC

---

From: "Lee, Jiwoong" <[email-masked]>
Date: Tue, 9 May 2000 11:16:04 +0900

Hi all,

My team is considering the launch of Mobile IP Testbed, under any
OS flatform. (We are a cell phone industry, preparing IMT-2000.)

Our concern is not the cost of testbeds (cost means not only the money),
but the purpose of the testbeds - "What we can get from it"

Thereby I hope some of the experienced experts give any kind of hint about
that.

I thank all in advance.

Regards,

Jiwoong Lee
Hansol M.com, Korea

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 19 May 2000 22:10:29 -0700

Hello Pat,

Here are some more answers.

> opposed to the MN-FA? Furthermore, what occurs with RFC2002 mobile nodes?

Annika, Eva, and I have come to the conclusion, each time that we
discuss this matter, that the mobile node has to know that it is
doing a regional registration.  And, the leaf FA has to know.
The details about why are grungy and would take too long to type
in just now, but I can try it if you aren't happy with the mere
statement of it.

RFC 2002 mobile nodes do home registrations, not regional registrations.

> and the GFA, but I question how often this would EVER be used. It really is

On the other hand, we don't want to mandate a restrictive security
model in the regional registration draft.  Everything we have specified
will work with diverse or uniform key distribution in the collection of
regional foreign agents.  If you want to manually distribute the same
key to every FA and every GFA, fine.  If you want to do IPsec++ with
trimordial block vigilantism algorithms, then that is also fine with us.
We just want to specify what the control flow for the registration
traffic should be.  That can be considered separately from how the
security associations are managed.  We also expect that a good security
draft will discuss AAA mechanisms.  We don't want to discuss AAA in
the regional registration draft.

> packet. If this wasn't the case, how would the FA know the source port?

In my heart of hearts, I resonate with this philosophy.  Unfortunately,
every time I try to follow it, the working group repudiates it.  The
feeling seems to be that most programmers can't handle the extra bit
of programming.  Examples where I have tried and failed to follow this
philosophy include Mobile IP, SLP, and DHCP drafts.  If you can manage
the sociological process of transferring requirements off the wire and
onto the CPU (and the mind of the lowest common denominator of the
programming breed), then I wish you the best of luck.  Be sure to
work it out with one or two IESG members before unleashing it onto
the working group.  Furthermore, it apparently matters not in the
least that extra bits over the air are bad for wireless, at least
not in the mindset of the current IETF leadership.

> sender through an API mechanism?

Can't ALGs be made infinitely smart with unbounded state?  Isn't this
good for the industry?

I don't understand the interaction of GFA with API, and besides I didn't
think that we did APIs here.

Regards,
Charlie P.

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 22 May 2000 09:56:55 -0700

> in just now, but I can try it if you aren't happy with the mere

Well, just because really doesn't answer my question :( I don't specifically
have a problem with the Mobile Node having to know that it is doing a
regional registration, but it would be REALLY nice to simplify the security
model.
> the regional registration draft.

I agree that it doesn't need to be discussed in the draft, but a single
authentication mechanism between the Mobile/FA/GFA would be really nice, and
alot simpler.

> not in the mindset of the current IETF leadership.

Well, given that there really aren't that many "legacy" devices out there that
I am aware of that cannot produce the source of a packet to an application, I
cannot see why this could not be considered. Do you think that this should be
taken up in the general IETF list since it appears to be more of a
sociological problem?

> Can't ALGs be made infinitely smart with unbounded state?  Isn't this

But I wanted to no NO ALGs required... I already have Mobile IP working
through my NAT fine, and this extension breaks it.

PatC

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 22 May 2000 10:19:55 -0700

Hello Pat,

> regional registration, but it would be REALLY nice to simplify the security

I guess I wasn't very clear.

1) I was asking for a rain check on answering the question, not
   saying just because.

2) You can use a simple security model.  I just say that it isn't
   the _only_ security model.

> authentication mechanism between the Mobile/FA/GFA would be really nice, and

Beauty is in the eye of the beholder.  But I agree with you on
all counts, except that I don't want to be restrictive in the
regional registration draft.

> taken up in the general IETF list since it appears to be more of a

I hope you have a lot of spare time.  There's a lot of things that
should be taken up on the general IETF list, like how drafts get
disapproved for making illustrative citations using example protocols
that somehow don't meet the litmus tests of certain IESG members.
I personally can't mess with it, and I don't like getting into
antagonistic pissing matches with people who have all the cards.
Maybe somebody else can find the magic algorithm for improvement.

> through my NAT fine, and this extension breaks it.

The function is important.  You can make a specific proposal that
meets working group approval and I'll be happy to go along.
I hope we are not yet at the stage yet where we have to include
a NAT Considerations section in each document, even for protocols
in the Routing Area.

Regards,
Charlie P.

---

From: Gopal Dommety <[email-masked]>
Date: Mon, 22 May 2000 11:31:08 -0700

Hello Charlie and Pat:

        I would appreciate you clarificaiton regarding the following sentance the draft.

   If the MN-AAA Authentication
   extension is present, then the Registration Message MAY be sent by
   the mobile node without containing the Mobile-HA Authentication
   extension [12]

Could you elaborate on how the HA authenticates the mobile in this case (i.e, only the MN-AAA
is present). It may prove useful to add this clarification to the draft to avoid confusion.

Thanks
Gopal

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 22 May 2000 16:05:38 -0700

> Could you elaborate on how the HA authenticates the mobile in this case
> (i.e, only the MN-AAA  is present). It may prove useful to add this
> clarification to the draft to avoid confusion.

Well, the intent is that the AAAH and the HA inherently trust each other, and
therefore that trust is assumed to be good enough to not require the MN-HA be
present. This is especially important in cases where the MN doesn't have an HA
allocated to it (initially), or when the HA is allocated in a foreign network.
 The AAA protocol *will* have to allow for messages between the AAAH and the
HA to be reasonably secure, in order for the HA to be able to trust the
request from the HA.

Hope this helps,

PatC