Subject: scoped addresses and routing headers(Re: draft-ipngwg-scoping-arch-01.txt)

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 29 Jul 2000 11:52:41 +0900

>>>>> On Thu, 29 Jun 2000 23:01:17 -0700, 
>>>>> Steve Deering <[email-masked]> said:

>> whether they are crossing boundaries for their scopes.  Thus, it is
>> possible, though generally inadvisable, to use a Routing Header to 
>> convey a non-global address across its associated zone boundary. 
>> 
>> I believe this is very inadvisable.

> Yeah, it's not likely to do anything useful.  But I would not want to
> impose the cost on implementations of a relatively expensive check (a
> scan through all the addresses in a Routing header) for a such an
> unlikely event.

I agree that we should not introduce expensive checks such as scanning
thru the entire routing header. However, the text of the draft about
this issue is not very clear for me. The draft says as follows: 

   A node that receives a packet addressed to itself and containing a
   Routing Header with more than zero Segments Left [RFC 2460, section
   4.4] swaps the original destination address with the next address in
   the Routing Header.  Then the above forwarding rules are applied,
   using the new destination address.

Where "the above forwarding rules" are ones based on arrival
interfaces, that is, the router determines the appropriate zone for
an incoming packet based on the arrival interface, and then forwards
the packet to an interface (or interfaces if mulicasted) that belongs
to the zone. But the situation is not so trivial (at least for me)
with routing headers.

Consider the following packet (actually, I raised this six months
ago, but I haven't seen any responses to this.)

  source = some global address
  (1st hop) destination = a global address "G1"
  2nd hop destination (in a routing header) = another global address "G2"
  3rd hop destination (in a routing header) = a link-local address "L"

Where "global2" belongs to a router "R" that has two interfaces "I1"
and "I2". I assume G2 is configured on I1.

Also suppose that G1 and G2 are offlink and there are several paths to
G2 like the following figure:

(node that has G1)              ........---+
   |                           /           |I1: G2
   +-------....(Internet clould)           R
                               \           |I2
                                +......----+

If the router R adopts the weak host(node) model, it will accept
packets destined to G2 regardless of the incoming interface (I1 or
I2). The incoming interface depends on the routing in the intermediate
cloud and can dynamically be changed.

Now, consider the situation where the packet with the routing header
arrives at I2 (that *doesn't* have G2).  When the router R processes
the routing header and tries to forward the packet to L, which link
(interface) should it send the packet? To the incoming interface (I2),
or the interface that has G2 (i.e. I1), or even another interface?

It seems to me that the only reasonable approach is to forward the
packet to the link to which I1 is attached, because if we forward the
packets to the *real* arrival interface (I2), succeeding packets with
the same routing header could be forwarded to another interface that
should surely be undesirable.

I need a clarification on this points before accepting the
description.

By the way, IMO, I'd rather take a stricter (and even simpler)
approach;

- the destination addresss field and all addresses in the routing
  header SHOULD have a same scope.
- when a router forwards a packet with a routing header, it should
  check the "current" destination address in the IPv6 header and the
  "next" destination address in the routing header. If scopes of the
  two addresses are different, the router MUST discard the packet (or
  return an ICMPv6 error).

Although the rule is stricter than the current definition in the
draft, it's clearer, practical enough, inexpensive for routers, at
least for me.

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