Subject: (IPng 6984) Re: route distribution via ND

From: Marc Fiuczynski <[email-masked]>
Date: Mon, 28 Dec 1998 11:30:09 -0800

Hi,

>From: Craig Metz [mailto:[email-masked]]
>In message <4D0A23B3F74DD111ACCD00805F31D8100AF819A2@RED-MSG-50>, you
write:
>>One can view ND as performing distribution of routes. For example
receipt of
>>an RA with a non-zero router lifetime communicates a default route (/0
>>route). A prefix-information option with the L bit communicates an
on-link
>>prefix (a /64 route).
>>
>>Why not define an option to let RAs communicate routes more generally?
For
>>example, define a new flag bit (call it the N bit) for prefix
information
>>options to say that this prefix should be added to the receiving
host's
>>route table, with the router sending the RA as the next-hop for the
prefix?
>
>  Unless I'm highly confused or the specs changed, ND already does this
and was
>intended all along to do this. Advertise a prefix with autonomous off
and
>on-link off.

Reading RFC 2461 it is not clear to me that ND does what we were more
explicitly proposing.  In section 4.6.2 it states the following for the
L bit:

[L is a ] 1-bit on-link flag.  When set, indicates that this
prefix can be used for on-link determination.  When
not set the advertisement makes no statement about
on-link or off-link properties of the prefix.  For
instance, the prefix might be used for address
configuration with some of the addresses belonging
to the prefix being on-link and others being off-
link.

Additionally, the description for the prefix information option states:

The Prefix Information option provide hosts with
on-link prefixes and prefixes for Address
Autoconfiguration.

After reading this (and more of the RFC) it isn't clear to me how the
prefix option should be processed if the L bit (and other bits) are not
set.  I can see how one might "interpret" that the prefix information
should then be used to create a route to the router sending the RA, but
the text does not explicitly state that.  It seems that a simple
clarification to the description of the prefix information option would
help.  Something along the lines of explicitly stating that the prefix
option indicates the next-hop for the supplied prefix if and only if all
of the flag bits are off.  This is functionally equivalent to
introducing a new bit (as Richard and I did), yet saves us from wasting
this particular bit as it should never need to be set in conjunction
with any of the existing or proposed prefix option flag bits.

Marc
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Wed, 30 Dec 1998 08:17:25 -0500

> set.

There are a number of bits defined in the prefix information
option. If a particular bit is set, there are instructions on what
that means. If a bit is not set, one is supposed to do *nothing*
special. Look at it as if there are optional fields. How do you
process an optional field in a packet if the optional field is
omitted? You don't do *anything* at all!

> I can see how one might "interpret" that the prefix information
> the text does not explicitly state that.

The text attempted to explictely say "do nothing" (see, for instance
the message from Matt Crawford).

> It seems that a simple clarification to the description of the
> prefix information option would help.  Something along the lines of
> explicitly stating that the prefix option indicates the next-hop for
> the supplied prefix if and only if all of the flag bits are off.

This is not what what the current document is intended to say. Thus,
this "clarification" would be a change in existing behavior.

Thomas