Subject: RE: [mobile-ip] RE: [mobile-imp] WG Last Call: draft-ietf-mobile ip-reg-tunnel-06. txt

From: "Ahmad Muhanna"<[email-masked]>
Date: Mon, 22 Apr 2002 17:26:16 -0500

Hello Charlie;

I still believe that those backward compatibility issues
have not been answered YET.
I will compile another response which includes all issues at once.

Regards;
Ahmad Muhanna

> 
> Hello Ahmad,
> 
> I'll try to make some answers here.
> 
> > You are proposing a solution for a specific problem.
> > You are making this great claim that this solution supports 
> existing Mobile
> > IPv4 implementation.
> > 
> > "
> >    Foreign agents that support regional registrations are 
> also required
> >    to support registrations according to Mobile IPv4 [9].  
> If there is
> >    a foreign agent address announced in the Agent Advertisement, the
> >    mobile node may register that foreign agent care-of 
> address with its
> >    home agent [9].
> > "
> 
> This is O.K., right?  What does it mean, "great claim"?
> 
> > Not only this, BUT you also make another great claim 
> without demonstrating
> > HOW!!!
> > "
> >    For mobile nodes that cannot process a NAI, or with 
> mobility agents
> >    that are not configured to advertise their NAI, regional 
> registration
> >    is still useful, but the lack of certain features may 
> result in less
> >    than optimal results.
> > "
> 
> If the mobile node cannot process NAI, then it can still do regional
> registration.  Why not?  Also, isn't it better to write down where
> additional configuration at the mobility agents can help to get the
> best results?  I think it's better to fully explain as much 
> as possible
> here.
> 
> 
> > On the other hand, it seems that you assume that the whole 
> network will
> > be upgraded at the same time to accommodate your solution.
> 
> Not true!  It is possible to mix regional foreign agents with regular
> foreign agents, and so on.
> 
> > We are dealing with at least three different entities, MN, 
> FA, and HA. you
> > added another one GFA.
> 
> Well, if you don't have a GFA, then you don't have regional 
> registration.
> Do you mean to suggest otherwise?
> 
> > There is a great absolute possibility that those entities 
> do not belong to the
> > same operator.
> > Unless your draft addresses clearly how these entities 
> would know what the
> > others support in reference
> > to what you are proposing or offering a smooth solution 
> without violating the
> > existing entities,
> > there will continue to be backward compatibility issues and 
> your first claim
> > is not justified.
> 
> As far as I can remember, regional registration has been 
> targeted mainly
> at domains (regions) operated by the same operator.  Maybe there are
> more considerations with multi-operator domain, but that 
> really was not
> on our radar.
> 
> > I hope I made myself clear here in order to address these backward
> > compatibility issues.
> 
> I think that the places where new features are enabled by 
> mechanism that
> is not able to be parsed by RFC 3220 mobile nodes should not 
> necessarily
> be given as examples of the lack of backward compatibility.  
> Mobile nodes
> that don't do regional registrations should be able to be served by
> foreign agents that do offer regional registrations in addtion to
> home registrations.  I am not aware of a place in the draft that would
> make this untrue.
> 
> Mobile nodes that wish to use regional registration with 
> foreign agents
> that do not support it, will not succeed.  Mobile nodes that 
> wish to use
> zero care-of addresses with home agents that do not support it, will
> not succeed.  Mobile nodes that cannot use advertisements unless the
> advertisement contains a care-of address, cannot register with a
> foreign agent that does not offer a care-of address.  These are not
> examples of backward incompatibility.  After all, to take the latter
> case, if the foreign agent doesn't offer a care-of address, it just
> is not running RFC3220, presumably for some good reason from the
> perspective of the local operator.  The mobile node that only run
> RFC3220 should just cannot use that foreign agent.
> 
> We have attempted to preserve backwards compatibility, while allowing
> the regional registration to offer new features and thus extend to
> scenarios where RFC 3220 would not work anyway.  That has to be
> considered O.K.
> 
> Regards,
> Charlie P.
>

---

From: "Ahmad Muhanna"<[email-masked]>
Date: Wed, 24 Apr 2002 11:37:33 -0500

Hello Charlie/Annika;

