Subject: Treatment of scoped addresses carried in extension headers

From: Brian Zill <[email-masked]>
Date: Thu, 14 Oct 1999 04:00:51 -0700

Recently I've been working on adding better support for scoped addresses to
our stack.  And while it's fairly clear how to treat scoped addresses when
they're presented along with a scope id, it is less clear how they should be
treated when they are not.

(For simplicity and the purposes of this message, you can take "scoped
addresses" to mean link-local and site-local unicast addresses)

When presented by a user, for example in a sockaddr_in6, a scoped address is
accompanied by a scope id which identifies the particular instance of a
scope (I'm told Steve Deering has proposed the term "zone" for this concept)
in which the address is meaningful.  When encountered in a packet on the
wire, however, a scoped address has no accompanying scope id.  This is not a
problem for the Source and Destination addresses present in the base IPv6
header, since the routing system should prevent packets with scoped
addresses in these fields from leaving their zone.  (Their zone can thus be
determined by the link they are encountered on, since they can't leave their
zone)

But what about scoped addresses in extension headers?  For example, in
routing headers and mobility options?  Since they are not hop-by-hop
options, routers will never look at them, and packets containing such could
easily leave the zone in which their embedded scoped addresses are
meaningful.  Nothing I could find in the current specs mentions how to treat
scoped addresses when present in these sorts of headers.

I can see three actions a node could take upon encountering such a header.
I can also see arguments for and against each one.

1) Treat the scoped address as meaningful in the zone that the interface the
packet arrived on belongs to.  This has the advantage of being simple to
implement and the disadvantage that in order to be useful, the originator of
the header would need detailed (?) information about the network topology.
In the absence of such information, the packet could easily be interpreted
incorrectly.  One could also argue that allowing remote nodes to send to a
local node that only has a link-local address via clever use of a routing
header is a security problem.  Others might see this as a handy feature.

2) This one only applies to multi-homed (or multi-sited) nodes.  Take a best
(?) guess as to the zone the address might be meaningful in, or try them all
(the latter is only feasible with some types of extension headers).  This
has the advantage that it is more likely the address will be interpreted
correctly, but at the risk that it might be interpreted incorrectly.  For
example, with a routing header, this might result in a packet being
delivered to one or more wrong recipients.

3) Treat scoped addresses as illegal in such headers and drop the packet.
This also has the advantage of being easy to implement, and is probably the
most defensible choice since the prescribed behavior is always clear and
unambiguous.  But it has the disadvantage that it prevents some possible
methods of using the protocol (I can imagine some mobility scenarios where
you might want to have a scoped care-of address or a scoped home address,
for example).  It also has the disadvantage that we'd need to update some
specs.

Comments?  Has this been discussed before and I missed it?

--Brian
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Thu, 14 Oct 1999 14:58:57 +0200

In your previous mail you wrote:

=> I have in my TODO list a similar comment about a proposed API for
scoped addresses. For instance a RSVP or IKE tool (daemon in Unix :-)
should use scoped addresses (ie. a structure with an address and a
scope ID in place of an address only).

[email-masked]

PS: I am not (yet) convinced by your argument but I know an example
of a (then not usable) link-local address without a scope ID (ie.
an interface index) in a proposed protocol: DHCPv6.
--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Thu, 14 Oct 1999 17:43:26 -0700 (PDT)

> for example).  It also has the disadvantage that we'd need to update some

draft-ietf-ipngwg-site-prefixes does specify how site-local addresses
can be used in mobile IPv6's use of extension headers and options
(in such a way that it doesn't cause confusion).

In this case (a mobile node which has been assigned site-local address(es)
that moves outside its site) the mobile node becomes multi-sited and
has to take appropriate care when dealing with non-global addresses.

   Erik