Re: OSPFv3 fwd'ing address

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

References: <1288871029.20050804055849@psg.com> <42F2145D.8020205@cisco.com> <42F21920.1040301@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <571507541.20050804063839@psg.com>
Date: Thu, 04 Aug 2005 06:38:39 -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: <42F21920.1040301@cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Acee,

>> 2) Forwarding address in AS-external-LSA. In IPv4, the next hop
>> address of a route can be any unicast address. In IPv6, the next hop 
>> of a route must be link-local address (RFC 2461, section 8). This 
>> requirement causes two problems: - OSPF cannot determine a global 
>> address of a neighboring router. The next hop of a route is a 
>> link-local address and OSPF must use a global address for the 
>> forwarding address in AS-external-LSA. - If a forwarding address is 
>> set in AS-external-LSA, a router connected to a common link with the 
>> router advertised in the forwarding address has to translate the 
>> forwarding address (global) to the next hop address (link- local). But 
>> the router does not have data to make translation.

> Right - as I stated at the meeting, we will NEVER use a link-local 
> address as a forwarding address.

That's not the case above, though. In the following scenario:

        [R3]
          |
   ------------
    |        |
   [R1]     [R2]

 R1 originates an ASE with R3's global address GA1 as the fwd addr. When R2
 calculates its route, it will have to translate GA1 to some link-local
 next-hop LA1, but it has no info in OSPF for this.

I'll wait to comment on the rest for now :)

--
Alex
 
   
> Hence, the forwarding
> address advertisement is effectively disabled - except for NSSAs where 
> we must choose of our global addresses as a
> forwarding address. Perhaps, I've let my own aversion to the 
> implementation complexity added by forwarding addresses :^)
> The problem here is that OSPFv3 may or may not have access to the global 
> unicast address for the next-hop. If the
> next-hop router is running OSPFv3 - then there will be a link-local LSA. 
> However, that begs the question of why this is
> not the router advertising the external prefix. The only reliable way 
> would be to require interaction with
> IPv6 ND (neighbor discovery) in order to determine a global address to 
> advertise. Architecturally, I don't like adding this
> dependency (and none of the implementations I've been associated with do 
> this yet). Comments? Could I be missing
> something simple?

> Thanks,
> Acee

>>
>>