Subject: RE: PPP over Sonet default MRU

From: Stephane St Hilaire <[email-masked]>
Date: Thu, 23 Jan 2003 17:59:02 -0500

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> 6.  LCP Configuration Options
> [...]
>    Design Philosophy
> 
> ... and with existing practice.  There are quite a few implementations
> that don't bother implementing every option listed in RFC 1661 (in
> particular, Quality-Protocol is somewhat rare).  None are mandatory.
> 

I think we're stuck in semantics. 
When negociating Quality Protocol (even if you reject this option), you're
NOT negociating your "ability to negociate" link quality monitoring. You're
specifying whether you support link quality monitoring or not. Yes link
quality monitoring IS optional. Having a MRU however is not a negociable
"feature". You may or may not support values other than the default but you
can't say I don't support "MRU negociation". Heck just sending a NACK or a
REJECT is PART of the negociation. Not that this matters a whole lot, it's
just semantics.

> It means "I don't support negotiation of your MRU (my MTU); you'll
> have to live with whatever the default might be, or whatever your
> local configuration tells you to do."

If that ("your MRU is fine") is actually what you wanted to tell the remote
end, a simple ACK would have done the trick.

> Obviously, the RFC can't specify a default.  That's not the same thing
> as saying that there *is* no default.

I meant of course that there is no RFC specified default, and I don't know
why we are still talking about IPCP. 

> 
> Basically, if you had a PPP implementation that refused *all*
> configuration options, that would be perfectly legal.  

Sure as long as the link came up using default values.

> > I see your point but it's not a very likely situation. I 
> don't see a router
> > removing all possibility of configuring interfaces MTU by 
> design just to
> > avoid the possibility of fragmentation. 
> 
> I think you might be underestimating the perversity of nature.  ;-}

Believe me, I never do at least when it comes to human nature.

> 
> I'm not claiming that's what's going on with either of these vendors,
> but it's certainly not an impossible situation.

I never said impossible, just unlikely.

I believe we have definitively exhausted this particular subject.

Thanks again

Steph

---

From: James Carlson <[email-masked]>
Date: Fri, 24 Jan 2003 08:44:22 -0500

> I think we're stuck in semantics. 

I think we're just stuck.

> NOT negociating your "ability to negociate" link quality monitoring.

The two are one and the same.

When the peer says Configure-Reject, the only thing you know is that
he's not willing to negotiate anything about that option.  If he were
willing to negotiate, he would have sent Configure-Nak or
Configure-Ack instead.  Configure-Reject can mean two things -- "I
know what this is, but I don't want it" or "I have no idea what you're
talking about."  The way the protocol was designed, there is *NO*
distinction between these two.  They're equivalent.

> You're

If you say "LCP Configure-Reject" for MRU, then you're saying that you
don't want that option.

> end, a simple ACK would have done the trick.

Ah, but that's not the same.  LCP Configure-Reject says "I don't feel
like discussing this option with you at all -- I'm not going to
suggest a different value with Configure-Nak, I'm not going to agree
to it, so you'd better just withdraw it from your next
Configure-Request."

That's not the same thing as "your MRU is fine."  What the peer
issuing that Configure-Reject is saying is that he doesn't *care* what
you think of that option.  If, due to your own implementation
decisions, you have to make some judgement about what the value ought
to be or whether the resulting link is usable at all, that's up to the
discretion of the implementor.

> why we are still talking about IPCP. 

Because the negotiation models are exactly the same.  I'm trying to
point out to you that there are *NO* privileged options.  There are NO
options that are "required" for implementation.  There are NO options
that you can rely on to be in any implementation.

You CANNOT assume that the MRU option is somehow special.  The fact
that the peer sends the option says nothing about whether the option
is understood to mean anything.

> Sure as long as the link came up using default values.

... *OR* with explicitly configured values.  Where there is no
explicit configuration, there is a common default value.

[...]
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

