That works for me.
Yours,
Joel
On 2/28/2013 11:19 AM, Stewart Bryant wrote:
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
.
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
