Re: One socket per AF (Was: 6to4 using ::FFFF:0000:0000/96...)

[Rémi Després <remi.despres@free.fr>]

Thanks for the detailed answer.
My comments are in line.

Kevin Day a écrit :
> On Jan 28, 2008, at 9:44 AM, Rémi Després wrote:
>
> > Jeroen Massar wrote :
> > > But using it on the wire or when presenting it to users is definitely 
> > > not.
> > Why ???
>
> The problem with presenting v4 mapped/compatibility addresses on the 
> wire is that the behavior of such packets has been left undefined so far.

> * How these packets should be routed is completely undefined.

I agree that there is some blank here.
However If a route is configured, with the 0::/64 prefix, to reach 
NATv6-v4 boxes, the longest prefix match will do what is expected.
Any other assumption would require some extra code.

> Should 
> routers handle them as though they were normal v6 unicast addresses? Or 
> should they look at the v4 address and route them the same way as though 
> it were v4?
NO.
> What about "special" v4 addresses (127.0.0.1, multicast, 
> etc)? From my very limited testing, it looks like Juniper routers drop 
> them, even if you add specific routes within the /96s for them. Our very 
IPv4 multicast destinations will have, and must have, the same fate in 
NATv4-v4s.

> * There seems to be no behavior for 6to4, Teredo or tunnel brokers to do 
> that results in anything working when receiving packets destined 
> to/sourced from these addresses.
Hosts considered here are assumed to be pure IPv6, and to be in sites 
where NATv6-v4 is available.

Boxes that do the NATv6-v4 may also have other means to tunnel IPv6 in 
IPv4.
There is no conflict because these other means act when destinations are 
IPv6, not IPv4-only.

> * There are profound security implications of allowing v4 
> mapped/compatibility addresses into your network. I'm not aware of any 
> firewall or security device that will handle v4 mapped/compatibility 
> addressed v6 packets, while still handling any of the behaviors 
> considered for v4. One example brought up on one of the FreeBSD mailing 
> lists long ago, before "net.inet6.ip6.v6only" got defaulted to "1" 
> (essentially turning off v4 compatibility address use) was something like:
>
> # Add a firewall rule keeping everyone out of my telnet server. All 
> packets from anywhere to 1.2.3.4 to port 23 are dropped.
> ipfw add drop tcp from any to 1.2.3.4 23
>
> Now, even if this host has no v6 configured beyond an auto-configured 
> link-local address, it was possible to "telnet ::FFFF:0102:0304" from 
> somewhere else on the LAN and bypass the firewall.
I am not sure I see the configuration.
But the NATv6-v4 I discuss being only for outgoing connections, it seems 
guaranteed that it cannot not create a new hole for incoming connections.

> Since then changes 
> were made to prevent this sort of thing in the simplest of cases (v4 
> compatibility addresses off by default, not accepting them over the wire 
> at any time, etc).
>
> While that's a really simplistic example, it shows that allowing these 
> packets on the wire adds an attack vector that wouldn't be considered by 
> most. Its giving attackers three different ways of expressing the same 
> address(v4 native, mapped, and compatibility) which doesn't take much 
> imagination to see being exploited.
The mapped address is only to express the public address of IPv4-only 
hosts where native such addresses cannot be used (in IPv6-only 
applications and at IPv6 link interfaces of IPv6-only hosts).
It is not one more way to do something already done.

> * There's no standard for how clients/servers should respond to these, 
> leading to breakage already. If you send a Linux server a packet to 
> ::FFFF:0102:0304 it responds back using its v4 stack with 1.2.3.4. 
> Windows uses its v6 stack, even when it probably doesn't make sense to 
> (through 6to4/Teredo tunnels). Mac OS X and the BSDs drop all packets in 
> ::FFFF:0:0/96 and ::/96 going in/out.
The case at hand is for an IPv6-only host reaching IPv4-only servers.
These servers will not see any mapped address.

> The only time I could ever see them being acceptable is on a link-local 
> scope, and only to/from your gateway for NAT-PT,
It would work as well in multi-subnet sites provided both IPv6 and IPv4 
are routed (and that the 0::/64 prefix is not artificially forbidden in 
intra-site routers).

> and only in the case 
> where you've got a v6-ONLY box that must talk to a v4 device.
This "only" case is IMHO worth dealing with.
It could very well become soon a practical case, when boxes that support 
NATv4-v4 also support NATv6-v4, a rather simple an extension (longer 
address support in NAT tables).
> Even then 
> though, it feels wrong. :)
I do hope you will soon feel differently, and even enthousiastic as I am 
about this simple solution to a real problem.

Thanks again for the discussion.

Rémi