I agree.  And if we follow up to it, could we *PLEASE* switch to just
plain text?

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 27 Jan 2003 20:23:43 -0500

I don't read the list regularly, but somebody asked me to look over this 
thread.  I'd like to affirm some of what Carlson said, but correct a few 
mistakes.  (And I also didn't read most of the HTML mail.)

On Configure-Reject:

  Implementation of -Reject is mandatory.  But it doesn't mean that you 
  have implemented MRU or anything else.  You're just rejecting a raw 
  option number.  

  Carlson says (which confuses the issue a bit) it could also mean 
  "I know what this is, but I don't want it".  That's not correct. 
  When you know what it is, you MUST send -Nak, instead (except in the 
  case of boolean options; see, it confuses the issue :-).

On Configure-Nak:

  Implementation of -Nak is mandatory.  In the case at hand, where an 
  MTU is configured to 4470, the implementation MAY -Nak with MRU 4470:
      Finally, an implementation may be configured to request the
      negotiation of a specific Configuration Option.  If that option is
      not listed, then that option MAY be appended to the list of Nak'd
      Configuration Options, in order to prompt the peer to include that
      option in its next Configure-Request packet.  Any value fields for
      the option MUST indicate values acceptable to the Configure-Nak
      sender.

  That doesn't mean that the peer will send a -Request with MRU 4470. 
  It "MAY"!  (see the full text)

On MRU:

  Implementation of MRU is optional.  But MRU has a default.  In most 
  cases, that default is 1500.  (For example, with some kinds of links, 
  such as Frame Relay, it's 1600.  We chose *NOT* to make it larger for 
  SONET/SDH.)

  At the end of a successful negotiation, when all is said and done, 
  and the peer has not negotiated MRU, it is absolutely prohibited to 
  send more than 1500 bytes. 

      The maximum length for the Information field, including Padding,
      but not including the Protocol field, is termed the Maximum
      Receive Unit (MRU), which defaults to 1500 octets.  By
      negotiation, consenting PPP implementations may use other values
      for the MRU.
      [RFC 1661, Page 5]

  It doesn't matter than some miscreant operator has accidentally 
  configured MTU 4470.  Sending 4470 into a link with a 1500 MRU is 
  non-conformant.  As you say in your 1st message, it is "wrong". 
  (And, in every implementation I've ever done, would be discarded.)

  Contrary to Carlson's assertion, manual configuration MUST NOT 
  ignore the PPP negotiation.  PPP is intended to be resilient in 
  the face of operator error. 
      ...
      implementor can specify improvements to the default configuration,
      which are automatically communicated to the peer without operator
      intervention.  Finally, the operator may explicitly configure
      options for the link which enable the link to operate in
      environments where it would otherwise be impossible.
      [RFC 1661, Page 2]

  In order for an implementor to specify an improvement, or an operator 
  to configure an option, that option MUST be implemented, and negotiated 
  with the peer.

The whole point of PPP is the option negotiation.  We already knew that 
SLIP sucked, as did a host of others (SLFP, cisco HDLC, and on and on),
because they were hard to successfully configure, as the implementors 
all had different ideas about what was "best", and the operators made
too many mistakes.
 
If it doesn't negotiate options, it's not PPP!

-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

---

From: James Carlson <[email-masked]>
Date: Tue, 28 Jan 2003 07:41:18 -0500

>   case of boolean options; see, it confuses the issue :-).

I'm afraid I must disagree.  Suppose I get an LCP Configure-Request
with the Authentication Protocol option, but I have no local
credentials to offer, or I am configured to refuse to identify myself.
In this case, I cannot possibly send a sensible Configure-Nak, and I
must respond with Configure-Reject.

Or suppose I have an implementation that supports MP, but only if the
call arrives over a certain medium (e.g., I am configured to support
MP for ISDN clients, but not for asynchronous callers).  Again, I have
to send Configure-Reject for an async caller who offers MRRU, because
I have no sensible alternative.

That's what I was trying to get across.  The code that you're staring
at might have the capability of responding to a particular option, but
still be forced to send Configure-Reject anyway because (with the
current configuration) there's no way to continue using that option.

Thus, Configure-Reject can indeed mean "I know what this is, but I
just don't want it at all."

> If it doesn't negotiate options, it's not PPP!

I mostly agree with that, and I certainly agree that it's at best
completely foolhardy to ignore the benefits that negotiation provides,
but I do disagree with outlawing "prior arrangement."  Suitably
configured peers may do anything they like -- including using
encapsulations that aren't in the RFCs -- and there's not much that
the RFCs can do about it.  There's no "IETF police squad."

Obviously, if someone does that, he's on his own.  If you want to call
all possible external arrangements "not PPP," I suppose that's fine,
but it doesn't mean that such things are not done at all.  (I've seen
any of a number of tremendously feeble justifications for using
*parts* of PPP without including crucial bits of the negotiation.)

