Subject: [MOBILE-IP] Disparate Address Space in RFC 2344bis [Was: [MOBILE-IP] Private addressing reference in rfc2002-bis ?]

From: Petri Bernhard <[email-masked]>
Date: Thu, 10 Feb 2000 15:22:21 +0100

Hi Gabriel,

I agree with Samita and you that the T bit should not be overloaded to also
indicate support of private addresses. Rather than doing this, we could in
the future look for something like a separate "P" bit and related solutions.
I see your point that the results of the discussions about the use of
private addresses are not mature enough to put more into the RFC 2344bis
draft than the current Appendix on Disparate Address Space Support.

I very much appreciate your work on this Appendix. Although it's just
informal information, it generally clarifies quite a number of the issues
introduced by the possible use of private addresses within Mobile IP, and
could therefore be very useful for subsequent drafting work to solve those
issues.

With regard to this Appendix, I've just got a few questions/comments on some
details:

- Below Figure A1, you describe how an MN sends a packet to an FA via layer
2 mechanisms. How does the FA, in this case, know that the source address
indicated by the MN belongs to MN's home address space C rather than to the
address spaces A or B, i.e. the address spaces of the FA itself? In section
A.3, you mention the possibility that some MAC or PPP information may be
used for that; in this case, how did the initial fixing of that relation
take place? Or, as a related question: how would the FA advertise an address
of an address space, it does not support?

- Below Figure 2 you show that the HA recovers the original packet by being
cognizant of address space C. How is this done? Probably, HA must apply an
algorithm saying something like:  for every (IP-IP) packet I receive with
source address Fb, the inner IP addresses belong to address space C, right ?

- In the paragraph below figure 3, I think there's a typo in the third to
the last line:  H2c  -> H2d

In general, I think that an extensive use of private IP addresses within
mobile IP will require "giving additional domain information" with those
addresses (as Pete has worded it in another mail), i.e. to add an explicit
indication to which that private IP address belongs.

Kind regards
-Bernhard

Bernhard Petri, Siemens
Tel: +49 89 722-34578
Fax: +49 89 722-29098
[email-masked]
______________________________

> -----Original Message-----
> From: Gabriel Montenegro [SMTP:[email-masked]]
> Sent: Thursday, February 03, 2000 11:47 PM
> To:   [email-masked]
> Subject:      Re:
>
> > 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: Gabriel Montenegro <[email-masked]>
Date: Thu, 24 Feb 2000 14:40:15 -0800

[kind words about rfc2344bis appendix elided (thanks!)...]

> address spaces A or B, i.e. the address spaces of the FA itself?

perhaps this is inferred from the mn's nai?

> In section
> take place?

at registration time? the registration process would have to
keep in its bindings all the info it also keeps for forwarding
packets FA->MN after terminating the forward tunnels.

> Or, as a related question: how would the FA advertise an address

i guess. this is where the extra information you can include in the
gre key id field coiuld help (i guess it is getting un-deprecated?).

> the last line:  H2c  -> H2d

yup, caught that soon after submitting it.

> indication to which that private IP address belongs.

yes, perhaps along the lines of my previous message to
the list?

tnx,

-gabriel