Re: OSPFv3 fwd'ing address

Alex Zinin <zinin@PSG.COM> Thu, 04 August 2005 17:38 UTC

References: <1288871029.20050804055849@psg.com> <42F2145D.8020205@cisco.com> <42F21920.1040301@cisco.com> <571507541.20050804063839@psg.com> <42F21DD3.9010102@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <5410120267.20050804103819@psg.com>
Date: Thu, 04 Aug 2005 10:38:19 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Alex Zinin <zinin@PSG.COM>
Subject: Re: OSPFv3 fwd'ing address
Comments: To: Acee Lindem <acee@cisco.com>
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <42F21DD3.9010102@cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

> Ok - let's say R3 is in a different routing domain and R1's OSPFv3 does
> go through some measure (possibly extraordinary) to determine a valid
> global address for R3's associated interface and assure the address is
> associated with a global prefix advertised internal to OSPFv3. R2 would
> also have to determine the prefix is directly connected (a route lookup)
> and then go to neighbor discovery to map the global address to the
> link-local address. I can thnk of other solutions but they would require
> more information advertised with the forwarding address.

Right. From what I remember, the ND-based option was a bit complicated,
but if you went in that direction, it would have to be spelled out.
Another option was to have a link-local LSA that would map global to
link-local addresses, and then install a GA1/128->LA1 route in the RT,
which would automatically resolve the lookup for the external.

Alex