For what it's worth, I think this is all a moot discussion.  The
behavior described in the original post reveals plain old bugs in both
implementations, and the poster should contact the vendors and
complain.  Instead, he asked if it was "possible" to refuse MRU
negotiation at all, which is how we got here.

---

From: William Allen Simpson <[email-masked]>
Date: Tue, 28 Jan 2003 11:14:10 -0500

> must respond with Configure-Reject.
You don't seem to be disagreeing in *THIS* example.  In the text, this 
scenario is clearly covered by:
      If some Configuration Options received in a Configure-Request are
      not recognizable or are not acceptable for negotiation (as
      configured by a network administrator), then the implementation
      MUST transmit a Configure-Reject.  
      [RFC 1661, Page 31]

> I have no sensible alternative.
Likewise (op cit).  

Although, to be pedantic, multilink was first envisioned and 
implemented to cover multiple async links, and we argued for a long 
time about the size of fields to cover simultaneous use of async, ISDN, 
and FrameRelay links.  (I'm pretty sure we gave up on async backup for 
SONET/SDH. ;-)  So, that would seem to be a "self defeating" 
configuration....

> current configuration) there's no way to continue using that option.
Ahh, you are talking about code reuse, and I was talking about 
operation.  It may be true that there is code somewhere in the 
system that understands an option, but when the options are 
inapplicable to a particular *kind* of interface, I've always 
understood that to be "not recognizable".

> the RFCs can do about it.  There's no "IETF police squad."
Well, actually, there _is_ a "police squad".  It's the purchaser!  

When I've specified contracts, and I've been responsible for hundreds 
of millions of dollars of contracts over the years, I've always tried 
to specify those magic terms of "conformant", "compliant", and 
"interoperable".  

(Indeed, long before PPP, circa the mid-80s, the very first piece of 
boilerplate that I was able to insert in the Michigan appropriations 
statutes was a requirement that computer and telecommunications purchases 
required demonstration of interoperation with at least 3 implementations. 
Apple was very unhappy about it, as was Burroughs.  But lo and hehold, 
a few months later, MacTCP appeared!) 

And yes, I've managed to force a complete refund when a vendor lied 
about it, and forfeit of a $250,000 performance bond.  That's something 
like "policing". 

> *parts* of PPP without including crucial bits of the negotiation.)
I have also seen such "PPP Lite" idiocy. 

> complain.  ...

And here we agree, again.
-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

---

From: James Carlson <[email-masked]>
Date: Tue, 28 Jan 2003 11:40:51 -0500

> SONET/SDH. ;-)  So, that would seem to be a "self defeating" 

Certainly -- and the first MP implementation I did was tested using
async because that's all we had at the time.  The point is not whether
async is usable with MP, but rather what the local policy on its use
might be.

> understood that to be "not recognizable".

