Subject: Re: How could OPSFv3 support IPv4 ?

From: Michael J Barnes <[email-masked]>
Date: Fri, 3 Jan 2003 09:35:22 -0800

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:[email-masked]]
> Sent: Thursday, December 12, 2002 10:44 AM
> To: [email-masked]
> 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:[email-masked]]
> Sent: Thursday, December 12, 2002 1:10 AM
> To: [email-masked]
> 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:[email-masked]]
> > > Sent: Wednesday, December 11, 2002 7:48 PM
> > > To: [email-masked]
> > > 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
> >

---

From: "Manral, Vishwas" <[email-masked]>
Date: Mon, 6 Jan 2003 00:07:00 -0500

Hi Michael,

I think its ok if you go forward with the draft, I am sure a lot of
people(including me) would be willing to help.

Thanks,
Vishwas

-----Original Message-----
From: Michael J Barnes [mailto:[email-masked]]
Sent: Friday, January 03, 2003 11:05 PM
To: [email-masked]
Subject: Re: How could OPSFv3 support IPv4 ?

Some ideas:

Regards,
Michael

---

From: "Manral, Vishwas" <[email-masked]>
Date: Mon, 13 Jan 2003 05:34:06 -0500

Hi Michael,

The case of a guy not winning the DR election does not arise with that
method. If we want to make a router a DR the method given is a sureshot way
to do it. Besides, the method is independent of the version of OSPF(OSPFv2
or OSPFv3), and can be used for other cases too.

I can explain it offline if you want.

Thanks,
Vishwas

-----Original Message-----
From: Michael J Barnes [mailto:[email-masked]]
Sent: Sunday, January 12, 2003 11:39 PM
To: [email-masked]
Subject: 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
>
> > > I don't think using the IPv4 mapped IPv6 address is the best way to
go.
> It