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

From: George Tsirtsis <[email-masked]>
Date: Thu, 7 Feb 2002 11:55:30 -0500

-----Original Message-----
From: Hans Sjöstrand [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 4:38 PM
To: [email-masked]
Subject: Re: results and proposal was: RE: [mobile-ip] RFC2002bis
interpretati on question

Thank you George for finding this and bringing it up,

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

GT> I think it is 4-2 but this was not a contest :-) as I said I think both
behaviors are correct given the current text.

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. 

GT> Well that is the point...you do not have an FA that
encapsulates/decapsulates just a control node that let you pass through or
not based on registrations, which is a much lighter function.

How does a FA indicate that it doesn't 
support "encaps/decaps services based on CoA"?

GT> This is easy. One way would be to allow an FA advert to have Rbit set
but does not include a CoA. The Mobile Node would then see that there is no
CoA so it needs to get a collocated address and since the Rbit is set the
node will have to register it through the FA.

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.

GT> No, no, now you are totally missing the point of the Rbit. Just because
some implementers chose to prefer CoAs if they can get them it does not mean
that CCoAs are not needed and it does not mean that the FA should not be
able to request registration. The Rbit is useful but it is weakly specified
which unfortunately allows you to think that is not needed.

George

George Tsirtsis wrote:

>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: kleung <[email-masked]>
Date: Thu, 07 Feb 2002 10:08:39 -0800

> node will have to register it through the FA.

Since FA supports tunneling, why shouldn't FA advert its CoA?  Then
it's up to MNs to decide to use CCoA or FA CoA.

The R bit is for FA access (or MIP service authorization) control.   The
CoA is not meant for tunneling control, but merely advertised service.
But the above scheme use CoA as tunneling control.

As said, MNs will likely use the FA CoA when advert received.  Though
I think the generic properties of existing spec allows flexibility for MN to
choose where it wants tunnel termination.

The access authentication/authorization scheme may factor in MN's
decision since it may go through 2 levels (802.1x and MIP) when
CCOA is used.  Of course, FA may decide to bypass MIP authentication
when it sees RRQ with D bit set and external CoA if it is aware that
802.1x already occurred.

Flexibility comes complexity.  :)  But forcing MNs to use FA COA
with R bit advertised is rigid, though simpler for the common scenario.

So if we leave spec as is, then MNs choose either CCoA or FA CoA
when it sends RRQ to FA, which advert the R bit.  Is this ambiguous?

Seems like the new proposal is to enforce CCOA tunneling by removing
COA in advert.  And on the other end, proposal to mandate that MN
must use FA COA.  Both cases when R bit set in advert.  Both takes
the right to choose from MN.  This is what we want, right?

Kent

---

From: Hans Sjöstrand <[email-masked]>
Date: Fri, 08 Feb 2002 00:43:04 +0100

- draft-ietf-mobileip-rfc2002-bis-08.txt passed rfc-editor and is in 
auth48 (even though it's been there for quite some time). It's unlikely 
to change before publication. I can't remember now if it goes for draft 
standard or stays proposed.
- There seams to be multiple interoperable implementations of of both 
variants.

The above facts indicate that whither we like it or not, things are 
likely to stay the same.

But RFC 2119 is there for a reason. It's unclear from the specs what is 
required from conforming MN, FA and HA implementations. It's also 
unclear what requirement level the function have, e.g. if it's a SHOULD 
or  MAY for a FA to accept registration replies with coa set to anything 
other than advertised coa. I'm quite sure that it from the crowd 
discussing this is possible to pick a combination of MN, FA and HA that 
won't interoperate. So, some SHOULD and MAY would have been nice to 
have. Vagueness is not a good design strategy when writing RFCs. Not a 
big problem though.  

Regards
/// Hasse