blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
3.2.1.8 Options: RFC-791 Section 3.2 Connected: An Internet Encyclopedia
3.2.1.8 Options: RFC-791 Section 3.2

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1122
Up: 3. INTERNET LAYER PROTOCOLS
Up: 3.2 PROTOCOL WALK-THROUGH
Up: 3.2.1 Internet Protocol -- IP
Prev: 3.2.1.7 Time-to-Live: RFC-791 Section 3.2
Next: 3.2.2 Internet Control Message Protocol -- ICMP

3.2.1.8 Options: RFC-791 Section 3.2

3.2.1.8 Options: RFC-791 Section 3.2

There MUST be a means for the transport layer to specify IP options to be included in transmitted IP datagrams (see Section 3.4).

All IP options (except NOP or END-OF-LIST) received in datagrams MUST be passed to the transport layer (or to ICMP processing when the datagram is an ICMP message). The IP and transport layer MUST each interpret those IP options that they understand and silently ignore the others.

Later sections of this document discuss specific IP option support required by each of ICMP, TCP, and UDP.

DISCUSSION:

Passing all received IP options to the transport layer is a deliberate "violation of strict layering" that is designed to ease the introduction of new transport- relevant IP options in the future. Each layer must pick out any options that are relevant to its own processing and ignore the rest. For this purpose, every IP option except NOP and END-OF-LIST will include a specification of its own length.

This document does not define the order in which a receiver must process multiple options in the same IP header. Hosts sending multiple options must be aware that this introduces an ambiguity in the meaning of certain options when combined with a source-route option.

IMPLEMENTATION:

The IP layer must not crash as the result of an option length that is outside the possible range. For example, erroneous option lengths have been observed to put some IP implementations into infinite loops.

Here are the requirements for specific IP options:

  1. Security Option

    Some environments require the Security option in every datagram; such a requirement is outside the scope of this document and the IP standard specification. Note, however, that the security options described in RFC-791 and RFC-1038 are obsolete. For DoD applications, vendors should consult [IP:8] for guidance.

  2. Stream Identifier Option

    This option is obsolete; it SHOULD NOT be sent, and it MUST be silently ignored if received.

  3. Source Route Options

    A host MUST support originating a source route and MUST be able to act as the final destination of a source route.

    If host receives a datagram containing a completed source route (i.e., the pointer points beyond the last field), the datagram has reached its final destination; the option as received (the recorded route) MUST be passed up to the transport layer (or to ICMP message processing). This recorded route will be reversed and used to form a return source route for reply datagrams (see discussion of IP Options in Section 4). When a return source route is built, it MUST be correctly formed even if the recorded route included the source host (see case (B) in the discussion below).

    An IP header containing more than one Source Route option MUST NOT be sent; the effect on routing of multiple Source Route options is implementation- specific.

    Section 3.3.5 presents the rules for a host acting as an intermediate hop in a source route, i.e., forwarding a source-routed datagram.

    DISCUSSION:

    If a source-routed datagram is fragmented, each fragment will contain a copy of the source route. Since the processing of IP options (including a source route) must precede reassembly, the original datagram will not be reassembled until the final destination is reached.

    Suppose a source routed datagram is to be routed from host S to host D via gateways G1, G2, ... Gn. There was an ambiguity in the specification over whether the source route option in a datagram sent out by S should be (A) or (B):

        (A):  {>>G2, G3, ... Gn, D}     <--- CORRECT
    
        (B):  {S, >>G2, G3, ... Gn, D}  <---- WRONG
    

    (where >> represents the pointer). If (A) is sent, the datagram received at D will contain the option: {G1, G2, ... Gn >>}, with S and D as the IP source and destination addresses. If (B) were sent, the datagram received at D would again contain S and D as the same IP source and destination addresses, but the option would be: {S, G1, ...Gn >>}; i.e., the originating host would be the first hop in the route.

  4. Record Route Option

    Implementation of originating and processing the Record Route option is OPTIONAL.

  5. Timestamp Option

    Implementation of originating and processing the Timestamp option is OPTIONAL. If it is implemented, the following rules apply:

    • The originating host MUST record a timestamp in a Timestamp option whose Internet address fields are not pre-specified or whose first pre-specified address is the host's interface address.

    • The destination host MUST (if possible) add the current timestamp to a Timestamp option before passing the option to the transport layer or to ICMP for processing.

    • A timestamp value MUST follow the rules given in Section 3.2.2.8 for the ICMP Timestamp message.


Next: 3.2.2 Internet Control Message Protocol -- ICMP

Connected: An Internet Encyclopedia
3.2.1.8 Options: RFC-791 Section 3.2

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609