OK; then it's just a word usage issue.  By "not recognizable" I mean
"not implemented in any way at all."  "Not recognizable" covers what
you do with options such as 201 -- never defined or used anywhere, no
idea what it might mean, and must be Configure-Rejected.  It's where
you end up in the "default:" case in your switch statement.  ;-}

"Recognized but unwanted" was a slightly different case, at least for
someone looking at some bit of PPP code and trying to understand how
the options work, but it's indistinguishable in behavior on the wire.

> Well, actually, there _is_ a "police squad".  It's the purchaser!  

I completely agree.  There's *no* IETF-related enforcement -- it's up
to customers to complain when a vendor violates an RFC *AND* that
violation causes interoperability trouble.

I think that lack of specific IETF enforcement is a good thing,
because it puts the focus right where it belongs -- on quality of
implementation and interoperability rather than on abstract
"conformance" to some specification.  Using "conformance" as a proxy
for correct operation is a problem seen in other standards bodies, and
it tends to result in forcing customers to buy all of their equipment
from a sole vendor because of minor differences in interpretation.

Or, in other words, vendors are required to be smart, rather than
being slaves to the standards process.

As we well know, there are many possible violations that do not affect
interoperability, or that actually make an implementation *more*
interoperable.  (E.g., violating the unnecessary RFC 2453 requirement
of dropping authenticated datagrams when you have no authentication
configured, even though a 1058 router would have accepted the those
same datagrams.)

> I have also seen such "PPP Lite" idiocy. 

As far as I've seen, the bug seems to bite people who think that PPP's
default three second restart timer has something to do with
"performance."  It's a pretty profound bit of confusion, and often not
repairable.

---

From: William Allen Simpson <[email-masked]>
Date: Tue, 28 Jan 2003 13:02:02 -0500

> the options work, but it's indistinguishable in behavior on the wire.
In general, protocol specifications such as PPP are written about 
behaviour on the wire.  Where an implementation hint was provided, 
I've always used the "Implementation Note" subsection.

In the case at hand, "No Protocol Field Compression" is specified for 
SONET/SDH.  Thus, PFC would be -Rejected.  The router may very well 
have code to support some other kind of interface, but on this link, it 
is "unrecognized".

> from a sole vendor because of minor differences in interpretation.
Indeed, we had that problem with the first specification of PPP over 
SONET/SDH!  Several manufacturers correctly built chips that had no 
problems with long strings of zeroes and quickly re-sync'd within two 
frames, as clearly indicated in the original Bellcore specification.  

Unfortunately, Lucent (and maybe Nortel, by hearsay, I didn't see a test 
of them), not only failed completely, but they were so cheap that they 
didn't include an independent clock, and unrelated signals sent in the 
return direction lost sync, too.  Amazingly bad design, but "conformant" 
because it wasn't "prohibited".

We have a tradition here of working around such flaws.  Just as we used
UI in the PPP header to get around a flaw in an early HDLC chipset, the
WG agreed to change the specification to (optionally) scramble the signal 
for those bad early OC3 links.

(I have no idea why Andy wanted to scramble OC12 and later links; 
there's certainly no technical reasons.  Oh well, as long as it works 
and it's no cost, who cares?)

> configured, even though a 1058 router would have accepted the those
Bad example.  Certainly, those authenticated datagrams have to be dropped 
when the operator doesn't know the password -- it's the very definition 
of authenticated authorization.  

Sometimes, people confuse interoperability with "easy for dummies". 
Authentication of routes is for protection against those dummies.

(And, technically, a 1058 router should also drop those datagrams, as 
there are non-zero must-be-zero fields, and the version is higher than 1.)

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 28 Jan 2003 11:42:45 -0700 (MST)

> From: William Allen Simpson <[email-masked]>

> of authenticated authorization.  

Nonsense.  In the case at hand, the sender is authenticating its bits,
but the receiver has no password and does not care.  It is clearly an
error in RFC 2453 that requires routers to accept unauthenticated
RIPv2 packets but refuse authenticated RIPv2 packets on the same wire.
Of course, if the receiving router cares about authentication, it
should reject unauthenticated packets as well as packets with bogus
authentication.

The only way it would make sense reject authenticated packets is if
RIPv2 authentication were required.  RIPv2 is not required, and so it
is silly to write RIPv1 or RIPv2 code that rejects a packet merely
because it carries extra and unneeded authentication.

> there are non-zero must-be-zero fields, and the version is higher than 1.)

