Subject: RE: scoping-arch and link-local addresses in RH

From: "Richard Draves" <[email-masked]>
Date: Mon, 22 Apr 2002 13:33:11 -0700

> E.g are you able to send a packet like:
> 
> src=global1
> dst=globalA
> routing header=site_localA, segments left=1
> 
> which would be translated at globalA to:
> 
> src=global1
> dst=site_localA
> routing header=globalA, segments left=0  ?
> 
> I think we need to have a much much more clearer view of what 
> is possible 
> and what is not when crossing zone boundaries with routing headers.

To prevent this I have a check when processing routing headers - when
swapping the old destination and the new destination, it's an error if
the new destination has smaller scope than the old destination.

I think it's important that when a packet arrives at its final
destination, if that destination is link-local then the receiving
application can know that the packet originated on-link, and if the
destination is site-local then the application can know that the packet
originated within the site.

Rich

--------------------------------------------------------------------
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 23 Apr 2002 14:05:22 +0900

>>>>> On Mon, 22 Apr 2002 13:33:11 -0700, 
>>>>> "Richard Draves" <[email-masked]> said:

> originated within the site.

I tend to agree, because otherwise we do not have a guarantee that the
"response" packet can be delivered to the originating node without
breaking the destination zone (of the original packet).  (Of course,
there is always a possibility to break a zone boundary when the scope
types of source and destination are different.  But the possibility
usually depends on the intra-zone routing whereas in this case there
can be an essential breakage.)

Can we agree on the restriction?  Then I'll add it to the next version
of the draft.

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