Re: [Mip4] WG Last call ondraft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST)

[Henrik Levkowetz <henrik at levkowetz.com>]

Hi Pete,

Monday 16 February 2004, Pete McCann wrote:
> Henrik Levkowetz writes:
...
>  > 
>  > This is a very good point.  Only the assigned HA should have to know
>  > anything about it's detailed setup, all others should only have to
>  > know about the addresses of alternative HAs.
> 
> Even if the information comes from the assigned HA, I am a little bit
> confused about the model here.  When up and running, a mobile node
> knows the following:
> 
> 1) its home address
> 2) its home subnet prefix (length)
> 3) its home agent address, and a security association with that home
>    agent.
> 
> Now, we don't really need to know the home agent's address in order to
> do home link detection; we just need to see a router advertisement
> that says we have returned to the home prefix, right?

Well...  in the basic 3344 scenario yes, but it isn't particularly good
if you go to private (rfc1918) address home networks.  (Too many of the
primate networks turn out to be 192.168.0.x and 192.168.1.x ...) Now,
knowing the exact address of the HA on the home network reduces the
error frequency (believing you're home when you're not) by in practice
maybe a factor on the order of 100 - but is really not particularly
good, either...

We really need a nai in the advertisements.  The general NAI extension
has been defined for advertisements too, so it's basically just a matter
of using it with a HA NAI in the advertisements.  That may need either
assignment of a subtype number for the generalized NAI, or declaring
that the currently defined HA identity NAI subtype may be used in
advertisements.  Mmh, I think I'll write a very short draft on this.

A remaining question then is - if we assign HA address dynamically,
should we also provide additional extension subtypes to carry additional
information about the assigned HA?  (For the NAI case this isn't needed
though, as it's covered by the NAI carrying extension.)

> Are we saying there will be cases where the home agent address is not
> on the home subnet prefix?  I suppose that is possible, and it
> presents no big problem: the HA could still be reachable at its
> "external" IP address even from within the "internal" subnet, modulo
> firewall configuration, so the MN could send a de-registration from
> anywhere.

No, this wasn't the scenario I was thinking of.

> Moreover, is it true that the data structures inside Mobile IP clients
> can remember more than one IP address for a given mobility security
> association?  Or would it be more proper to think of these as separate
> security associations with separate entities, even though they might
> have some keys/SPIs in common?

Mmm, the latter, I think.

...

>  >
>  > > To solve this, one way would be to mandate the MN always to send the
>  > > extension if the dynamic HA assignment is supported and configured.
>  > > Another way is to remove the option to have a unicast address in the
>  > > HA field. I didn't quite understand the advantage over just always use
>  > > ALL-ZERO-ONE-ADDR. 
>  > 
>  > It seems to me that there are two ways the HA may receive a request with
>  > a unicast address which does not match its own address:
>  > 
>  > 1) The MN places different HA addresses in the request HA field and in
>  > the IP header destination address.  I don't see that this gives any
>  > extra functionality over using the ALL-ZERO-ONE-ADDR.
> 
> I agree.  Maybe we should adopt this convention as an indication of
> support for the rejection code.

Not sure I follow - could you elaborate? 

>  > 2) The FA decides to forward the registration request to a different HA
>  > than the one requested by the MN.  In this case, the draft suggests that
>  > the discrepancy be observed by the HA, which may respond with a
>  > REDIRECT-HA-REQ error value.  
>  >
>  > Now, I don't have any great issue with the HA side of this, but I'm
>  > quite doubtful as to permitting a FA to make the decision of forwarding
>  > a registration to another HA than the one requested by the MN.  And what
>  > is the the advantage here?
> 
> I agree the FA should not be forwarding the request willy-nilly when
> the MN did in fact specify a valid unicast HA address.  However, there
> may be some sort of policy in place at the FA to only allow a certain
> set of HAs.  So, maybe we should allow the FA to insert a rejection
> code to inform the MN that it should try again with the
> ALL-ZERO-ONE-ADDR, even though we have no indication that the MN
> supports the extension, because the only other alternative might be to
> silently deny service to the MN.  This would be a good use for
> Charlie's new FA rejection code procedure.

Sounds like a possibility. 

Alternatively, we could use an extension from the MN to indicate support.

	Henrik

Attachment: pgp00089.pgp
Description: PGP signature