Hello,
Xu Xiaohu comment is right but probably be too much restrictive.
Excluding all public IPv4 addresses is too strict and not enough because it
does not excludes 6 to 4 gateways between the local private network and the
IPv6 network with a private IPv4 address.
ISATAP use an IPv6 operator prefix instead of a well known prefix, so it means
that ISATAP is built to ensure IPv6 connectivity of IPv4 Islands inside an IPv6
network managed by a specific operator.
So the encapsulation of IPv6 packet into IPv4 done by the gateway must be
restricted to IPv4 destination addresses managed by this operator (the ISATAP
equipment operator) excluding all IPv4 addresses managed by this operator and
allocated to ISATAP, 6 to 4 gateway or any other gateway between the IPv4
network and the IPv6 network like for example IVI-T gateways.
This limitation can be implemented through an access list in the ISATAP
gateway, in IVI-T gateways or in any other gateway between the IPv4 network and
the IPv6 network doing encapsulation of IPv6 packet, with a prefix allocated to
an operator, in IPv4 packet.
Eric BURGEY
-----Message d'origine-----
De : [email protected] [mailto:[email protected]] De la part de
Rémi Després
Envoyé : jeudi 17 septembre 2009 10:40
À : Xu Xiaohu
Cc : [email protected]; 'Templin, Fred L'; 'Behave WG'
Objet : Re: [BEHAVE] [Softwires] Some Thought about the AutomaticTunnelAddress
Xu,
Thanks for you answer.
Further comment below.
Le 17 sept. 09 à 05:17, Xu Xiaohu a écrit :
> In your msg
> (http://www.ietf.org/mail-archive/web/behave/current/
> msg06816.html), you
> said "... Suffice it to say that a 6to4 relay router may need, to
> be safe,
> to look at IPv4 addresses that are embedded in ISATAP IPv6
> addresses. In the
> above example, if the 6to4 relay router sees that the IPv4 embedded
> address
> in the IPv6 destination is its own IPv4 address 192.88.99.1, it can
> discard
> the packet and thus prevent the loop". However, I feel this is not
> a good
> idea for a 6to4 router to check the ISATAP address. In fact, the
> routing-loop attack can be easily avoided by using a private IPv4
> address,
> rather that a public IPv4 address as the ISATAP tunnel endpoint
> address on
> the ISATAP router.
If the IPv4 address of an ISATAP router is private, the attack
scenario below doesn't exists, YES.
But 5214 says in its introduction that "ISATAP enables automatic
tunneling whether global or private IPv4 addresses are used".
To prevent all routing-loop attacks, 6to4 relay routers should
therefore also deal with ISATAP routers that have global IPv4 addresses.
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).
> 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 |
> | |
> +--------+----------------------------------+-----------+
>
_______________________________________________
Behave mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
