Subject: RE: Scoped Addressing Architecture Routing Issue

From: Richard Draves <[email-masked]>
Date: Mon, 31 Jul 2000 14:40:21 -0700

I've thought some in the past about your proposal. It would mean, for
example, that there would be no Destination Unreachable / Scope Exceeded
ICMP error because the routing table lookup would be constrained so as to
not exceed the scope of the source address.

My conclusion was that in normal configurations, it wouldn't make a
difference. But when a network is misconfigured, it would get in the way of
debugging the problem because you wouldn't get the ICMP error.

Rich

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Monday, July 31, 2000 12:26 PM
> To: IPng Working Group
> Subject: Scoped Addressing Architecture Routing Issue
> 
> 
> 
> I believe that there is a problem with the forwarding section
> of the Scoped Addressing Architecture document (section 9).
> 
> The current draft assumes that a next hop will be selected
> based only on the destination address of the packet, but I
> believe that it is necessary to take both the destination and
> source addresses into account to choose the correct conceptual
> routing table.
> 
> Consider the following example:
> 
> 			  (Cost 1)
>                     +--------R1-----------------+             
>                        
> +------------------|-----+   |    +------------|------------------+
> | SITE A           |     |   |    | SITE B     |       H1         |
> | Link1________.___|___  |   |    | Link2______|_______|_         |
> |              |         |   +---------------+             +--+   |
> +--------------|---------+        | Link3____|_____________|  |   |
>                 |                  |                          
>  //<=== Cost >=2 
>                 |                  | Link4_____.________.___.  |   |
>                 |                  |           |        |   |  |   |
>                 |                  |           |        H2  +--+   |
>                 |                  +-----------|-------------------+
>                 |                              |
>                 +--------------R2--------------+
> 			   (Cost 1)
> 
> There are two sites, SITE A and Site B.  SITE A has one link, Link1.
> SITE B has three links: Link2, Link3 and Link4.  H1 is a host on
> Link2, and H2 is a host on Link4.  R1 is a site-boundary router 
> with interfaces on Link1(SITE A), Link2(SITE B) and Link3 (SITE B),
> and the cost for traversing this router is always 1.  R2 is another
> site-boundary router, connecting Link1(SITE A) and Link4(SITE B),
> and the cost for traversing R2 is also 1.  There is additional routing
> infrastructure inside SITE B which connects Link3 and Link4 at a 
> cost greater than or equal to 2.
> 
> H1 sends a packet to H2 with the following addresses:
> 
> 	Destination:  Global address of H2
>         Source:       Site Local address of H1
> 
> Although this packet can (and should) reach its destination, it will
> not do so using the process described in section 9 of the Scoped
> Addressing Architecture.
> 
> 
>             o  The zone of the destination address is 
> determined by the
>                scope of the address and arrival interface of 
> the packet.
>                The next-hop interface is chosen by looking up the
>                destination address in a (conceptual) routing table
>                specific to that zone.  That routing table is 
> restricted
>                to refer only to interfaces belonging to that zone.
> 
> The zone of the destination address is Global.  So, we will look in
> the global table to determine how to route to H2.  The shortest
> (or cheapest) next-hop will be chosen -- router R2, through SITE A.
> 
> 
>             o  After the next-hop interface is chosen, the zone of the
>                source address is considered.  As with the destination
>                address, the zone of the source address is 
> determined by
>                the scope of the address and arrival interface of the
>                packet.  If transmitting the packet on the chosen next-
>                hop interface would cause the packet to leave 
> the zone of
>                the source address, i.e., cross a zone boundary of the
>                scope of the source address, then the packet 
> is discarded
>                and an ICMP Destination Unreachable message [RFC 2463]
>                with Code 2 ("beyond scope of source address") 
> is sent to
>                the source of the packet.
> 
> However, the site local (to SITE B) source address was used, so we 
> will discard the packet before sending it to SITE A.
> 
> Preferably, we would choose a site-local route to send this packet,
> even if it might result in a longer (or more expense) routing path.  
> This could be achieved by using the scope of both the destination 
> and source addresses to determine which conceptual routing table to 
> use for packet forwarding.  
> 
> A router should look at both the source and destination addresses 
> and determine which is of the lesser scope.  The lesser scope 
> (site-local in my example) will then be used to select the conceptual 
> routing table.  In this instance, the global address would be
> looked up in the site-local routing table, and an appropriate next
> hop could be chosen (if it exists) to route the packet to the
> global destination address using a site-local path.
> 
> Thoughts?
> 
> Margaret
> 
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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]
--------------------------------------------------------------------