Subject: RE: scope-exceeded and routing headers

From: Brian Zill <[email-masked]>
Date: Wed, 26 Jan 2000 23:01:09 -0800

First let me say that what I said in my previous message was my
interpretation of the outcome of an earlier discussion of this issue, not
what my personal inclination was.  My original thought was that we'd need to
disallow scoped addresses in routing headers (i.e. global only).  The
opposing argument was that we shouldn't prevent people from doing something
unnecessarily, and if senders want to play with fire this way, let them.  I
ended up agreeing with that argument.

> 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 don't see anything wrong with this.  If the source (g1) wants to send to
(g2) and insist that the packet passes through "router" on the way, this
seems like a perfectly good way to do it.  Why is this a problem?

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

I see in another message that itojun agrees with you on this.  I don't think
I do.  Unless there is a very good reason for such a draconian policy, I
don't think we should set one.  We're way beyond discussing just routing
headers here, but are getting into the realm of scoped address routing and
source and destination address selection.  Both the scoped-routing draft and
the default-addr-select draft allow for, and explain how to work with,
situations where the source and destination addresses are of different
scopes.

--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: Jeff Williams <[email-masked]>
Date: Thu, 27 Jan 2000 01:35:53 -0800

Brian and all,

  I agree with Brian that scoped addressesin routing headers is
a mistake for obvious reasons.

> situations where the source and destination addresses are of different

Regards,

--
Jeffrey A. Williams
Spokesman INEGroup (Over 95k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 Jan 2000 03:45:20 +0900

>>>>> On Wed, 26 Jan 2000 23:01:09 -0800, 
>>>>> Brian Zill <[email-masked]> said:

> ended up agreeing with that argument.

Okay, and I agree that we should allow a die-hard user to play with
anything (even if it could be dangerous) unless there is a strong and
reasonable reason to oppose it.

 src    router
  |g1     |link-local
  |       |
|-+---+---+---|
      |
 another_router
      |

> seems like a perfectly good way to do it.  Why is this a problem?

Because the "router" essentially forwards the packet to another link
of "dst" in this case (if g2 belongs to a different link from the link
of "dst"). You said in your previous mail as follows:

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

When the "router" forwards to the packet toward "global2", it won't be
able to detect the (new) destination is in the same link of "dst". Why
is this case allowed while the previous case is prohibited? Also,
please note that once the "router" cycles the destination address to
"global2", the "another_router" won't be able to detect that the
packet is leaving the link scope of "dst" unless it checks the content
of the embedded routing header, which will cause a tremendous overhead
on the router as you said in another mail.

However...we could take an approach that once an address contained in
a routing header is validly processed, the packet containing the
header can even leave the scope zone of the address (like the above
example). If this is a wg consensus, I'll follow it. But please let me
confirm one more point. Consider the following packet containing a
routing header:

src = global1
dst = global2
1st element of the rthdr: link-local

Also suppose that global1 and global2 are offlink and there are
several paths to global2 like the following figure:

global1                         ........---+
   |                           /           |(interface1)
   +-------....(Internet clould)       global2
                               \           |(interface2)
                                +......----+

If the router of global2 adopt the weak host(node) model, it will
accept packets destined to global2 regardless of the incoming
interface (interface1 or interface2). The incoming interface depends
on the routing in the intermediate cloud and could be dynamically
changed.

When global2 tries to forward the packet to "linklocal", which link
(interface) should it send the packet? To the incoming interface, or
the interface that has "global2" (those two are not necessarily same),
or even another interface? According to your mail as a response to
Jim, you seem to take the former (i.e. forward to the incoming
interface). But as I said above, the incoming interface could
dynamically change according to the routing.

Your proposal assumes a "clever" sending node that knows all the
network topology. (Though I'm not sure if it is practically feasible)
the assumption itself is OK for me. However, isn't it a too strong
assumption that the sending node can know or control the routing in
the intermediate cloud?

Or do you propose the latter approach? Or should all routers that
handle a routing header adopt the strong host (node) model?

I need a clarification on these points before accepting your proposal.

> situations where the source and destination addresses are of different

Oops, sorry. I made a mistake in the above text (of mine). My
intention was "we should not put addresses of different type of scopes
into the destination filed and all intermediate destination fields of
a routing header (i.e. the source can belong to any type of
scope)". The source and destination (including one in a routing
header) addresses can have different kind of scopes. If the packet
with such src and dst addresses is leaving a scope, the forwarding
router will be able to detect it and drop the packet.

					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: Erik Nordmark <[email-masked]>
Date: Thu, 27 Jan 2000 13:38:13 -0800 (PST)

> seems like a perfectly good way to do it.  Why is this a problem?

Shouldn't g2 be able to reverse the routing header and use it for packets
in the reverse direction?
If it did it would try to send to the link-local address of "router" which
is in a different zone.

  Erik