Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!bellcore!ulysses!ucbvax!SU-NAVAJO.ARPA!mogul
From: mogul@SU-NAVAJO.ARPA (Jeff Mogul)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: more interesting features of 4.2 ("ARP Hack")
Message-ID: <8606050253.AA00383@ucbvax.Berkeley.EDU>
Date: Wed, 4-Jun-86 15:56:00 EDT
Article-I.D.: ucbvax.8606050253.AA00383
Posted: Wed Jun  4 15:56:00 1986
Date-Received: Thu, 5-Jun-86 09:24:36 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 23
Approved: tcp-ip@sri-nic.arpa


	I just reread the relevant section of 917, and in fact Mogul says that
	ARP-based subnetting is a reasonable strategy.

Actually, about the nicest thing I said about it is that it is "somewhat
unsatisfactory."  I certainly did not intend this to be an excuse for
IP vendors who aren't willing/able to get their acts together.  Granted,
this is less annoying than those hosts which spray broadcasts all over
everything, or those that try to act as gateways when they aren't
supposed to, but it really isn't that hard to get this right.

I also (now) regret the term "ARP-based subnetting", for its implication
that ARP is in any way central to the use of subnets.  I don't have a
perfect term, but something like "ARP-compatible subnetting" or
"subnet-extended ARP" would be less misleading.

I sure wish people who design widely-used IP implementations would
test their bright ideas on the Internet community before shipping
half a million workstations.

-Jeff

P.S.: Noel, you warned me.