[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How could OPSFv3 support IPv4 ?
Hello Vishwas,
Yes, this is a good idea, and I'll add it to my notes to include in the
draft (which I'm going to start on this morning).
However, if I'm not mistaken this method does rely on the v4AF capable
router to be able to win the DR election. I think we should specify that
behavior, but we also need to consider what should happen if a v4AF
capable router can not win the election.
So I propose we do this:
1) If the DR is not v4AF capable, and the v4AF capable router recognizes
that it would become the DR after a new election, then it will declare
itself first to be BDR, and then after it has formed adjacencies with the
other routers on the network, it will declare itself to be DR. If the v4AF
capable router can beat the DR but not the BDR then it will skip the BDR
steps.
2) If the v4AF capable router can not win the DR election, then the v4AF
capable routers will <one of the mechanisms from my previous email>
Thanks
Michael
"Manral, Vishwas" wrote:
>
> Hi Michael,
>
> Just one comments regarding non-v4AF supporting routers. I think a similar
> problem exists for Opaque support too in OSPFv2, because it could happen
> that the DR supported may not have Opaque support.
>
> I think a simple solution to these kinds of problems is
> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0205&L=ospf&T=0&F=&S=&;
> P=7884
>
> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0206&L=OSPF&P=R3746&I=
> -3
>
> Let me know if you agree.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Michael J Barnes [mailto:mjbarnes at CISCO.COM]
> Sent: Friday, January 03, 2003 11:05 PM
> To: OSPF at DISCUSS.MICROSOFT.COM
> Subject: Re: How could OPSFv3 support IPv4 ?
>
> Hello Vishwas and everyone,
>
> I'm thinking along these lines too. If nobody else is, I'm prepared to
> start writing a draft document for supporting IPv4 addresses in OSPFv3. It
> seems that there is enough interest in this capability to warrant it.
>
> These are the points I have, taken from previous e-mails and thoughts of
> my own:
>
> - Create IPv4 Address Family versions of the Link, Intra-Area-Prefix,
> Inter-Area-Prefix, and AS-External LSAs. These LSAs would be adaptations
> of the current OSPFv3 LSAs. Unless otherwise specified, these LSAs will
> be treated in the same manner as their IPv6 counterparts.
> - Whether or not the U-bit is set in IPv4 AF LSAs should be user
> configurable, but defaulting to set.
> - Have a v4-bit in the Options field, indicating whether or not the
> router forwards IPv4 packets.
> - If all router LSAs have the v4 bit set, then a single SPF calculation
> can be done. Otherwise there must be a separate v4 SPF calculation.
> An implementation can always do two SPF calculations.
> - Whether or not an ABR originates IPv4 AF Inter-Area-Summary LSAs should
> be user configurable.
> - If the v6-bit is set for the router, then any interface over which an
> adjacency can be formed must forward IPv6 packets. Interfaces that
> forward IPv4 packets but not IPv6 packets will, in general, be treated
> like connections to stub networks.
>
> The two issues I'm most concerned about are 1) how to handle multi-access
> networks with some non-v4AF capable routers, and 2) routers with both the
> v6-bit and v4-bit set, but which have some interfaces on a transit links
> which are not able to forward IPv4 packets.
>
> Routers on a broadcast link which do not support IPv4 AF should have their
> router priority set to 0 so that they do not become the DR. However, we
> need to consider how the case of the DR not v4AF capable.
>
> Some ideas:
>
> 1 - The v4AF capable routers on the link select a proxy DR which will
> originate the v4 Intra-Area-Prefix LSA for the link.
>
> Special rules are needed for some cases, non-full mesh NBMA networks
> for example. In those cases the v4AF capable routers will not
> originate v4 Link LSAs for the network. (Thus the v4 bit will not be
> set in the Network LSA, and the network will not function as a
> transit network for IPv4.)
>
> 2 - Each v4AF capable router could originate a v4 Intra-Area-Prefix LSA
> associated with its Router LSA, advertising just its own v4
> prefixes for the link.
>
> Some special rules would also be needed for this solution.
>
> 3 - Require the v4AF capable routers to automatically raise their
> priorities by the amount of the highest priority of the non v4AF
> capable routers.
>
> I also have a few ideas about routers which have the v6-bit and v4-bit set
> but are able to forward IPv4 packets on only some of the interfaces which
> can forward IPv6 packets. (Excepting interfaces connected to stub
> networks.)
>
> 1 - Define one of the bits in the unused byte between the Type and Metric
> fields as a v4-bit. If this bit is not set the interface would
> not be considered during the IPv4 SPF calculation. This bit will
> only be set if there is a v4AF capable neighor on this link.
>
> 2 - The interface must be either 2-WAY or FULL with at least one v4AF
> capable neighbor, and must be able to forward IPv4 packets on that
> interface. Otherwise the interface will be treated as if it were
> connected to a stub network and it will not be listed in the
> Router LSA.
>
> 3 - If some, but not all, interfaces have IPv4 enabled then originate
> two Router LSAs, one with the v6-bit set and the other with the
> v4-bit set. Each Router LSA would then describe the interfaces which
> are capable of forwarding their corresponding IP packets.
>
> I look forward to further discussion.
>
> Regards,
> Michael
>
> > -----Original Message-----
> > From: Manral, Vishwas [mailto:VishwasM at NETPLANE.COM]
> > Sent: Thursday, December 12, 2002 10:44 AM
> > To: OSPF at DISCUSS.MICROSOFT.COM
> > Subject: Re: How could OPSFv3 support IPv4 ?
> >
> > Hi Vincent,
> >
> > I think importing v2 LSA's directly would not be a good idea in this case,
> > as most of the information other than the IPv4 addresses are already there
> > in OSPFv3 LSA's. Importing it would make it compulsary for OSPFv3 to
> > understand OSPFv2 LSA types, besides the entire SPF processing(as well as
> > LSA generation), would have to change to make use of information contained
> > in OSPFv2 LSA's.
> >
> > Using just the new OSPFv3 LSA's with equivalents for the IPv6 address
> > containing LSA's, would make the job a lot easier, and we could infact do
> > the SPF irrespective of protocol, and IPv4/IPv6 address nodes would be
> added
> > as stubs on the tree.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Vincent Jardin [mailto:jardin at 6WIND.COM]
> > Sent: Thursday, December 12, 2002 1:10 AM
> > To: OSPF at DISCUSS.MICROSOFT.COM
> > Subject: Re: How could OPSFv3 support IPv4 ?
> >
> > Hi Vishwas,
> >
> > If we just have some new LSA types instead of the IPv4 mapped IPv6
> > address, would it be enough to import the OSPFv2 LSA's within OSPFv3 ?
> >
> > Moreover, it could use the scope feature of OSPFv3.
> >
> > Vincent
> >
> > On Wed, 11 Dec 2002, Acee Lindem wrote:
> >
> > > Manral, Vishwas wrote:
> > > > Hi Yasu,
> > > >
> > > > I think you missed "Link-LSA" equivalents. I think they would be
> > required
> > > > too !!!
> > >
> > > Yup. I think these would be needed too. Also, if we were serious about
> > this
> > > I don't think using the IPv4 mapped IPv6 address is the best way to go.
> It
> > > would be better to have new LSA types for for IPv4 or with an AF and
> > generic
> > > address.
> > >
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > > -----Original Message-----
> > > > From: Yasuhiro Ohara [mailto:yasu at SFC.WIDE.AD.JP]
> > > > Sent: Wednesday, December 11, 2002 7:48 PM
> > > > To: OSPF at DISCUSS.MICROSOFT.COM
> > > > Subject: Re: How could OPSFv3 support IPv4 ?
> > > >
> > > >
> > > >
> > > >>I am wondering how OSPFv3 could support IPv4.
> > > >>
> > > >>According to the RFC2740, the 24-bit OSPFv3 options field describes
> the
> > > >>router capabilities. For example, the R-bit and the V6-bit are used in
> > > >>order to announce IPv6 forwarding capabilities. However, what's
> happened
> > > >>if this V6-bit is clear ?
> > > >
> > > >
> > > > RFC2740's section 2.7 gives the exact answer:
> > > >
> > > > V6-bit specializes the R-bit; if the V6-bit is clear an OSPF
> > > > speaker can participate in OSPF topology distribution without
> > > > being used to forward IPv6 datagrams. If the R-bit is set and
> the
> > > > V6-bit is clear, IPv6 datagrams are not forwarded but diagrams
> > > > belonging to another protocol family may be forwarded.
> > > >
> > > > In routers do not support other protocol family other than IPv6,
> > > > the router having V6-bit off should be treated as a non-working router
> > > > from the rest of the network.
> > > >
> > > >
> > > >>If there would be a V4-bit in order to announce the IPv4 capabilities,
> > > >>how could OSPFv3 be extended in order to support IPv4 like Integrated
> > > >>ISIS ?
> > > >
> > > >
> > > > You'll need only to define IPv4 version of Intra-Area-Prefix-LSA,
> > > > Inter-Area-Prefix-LSA, AS-External-LSA. Using IPv6 address holding
> > > > embedded IPv4 address is another option. I guess IPv4-mapped will be
> > > > the right choice semantically in that case, but it may not be
> > > > accepted as I saw someone states "IPv4-mapped address should not
> > > > appear on the wire" somewhere. I believe it means as IP source or
> > > > destination, though.
> > > >
> > > > regards,
> > > > yasu
> > >
> > > Acee
> > >
--
Michael Barnes
Core IP Eng - Routing
408-525-2785