Re: OSPFv3 fwd'ing address

[Acee Lindem <[e-mail]>]

Alex Zinin wrote:

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

Thanks,
Acee

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