Subject: OSPFv3 fwd'ing address

From: Alex Zinin <[email-masked]>
Date: Thu, 4 Aug 2005 05:58:49 -0700

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

-- 
Alex

---

From: Acee Lindem <[email-masked]>
Date: Thu, 4 Aug 2005 09:33:20 -0400

Hi Alex,

So I did understand the comment - see inline.

Acee Lindem wrote:

> Alex Zinin wrote:
> *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

---

From: Alex Zinin <[email-masked]>
Date: Thu, 4 Aug 2005 06:38:39 -0700

Acee,

> 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

---

From: Acee Lindem <[email-masked]>
Date: Thu, 4 Aug 2005 09:53:23 -0400

>That's not the case above, though. In the following scenario:
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

---

From: Alex Zinin <[email-masked]>
Date: Thu, 4 Aug 2005 10:38:19 -0700

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

---

From: Naiming Shen <[email-masked]>
Date: Thu, 4 Aug 2005 11:25:06 -0700

> 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

---

From: Mike Fox <[email-masked]>
Date: Thu, 4 Aug 2005 12:58:42 -0600

> accept the link-local as nexthops.

That's how we implemented it.  For the AS-External forwarding address, our 
implementation will accept any non-link-local address that is reachable 
using the OSPF protocol.  As a user of an AS-External LSA we will send 
packets for the external destination to the specified forwarding address 
(if provided) and we assumed others would do the same, so as long as 
routers in the AS can route to that forwarding address, it should work. 

This significantly limits its usefulness, but it does work.  The place we 
expect to see this used the most is for external default routes.  On our 
platform the user can specify that an ASBR is to advertise an external 
default route, and the user can optionally specify a forwarding address to 
use on that route, with the restrictions that it can't be a link-local 
address and it has to be an address or prefix that is routable in the OSPF 
domain. 

Mike
-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC  USA

---

From: Paul Jakma <[email-masked]>
Date: Sat, 6 Aug 2005 15:42:29 +0100

Hi,

On Thu, 4 Aug 2005, Mike Fox wrote:

> specify a forwarding address to use on that route, with the 
> restrictions that it can't be a link-local address and it has to be 
> an address or prefix that is routable in the OSPF domain.

Which seem like quite reasonable restrictions really.

And definitely far more reasonable than mandating the sucking up of 
details of global->LL address resolution and/or neighbour discovery 
into OSPF.

> Mike

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"All the people are so happy now, their heads are caving in.  I'm glad they
are a snowman with protective rubber skin"
-- They Might Be Giants

---

From: Acee Lindem <[email-masked]>
Date: Sat, 6 Aug 2005 08:23:34 -0400

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

Acee

---

From: Acee Lindem <[email-masked]>
Date: Sat, 6 Aug 2005 08:30:35 -0400

Hi Mike,

>address and it has to be an address or prefix that is routable in the OSPF 
I don't see any problems with this as long as a global IPv6 address is 
available - either as the
next-hop gateway in the redistributed route or explicitly specified. I 
could document this case. .