RFC 1058 is not the authoritative definition of RIPv1.  The BSD
source is the authorative definition of the protocol that was
created and defined in 4.2BSD and modified slightly over the years.
That's just as well, because there are some serious errors in RFC 1058.

If RIPv1 had been defined as requiring that packets with non-zero
must-be-zero fields be rejected with a version higher than 1, it might
have been reasonable to reject them.  However, the authoriative
definition of RIPv1 is in the ancient code BSD code.

The biggest error in that last statement by Mr. Simipson is the
self-important notion that the purposes of RFCs include punishing or
policing.  RFCs have a single legitimate purpose, to increase the
likelihood of interoperation.  The first and primary rule for all
Internet standards is "be liberal in what you accept and conserative
in what you send."  Must-be-zero fields "MUST" be zero when sent, but
when possible ought to be ignored on receipt.  At most you might have
a special compliance checking mode that logs non-zero must-be-zero
fields for shaking down your own code in your own test networks.

Vernon Schryver    [email-masked]

---

From: James Carlson <[email-masked]>
Date: Tue, 28 Jan 2003 14:04:50 -0500

> I've always used the "Implementation Note" subsection.

Absolutely true, but I think the thread of conversation I had with the
original poster revealed a difficulty in exactly this area.  He seems
to have interpreted "unrecognized" with reference to what the
implementation might have in its code, not with reference to what
appears on the wire.

I think we're in violent agreement.

> of authenticated authorization.  

No; I think you might be misinterpreting the example.

If you're a RIP-2 router configured to accept routing datagrams
*WITHOUT* authentication -- which is certainly one of the possible
acceptable configurations -- then it's rather senseless to drop
datagrams that happen to carry unwanted authentication information.
What RFC 2453 says is this:

5.2 Authentication

   The following algorithm should be used to authenticate a RIP message.
   If the router is not configured to authenticate RIP-2 messages, then
   RIP-1 and unauthenticated RIP-2 messages will be accepted;
   authenticated RIP-2 messages shall be discarded.  [...]

Obviously, if you're configured to authenticate at all, then you must
drop all messages with bad authentication data.  If you're not
configured to authenticate, though, then you obviously don't care
about the security of the incoming message, and dropping it because
it's "more secure" than you expect is just senseless.  Why prefer
unauthenticated data over authenticated data?  Is unauthenticated
somehow "better?"

Worse still, it creates needless confusion.  A RIP-1 router (or RIP-2
router that doesn't include authentication extensions) would have
accepted those authenticated messages without thinking twice, and
would have just ignored the odd address family 0xffff, so dropping the
messages makes this compatibility mode operation essentially
non-conformant.  [See notes copied from RFC 1058 below.]

(There's another good example in there that deals with the hop count
handling and that results in truncating the maximum network diameter
by one -- again, for no good reason, since it ends up being an
internal implementation detail whether you increment by one on input
or output.  Violating this "requirement" is fairly common.)

> there are non-zero must-be-zero fields, and the version is higher than 1.)

Nope; that's quite wrong.  RIP-1 was intentionally designed to be
upward-compatible.  See RFC 1058:

3.1. Message formats
[...]
   networks.  The address family identifier for IP is 2.  None of the
   RIP implementations available to the author implement any other type
   of address.  However, to allow for future development,
   implementations are required to skip entries that specify address
   families that are not supported by the implementation.  (The size of
   these entries will be the same as the size of an entry specifying an
   IP address.) Processing of the message continues normally after any
   unsupported entries are skipped.  The IP address is the usual
