netdev - Re: IPv4 header extension for IPv6 translation support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK617oTvCqu4DwAmDMOQBWxWRba7_C_Gn+qY_ajxMFkDg5P9_w@mail.gmail.com>
Date:	Wed, 29 Aug 2012 17:15:42 +0400
From:	Vlad Maraev <maraevvb@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	netdev@...r.kernel.org
Subject: Re: IPv4 header extension for IPv6 translation support

Dear Eric,

I'm glad to receive the detailed feedback from you.
But I can't agree with some of your arguments:

> You are going over territory that has been rather thoroughly explored
> already.
I know the territory but I don't see that the problems are solved. I
mean problems caused by NATs: scalability, complexity, connection
tracking, additional addresses for NAT device.

>   In fact it is more difficult
>   because ipv6 is present in most end devices today, it is the network
>   links that are the bottle-neck in rolling out ipv6.
The fact that the end devices are ready for IPv6 doesn't mean that ISP
customers will make transitions in a one period of time. That's why
NATs are needed and they are in use. Detailed motivations are stated
in RFC6144 ("why translation" section).

> For the best interoperatiblity the best transition strategy remains
> dual-stack.  With native ipv6 connectivity and some flavor of ipv4
> connectivity (native, dual-stack-lite, or 646xlate).
My solution doesn't compete with dual stack and ds-lite that is good
for creating overlaying network. I offer a strategy that is an
alternative to existing NAT solutions.

Thanks

Vlad


P.S.
I found that this problem that was stated in my proposal
> 1. Intermediate nodes can look below the Destination Address for the
> options if ihl>5 and will be confused with IPv4x data.
has a solution: we can use IPv4 option field for placing this data.
Intermediate nodes that know nothing about this option will skip it
and forward the packet.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html