>From Paul Werner
Actually, you and I are not as much in disagreement as it might seem at
first.
Unfortunately, the reality is that some RFCs don't track industry
practice. I would say 1812 is the definitive document, but I would
also agree this is largely by reference rather than official
supercession.
At the London IETF a couple of weeks ago, some people (I'd have to
dig up names, but I think they are at USC/ISI, where the RFC Editor
function lives) said they are actively working on an update to the
host requirements document. I didn't have a chance to ask whether
they are also thinking of an 1812 update so the pair of documents are
again more or less in sync. I do plan to follow up on this. The
discussion was in the PTOMAINE BOF, so it isn't even a WG yet that
could act as a home for these documents. I'd suspect they would be
directly overseen by the IESG.
>omments within and below.
>
>> Subject: Re: Subject: Re: TCP/IP question [7:17343]
>>
>> >This subject is not as clear as it ought to be. If you look
>at
>> >the subject of loopbacks generically, there are two RFCs that
>> >come to mind. The first deals with RFC 1122 "Requirements
>for
>> >Internet Hosts". The second deals with RFC
>1122 "Requirements
>> >for IPv4 Routers".
>>
>> Kind of a nit, but 1122 has been superceded by 1812.
>>
>
>I must respectfully disagree.
>
>The lineage of the RFC progression of Internet Gateways is
>documented very well in Fred Baker's hyperlinked RFC pages and
>other sources. On the first page he notes in the preface the
>following:
>
>"PREFACE
>This document is an updated version of RFC 1716, the historical
>Router Requirements document. That RFC preserved the
>significant work that went into the working group, but failed
>to adequately describe current technology for the IESG to
>consider it a current standard."
>
>This disclaimer statement is likely necessary because RFC 1716
>was categorized as informational, not standards track.
>
>If you go to RFC 1716 and look at the introductory paragraph it
>states the following:
>
>"1 INTRODUCTION
>
>The goal of this work is to replace RFC-1009, Requirements for
>Internet Gateways ([INTRO:1]) with a new document."
>
>If you go to RFC 1009, that appears to be more or less the
>first defined RFC named, "Requirements for Internet Gateways".
>Although RFC 985 does deserve mention, it was only a draft
>standard. The RFCs that are referenced in this document number
>62 references, including the original RFCs governing IP (700
>series RFCs).
>
>If you look at RFC 1122, it states the following:
>
>"Status of This Memo
>
>This RFC is an official specification for the Internet
>community. It incorporates by reference, amends, corrects, and
>supplements the primary protocol standards documents relating
>to hosts. Distribution of this document is unlimited."
>
>There are no listed or named successor standards that supercede
>RFC 1122 in the standards track (as they relate exclusively to
>Internet Hosts).
>
>The general point of confusion exists around this specific
>statement in RFC 1812, para. 1.2 appropriately
>titled, "Relationship to other standards". It states,
>
>"Host Requirements - This pair of documents reviews the
>specifications that apply to hosts and supplies guidance and
>clarification for any ambiguities. Note that these requirements
>also apply to routers, except where otherwise specified in this
>memo. As of this writing, the current versions of these
>documents are RFC 1122 and RFC 1123 (STD 3), [INTRO:2] and
>[INTRO:3].
>
>This is saying not that the standard has been superceded, but
>rather it has been incoporated by reference. Any areas of
>ambiguities (as they apply to Internet gateways) are to be
>resolved explicitly in RFC 1812.
>
>Okay, if you have made it this far, you are naturally
>asking, "what is my point"? There are discontinuities in
>certain areas of RFC 1122 and RFC 1812. If the device is an
>Internet host (not a router), it is only required to comply
>with the requirrements in RFC 1122. If it is an IPv4 router,
>than it should comply with the requirements in RFC 1812. So
>where's the discontinuity?
>
>Let's try subnet zero for starters. Look at this statement
>from RFC 1812, page 49, para. 4.2.2.11:
>
>"DISCUSSION
>Previous versions of this document also noted that subnet
>numbers must be neither 0 nor -1, and must be at least two bits
>in length. In a CIDR world, the subnet number is clearly an
>extension of the network prefix and cannot be interpreted
>without the remainder of the prefix. This restriction of subnet
>numbers is therefore meaningless in view of CIDR and may be
>safely ignored. "
>
>This says that subnet zero is allowed and is considered a good
>practice to use in the CIDR world (why waste address space?)
>
>Here's the rub. Go to RFC 1122 and see what it says about
>subnet zero:
>
>"From the Assigned Numbers memo [9]:
>
> "In certain contexts, it is useful to have fixed
>addresses with functional significance rather than as
>identifiers of specific hosts. When such usage is called for,
>the address zero is to be interpreted as meaning "this", as
>in "this network". The address of all ones are to be
>interpreted as meaning "all", as in "all hosts". For example,
>the address 128.9.255.255 could be interpreted as meaning all
>hosts on the network 128.9. Or, the address 0.0.0.37 could be
>interpreted as meaning host 37 on this network."
>
> It is useful to preserve and extend the interpretation
>of these special addresses in subnetted networks. This means
>the values of all zeros and all ones in the subnet field should
>not be assigned to actual (physical) subnets.
>
>So, what is the issue and what are the differences? RFC 1812
>indicates that subnet zero is allowed, useful in CIDR, and
>should be used. RFC 1122 clearly indicates that Internet hosts
>should not be placed in subnet zero networks.
>
>One could easily ask, what relevance does this have to anything
>I do today? In my particular case, I walked into a situation
>where I was using a terminal server configured by somebody
>else's equipment. Everything that I checked seem to indicate
>that it should work. In the process of deductive analysis, I
>finally ended up connecting the host directly into the ethernet
>interface of the router via crossover cable, bypassing all hubs
>and switches. The router's IP addr was 172.16.0.1/24 My PC's
>IP addr was 172.16.0.8/24. The PC **could not* ping the
>router, period. I then dug back into my memory banks on this
>very issue of subnet zero and decided to change the IP addr of
>the router to 172.16.1.1/24 and I changed the host to
>172.16.1.8/24. Everything worked flawlessly. Although MS
>claimed that Win98 (don't remember the exact iteration) would
>recognize subnet zero, it didn't.
>
>As a general rule of thumb, it is safe to say that the use of
>subnet zero is safely used on any given router, particularly if
>there are no Internet hosts on that segment (such as WAN
>links). It is not a good idea however, to use subnet zero as a
>subnetwork populated with Internet hosts. This is just one of
>several incosistencies between RFC 1812 and RFC 1122. If an
>issue pertains to an Internet host explicitly, RFC 1122 is the
>governing Internet standard. If the issue involves an IPv4
>router (Internet Gateway), then RFC 1812 governs. In the case
>of devices that resemble both (NT4 server running RRAS among
>other possibilities), it is not really clear which RFC would
>govern. My bet would be on the more stringent requirement
>between the two standards.
>
>v/r,
>
>Paul Werner
>
>p.s. In this particular instance (loopbacks), there are no
>incosistencies between the two standards.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=17527&t=17343
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
