Subject: RE: [mobile-ip] Mobile Prefix Advertisements

From: "Powell, Ken" <[email-masked]>
Date: Tue, 26 Jun 2001 12:20:34 -0400

Hi TJ, Charlie

> -----Original Message-----
> From: T.J. Kniveton [mailto:[email-masked]]
> Sent: Monday, June 25, 2001 5:18 PM
> To: Charles E. Perkins
> Cc: Powell, Ken; [email-masked]; 'T.J. Kniveton'
> Subject: Re: [mobile-ip] Mobile Prefix Advertisements
> 
> 
> Thanks for the message Charlie. I agree with all your comments, and
> would like to add the following:
> 
> "Charles E. Perkins" wrote:
> > >  > Destination Address
> > >  >     If a Mobile Prefix Solicitation was sent, the Source
> > >  >     Address field from that packet.
> > >
> > >    If the Mobile Prefix Solicitation contained a home address
> > >    option, should the should this Destination Address be set
> > >    to the mobile node's home address?
> 
> This level of indirection is unnecessary, and will only work 
> sometimes;
> specifically, we can't rely on a home address option, and using the
> option when it is there is OK, but not necessary. We don't need to
> preserve a MN's Home Address in an advertisement -- the MN should be
> ready to receive a MPA at the same address it sent the MPS from,
> specifically the COA.
> 
> Of course I might be wrong, so let me know if there is a better way to
> support both of these cases.
> 
> > Wouldn't the packet be sent with a routing header?  If so,
> > then this should follow normal rules for sending packets.
> 
> A mobile prefix solicitation will sometimes be sent from a mobile node
> that is trying to construct a home address; thus, you can't rely on an
> home address option.

I agree.

> > > 9.8.1. Building Aggregate List of Home Network Prefixes
> > >    I noticed you added an interesting optimization of filtering
> > >    out any prefixes not used for autoconfiguration. This seems
> > >    like a reasonable thing to do. The mobile node ignores this
> > >    info when off link, and will rediscover all it needs soon
> > >    after moving home. Should this same filter be used to restrict
> > >    which prefixes from the home agent's AdvPrefixList are copied
> > >    to the aggregate list?
> 
> In a sense, that was what I was attempting to do above. I was thinking
> that the more complexity that can be cut out of constructing, sending,
> and receiving/processing the list, the better. But of course 
> this is not
> supposed to be at the expense of doing things the wrong way, so please
> share your alternate thoughts about how to do it.
> 

OK, I was thinking something like changing

 x - Copy prefix information defined in the home agent's AdvPrefixList
 x   on the home subnet's interfaces to the aggregate list.  Also
 x   apply any changes made to the AdvPrefixList on the home agent to
 x   the aggregate list.

to

 + - For each home subnet interface on the home agent, copy any prefix
 +   information defined in the home agent's AdvPrefixList with the "A"
 +   bit set to the aggregate list.  Also apply any changes to made to
 +   the AdvPrefixList on the home agent to the aggregate list.

Ken

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 26 Jun 2001 09:31:44 -0700

>  + - For each home subnet interface on the home agent, copy any prefix

I'm not sure that a given home agent would want to use prefix info from
all of its interfaces.

>  +   the AdvPrefixList on the home agent to the aggregate list.

This may be below our radar when considering the 'general' case. In
essence, this rule would be restricting the MPAs to advertising only
auto-configurable addresses, which would close the gap for the minority
of admins who may want to use stateful configuration or something else.
To me, this is an acceptable change, and I agree with your idea, but I
think we should have someone else sanity check this.

-- 
        T.J. Kniveton 
  Communications Systems Lab
     Nokia Research Center