Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #2

From: Phil Roberts <[email-masked]>
Date: Mon, 13 May 2002 15:37:51 -0400

We would like to know whether folks agree or disagree with these
proposed resolutions.

Annika, we're going to need proposed text for each of them, and a
pointer to where it would go in the draft.

Thanks,
Phil

> -----Original Message-----
> From: Annika Jonsson [mailto:[email-masked]] 
> Sent: Monday, May 13, 2002 11:53 AM
> To: [email-masked]
> Subject: [mobile-ip] Regional Registration Last Call 
> Resolution Issue #2
> 
> 
> Hi
> 
> Here are my conclusions and proposals for additions/changes 
> to solve the 
> backwards compatibility issues in the Regional Registrations draft:
> 
> A: Backwards compatibility with RFC3220 MN:s.
> FA:s must advertise their own address, since it is used for movement 
> detection by RFC3220 MN:s. This requires one change and one 
> clarification 
> to the draft:
> - To be backwards compatible, if the FA only advertises one 
> CoA it must be 
> its own address (not the GFA address as specified now). This 
> FA must be 
> able to act as a normal RFC3220 FA (that's in the draft already).
> - clarify that if the FA advertises a zero address, it will 
> not support 
> RFC3220 MN:s. In some cases the owner of the network might 
> prefer this.
> 
> 
> B: Backwards compatibility with RFC3220 HA:s
> The problem here is that an RFC 3220 HA does not understand 
> the GFA IP 
> extension used if the MN sends a registration with zero CoA. 
> There are two 
> ways to solve this:
> 
> B1: According to the draft right now, the MN MUST NOT send a 
> Registration 
> Request with zero CoA if it's HA doesn't support that. This 
> is simple, but 
> not very flexible. If the FA advertises a GFA CoA (in 
> addition to the FA 
> CoA), the MN should use that, and can then make use of regional 
> registrations even though it's HA does not support it. If the FA only 
> advertises it's own address, the MN can not make use of regional 
> registration unless it's HA supports it, but can still use 
> normal Mobile 
> IP. An FA that only advertises a zero address will not be 
> backwards compatible.
> 
> B2: The other alternative is that the draft could be changed 
> by adding a 
> new error code from the GFA to tell the MN that the HA did 
> not support the 
> GFA IP extension. The MN could then try the advertised CoA 
> instead (or, 
> possibly, a new extension added so the the GFA could tell the 
> MN what CoA 
> to use).
> 
> I see one problem with this: I'm not sure how an RFC3220 HA 
> would deal with 
> this kind of registration. In the draft today, the GFA IP 
> extension is 
> non-skippable (because the HA MUST support it if the MN uses 
> it). A HA that 
> doesn't support this would not answer to this registration at 
> all, it would 
> silently discard the message.
> 
> If the extension was changed to be skippable, how would the HA react? 
> Either it would notice that something is wrong with the CoA, 
> and send a 
> reply with some error code (e.g. "poorly formed request??). 
> Or it would not 
> even check the CoA (I couldn't find this mentioned anywhere 
> in RFC3220). In 
> this case it would accept the registration, and set the CoA 
> to zero. The 
> GFA will then receive a reply without a GFA IP extension. In 
> both cases, 
> the GFA _could_ assume that the HA did not support the GFA IP 
> extension, 
> but it doesn't know for sure.
> 
> To conclude: this option (B2) seems too uncertain, so I would 
> rather go for 
> the (more unflexible, but simple) B1 (i.e. no changes to the 
> current draft, 
> but it could be clarified a bit).
> 
> /Annika
>

---

From: Annika Jonsson <[email-masked]>
Date: Tue, 14 May 2002 11:47:13 +0200

>pointer to where it would go in the draft.

se below...

> > able to act as a normal RFC3220 FA (that's in the draft already).

This would go into section 3.3. It would be changed to:

"
3.3. Advertising Foreign Agent and GFA

A foreign agent typically announces its presence via an Agent Advertisement 
message [9]. If the domain to which a foreign agent belongs supports 
regional registrations, the following changes are applied to the Agent 
Advertisement message.

The `I' flag (see Section 7) MUST be set to indicate that the domain 
supports regional tunnel management. 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. If the `I' bit is set, and there is only one 
care-of address (i.e. not zero), 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. The 
FA-NAI (see section 7.2) SHOULD also be present to enable the mobile node 
to decide whether or not it is in its home domain. The decision is based on 
whether the realm part of the advertised FA-NAI matches the mobile node's 
realm. "

> > RFC3220 MN:s. In some cases the owner of the network might

A new section about backwards compatibility:

"3.4 Backwards compatibility with RFC3220

A domain that supports Regional Regisratiosn SHOULD also be backwards 
compatible with RFC3220. If the Foreign Agent does not advertise a zero 
care-of-address, it MUST support registrations according to Mobile IPv4 
[9]. This allows mobile nodes that doesn't support Regional Registrations 
to register via this Foreign Agent using standard Mobile IPv4. If the 
Foreign Agent advertises both its own care- of address and a GFA care-of 
address, a mobile node that supports Regional Registrations but has a Home 
Agent that doesn't, will still be able to make use of Regional 
Registrations through that GFA care-of address. A Foreign Agent that 
advertises a zero care-of address will not be backwards compatible wiht 
RFC3220, since both mobile nodes and Home Agents have to understand the 
zero care-of address. 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."

> > but it could be clarified a bit).

see the proposed new section 3.4 above.

/Annika

---

From: "Ahmad Muhanna"<[email-masked]>
Date: Wed, 15 May 2002 12:46:45 -0500

Hello Annika,
Please see my comments inline.

Regards;
Ahmad Muhanna

> address MAY be set to zero. If the `I' bit is set, and there 

See my comments below.
 
> the mobile node and its home agent MUST support the GFA IP 

Despite the fact that I earlier suggested the restriction when the 
FA advertise a care of address of zero, I need to DISAGREE here!

A more in depth reading of RFC3220 reveals the following:

1. There is nothing in RFC3220 mandates the Mobile Node to check if the
advertised
    care-of address is other than ZERO.
2. On the other hand, the only thing RFC3220 indicate to the Mobile Node
    that there is (are) advertised care-of address(es) is by checking the
length
    of the Mobility Agent Advertisement Extension. (see section 2.1.1.)
3. Therefore, when a Foreign Agent advertised a care-of address of ZERO,
    Mobile Node will accept this address as a valid address and use it as a
valid 
    care-of address in its registration request.
4. Now is the dilemma, the proposed FA will receive this Registration
Request with
    care-of address is set to ZERO.
5. Guess what, the FA will add the GFA IP address extension and send it the
registration
    request to the GFA which will forward it to the Home Agent of this
(RFC3220 compliant) 
    Mobile Node.
6. Again, this Home Agent does not support the GFA IP Address extension
which is
    a non-skippable extension!!!
7. Home Agent will drop the registration request.
8. GFA and probably the FA will timeout, and send a Registration Reply
message with
    error code 78. "registration time out"

9. Guess what, Mobile Node will retry to register again, and the loop
continues!!!
    I guarantee you many people will be very upset.
    
I am not sure if there is a way around this!!!!!

---

From: "Alan O'Neill" <[email-masked]>
Date: Thu, 16 May 2002 03:11:59 -0400

Hi Annika,

DISAGREE (somewhat..)

I would suggest we explore B2 a bit more first. We need to clarify what 3220
should have said then, given that, clarify how a HA should respond to a CoA
= 0. The CoA must be checked by the HA to ensure that CoA != HoA, which
ceases the existing binding. Given this check, and the fact that a 0.0.0.0
destination address is illegal, then replying with a malformed error code
message is optimal.  Given this, the GFA can check the error code and decide
if it wishes to offer a GFA CoA to the MN. If it is offered then the MN can
retry. 

If the MN only uses this when it knows its HA supports it then we are fine.
If the MN knows the HA doesn't support it then why did the MN send it...ie
this is merely covering a dark corner case which the GFA error code
processing is giving us a way out of.. ?

Now if the MN knows the HA does not support GFAIPext then it needs to do
something else, and clearly avoiding sending a CoA=0 is good. In this case
it can only use the advertised GFA CoA in the FAA. This has all the problems
related to disparate address spaces...

	if the GFA CoA is a private address then it can only work with FAs,
GFAs and HAs in the same addressing domain
      if the GFA CoA is a public address then it can only work with publicly
reachable HAs, GFAs and FAs leaving a corporate set of GFAs / FAs publicly
exposed (not good)

We can add some text that says if the MN knows that its HA is in the same
domain as the FA/GFA then it can use the private GFA CoA. Similarly for a
public address.

All of this then looks fine apart from the fact that the MN really has no
way to know the relationship between the FA, GFA and HA, and requiring
public addresses everywhere is a practical no-no. So the MN can only try the
default CoA blindly to use regional registration which the GFA or HA might
then fail given the GFA-HA address space. What then comes back...probably a
mal-formed error message which should cause the GFA to allocate an
appropriate GFA CoA if possibly...ie we still need this mechanism and it is
here that it is most important because this is not a corner case..

Therefore if we combine B1 and B2, convert the MUST NOT to SHOULD NOT wrt
CoA=0 and use of a GFA CoA from the wrong space, and allow the GFA to return
a GFA CoA in all Replies then we are great..this is good useful information
that the FA as well as the MN can use (for the mapping stuff). We can then
leave it up to the MN whether or not it tries again, and allow the FA to
strip the GFA CoA if it wishes to deny that repeat attempt given the HA or
GFA error message.

Hope this makes sense...another RTT may well be necessary though...

-----Original Message-----
From: Annika Jonsson [mailto:[email-masked]]
Sent: 14 May 2002 01:23
To: [email-masked]
Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #2

Hi

Here are my conclusions and proposals for additions/changes to solve the 
backwards compatibility issues in the Regional Registrations draft:

A: Backwards compatibility with RFC3220 MN:s.
FA:s must advertise their own address, since it is used for movement 
detection by RFC3220 MN:s. This requires one change and one clarification 
to the draft:
- To be backwards compatible, if the FA only advertises one CoA it must be 
its own address (not the GFA address as specified now). This FA must be 
able to act as a normal RFC3220 FA (that's in the draft already).
- clarify that if the FA advertises a zero address, it will not support 
RFC3220 MN:s. In some cases the owner of the network might prefer this.

B: Backwards compatibility with RFC3220 HA:s
The problem here is that an RFC 3220 HA does not understand the GFA IP 
extension used if the MN sends a registration with zero CoA. There are two 
ways to solve this:

B1: According to the draft right now, the MN MUST NOT send a Registration 
Request with zero CoA if it's HA doesn't support that. This is simple, but 
not very flexible. If the FA advertises a GFA CoA (in addition to the FA 
CoA), the MN should use that, and can then make use of regional 
registrations even though it's HA does not support it. If the FA only 
advertises it's own address, the MN can not make use of regional 
registration unless it's HA supports it, but can still use normal Mobile 
IP. An FA that only advertises a zero address will not be backwards
compatible.

B2: The other alternative is that the draft could be changed by adding a 
new error code from the GFA to tell the MN that the HA did not support the 
GFA IP extension. The MN could then try the advertised CoA instead (or, 
possibly, a new extension added so the the GFA could tell the MN what CoA 
to use).

I see one problem with this: I'm not sure how an RFC3220 HA would deal with 
this kind of registration. In the draft today, the GFA IP extension is 
non-skippable (because the HA MUST support it if the MN uses it). A HA that 
doesn't support this would not answer to this registration at all, it would 
silently discard the message.

If the extension was changed to be skippable, how would the HA react? 
Either it would notice that something is wrong with the CoA, and send a 
reply with some error code (e.g. "poorly formed request??). Or it would not 
even check the CoA (I couldn't find this mentioned anywhere in RFC3220). In 
this case it would accept the registration, and set the CoA to zero. The 
GFA will then receive a reply without a GFA IP extension. In both cases, 
the GFA _could_ assume that the HA did not support the GFA IP extension, 
but it doesn't know for sure.

To conclude: this option (B2) seems too uncertain, so I would rather go for 
the (more unflexible, but simple) B1 (i.e. no changes to the current draft, 
but it could be clarified a bit).

/Annika