As I mentioned earlier that I will summarize those backward compatibility
issues which
I still believe have not been answered.

My concern here was to make this draft work before it becomes a standard. 
As long as this feature is OPTIONAL and it is 100% BACKWARD COMPATIBLE, I
have no
problem with it.
The more solutions we have for the same problem is the better as long as
they are:
	1. OPTIONAL
	2. 100% BACKWARD COMPATIBLE.

Operators can pick and choose the best for them.

Before moving to the technical issues that I feel this draft MUST address. 
I may agree with you that some of these points can be eliminated with static

configuration or provisioning. However, the draft has two choices here:
    i.  Either clearly mention these provisioning restrictions, or
    ii. Offer a smooth solution for backward compatibility

Now to the technical points:

ISSUE No. 1: FA advertised a GFA of ZERO:

This draft makes it optional for the FA to set the only advertised Care-of
address
to ZERO. You mentioned that operator must know that by doing this he/she is
blocking
all RFC3220 compliant Mobile Node which needs a FA Care-of Address to
register.
I agree with this BUT the draft must clearly include this.

section 3.3. can read as follows:
" The `I' flag (see Section 7) MUST be set to indicate that the domain
   supports regional tunnel management, and that the availability of a
   GFA is advertised in the Agent Advertisement message.  If the `I'
   bit is set, there MUST be at least one care-of address in the Agent
   Advertisement message, but that address MAY be set to zero. 
  <NEW TEXT> However, setting the only advertised care-of address 
   to ZERO will eliminate the mobile IP service to all mobile nodes which 
   do not support regional registration<NEW TEXT>.
"
Or just eliminate the option of sending a ZERO care-of address.
What do you think?

ISSUE No. 2: FA advertised ONLY one care-of address "GFA care-of address":
Also on another location, this draft makes it possible for the FA to
advertise only
one care-of address. It also make it very specific by saying that if this
happens, 
this address is the care-of address of the GFA.

Now, this will cause the legacy Mobile Nodes not to know that it handed over
to a new
FA, because it always receives the same care-of address. May be we need to 
repeat the above restriction again. OR WHAT about reversing the logic. If
there 
is only one care-of address in the Agent Advertisement, it is the FA care-of
address. Now, Mobile Nodes which wants to use this service with this
condition
it sets the GFA to ZERO.

section 3.3: can be read as follows <some text has been removed>
"
...
   If the `I' bit is set, and there is only one care-of address, it is
   the address of the FA. 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.
...
"
What do you think?

ISSUE No. 3: Legacy HA receives a Registration Request with 
                     GFA IP Address extension or a Replay Protection Style
extension
"
   A Registration Request that does not contain a GFA IP Address
   extension or a Replay Protection Style extension is processed
   by the home agent as described in [9].  If the home agent 
   receives a Registration Request with one of these extensions,
   and the home agent does not support the extension, the home
   agent must return a Registration Reply with the Code value set to
   UNSUPPORTED_EXTENSION [9].  
"

Now this is a new restriction or demand on the legacy HA and is not
acceptable.
Since those extensions are skippable, HA will process the RRQ as Regular MIP
call. You need to make sure to handle this at the GFA. for example something

like the following can be added to section 4.3.

"
If the GFA relays a Registration Request with GFA IP Address extension or a 
Replay Protection Style extension or both and receives a successful
registration 
reply without any of these extension, the GFA MUST send a registration reply

message to the Mobile node with error code of HOME_AGENT_DOES_NOT_SUPPORT_RR

"
What do you think? 

ISSUE 4 & 5
ZERO_CAREOF_ADDRESS & Care-of Address set to zero and a GFA IP Address
extension

I agree these are covered in the Mobile Node consideration as in section
4.1.
"
    If the mobile node sets the care-of address to zero, the mobile node 
   and its home agent MUST support the GFA IP address extension (see section
8.1).  
"

Thanks;
Ahmad Muhanna

Hello Charlie;

---

From: Annika Jonsson <[email-masked]>
Date: Thu, 25 Apr 2002 11:36:48 +0200

Hi Ahmad,

I agree with you that we should sort out the backwards compatibility 
issues. See my answers below.

