Subject: Re: [MOBILE-IP] Private addressing reference in rfc2002-bis ?

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 3 Feb 2000 14:47:20 -0800

> It may make sense to update rfc2344 the tunnel routing
> issues for private addresses,

by the way, i've submitted the rfc2344-bis draft. if you want
to get it before the announcement comes out, you can get it
at:

  http://playground.sun.com/~gab/papers/tunnel.txt

(the only changes are new section 6.3 and an appendix).

> but I still think that
> mipagent (FA) somehow needs to inform the mobile nodes
> that it can handle private addresses-- that means having
> 'T' bit in the agent advertisement field is not sufficient
> to provide support for private addresses.

agreed, but please note that any of this is not in scope for
the update to rfc2344 at this time.

now, going forward (as a separate task),
we could overload the 'T' bit to also imply support
for private addresses as specified in the revision of 2344.

if this is not agreeable to everyone, then, yes, perhaps a new 'P'
bit makes sense.

> It seems logical to me that 'P' bit with agent advertisement
> can let the privately addressed mobile node choose the right FA
> -- but it may have other implications--any particular reasons
> against it ?

but the 'P' bit (or overloaded 'T' bit) does not answer this question:

        what COA should the MN used for registration?

notice that the COA may very well be a function of the MN's home
address: for MN's within the FA's domain the COA is probably
an 'inside' address of the FA. for MN's with home addresses outside
the FA's domain, perhaps an 'external' COA makes more sense.

how are these two different coa's advertised and kept apart? perhaps
a new  private addr extension could carry
pairs along these lines:

        nai, coa

        or

        dns authority, coa

given the first element of the pair, an mn would be in a position to select
the right coa it needs to use.

the private addr extension need not be included in all advertisements. upon hearing a 'P' bit,
the mn could solicit with a special code, say in order to obtain the priv
addr extension.

this is just wondering out loud what to do, as i said, the revision to rfc2344 does
not go into this and is very limited in scope. this last stuff is for later discussion.

-gabriel

---

From: Pete McCann <[email-masked]>
Date: Fri, 4 Feb 2000 13:54:43 -0600

Hi, Gabriel,

Gabriel Montenegro <[email-masked]> (GM) writes:

GM> but the 'P' bit (or overloaded 'T' bit) does not answer this question:

GM>         what COA should the MN used for registration?

GM> notice that the COA may very well be a function of the MN's home
GM> address: for MN's within the FA's domain the COA is probably
GM> an 'inside' address of the FA. for MN's with home addresses outside
GM> the FA's domain, perhaps an 'external' COA makes more sense.

In the scenarios we considered in 3GPP2, the advertised COA was always
the externally visible, public address of the FA.  In these scenarios
the FA and HA always have one publicly visible address.

If you assume that an FA is there to provide services to visiting
mobile nodes in the form of tunnels back to an HA, it doesn't make
much sense to allow them to register with a private COA.  I would
prefer that this internal address is normally hidden completely from
the MN.  In 3GPP2 this is perfectly reasonable because you are connected
to the FA over the R-P interface on a point-to-point link; you don't
ever need to know the internal address of the tunnel endpoint.
Other deployment cases may have other requirements but I want to make
sure this is kept as an option.

If we assume that FAs are somehow deployed *within* a private network
then that is a different scenario.  If an FA is intended to serve only
internal customers than it can certainly advertise its internal
address (indeed it may have only an internal address).  If an FA is
intended to serve both internal and external customers, then I think
we need solutions like the one you talked about (giving additional
domain information along with each advertised COA).  Otherwise there
are some questions that need to be resolved with respect to address
space collisions.  A MN might be fooled into thinking it is at home
(by seeing an advertised private COA) even when it is not, and might
try to use an internal HA even when no such HA exists (or at least the
MIP SA won't work even if there is an HA at that address).

I remember once someone was talking about putting an NAI in agent
advertisements, but this doesn't seem to be allowed by the current NAI
draft.  Does anyone know if this is still being contemplated?  Maybe
simply placing the NAI somewhere in the advertisement would be enough
for the MN to determine if it is inside or outside its home network,
even if the NAI is not associated with any address as you suggested.
Alternatively, we could just describe a new response code that says
"you're at home, bozo" whenever an at-home mobile tries to register
(note that this may or may not be a rejection of a request, depending
on the address allocation strategy in use - a few of us are working on
a draft that describes this sort of behavior).

-Pete

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 4 Feb 2000 12:36:07 -0800

> a draft that describes this sort of behavior).
I would welcome this change (and I wouldn't have to change my implementation :)
 PatC