Browse Prior Art Database

Transmission of IPv6 Packets over Token Ring Networks (RFC2470)

IP.com Disclosure Number: IPCOM000003050D
Original Publication Date: 1998-Dec-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 11 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Crawford: AUTHOR [+2]

Related Documents

10.17487/RFC2470: DOI

Abstract

This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 17% of the total text.

Network Working Group M. Crawford Request for Comments: 2470 Fermilab Category: Standards Track T. Narten IBM S. Thomas TransNexus December 1998

Transmission of IPv6 Packets over Token Ring Networks

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved.

1. Introduction

This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Redirect, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network.

Implementors should be careful to note that Token Ring adaptors assume addresses are in non-canonical rather than canonical format, requiring that special care be taken to insure that addresses are processed correctly. See [CANON] for more details.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KWORD].

2. Maximum Transmission Unit

IEEE 802.5 networks have a maximum frame size based on the maximum time a node may hold the token. This time depends on many factors including the data signaling rate and the number of nodes on the ring. Because the maximum frame size varies, implementations must

Crawford, et. al. Standards Track [Page 1]

RFC 2470 IPv6 over Token Ring December 1998

rely on manual configuration or router advertisements [DISC] to determine actual MTU sizes. Common default values include approximately 2000, 4000, and 8000 octets.

In the absence of any other information, an implementation should use a default MTU of 1500 octets. This size offers compatibility with all common 802.5 defaults, as well as with Ethernet LANs in an environment using transparent bridging.

In an environment using source route bridging, the process of discovering the MAC-level path to a neighbor can yield the MTU for the path to that neighbor. The information is contained in the largest frame (LF) subfield of the routing information field. This field limits the size of the information field of frames to that destination, and that information field includes both the LLC [LLC] header and the IPv6 datagram. Since, for IPv6, the LLC header is always 8 octets in length, the IPv6 MTU can be found by subtracting 8 from the maximum frame size defined by the LF subfield. If an implementation uses this information to determine MTU sizes, it must maintain separate MTU val...

Processing...
Loading...