Subject: (IPng 6691) Last Minute comments on "A Method for the Transmission of IPv6 Packets over ARCnet Networks"

From: Ignatios Souvatzis <[email-masked]>
Date: Wed, 4 Nov 1998 17:32:47 +0100

I received a few comments by Thomas Narten, some of turned out not to be 
purely editorial... I'll try to summarize and add my notes, with questions
to the WG: (> > lines are by me (draft or comment), > lines are by TN)
 
Thomas Narten wrote:

> >    The protocol id used is D4 hexadecimal, the same as for IPv4. IPv6
> >    packets are recognized by looking at the version number in the high
> >    half of the first octet of the data, which is 4 for IPv4 and 6 for
> >    IPv6. This method of distinguishing IPv6 packets was chosen because
> >    there are only 256 values of ARCnet protocol ids available.
> 
> I note that this is inconsistent with the IPng position that all link
> layer types provide a way to identify IPv6 packets as distinct from
> IPv4. The above will also make it impossible to implement Header
> Compression as outlined in draft-degermark-ipv6-hc-06.txt on ARCnet
> links. Is this a potential problem?
 
Currently, there are no plans to implement header compression over ARCnet.

Rereading the header compression paper, I note that header compression
is aimed at slow to medium speed point to point style links, with some
sort of link level negotiation protocol. So it would not be really desirable 
to implement header compression for ARCnet (at 2.5 MBit/s) (or Ethernet,
FDDI, Token Ring...)
Am I correct?

> > Should that be planned, I guess it might be possible to get an additional
> > "Protocol ID" from Datapoint Corporation for this use. They were not willing
> > to give out an additional ID as long as none is needed. (Back then, when I
> > asked, there was no generic header compression specification.)

> The problem with
> asking for a code point later (rather than now) is that you'll have to
> deal with already deployed boxes that don't understand the new code
> point. 

Even if somebody planned later to implement header compression for IPv6 over
ARCnet:

- it would like as many as 6 protocol ids.
- if it can't have them, it can multiplex its packet types over a single
  protocol id with normal IPv6, by using a prefix byte and the first header
  nibble.
=> As I understand, it would be possible to route normal IPv6 over one ID and
  only the header compression variant over a seperate one.
  Is this correct? (If you think that header compression should never be
  implemented for ARCnet, dont bother to think about this issue ;-)

> >    The maximum IPv6 packet length possible using this encapsulation
> >    method is 60480 octets. Since this length is impractical because of
> >    its worst case transmission time of several seconds, all ARCnet
> >    implementations on a given ARCnet network should agree on a smaller
> >    value.
> > 
> >    Implementations SHOULD support an MTU of 9072 octets and MUST support
> >    the minimum MTU required by [IPV6].

> My read of the above is that the intention is that all ARCnet links
> support an MTU of 9072 and that this be the default value unless
> otherwise configured. If so, I'd like to see that wording made more
> explicit. In particular, use MUST rather than SHOULD? Also (and this
> is the reason why I think MUST makes sense), how about adding a
> sentence along the lines of:

>       In the absence of explicit configuration (e.g., via reciept of
>       an MTU option in a Neigbor Advertisement message), the default
>       MTU for an ARCnet link is 9072 octets.

> > I wanted to allow consenting implementations that can not receive
> > 18-fragment (thats 9072 bytes) packets to coexist on a link. Embedded
> > applications might want to make use of this. (9072 is for normal
> > workstation/server use).

> That goal seems fine. At the same time, in order to simplify
> configuration it is desirable for there to be a standard configuration
> that "works out of the box" without any configuartion. Thus, I think
> that there should be one value that is defined to be the default. That
> value can always be changed to a larger value if useful, and if the
> system administrator has knowledge that all devices can support a
> larger value. What I think is undesirable is to have it be possible
> for "embedded applications" to use a small MTU (and not violate the
> spec) while others use a different and incompatible MTU by
> default. This would lead to interoperability problems.
> 
> Note: I don't care what the exact MTU value  is, I just care that
> there be a well-defined one.

This seems important to me. I'd still want the default value to be 9072
(thats 18 times 504 in case someone wonders) and consider to change the
SHOULD to a "MUST", unless somebody tells me this is a real problem for
embedded implementations.

Also I think, that another sentence should be added:

	The MTU MAY only be enlarged above the value of 9072 using either
	router advertisements or manual configuration, if it is positively
	known that all connected nodes can receive packets of a larger size.

I prepared an updated draft, containing editorial changes/corrections
suggested by TN, and a strengthened "security" paragraph, available as
http://www.rhein.de/~is/arcipv6.04c

My intent is to add the above changes, and resubmit the paper.
Btw: for conformity, I'd delete the "A method for the" from the title, as 
has happened with the other IPv6 over link documents. Is this ok at this 
stage of affairs?

Regards,
	Ignatios Souvatzis
--------------------------------------------------------------------
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]
--------------------------------------------------------------------