Subject: RE: scope-exceeded and routing headers

From: Brian Zill <[email-masked]>
Date: Wed, 26 Jan 2000 19:02:32 -0800

Sorry I wasn't clear.  Allow me to clarify:

In regular packet forwarding cases (i.e. non routing header), a scoped
address in either the source or destination fields of the IP header cannot
"leave the scope" (maybe I should have said "zone" here) since routers will
refuse to forward such a packet outside of its zone.

However, a scoped address contained in a routing header (i.e. it's not yet
cycled up to the destination field) can pass through a non-destination
router unnoticed since such routers do not look at routing headers (they
only look at hop-by-hop options, of which the router header is not one).
This is what I meant when I said addresses can "leave their scope".  (Note:
some of the IP mobility headers also contain embedded IPv6 addresses,
similar issues apply there)

At an intermediate destination router, the next address in the routing
header is cycled up to the destination field in the IP header and is used to
send the packet onward.  If this address is a scoped address, there is no
way of knowing what zone it originated in.  The "best guess" in this case is
to use the zone which applies to the receiving interface (or possibly the
the zone which applies to the interface which has the intermediate
destination address -- these could be different in "weak host" model nodes,
which is one of many reasons I prefer the "strong host" model).  The
assumption is that senders have enough topology information about the
network to know what zone the intermediate destination address is in, and
only use scoped addresses that apply to that zone.

At an intermediate destination router, regardless of whether or not the next
intermediate destination is a scoped address, the router shouldn't run
through the other addresses in the routing header to see whether or not they
are scoped addresses.  One could imagine a router attempting this in a
misguided attempt at preventing scoped addresses from leaving their zone.
However, since such addresses can "leave their zone" by passing through
routers that aren't intermediate destinations, there is no point to this
idea.

Anyhow, the last three paragraphs explain what I meant by the 1st, 3rd, and
2nd sentences of point (1) in my original mail :-)

For your first example, the thing to do is to forward the packet to the
link-local destination ("rthdr") on the interface with address "dst".  For
your second example, you'd forward the packet to the site-local address
("rthdr") in the site to which the interface that has the link-local address
"dst" belongs (if there is no route to that site-local prefix out of an
interface in that site, you'd drop the packet).  For your third example,
you'd forward the packet to the global address ("rthdr") -- but only if the
route you'd use to reach that global address goes out the interface with the
link-local address "dst", otherwise you'd drop the packet.

Yes, I know.  Steve D. and I are supposed to be writing an ID that clarifies
all this.

--Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2000 17:30
> To: Brian Zill; Richard Draves
> Cc: IPng List
> Subject: Re: scope-exceeded and routing headers
> 
> 
> 
> >This was actually discussed (somewhere) not too long ago 
> when I asked more
> >or less the same question.  The consensus seemed to be:
> >1) Scoped addresses in routing headers are allowed to leave 
> their scope.
> >Routers are not expected to run through all the hops in a 
> router header to
> >perform scope verification.  Senders are assumed to know 
> what they are
> >doing.
> >2) Believing that scoped addresses provide some sort of 
> quasi-security
> >guarantees about where a given packet comes from is a bad 
> idea.  People
> >should use real security if they want real security.
> 
> 	That depends on what is meant by "leave the scope".  
> Could you give
> 	me more concrete example?
> 
> 	My take was that, you can't leave scope boundary 
> because routes cannot
> 	forward them.  This is because there's no indication of "zones"
> 	(or scope-id) in the routing header.  When router 
> interprets routing
> 	header, it needs to find the outgoing interface (or 
> zone), and the
> 	only hint it has is the incoming interface.
> 
> 	For example, to forward this packet:
> 		src = link-local
> 		dst = link-local (= router)
> 		rthdr = link-local (to where fourter forwards it)
> 	router needs to guess which interface it should be forwarded.
> 	possible solutions I can think of is
> 	- forbidden
> 	- forward to the node on the incoming interface, hence 
> you are not
> 	  leaving the scope
> 
> 	This goes the same with:
> 		src = link-local
> 		dst = link-local (= router)
> 		rthdr = site-local (to where fourter forwards it)
> 	since if the router is on site boundary, it can't be forwarded.
> 
> 	We may be able to set an exception when we set global address
> 	in the routing header.
> 		src = link-local
> 		dst = link-local (= router)
> 		rthdr = global (where router forwards it)
> 	In this case, it can reach the final destination 
> (because there's only
> 	single global address space), however, reverse path is 
> not available.
> 
> itojun
> 
--------------------------------------------------------------------
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: Jim Bound <[email-masked]>
Date: Wed, 26 Jan 2000 23:14:29 -0500

Hi Brian,

>only use scoped addresses that apply to that zone.

