Fun with my mailor, let me try this again.
So, if someone, or possibly a group of someones, were to make the
following request to the various router vendors, would they be met with
approval by most of the readers?
We requests that your routers be configurable, at the interface
level, to prevent the forwarding of an ICMP echo-request packet through an
interface that has a broadcast or wire address that matches the
destination address of that packet. We also request that the default
configurations of your routers be modified to prevent said forwarding.
We request that your routers be configurable, both globally and
and the interface level, with the interface configuration overiding the
global configuration, to prevent the forwarding of an IP packet with a
source network address different from the network address of the interface
on which it was received. We also request that the default configurations
of your routers be modified to prevent, globally, said forwarding.
- --
Rusty Zickefoose | The most exciting phrase to hear in science,
rusty@mci.net | the one that heralds new discoveries, is not
==> So, if someone, or possibly a group of someones, were to make the
==>following request to the various router vendors, would they be met with
==>approval by most of the readers?
==>
==> We requests that your routers be configurable, at the interface
==>level, to prevent the forwarding of an ICMP echo-request packet through an
==>interface that has a broadcast or wire address that matches the
==>destination address of that packet. We also request that the default
==>configurations of your routers be modified to prevent said forwarding.
This is against RFC 1812.
RFC 1812, "Requirements for IP Version 4 Routers", Section 5.3.5,
specifies:
Lucent/Livingston has pointedly ignored just this RFE request for over a year.
There is no noise, only signal. There is no signal, only noise.
Or they could have a knob for each interface, and a knob which sets the
default for each interface which doesn't have its own setting. Then the
default for the global default parameter could be RFC1812 compliant, yet
allow a user to easily change it without having to update every interface.
That would still mean that someone who started using the router without
setting that parameter would be contributing to the problem, but they have
to configure the box anyway to use it.
As it is, it is easy to forget to set it on a new interface (although
typically those are point-to-point links which only have a 2x factor
anyway), at least until you have been burned once.
John Tamplin Traveller Information Services
jat@Traveller.COM 2104 West Ferry Way
205/883-4233x7007 Huntsville, AL 35801
Nose around here http://www.ietf.org/ID.html and see if you find anything.
If not, gather one or two other folks and write up a revised RFC or better
yet, just write up a document describing the old paragraph, your proposed
change, and why you think it needs to be changed. Read this
ftp://ftp.ietf.org/ietf/1id-guidelines.txt for formatting guidlines and
when it is written submit it to internet-drafts@ietf.org
Then hang out on the IETF discussion list
http://www.ietf.org/maillist.html and answer questions. Since this is a
standards track RFC you'll need to do more than this to actually get the
RFC changed but this should start the ball rolling.
Technically, RFC 1812 is only a proposed standard which is the lowest of
the three positions on the standards track. According to RFC 2026:
A Proposed Standard ... has received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience
might result in a change or even retraction of the specification
before it advances.
It also says:
Implementors should treat Proposed Standards as immature
specifications. It is desirable to implement them in order to gain
experience and to validate, test, and clarify the specification.
However, since the content of Proposed Standards may be changed if
problems are found or better solutions are identified, deploying
implementations of such standards into a disruption-sensitive
environment is not recommended.
So basically, you can stop this RFC in its tracks by clearly stating your
objections in the form of an Internet draft and it might even be possible
to get vendors to change this before the RFC is revised because the
Internet IMHO qualifies as a disruption sensitive environment.
Note that I'm not arguing that it *should* be the default, I'm just
arguing that vendors have implemented it this way because that's the way
they were told to in the RFC.
Umm.... this is only partially true. As of the writing of 1812 (and
predecessors), vendors had implemented it one particular way and argued
that the spec should reflect the implementations. Of course, at the time,
the net was a kinder, gentler place, and the threats of smurfing were not
well known.
Live and learn. 
Tony