At 11:37 2002-04-24 -0500, Ahmad Muhanna wrote:

>to ZERO. You mentioned that operator must know that by doing this he/she 
>is blocking

I think we should keep the option, and I agree that we should add this 
clarifying text.

>Now, this will cause the legacy Mobile Nodes not to know that it handed 
>over to a new

Hmmm, yes, I see your point. The reason that we decided that it should be 
the GFA address (if only one) was that that would allow the network between 
the FA:s and the GFA to use for example private addresses, and hide that 
from the MN:s. But that requires a move detection algorithm that doesn't 
rely on the advertised CoA. If this can't be done by "regular" MN:s anyway, 
I agree with you.

So the conclusion is, if you want to use private addresses, or disallow the 
use of the "regular" FA functionality for any other reason, you should 
advertise a zero CoA as above, and then you know that this is not backwards 
compatible.

>                      GFA IP Address extension or a Replay Protection 
> Style extension
>"

I absolutely agree. Actually, I was about to propose something like that, 
since your previous mail got me thinking about this.

>I agree these are covered in the Mobile Node consideration as in section 4.1.
>"
>    and its home agent MUST support the GFA IP address extension (see 
> section 8.1).
>"

Good.
I hope we have sorted out all backwards compatibility issues now, and 
thanks for your help.
/Annika

---

From: Annika Jonsson <[email-masked]>
Date: Thu, 25 Apr 2002 15:10:51 +0200

Hi Ahamad,

I have thought more about this and realised that we have missed one 
thing... see below.

>>message to the Mobile node with error code of HOME_AGENT_DOES_NOT_SUPPORT_RR

Actually, the HA should not return a successful registration reply, becuse 
if it didn't understand the GFA IP extension it doesn't know where the 
tunnel end-point is since the CoA field is zero. I'm not sure what the HA 
will return in this case but I think the approporiate error code is "poorly 
formed request". If this is the case, the GFA can suspect that the problem 
is that the HA did not understand the GFA IP extension, but it doesn't have 
to tell the MN anything, because the MN can see that error code itself and 
draw the same conclusion. One idea to reslove this would be that the GFA in 
this case added the GFA IP extension in the reply to the MN. Then the MN 
can generate a new registration request with a CoA in it so that the HA can 
accept the registration.

/Annika

---

From: "Ahmad Muhanna"<[email-masked]>
Date: Tue, 30 Apr 2002 09:50:40 -0500

Hello Annika;

In section 4.1 the third paragraph it talks about Mobile Nodes
with co-located care-of address and the way it uses
Regional Registration. This section is under Home Registration.
This means that it does not talk about the Regional Registration mechanism
YET. Because that has a separate section No. 5.

Now in the third paragraph section 4.1 as shown below, it talks about the 
Mobile Node adding a Hierarchical Foreign Agent extension and to be placed
after the MN-HA authentication extension in Registration Request message. 
Also, to be protected by the MN-GFA authentication extension. It also
continues 
to say using the mobility security association which has been established
with 
GFA according to section 3.1.2.

" ........... 
   In this case, the mobile node MUST add a
   Hierarchical Foreign Agent extension 8.2, including its co-located
   care-of address, to the Registration Request before sending it.  The
   Hierarchical Foreign Agent extension SHOULD be placed after the MN-HA
   authentication extension.  It SHOULD be authenticated by using the
   MN-GFA authentication extension (see Section 10).  The authentication
   data SHOULD be calculated using a mobility security association
   that has been established with the GFA (Section 3.1.2). ...........
"

I am really confused here for the following points: 
1. We are talking about Home registration. Which I understand is the initial
registration with the Mobile Node Home Agent or when it changes GFA.
However,
the text talk about the initial registration request here.
2. Now at this point of time, there is no established mobility security
association
between the mobile Node and GFA.
3. section 3.1.2, talks about using the mobility security association, which
has been 
established during the initial (Home Registration), in Regional Registration
NOT Home
Registration.
4. In other words, Mobile Node does not have a mobility security association
with the
GFA at the time of initial or Home registration that paragraph 3 talks
about.

Am I correct or I am missing something. 
Please let me know.

Regards;
Ahmad Muhanna