- April fools day RFCs (posted 2002-04-01)
April fools day is coming up again! Don't let it catch you by surprise.
Over the years, a number of RFCs have been published on April first, such as:
0894
Standard for the transmission of IP datagrams over Ethernet
networks. C. Hornig. Apr-01-1984. (Format: TXT=5697 bytes) (Also
STD0041) (Status: STANDARD)
But not all RFCs stubbornly ignore their publishing day. The first
"fools day compatible" RFC dates back to 1978:
0748
Telnet randomly-lose option. M.R. Crispin. Apr-01-1978. (Format:
TXT=2741 bytes) (Status: UNKNOWN)
Probably the most famous of all is RFC 1149, which was updated in RFC 2549:
1149
Standard for the transmission of IP datagrams on avian carriers.
D. Waitzman. Apr-01-1990. (Format: TXT=3329 bytes) (Updated by
RFC2549) (Status: EXPERIMENTAL)
2549
IP over Avian Carriers with Quality of Service. D. Waitzman.
Apr-01-1999. (Format: TXT=9519 bytes) (Updates RFC1149) (Status:
INFORMATIONAL)
It took some time, but in 2001 the Bergen Linux User Group
implemented
RFC 1149 and carried out some tests.
Can't get enough? Here are more April first RFCs:
RFC 1097,
RFC 1217,
RFC 1313,
RFC 1437,
RFC 1438,
RFC 1605,
RFC 1606,
RFC 1607,
RFC 1776,
RFC 1924,
RFC 1925,
RFC 1926,
RFC 1927,
RFC 2100,
RFC 2321,
RFC 2323,
RFC 2324,
RFC 2550,
RFC 2551,
RFC 2795.
- Telephony best practices for IP (posted 2002-06-28)
In March, the NANOG list focussed some of its attention on efforts of
the telephony world to com up with "best practices" about packet
networks/the internet.
(Network Reliability and
Interoperability Council publications) In meeting minutes, 100% of the
carriers reported to abide by these best practices, which include firewalling
routers and DNS servers.
There were discussions about the merits of filtering/firewalling at OC-192
(10 Gbps) speeds (which, depending on your definition of "firewall" may be
impossible to do) and about out-of-band versus in-band management.
The former is always used in the telephony world, the latter often in IP.
The main problem with out of band management is that the management network
may be unavailable when the network is in critical need of being "managed".
Also, many vendors do not support a clear separation between production and
for-management interfaces.
- Packet reordering (posted 2002-06-29)
During the second week of April there was some discussion on reordering
of packets on parallel links at Internet Exchanges. Equipment vendors try
very hard to make sure this doesn't happen, but this has the risk that
balancing traffic over parallel links doesn't work as good as it should.
It is generally accepted that reordering leeds to inefficiency or even
slowdowns in TCP implementations, but it seems unlikely reordering will
happen much hosts are connected at the speed of the parallel links (ie,
Gigabit Ethernet) or there is significant congestion.
- Ownership of address space (posted 2002-06-30)
In the first week of May, a message was posted on the NANOG list by someone
who had a dispute with one of his ISPs.
When it became obvious this dispute wasn't going to
be resolved, the ISP wasn't content with no longer providing any service,
but they also contacted the other ISP this network connected to, and asked
them to stop routing the /22 out of their range the (ex-)customer was using.
The second ISP complied and the customer network was cut off from the internet.
(This all happened on a sunday afternoon, so it is likely there is more to
the story than what was posted on the NANOG list.)
The surprising thing was that many people on the list didn't think this
was a very unreasonable thing to do. It is generally accepted that a network
using an ISP's address space should stop using these addresses when it no
longer connects to that ISP, but in the cases I have been involved with there
was always a reasonable time to renumber. Obviously
depending on such a grace period is a very dangerous thing to do. You have
been warned.
|