[...]
3.4. Input processing

   This section will describe the handling of datagrams received on UDP
   port 520.  Before processing the datagrams in detail, certain general
   format checks must be made.  These depend upon the version number
   field in the datagram, as follows:
[...]
      >1  Datagrams whose version number are greater than one are
          to be processed as described in the rest of this
          specification.  All fields that are described above as
          "must be zero" are to be ignored.  Future versions of the
          protocol may put data into these fields.  Version 1
          implementations are to ignore this extra data and process
          only the fields specified in this document.

If you know of an implementation that doesn't do this right, then you
might want to notify the vendor, because it's just plain broken.

---

From: William Allen Simpson <[email-masked]>
Date: Tue, 28 Jan 2003 15:45:10 -0500

> I think we're in violent agreement.
OK.

> No; I think you might be misinterpreting the example.
Well, I'm remembering the discussion in the working group....  
But this is way off topic for the PPP WG.

> datagrams that happen to carry unwanted authentication information.

In fact, we've long had problems with idiotic snooping of routing 
protocols, routing loops generated by idiotic misconfigurations, 
and on and on....

> unauthenticated data over authenticated data?  Is unauthenticated
Authentication is an aspect of security, but this speaks to whether 
the router is properly configured to be a member of an authenticated 
confederation.

> router that doesn't include authentication extensions) 

There is no such thing.  All conformant version 2 routers accept 
authentication:
                                   ... The Version field will specify
   version number 2 for RIP messages which use authentication or carry
   information in any of the newly defined fields.

> or output.  Violating this "requirement" is fairly common.)
Actually, it's not, and was a subject of much discussion. 

We had real operational problems to solve -- including rings of RS6000 
boxes acting as a single router -- on deciding when and where to update 
the counts, and how to handle updates that come in with "infinity".

The WG came to consensus.  Hopefully, people fixed their implementations 
to reflect that consensus.  If they didn't, then infinity might end up 
being smaller -- but in RIP that's not much of a problem, as RIP should 
never be used with a network diameter of more than 2 or 3.

Really, the first implementation is not often the best.  Remember D.P.'s
first PPP implementation? 

If all we really needed was a copy of an implementation, and then told 
people, "make it work like that", then we wouldn't have bothered to 
spend all this time writing detailed specifications.

Ah, well, the IETF ain't what she used to be....
-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 28 Jan 2003 14:01:25 -0700 (MST)

>    information in any of the newly defined fields.

Which conformant RIPv2 routers cannot be configured to not use
authentication?

There are or at least were RIPv2 implementations that did not have
the faintest idea about RIPv2 authentication.  I believe Cisco's first
RIPv2 effort lacked RIPv2 authentication.  Since RIPv2 was specified
well before RIPv2 authentication and since the first version of RIPv2
authentication was a simplistic cleartext password, that was entirely
understandable and reasonable.

I've not checked the router requirements RFC, but I bet that if I did
I would not find any words requiring that RIPv2 implementations include
either flavor of RIPv2 authentication.

> never be used with a network diameter of more than 2 or 3.

Few networks a diameter of 2 need more than static routing, usually
of a default.  There have been many RIPv1 internets with more than
1000 networks with diameters larger than 3.  I don't think RIP is the
best choice for more than a few gross of networks, but the old bit
about a few dozen hosts being the limit for IP is stale old router
salescritter and trade rag consultant e-spurt noise.

> Ah, well, the IETF ain't what she used to be....

The IETF has always suffered from people with pecuniary and other
interests in getting their names on RFCs.

(I don't mean to imply that RFC 1058 suffered from that syndrome.
It was a useful document despite its shortcomings.)

---

From: James Carlson <[email-masked]>
Date: Tue, 28 Jan 2003 16:23:39 -0500

> But this is way off topic for the PPP WG.

It looks it.

