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
