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

From: Annika Jonsson <[email-masked]>
Date: Mon, 13 May 2002 17:52:38 +0200

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: Behcet Sarikaya <[email-masked]>
Date: Mon, 13 May 2002 11:53:48 -0500

Hello Annika,
  I have a question on how your draft which I strongly support would 
behave in the presence of NAT/NAPT boxes and IPsec VPNs? I could not see 
any GFA consideration in?
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt
and in
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-vpn-problem-statement-00.txt

Regards,

Annika Jonsson wrote:

--behcet

---

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

Hi Behcet,

I have only looked at those drafts briefly, but my guess is that regional 
registartions would have the same problems, and they could be solved in the 
same way as basic Mobile IPv4. The GFA will act as, and look like, any FA 
to the outside world, so there shouldn't be a big difference. It could of 
course be good if these drafts also included GFA considerations.

There might be one difference in the NAT case: a GFA could in itself be 
placed on the border between a private and a public domain, instead of a 
NAT. This has always been the intention with this draft, although it was 
not really stated explicitly. But now, after incorporationg some of Alan's 
comments (as I think we will, but of course it depends on if we get 
consensus on the list), this will become clearer, and more flexible.

/Annika