Hi Remi, > > What's the real purpose of the above model (IPv6 addresses > > beginning with > > other than '000' use a 64-bit prefix)? Can somebody help explain it? > > Xu, > > I had the view that this statement badly needed a reliable > justification, and argued about it. > > But it now happens that the study about routing-loop attacks > documented last August by Gabi Nakibly, in www.ops.ietf.org/lists/ > v6ops/v6ops.2009/msg00601, leads IMHO to such a justification. > > I tried to explain all this in www.ietf.org/mail-archive/web/behave/ > current/msg06816. > You may find relevant to this discussion.
Thanks for your reply. 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. Hence, I don't think the routing-loop attack prevention is a justification for the "IID-format constraint". Best wishes, Xiaohu NOTE: The following is quoted from Remi's msg (http://www.ietf.org/mail-archive/web/behave/current/msg06816.html) ****************************************************************** ROUTING-LOOP ATTACK PROTECTION AND ITS IMPLICATION ON IPV6 ADDRESS FORMATS In a mail of Aug 17 (www.ops.ietf.org/lists/v6ops/v6ops.2009/ msg00601), Gabi Nakibly documented a new type of attack: the "routing loop" attack. With it, some packets can be repeatedly retransmitted between two ISATAP routers, or between an ISATAP router and a 6to4 relay router. 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 | | | +--------+----------------------------------+-----------+ Detailed protection mechanisms against these attacks are being discussed on the v6ops and 6man lists, in particular with Gabi Nakibly, Fred Templin, and Christian Huitema, and are out of scope here. 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. Now, IPv4 addresses embedded in ISATAP addresses can be reliably detected ONLY if non-ISATAP addresses NEVER have 200:5efe::/32 in their octets 8 to 15. If some mappable-only address would have this pattern, there could be a slight but real possibility that an intermediate 6to4 relay would discard packets sent to this address. This is, in my understanding, a sufficient technical reason for the IID-format constraint to apply to all IPv6 addresses (with or without real IID). Regards, RD ***************************************************************** _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
