Subject: RE: scope-exceeded and routing headers

From: Brian Zill <[email-masked]>
Date: Thu, 27 Jan 2000 00:25:31 -0800

Hi'ya Jim,

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

Yes, it really takes a knowledgeable sender for this to work.  Thus I expect
we won't see much use of scoped addresses in routing headers in practice.
  
> 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.

Uh, why not?  We allow mixed scope source/destination addresses in other
cases today.  I'd think it'd be ok to forward the packet in this example,
but only on the link the packet came in on.

Looks like I may have opened another can of worms here :-)

Let me try a different approach.  In the normal (no routing header) case,
you can only forward packets to places inside their zone.  This requires
checking both the source and destination fields in the IP header.  Packets
with a link-level source and/or destination address can only be forwarded
out via the same interface they came in on.  Packets with a site-local
source and/or destination address can only be forwarded out via an interface
that shares a scope_id value with the interface that the packet came in on
(i.e. it must go out the same interface it came in on, or another interface
within the same "site" as the one it came in on).  Any packets that don't
pass these checks get dropped and an ICMPv6 scope-exceeded message gets sent
back to the source.  Haberman's scoped-routing draft covers most of this.

The problem with the routing header is that it allows scoped addresses to
cross zone boundaries without being subject to these checks because the
checks are only performed against the source and destination fields of the
IP header proper.  Telling routers that they must make these checks against
every address present in a routing header when forwarding would add
tremendous overhead (it'd have to be done at each hop, not just at every
intermediate destination) and also run against the base IPv6 Specification
which says that only hop-by-hop options are done at each hop.  So that's
out.  The only options are to disallow scoped addresses in routing headers
completely (which was actually my original idea until I got talked out of
it), or allow them and come up with some way of assigning them a zone when
they cycle up out of a routing header.

So what zone should they be assigned?  There is no way to tell with
certainty what zone the packet originated in, so that's out.  The current
router that the packet is at might not have an interface in the original
zone in any case.  So the proposed rule is to use the zone of the interface
that the packet came in on ("weak host" model nodes might want to use the
zone of the interface with the IP address corresponding to the destination
field in the packet).  In other words, if the packet came in on interface
"5", and the next address in the routing header is link-local, treat that
link-local address as having a scope_id of "5".  If the next address in the
routing header is site-local, then treat it as having a scope_id equal to
whatever interface 5's site identifier is.  Then route as normal and the
normal routing rules for scoped addresses will prevent the packet from
leaving its newly assigned zone.

The end result of this is that putting scoped addresses in routing headers
is only useful if the sender knows the "zone" of the intermediate
destination just prior to the scoped address.  Because that is the "zone"
the scoped address will be interpreted in.  So yeah, this is one smart
sender.  One contrived example: say I have a dumb device on my local wire
that only has a link-local address, and I normally talk to it via my
workstation on the same local wire.  I could still send to this dumb device
when I'm far away by using a routing header with my workstation's global
address as the intermediate destination and the dumb device's link-local
address as the final destination.  It couldn't respond, but oh well.

Is this capability really useful?  I dunno.  Is there any reason to forbid
it?  I can't think of one.  So I think it would be better to take the more
permissive approach.  The behavior outlined in this message is how the
latest release of our stack (msripv6 1.4) behaves.

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

Okay, I'll do that in the draft.

Thanks,
--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: Jim Bound <[email-masked]>
Date: Thu, 27 Jan 2000 10:35:13 -0500

Hi Brian,

>but only on the link the packet came in on.

Good point on the same link.  In my above words I was thinking different
link, sorry.  For the same link that is fine.  I just assumed this is OK
in my reading of the ICMPv6 dst unreachable exceeding scope...uh oh..
Do we need to clarify that for that icmp type?

>Looks like I may have opened another can of worms here :-)

Alot of worms as we learn more.  When I started working on IPv6 I
accepted we would have warts :---)....

Wait till I open the discussion of rfc2553bis (soon) ---)..

>back to the source.  Haberman's scoped-routing draft covers most of this.

Yep.

>they cycle up out of a routing header.

A point.  There is no bits in the address to define a scope_id so your
sentence:

>The only options are to disallow scoped addresses in routing headers

I am having trouble parsing?  All addresses are scoped but the scope_id
is not part of the address?

>leaving its newly assigned zone.

Think we should stop saying scoped addresses here?  And maybe refer to
addresses which have an associated scope_id?  I think it will get
confusing for discussions?

This could be done as you suggest but put a lot of overhead in the
forwarding path which already may be an issue for VoIP packets,
Cell-HTTP packets from a mobile node, etc...  So I am wondering if we
can just make this much more simple.  I need to go reread Brian's draft
and think about this some more.  

But right now we need to answer the simple question of the scope
exceeded issue Richard raised.

I'll be back later.

>address as the final destination.  It couldn't respond, but oh well.

Again all addresses are scoped?  

Your last sentence is my issue with even permitting normal
communications that have src=link-local and dst=global. I am a
pragmatist.  The dst simply cannot respond.  I hated calculus until I
took diffyQ then I understood why calculus was useful to me as an
engineer.  Likewise whats the win here?  I don't see it?

>latest release of our stack (msripv6 1.4) behaves.

OK.  I kind said above the same thing, is it useful? I dunno?  But we
should not change the ICMPv6 spec till we are sure.

>Okay, I'll do that in the draft.

Great... My input to you is we need you to work with Steve on the site
stuff first :----)....

thanks
/jim