Mattias Pettersson wrote:
>
> "Powell, Ken" wrote:
>
> > I suppose another option would be to add a
> > "request aggregate prefix list" flag bit to
> > the router solicitation message. Such a flag
> > bit would be easier to implement in that
> > it would only impact the part of the stack
> > that deals with router solicitation/advertisement
> > processing.
> >
> > What do others prefer?
>
> I prefer this new RS type.
>
> If the HA needs to know what home _link_ is in question, in case there
> are more than one, it can use the destination address of the RS. Thus,
> one fewer purpose for the home address option.
>
Let me play devil's advocate:
No new types are required! What we're sending is still a Router
Solicitation/Advertisement. The fact that it is routed gives us more
information:
1. The TTL of RS is < 255, which tells the HA it is from off-link.
2. The HA knows that (1) means it is a mobile node and needs all
prefixes on the link.
3. It sends a regular (HA) RA, and adds prefix options for every prefix
on the link
4. The TTL of the RA is < 255, which tells the MN it is from off-link.
5. The MN knows that (4) means it is a HA-generated RA and applies to
its home address(es)
There is no need to create a new type, when we are simply allowing a
superset of normal RS/RA behavior. Consider the following:
A. If router solicitations are extended to allow off-link RSs, the RSs
for mobile nodes would be totally compatible and "make sense".
B. If RAs are extended as well, these mobile RAs would also make sense
These messages will only ever be shared between MN & HA, who will both
understand what they mean. Nevertheless, the point of (A) & (B) is that
these messages are globally consistent and do not conflict with other
possible extensions.
It makes more sense to think of these messages as router advertisements
and solicitations -- that's really what they are, extended to handle
mobility. If the goal of Mobile IP is to modify/enhance existing
protocols as little as possible to support mobility, adding message
types when it's not necessary is the wrong thing to do.
--
T.J. Kniveton
NOKIA Research Center
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