> the router is properly configured to be a member of an authenticated 

... which, in turn, has something to do with whether the 

> There is no such thing.  All conformant version 2 routers accept 

Not so.  The protocol *allows* it, but nothing *requires* anyone to
implement features they don't want to implement.  If I had a RIP-2
implementation that didn't include authentication, it'd be equivalent
to saying that the user interface knob to require authentication is
permanently set to "no."

For that matter, it's easy to envision cases in which configuration of
authentication is simply impossible because the required key storage
is lacking.

>    information in any of the newly defined fields.

Note the "or" in the sentence above.  In other words, you have to say
"2" if you want to use any of the new RIP-2 features.  It doesn't say
that you *have* to implement either or both.

> Actually, it's not, and was a subject of much discussion. 

I maintain that if you cannot see the difference on the wire, then
it's not a difference that matters to anyone looking at IETF
documents.

> the counts, and how to handle updates that come in with "infinity".

Agreed, but the RFC as written actually treats a route metric of 15
and 16 as being the same.

3.5 Protocol Specification
[...]
   about each of these networks.  The most important is its metric or
   "cost".  The metric of a network is an integer between 1 and 15
[...]
3.9.2 Response Messages
[...]
   Once the entry has been validated, update the metric by adding the
   cost of the network on which the message arrived.  If the result is
   greater than infinity, use infinity.  That is,

   metric = MIN (metric + cost, infinity)

This handling means that when you receive a route with metric 15, you
bump the metric by at least one before attempting to install it in
your local table.  You thus end up assuming that metric 15 routes
advertised to you are all "unreachable," which is a fairly silly
result.

A more reasonable approach is to use a zero-based 'cost' for the link,
so that metric 15 is installed in the local table and in the local
forwarding entries, and then increment by 1 when you go to advertise
to your peers, and do the check for infinity there.

Since the sum ends up being the same either way, the routes that you
pass along to your peers will be exactly the same either way, and your
behavior in the protocol itself is thus the same, and interoperability
is not affected.  The only difference ends up being whether or not you
install valid routes that you receive into your own IP forwarding
table, which is a local matter.  The RFC tells you not to, but my
reading suggests otherwise.

The fact that the RFC tells you to implement the +1 on the receive
side rather than on the transmit side is, in my opinion, an
implementation detail.

In fact, if you confer with this section:

3.2 Limitations of the Protocol
[...]
   - The protocol is limited to networks whose longest path (the
     network's diameter) is 15 hops.  The designers believe that the
     basic protocol design is inappropriate for larger networks.  Note
     that this statement of the limit assumes that a cost of 1 is used
     for each network.  This is the way RIP is normally configured.  If
     the system administrator chooses to use larger costs, the upper
     bound of 15 can easily become a problem.

... it becomes clear that this was perhaps just an oversight.  The
upper bound of the protocol as described by the RFC is actually 14
hops:

	link-->H1--m1-->H2--m2-->...--m13-->H14--m14-->RR

The first hop (the advertising router with a connection to the actual
network) must advertise a metric of no less than 1 (denoted "m1"
above; metric 0 is not legal in RIP).  If each hop adds the minimum
link cost of 1, then you go through 14 hops before the route becomes
unusable.  (If that receiving router [RR] were to try to pass the
route along to anyone, it'd have to pass along metric 15, and as shown
above, that's effectively the same as infinity.)

---

From: James Carlson <[email-masked]>
Date: Tue, 28 Jan 2003 16:36:06 -0500

> ... which, in turn, has something to do with whether the 

whoops; truncated sentence there:

... which, in turn, has something to do with whether the router in
question is able to *send* routes to those routers in the
authenticated confederation.  Obviously, if it doesn't have the
credentials to do so, then it cannot.

Note that I've already shown that a proper RFC 1058 compliant RIP-1
implementation *WILL* receive and process those authenticated RIP-2
messages, and will just ignore the unnecessary authentication bits.