I have no issue if the sender has enough topology information by
specifying a source route that the scope of a particular address (as 
scope is discussed in RFC 2373) when it is cycled to the destination
address is in fact routable to a like scope interface by the router or
switched as some say today .--)... This is one smart sender.  But if the
packet src is FEC0/8 and the DST cycles to >site (i.e. 3ffe) then I do
not think the packet should be forwarded at all.  

The concept of scope_id (zone) for a scoped address is not intellgible
to our IPv6 routing protocols, so I don't see how that can even be used? 

>routers that aren't intermediate destinations, there is no point to this

All addresses are scoped: Global, Site, Link-Local, et al?  I would
think they can leave their zone by the fiat above or on purpose by a
smart sender but at the point they enter the forwarding code the ICMPv6
scope exceeded test applies.

Be good to use examples with real addresses for me anyway else I can't
get into the examples.

thanks
/jim

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 27 Jan 2000 15:05:40 +0900

>>>>> On Wed, 26 Jan 2000 19:02:32 -0800, 
>>>>> Brian Zill <[email-masked]> said:

> For your third example,

>> single global address space), however, reverse path is 

Then how do you think about the following case?

src = global1
dst = link-local (router)
rthdr = global2 (where router forwards it)

In this case, even if the outgoing interface to global2 for the router
is in the same link to which "dst" belongs, the forwarded packet could
be leave the link scope of "dst" (see the following figure).

 src    router
  |g1     |link-local
  |       |
|-+---+---+---|
      |
 another_router
      |
      +---------.......---g2 (final destination)

I'd personally think we should not put addresses of different type of
scopes into the source filed, destination filed, and all intermediate
destination field of a routing header. i.e. All the addresses should
belong to a same kind of scope.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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, 27 Jan 2000 15:13:37 +0900

>belong to a same kind of scope.

	I agree with jinmei on this point.  I wasn't clear enough.

itojun

---

From: Jim Bound <[email-masked]>
Date: Thu, 27 Jan 2000 10:16:19 -0500

>	I agree with jinmei on this point.  I wasn't clear enough.

I believe this is a prudent ruleset too. Avoids the issue completely.

/jim

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Jan 2000 22:45:45 +0100

=> I agree for a SHOULD (this doesn't completely avoid the issue
but make more discussions nearly useless :-).

Regards

[email-masked]

PS: there is an other very old issue related to this one discovered
by Jean-Luc Richier (who doesn't want to use such routing header hack).
If you are doing a topology discovery using SNMP and routing tables,
you should get as "next hop" only link-local addresses (with scope IDs)
and you can go further than the first round because this kind of
information is not enough for sending SNMP requests to routers.
A link-local address to global address (or name) proxy service
should be a good solution but none is really available even on paper
(I haven't search in draft-ietf-ipngwg-icmp-name-lookups-05.txt
then I apologize if this is in the I-D).
--------------------------------------------------------------------
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: Alain Durand <[email-masked]>
Date: Thu, 27 Jan 2000 15:15:47 -0800

> then I apologize if this is in the I-D).

Francis,

It is in this ID, section 5.4

    - Alain.

5.4.  Node Addresses

    The NI Node Addresses Query requests some set of the Responder's
    IPv6 unicast addresses.  The Reply Data is a sequence of 128-bit
    IPv6 addresses, each address preceded by separate a 32-bit TTL
    value, with Preferred addresses listed before Deprecated addresses
    [2461], but otherwise in no special order.  Five flag bits are
    defined in the Query, and six in the Reply.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Qtype=3            |       unused      |G|S|L|C|A|T|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    G   If set to 1, Global-scope addresses [2374] are requested.

    S   If set to 1, Site-local addresses [2374] are requested.

    L   If set to 1, Link-local addresses [2374] are requested.

    C   If set to 1, IPv4-compatible and IPv4-mapped addresses [2373]
        are requested.

    A   If set to 1, all the Responder's unicast addresses (of the
        specified scope(s)) are requested.  If 0, only those addresses
        are requested which belong to the interface (or any one
        interface) which has the Subject Address, or which are
        associated with the Subject Name.

    T   Defined in a Reply only, indicates that the set of addresses is
        incomplete for space reasons.

    Flags G, S, L, C and A are copied from a Query to the corresponding
    Reply.

    The TTL associated with each address are to be determined by the
    rules in section 5.3, applied to the returned address rather than
    the Subject.  If no meaningful caching time can be given for an
    address, the corresponding TTL field MUST be zero.

    Each address with non-zero TTL in a NI Node Address Reply may be
    cached and used for the period indicated by that TTL.  If the TTL is
    zero, the corresponding address must not be used more than once.  If
    the Query was sent by a DNS server on behalf of a DNS client, the
    result may be returned to that client as a DNS response with TTL
    zero.

    IPv4-mapped addresses can only be returned by a Node Information
    proxy, since they represent addresses of IPv4-only nodes, which
    perforce do not implement this protocol.