>>>>> On Tue, 23 Apr 2002 09:24:51 +0300 (EEST),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
>> > 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.
>>
>> I admit the notion is quite complicated and the text may have unclear
>> points, but the described behavior is clear at least to me so that I
>> could implement the rule in my implementation.
> Did you write or participate in writing of the text? :-)
The answer depends on the definition of "the text" and "participate
in":-)
Though I'm a co-author of the draft, I have basically contributed the
textual representation section only. For other sections, I'm almost a
reader of the draft, just like you.
>> So, could you be more
>> specific about the unclearness? Could you give me a concrete example
>> that cannot be explained with the description?
> The text about the scope and zone of the source address and the previous
> hop make the specification difficult to understand.
> For regular packet forwarding, the second bullet in 9. basically seems to
> say: "if you cross the zone boundary, the packet is discarded".
This is oversimplification. The second ballet says "a packet must not
cross the zone boundary of the source address's zone".
> This should be, IMO, honoured with routing header too.
As for the source address, that's correct (or at least what the draft
intended to say).
> In particular, one
> should not be able (IMO) to control how routing should go inside a site,
> using site-internal addresses (as these addresses aren't reachable to the
> source, and may have a different level of security etc.). If the
> destination site does not have global addresses in use there, he probably
> don't want site-local's being used either.
Sorry, I don't understand the statement above. Could you be more
specific please?
> Does does scoped arch work in the following case:
> src=linklocalA
> dst=globalB
> routing header=linklocalB, segments left=1
> Processing at globalB, I believe this would be discarded if linklocalA is
> not a direct neighbor of globalB, correct?
Correct.
> Processing at linklocalB, the
> packet would always be accepted (if the proposed new rule is not adopted)?
If all the 3 addresses are in the same link, yes. Otherwise, no.
> Site-locals are potentially fishier as they can't be as trivially
> restricted to a link.
> I'd like to see a "roadmap" of what kind of forwarding is possible with
> routing header, and what is not. I couldn't make a clear mental image
> based on the text.
I'm not sure what "roadmap" exactly means, but the restriction that
Rich mentioned will be clearer about the rule...
> A comment,
> Then the above forwarding rules are applied,
> using the new destination address where the zone of the new
> destination address should be determined by the scope of the previous
> destination address and the interface to which the previous address
> belongs (which is not necessarily equal to the incoming interface).
> ==> does incoming interface mean 'incoming interface' or 'incoming link'?
It means 'incoming interface' (or 'arrival interface').
> That is, can you use RH to forward packets out of the incoming link with
> e.g. link-local addresses? (As in the previous paragraph in the text.)
That depends on the precise configuration, as I said above.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
p.s. to make my position clear, I'm not a fan of the current rule.
Formerly I proposed a stricter rule that required all destinations in
a routing header were in the same scope type for deterministic
behavior. But the consensus at that time was that the flexible rule
was supported.
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
