Subject: results and proposal was: RE: [mobile-ip] RFC2002bis interpretati on question

From: George Tsirtsis <[email-masked]>
Date: Thu, 7 Feb 2002 10:15:47 -0500

First of all thanks to Hans and all the others that responded.

The score is 2-all but I only got 4 responses altogether
Behavior 1 (2 votes): if R bit is set the forget the collocated address and
register using the advertised CoA.
Behavior 2 (2 votes):  if Rbit is set then register the collocated address
via the FA.

I have also some information that Rbit has never been tested in interop
events but please correct me if you know otherwise. This is important
because if an FA is implemented to expect behavior 1 but mobiles implements
behavior 2 (and vise versa) I am not sure things will work out as expected.
My opinion is that the Rbit is weakly specified in the spec. I also
interpret the spec as behavior 2, so I guess this has 3 votes :-) , but I
think Behavior 1 is clearly also allowed by the current text. The problem is
the following:

The Rbit was invented to make sure that all nodes connected to the FA
register with it. This means as a minimum that if the Rbit is set and if you
want to use a collocated address then you MUST register it to the FA
otherwise the FA will drop your packets. This was an opinion that was
expressed by someone privately and I also agree with.

One, however, should be able to use an FA that *requires* registration but
DOES NOT offer encaps/decaps services based on CoA. i.e. all mobile nodes
are supposed to have collocated addresses but before they use them they MUST
register through the FA.

Unfortunately, the spec does not allow that because if you send an Foreign
Agent Advertisement you MUST include at least one valid CoA. I think this is
an unreasonable over-specification and disallows a potentially useful model.
The collocated and non-collocated models are independent and should be
possible to be deployed independently.

Can we fix this?

Thoughts?

Regards
George

-----Original Message-----
From: Hans Sjöstrand [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 2:30 PM
To: [email-masked]
Subject: Re: [mobile-ip] RFC2002bis interpretation question

We register with the care-of-address advertised in the advertisement. We use
the home address as source address. Collocated care-of-address we only use
when registering directly with HA.

Have never thought of this as ambiguous, interesting to note that otheres
have. 

So, whats the score George ? It would be interesting to know even though not
revealing who does what for those that haven't responded to the list. 

Regards
/// Hasse 

Bjorn Andersson wrote:

On Tue, Feb 05 2002, at 07:53:55 -0500, George Tsirtsis wrote:
I am trying to figure out how implementers have interpreted the Rbit part
ofrfc2002. I have asked a few people privately and I do not get
identicalfeedback so some discussion here maybe helpful. I remind you that
if the Rbit is set in a Foreign Agent Advertisement theMIP client is
required to register through the Foreign Agent even if it hasaccess to a
collocated address...But what does that mean exactly?1. Should the client
register its Collocated care-of-address (and thusignore the advertized CoA)
but send the registration request to the FA andthe FA forwards it to the
HA?2. Should the client register with the care-of-address advertised in
theadvertisement? If this is the case, can the mobile now also use a
collocatedcare of address as source address for some traffic??
I think it is pretty clear that it is alternative 1. The purpose, assaid in
draft-ietf-mobileip-rfc2002-bis-08.txt, is: "to allow sites toenforce
visiting policies (such as accounting) which require exchangesof
authorization." What would the use of the collocated CoA be if theMN did not
register it with anyone? It would be able to use theaddress as any node, but
it would not be a care-of address.  Bjorn

---

From: Hans Sjöstrand <[email-masked]>
Date: Thu, 07 Feb 2002 17:38:22 +0100

Thank you George for finding this and bringing it up,

BTW, it seams to be up to 5-1 now.

You learn something every day, I didn't know of this little finesse, 
registering with the FA adn yet running co-located mode. And I don't 
know what would be the big benafit. What is the advantage of running 
co-located when yuo have a FA. How does a FA indicate that it doesn't 
support "encaps/decaps services based on CoA"?

We have never run into the problem because our MN always switch to FA 
registered if a adverticements comes out, regardless of R-bit. So, an 
interop with us would be pointless.

If someone perceives to run co-located despite our agents 
adverticements, they will be sean as using our simple IP service and not 
mobile IP. The packets will be treated according to the policy 
configured in the FA (not really a FA in that case, more of a ACD 
(Access Control Device)) and if he is authenticated by some other means 
(like web-login or 802.1x).

My private feeling is that there are no advantage for the MN to run 
co-located over registered with FA. And there is no way for a FA to tell 
that he proposes co-located mode. So, in my mind it's already set, adn 
instead the spec could be clarified to disallow registering with 
co-located address to FA.

E.g. says 3024
   However, one of the primary objectives of the Mobile IP specification
   is not to require this mode of operation.

   The mechanisms outlined in this document are primarily intended for
   use by mobile nodes that rely on the foreign agent for forward tunnel
   support.  It is desirable to continue supporting these mobile nodes,
   even in the presence of filtering routers.

Regards
/// Hasse

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 08 Feb 2002 14:08:03 -0800

Hello folks,

As best I can remember, the 'R' bit was never intended to restrict
against operation with a co-located care-of address.

> co-located address to FA.

This would be a change to the specification, and I don't think it
would be warranted unless someone can show a problem with it.

Also, I do not personally subscribe to the theory that all permissible
behaviors have to be explicitly listed in the specification.  That would
be hard, because then one would get into immeasurable amounts of work,
viz:
- the mobile node can transmit ICMP
- the mobile node can receive ICMP
- the mobile node can use UDP port 80
- the mobile node can use SMTP
- the mobile node can use ...
but none of these are _explicitly_ allowed as a result of any
specific enablement (i.e., "MAY") in RFC2002bis.

Regards,
Charlie P.