Eric, The point is that ISATAP can be used with public IPv4 addresses (in which case the IPv6 address is constructed as: "FOO::0200:5EFE:V4ADDR") and there is no guarantee in that case that the ISATAP router is located behind an ip-proto-41 nor ingress-filtering site border router. Plus, I know of at least one major enterprise network that uses public IPv4 addresses internally, and the network is much too large to be covered by a single ISATAP link.
This discussion should probably by synchronized with the one taking place on the v6ops, 6man and secdir lists. Fred [email protected] > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Thursday, September 17, 2009 7:45 AM > To: [email protected]; [email protected] > Cc: [email protected]; Templin, Fred L; [email protected] > Subject: RE: [BEHAVE] [Softwires] Some Thought about the > AutomaticTunnelAddress > > 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
