Subject: global/link-local nexthops and RFC2461

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Jul 2003 10:16:09 +0300 (EEST)

Hi,

Discussing one implementation, a possible source of ambiguity in RFC2461 
came up.

RFC2461 discusses that next-hops must be on-link.

However, section 8 on redirect basically requires:
 - routers know each others' link-local addresses (not an issue from 
hosts' perspective, just use routing protocols or other mechanisms)
 - hosts are able to verify that the redirect comes from the link-local 
address the host is currently using as its next-hop

The latter is a bit problematic.  How could the host know this in the case 
where the next-hop has been configured using e.g. a _global_ (but on-link) 
address?

What's the deal here?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 17 Jul 2003 16:25:48 +0900

>where the next-hop has been configured using e.g. a _global_ (but on-link) 

	to say it backwards, for the ICMPv6 redirect to work correctly, nexthop
	address on the routing table MUST be link-local (even when manually
	configured).  i think adding this text clarifies the concern.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Jul 2003 10:30:28 +0300 (EEST)

> 	configured).  i think adding this text clarifies the concern.

Yes, this would fix and clarify the issue, but I think it might
substantially change the overall assumption of the document, i.e.  
"next-hop must be onlink".

It might be interesting to hear if this was an issue that was debated when 
RFC2461 (or previous versions) were specified.

---

From: [email-masked]
Date: Thu, 17 Jul 2003 16:37:14 +0900

>"next-hop must be onlink".

	are there any linklocal address peers that are "not onlink"?
	note that it is because the defition of "onlink" is a bit vague:
	- sharing the same subnet number
	- same link-local scope zone

	i'm using the latter definition, and i guess you are using former.
	multilink subnet folks are using the former.

itojun

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Jul 2003 09:55:43 +0200

In your previous mail you wrote:

   
=> this is an obvious requirement.

=> routers may know each others' global addresses too, mainly
through prefix-infos with the R bit set (so this R bit is useful
outside mobile IPv6 and should be added in a RFC 2461bis) or through
external routing protocols. BTW when routers don't know each others'
global addresses you can't use standard network management tools
(i.e., SNMP with standard MIBs) to perform a topology discovery
(i.e., a network map) because you can't go further than the local links.
This issue was signaled by Jean-Luc Richier many years ago but was
never solved...

   
   What's the deal here?
   
=> I agree RFC 2461 expects the next-hop is always characterized by its
link-local address (as it is on a shared link it always has one).
There are some implementations which enforce the use of link-local
addresses but I agree that global addresses are not forbidden, or
the use of more than one link-local address... BTW I don't believe
a host is required to redirect its packets.

Regards

[email-masked]

PS: I've looked at BSD (mine old stack and KAME) codes: the source
of the redirect is compared with the "gateway" field of the route to
the redirected destination: if they don't match the redirect is rejected.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Jul 2003 10:59:01 +0300 (EEST)

> 	multilink subnet folks are using the former.

This is not a problem (IMO): the problem is that certain global addresses 
are *also* on-link, but cause issues with redirects.

---

From: [email-masked]
Date: Thu, 17 Jul 2003 17:00:09 +0900

>are *also* on-link, but cause issues with redirects.

	so i suggest replacing "next-hop must be onlink" with
	"next-hop must be link-local".

itojun

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Jul 2003 11:23:16 +0300 (EEST)

On Thu, 17 Jul 2003, Francis Dupont wrote:
> the use of more than one link-local address...

Note that this also happens if you'd like to use an anycast address as the 
nexthop: even in the link-local scope, e.g. fe80::.

