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

From: "Ahmad Muhanna"<[email-masked]>
Date: Sun, 21 Apr 2002 22:35:37 -0500

Well, me too. I am not sure what I was doing in 1998.

I believe the scope of this discussion is really absolutely too late. 
However, I would like to continue to raise technical issues about 
this draft which mostly related to backward compatibility.

In section 4.4: Home Agent Considerations:

Issue No. 1:
"
   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].  
"

This section mandates that a legacy HA rejects any Registration Request
which 
contains a GFA IP Address extension or a Replay Protection Style extension
with
an error code of UNSUPPORTED_EXTENSION. Where is the backward compatibility 
here. Also, it references RFC3220 while RFC3220 does not have an error code
of 
UNSUPPORTED_EXTENSION.!!!

Issue No. 2:
"
   If a home agent receives a Registration
   Request message with the care-of address set to zero, and a GFA
   IP Address extension, it MUST register the IP address of the GFA
   as the care-of address of the mobile node in its mobility binding
   list.
"

This section also mandates that a legacy HA to accept a Registration Request
with Care-of Address set to zero and a GFA IP Address extension and to
include
the GFA IP address as the care-of address in the binding table.
Is this backward compatible solution!!!!!

Issue No. 3:
"
If a home agent
   receives a Registration Request message with the care-of address set
   to zero, but no GFA IP Address extension, it MUST deny the request
   by sending a Registration Reply message with the Code field set to
   ZERO_CAREOF_ADDRESS (see section 8.4).
"

This section also mandates that a legacy HA rejects a Registration Request
which contains a care-of address field of zero by sending a Registration
Reply
message with error code of ZERO_CAREOF_ADDRESS.
Again, where is the backward compatibility here or we are asking all
carriers 
to update their HAs in order to be standard compliant by not supporting this
feature!!!

I hope that there is someone out there who have an answer for these issues.

Regards;
Ahmad Muhanna

---

From: Annika Jonsson <[email-masked]>
Date: Mon, 22 Apr 2002 17:10:47 +0200

Hi,

you are right in all cases, but it only matters in one case in my opinion. 
It is the difficult balance between backwards compatibility and optimisations.

That the GFA IP extension and zero CoA field is not backwards compatible is 
obvious, but this is an optimisation, since it is better for the visited 
network to be able to allocate GFA and CoA dynamically. I think we should 
allow this, but not as the only solution. That is why I would like to keep 
the possibility for the MN to include the CoA address in my answer to 
Alan's suggestions.

The first issue that you bring up is more critical, namely what happens if 
a HA doesn't support these new extensions? The "UNSUPPORTED_EXTENSION" 
doesn't exist, as you say. So the HA will probably answer with e.g.  128 
reason unspecified, or 129 administratively prohibited , or 134 poorly 
formed Request. We should correct this, and clarify that if the MN receives 
such a reply, it should try to send a new registration using the advertised 
CoA.

/Annika

At 22:35 2002-04-21 -0500, Ahmad Muhanna wrote:

>This section mandates that a legacy HA rejects any Registration Request which
>here. Also, it references RFC3220 while RFC3220 does not have an error 
>code of
>Again, where is the backward compatibility here or we are asking all carriers