Re: OSPFv3 fwd'ing address

[Acee Lindem <[e-mail]>]

Hi Alex,

So I did understand the comment - see inline.

Acee Lindem wrote:

> Alex Zinin wrote:
>
>> Folks-
>>
>> For the problem with the forwarding address that I mentioned during the
>> meeting, please see the following thread:
>>
>> http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0203&L=OSPF&P=R2888&I=-3 
>>
>>
>>  
>>
>
> *Date:*         Tue, 12 Mar 2002 06:26:54 -0500
> *Reply-To:*     Mailing List <[log in to unmask]>
> *Sender:*       Mailing List <[log in to unmask]>
> *From:*         "Kwiatkowski, Jacek" <[log in to unmask]>
> *Subject:*      Issues in OSPFv3 (RFC2740)
>
> 1) RFC 2740 specifies two options bits: V6-bit and R-bit. These bits 
> are set in Router-LSAs and Link-LSAs (also in Network-LSAs and 
> Inter-Area- Router-LSAs if these bits are set in associated LSAs). 
> Section 3.8.1 does not specify how to use these V6-bit and R-bit 
> during routing table calculation. I understand that all LSAs without 
> V6-bit should be ignored during calculation. Handling of R-bit is a 
> bit more complicated. A host may advertise addresses that are not 
> advertised by other OSPF routers. I think LSAs whose R-bit is reset 
> should not be ignored. A vertex without R-bit should be added to 
> shortest path tree as a leaf. It can be achieved if a calculating 
> router will ignore all links of a such vertex after the vertex was 
> added to the shortest path tree. During next stage, when 
> intra-area-prefix-LSA associated with vertex without R-bit is 
> examined, only prefixes whose LA-bit is set should be included in the 
> calculation. I think it is also worth to write in the specification 
> how OSPF should work as a host. 

This has been clarified in the 2740 respin.

> 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. 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

>
>