Re: OSPFv3 fwd'ing address

[Acee Lindem <[e-mail]>]

Hi Naiming,
This is precisely why I didn't want to go down this path. Thanks for
articulating all the complexities.

Acee

Naiming Shen wrote:

> Alex Zinin said the following on 08/04/2005 10:38 AM:
>
>>> 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.
>>
>
> Assume on the shared media there is no OSPF neighbor with the nexthop,
> there will be no link-local LSAs. ND interaction would be the most
> reliable way to solve this, and remember link-local address can
> also change at anytime(thus the relation needs to be callback
> notification or constant polling).
>
> But if we think of this problem in another way, this 'nexthop' is only
> an internal state within the router, what does anyone care if
> I use a true 'link-local' address as a nexthop, or use the global
> address as the nexthop which passed by the OSPF forwarding address?
> I would not implement the IPv6 forwarding in a way to only
> accept the link-local as nexthops.
>
> thanks.
> - Naiming
>
>
>> Alex
>
>