>> and it was from outside, the kernel does not drop it for the sake of
>> SIIT (too-clever SIIT enabled client may try to drop it because of
>> IPv4 rules)
> Not too-clever.
i don't see any of your wording on RFC2765. i took your email as a
suggestion to RFC2765, am I right?
your suggestion does not protect nodes that are outside of SIIT cloud
(which is more common setup today). how do you intend to secure
those nodes? i think you are making separate discussion thread here.
> SIIT should drop packets whose source address is
> ::ffff:a.b.c.d/(96+n) (assuming figure in my previous mail).
you mean the SIIT box ([SIIT] in the following figure) should drop
the packet, when the packet tryes to go into the SIIT cloud?
drop it
___________ <----- ___________
/ \ / \
[IPv6 Host]--< Dual network>--[SIIT]--< IPv4 network>--[IPv4 Host]
\___________/ | \___________/
(pool of IPv4 addresses)
> Nodes in SIIT cloud should drop packets whose source
> address is ::ffff:127.0.0.0/104 and ::ffff:a.b.c.d/(96+n) from
> outside.
i don't think this is workable, as this requires every nodes in
SIIT cloud to know about the IPv4 address pool configured to the
SIIT cloud.
From seeing RFC2765 section 5, I think that the nodes in SIIT
cloud is unaware of the existence of SIIT box (or it does not know
if it is inside SIIT cloud or not).
> Nodes not in SIIT cloud should drop ::ffff:0:0/96 from outside.
> Anyway, issues seems to be administrative problem.
i think, for an end node in SIIT cloud, it is impossible to
determine if the traffic is from the outside, or from inside.
itojun
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
