That is a valid response and I agree that the text is strictly
correct. However there also appears to be an existence
proof that more than one reader was confused (the
reference to Quagga).
It would be at least charitable to has some text somewhere
that unconfused such a reader and the only way I can see
to do this is either to add an accepted errata or a fixed in
next version saying something like.
In section 3.9.1 "Note that an authentication header is
not considered to be an RTE".
Yes/No/Other proposals?
- Stewart
On 28/02/2013 15:44, Acee Lindem wrote:
Hi Stewart,
To retain compatibility with RIPv1, the RIPv2 WG kept the packets formatted as
a variable number of 20 byte entries. The one containing the authentication is,
well, the authentication and, by definition, is not a route. I'm don't think
this needs any clarification.
Thanks,
Acee
On Feb 28, 2013, at 10:03 AM, Stewart Bryant wrote:
The confusion seems to be whether the AH, which gets carried as
a special type of RIP entry, is an RTE or not.
I can see arguments both ways, although the fact that this has taken
25 years to surface suggests that most implementers have
subscribed to a common view that the an AH is not an RTE,
and therefore the RFC is correct.
I propose that we close this as an errata to be fixed in next version
with the statement:
"Some readers have been confused as to whether an AH is considered
to be an RTE. The consensus view it that that it is not. If this
RFC is revised, some clarifying text should be added."
Is that a reasonable way forward?
Stewart
On 02/01/2013 06:08, Bharat Joshi wrote:
Dear Gopakumar,
I understand what you are saying. In fact, I tested some vendor's
behaviour to understand how other people have implemented it.
When authentication is enabled, there should be 2 route entries for
things to work but I still feel that the RFC is not clear enough on this. In
fact, in my search, I found that Quagga has issues with this.
Regards,
Bharat
________________________________________
From: Gopakumar C [[email protected]]
Sent: Wednesday, January 02, 2013 11:05 AM
To: Bharat Joshi; [email protected]
Subject: RE: A query on RIPv2
Dear Bharat,
In the scenario that you mentioned RIP packet will have two RTEs after the RIP
header, first one will be authentication RTE and second one will be FULL table
request RTE with address family identifier as 0. This may be followed by
authentication trailer depending on the authentication scheme selected.
RFC section 3.9.1 first states the general format of RIP Version 2 request
message. Even though authentication is present, there is only one RTE (full
table RTE) other than authentication as authentication RTE doesn't convey
routing information.
Hope this helps.
Note: I think this is not correct forum to discuss this issue. I am not sure
where you can post it as RIP mailing list is not active anymore.
Regards,
-Gopakumar
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Bharat Joshi
Sent: Tuesday, December 25, 2012 4:02 PM
To: [email protected]
Cc: Bharat Joshi
Subject: A query on RIPv2
Hi All,
I came across some text in RFC 2453 (RIPv2) which has confused me. It
would be great if someone can clarify this for me. I searched the net and
looked through the errata but could not find any reference to this.
In section 3.9.1 of RFC 2453
(http://tools.ietf.org/html/rfc2453#section-3.9.1), in second para, following
text is available:
<quote>
There is one special case. If there is exactly
one entry in the request, and it has an address family identifier of
zero and a metric of infinity (i.e., 16), then this is a request to
send the entire routing table.
<unquote>
In section 4.1 of same RFC (http://tools.ietf.org/html/rfc2453#section-4.1), in
first para, following text is available:
<quote>
If the Address Family Identifier of the first (and
only the first) entry in the message is 0xFFFF, then the remainder of
the entry contains the authentication.
<unquote>
Now what has confused me is that if a router is configured to use
authentication, how should its 'request' message for full routing table look?
Should it go without authentication information or with authentication
information?
If it goes with authentication information then it is not conforming to
the statement of 3.9.1. If it goes without authentication information then it
is not conforming to the user configuration and also there may be security
issues.
Regards,
Bharat
PS: I am currently not subscribed to RTG working group mailing list, so please
reply all so that I can get your reply.
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are
not
to copy, disclose, or distribute this e-mail or its contents to any other
person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has
taken
every reasonable precaution to minimize this risk, but is not liable for any
damage
you may sustain as a result of any virus in this e-mail. You should carry out
your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this
e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
.
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
.
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