(I'm not sure whether these are realistic scenarios or not..)

> BTW I don't believe

You mean, host is not required to respond to redirects sent by the 
routers?

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Jul 2003 10:56:14 +0200

=> even if in theory this should work in practice this doesn't work
at all (at least it was a disaster when I tried many years ago :-).

=> there are many nodes with multiple link-local addresses and
in these nodes some are routers. IMHO we should not try to
support redirect sent from a "random" link-local source address
but we have to address the problem, i.e., just change on-link by
link-local is not enough to really answer to your question...

   
=> host is not required to update its routing table (i.e., there is
a SHOULD, not a MUST).

Thanks

PS: I have a limited interest question about redirects: some implementations
drop received redirects on routers, in fact RFC 2461 only says it MUST NOT
update its routing table, so a redirect received from an unknown router
should give a new STALE neighbor cache entry...
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Thu, 17 Jul 2003 13:59:12 +0200

> address the host is currently using as its next-hop

As I recall, routers use LL addresses in RAs for source addresses to
avoid aliasing problems. If a router has multiple addresses (and if
those addresses change over time, e.g., as a result of renumbering) a
host could get confused and think there were (say) two routers on the
link when the two were really the same.

Having the router just always use its LL address when talking to the
host via RAs/redirects avoids a bunch of potential problems. E.g.,
when a router A sends a redirect saying use router B, and B later
sends a redirect saying use router C, the source address B uses in the
redirect better be the same one router A used as a target in its
redirect or the redirect gets ignored. Note that ensuring this would
require two different routers to be in sync with each other, which is
a pain at best (no obvious way to do that) if any address could be
used.

Using LLs avoids unneeded complexity.

Thomas

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Jul 2003 15:11:50 +0200 (CEST)

> where the next-hop has been configured using e.g. a _global_ (but on-link) 

Per rfc 2461 the source address of the redirect must be a link-local address.
Thus if you want to create a static route on the host and make
redirects work at the same time you'd better use the link-local address
of the router in the static route.

So apart from this requirement on the manually added static routes, what
is the issue?

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Jul 2003 17:08:45 +0300 (EEST)

> link when the two were really the same.
[...]

Yes, routers use LL as source addresses.

So, basically you could specify that, like, when you discover the L2 
address of your router, you'll record it's source address somewhere (to 
be used when redirects arrive).

(you don't even have to wait for RA's I think)

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Jul 2003 17:13:14 +0300 (EEST)

> So apart from this requirement on the manually added static routes, what

I think the question whether:

 - we want to specify next-hops must be link-locals

 - we want to clearly state that redirects work only when using 
link-locals, and when the link-locals are the same as used in next-hops

 - we want to figure out whether it's worth exploring the details needed 
to make redirects work with global/anycast next-hops.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Jul 2003 17:14:54 +0300 (EEST)

> 	"next-hop must be link-local".

Would this also apply in some other cases, like configuring 6to4 nexthop 
as 2002:<something> ?

(or in P-t-P links or tunnels where redirects aren't possible)

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Jul 2003 16:27:32 +0200

=> I disagree (the must is far too strong)

=> I agree

=> I disagree (we have far more useful things to do).
In conclusion my opinion is N/Y/N.

Thanks

---

From: Robert Elz <[email-masked]>
Date: Thu, 17 Jul 2003 21:31:40 +0700

Date:        Thu, 17 Jul 2003 15:11:50 +0200 (CEST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | Thus if you want to create a static route on the host and make
  | redirects work at the same time you'd better use the link-local address
  | of the router in the static route.

Of course, an implementation can easily (if asked to install a route
with a non-LL address as next hop) send a NIQ and get the equivalent
LL address ... (in unix type systems the route(8) command would do that
before installing it in the kernel).

If something like this isn't done, we won't be able to do

	route add <whatever magic syntax> name-of-gateway

as the name-of-gateway to address translation is unlikely (normally
anyway) to produce an LL address.

I certainly agree that next-hops should always be LL addresses.
I also don't think the "router has multiple LL addresses so we
can get confused" case is likely to ever be common enough to
bother anyone, so I wouldn't waste any effort on looking for
solutions to that.

kre

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 17 Jul 2003 22:03:49 +0200 (CEST)

> to make redirects work with global/anycast next-hops.

Explored the global part long time ago. Conclusion was:
In order to make redirects work well in this case and maintain the
check to only accept redirects from the current nexthop requires the
host to maintain an equivalence class for each router on the link i.e.
knowing all the addresses of all the routers on the link.
This adds memory requirements and some more complexity on small hosts for
not much benefit. Also, accepting redirects from non-link-local sources
removes one security check (but we still have the hoplimit=255 check;
but implementation bugs means it might make sense to have two checks instead of
one).

Anycast is harder due to the "no anycast as source" requirement.

  Erik

---

From: Derek Fawcus <[email-masked]>
Date: Fri, 18 Jul 2003 16:15:20 +0100

> In conclusion my opinion is N/Y/N.

I basically agree with Francis' points above,  with one provisio.  I may
occasionally be possible for a router (with a static route via a non LL
next-hop) to discover the corresponding LL and hence validate redirects.

Hence I'd say the answer to the second point is that you're only
guarenteed to be able to get working redirects if a LL next hop is
used.  With a non LL next-hop it's imp. (and specific config)
dependent if you'll get working redirects.

DF