Le 17 sept. 09 à 11:28, Xu Xiaohu a écrit :
As a matter of facts, ISATAP can be useful with a global IPv4 address
in a large private network that has enough global IPv4 addresses to
use them internally: this provides IPv6 connectivity to dual-stack
hosts that support ISATAP (e.g. with Windows or Linux AKAIK).
The site network could use public IPv4 address as long as the
address used
as ISATAP tunnel endpoint on the ISATAP router is an address which is
unaccessible from the IPv4 Internet.
Yes.
I would also suggest to configure it this way.
But, one may want to protect the 6to4 relay WITHOUT assumptions that
go beyond what the ISATAP spec says (IMHO a legitimate objective).
For this, the proposed check can do the job.
BTW, are there scenarios you are interested in where having to
protect the 9th octet of IPv6 addresses is very annoying (I find it
annoying myself but, well, if we have to live with it let's accept it
and proceed.)
Regards,
RD
Xiaohu
Hence, I don't think the routing-loop attack prevention is a
justification
for the "IID-format constraint".
I also wish it would not have been a justification, but for the
reason above I believe it is one we have to live with :-(.
Did I miss anything?
Regards,
RD
For a brief illustration of one instance of the the attack, here
is an
example:
+-------------------------------------------------------+
| IPv6 IPv6 packet |
|Internet dst6: 2002:198.16.9.9::1 |
| src6: 2001:db8:1::200:5efe:192.88.99.1|
| | |
| V |
| .--------------->--------------. | |
| / \| |
+--------+----------------------------------+-----------+
| |
2001:db8:1::/48 2002::/16
+---------+ +---------+
| ISATAP | | 6to4 |
+---------+ +---------+
198.16.9.9 192.88.99.1
| |
+--------+---------+ |
| IPv4 ^ | |
| site ^ | |
| ^ | V
| ^ | |
+--------+---------+ |
198.16.9.0/24 |
| |
| |
+--------+----------------------------------+-----------+
| IPv4 \ / |
|internet '----------------<-------------' |
| IPv6 in IPv4 packet |
| dst4: 198.16.9.9 |
| src4: 192.88.99.1 |
| |
+--------+----------------------------------+-----------+
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
