Actually, having a single RTM supporting IPv4, IPv6 (global-scoped or otherwise), and any other protocol requires some intelligence on the part of the routing protocol. In my prototype of IPv6 scoped routing, I maintained a single RTM without a problem. However, I had to implement a mechanism that would determine which entries could be advertised per interface.
Regards, Brian Murugan KAT wrote: > > Jim, > > Let us think of a single RTM having for both V4 and V6. > But to what extent this is valid from routing stacks.? Will it be valid to > propogate V4 routing info. also to V6 domain.? Obviously the other way is > not valid? > > Thanks > KAT.Murugan > > -----Original Message----- > From: Bound, Jim [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, 19 March 2002 9:04 PM > To: Brian Haberman > Cc: [EMAIL PROTECTED]; IPng List > Subject: RE: Dual stack routers > > Brian, > > Agree. The entire issue of scoping will need to be added to the > infrastructure for sure. > > thanks > /jim > > > -----Original Message----- > > From: Brian Haberman [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, March 19, 2002 8:22 AM > > To: Bound, Jim > > Cc: [EMAIL PROTECTED]; IPng List > > Subject: Re: Dual stack routers > > > > > > Jim, > > I agree with your assessment. It is essentially the way I have > > integrated IPv6 into an IPv4 system. One point to keep in mind though > > is how to support site-scoped addresses in this model. The > > route table > > needs expansion in order to incorporate the zone IDs in the lookup. > > > > Regards, > > Brian > > > > "Bound, Jim" wrote: > > > > > > Its really up to the engineering team for that > > implementation. I would integrate v4 and v6 and duplicate as > > little as possible. At least all data structures so the > > algorithm for update/replace/delete was the same function > > module and not duplicated once for tcp and once for udp and > > yet again for SCTP. Then there is the emerging RDMA the > > router might want to use for storage. Treating all addresses > > as 16bytes (v4 and v6) works and will perform. Also all the > > traffic shaping, classification, et al on hardware would make > > the hardware engineers job a lot easier and thats a > > performance win too to support both address types. > > > > > > regards, > > > /jim > > > > > > > -----Original Message----- > > > > From: Murugan KAT [mailto:[EMAIL PROTECTED]] > > > > Sent: Tuesday, March 19, 2002 2:15 AM > > > > To: 'IPng List' > > > > Subject: Dual stack routers > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Murugan KAT > > > > Sent: Tuesday, 19 March 2002 12:07 AM > > > > To: 'IPng List' > > > > Subject: RE: Requirements for 'O' flag (was Re: IPv6 working group > > > > agendafor Minneapolis IETF) > > > > > > > > > > > > Hi, > > > > > > > > Regarding Dual Stack Router implementation should a > > router maintain 2 > > > > routing tables, one for V4 and other for V6. What about the > > > > routing stacks? > > > > Should there be 2 instances of a routing protocol (BGP, > > OSPF etc.,) ? > > > > > > > > What is the general approach? > > > > > > > > > > > > Thanks, > > > > KAT > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home Page: > > http://playground.sun.com/ipng > > > > FTP archive: > > ftp://playground.sun.com/pub/ipng > > > > Direct all administrative requests to > > [EMAIL PROTECTED] > > > > > > -------------------------------------------------------------------- > > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home Page: > > http://playground.sun.com/ipng > > > > FTP archive: > > ftp://playground.sun.com/pub/ipng > > > > Direct all administrative requests to > > [EMAIL PROTECTED] > > > > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to [EMAIL PROTECTED] > > > -------------------------------------------------------------------- > > > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > > ------------------------------------------------------------------------ > Name: winmail.dat > winmail.dat Type: application/ms-tnef > Encoding: base64 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
