Call for testers: RFC 5569 (6rd) support in stf(4)

[Hiroki Sato]

Doug Barton <dougb at freebsd.org> wrote
  in <4CA51544.9080103 at FreeBSD.org>:

do> In any case I didn't say that 6rd was not useful at all. What I tried
do> to make the case for is that its utility is limited, both in the
do> absolute sense and in the temporal sense; and that because of these
do> limitations the benefits that adding the code bring are outweighed by
do> the costs of maintaining it past what will likely be its useful
do> lifetime.
do>
do> My point about FreeBSD 9 is that if we add the 6rd code today, then
do> release 9.0 in about a year, then support the RELENG_9 branch for 4-6
do> years that we will still be maintaining code that no one has any use
do> for. Sorry if I wasn't clear.

 In my understanding the transition period from IPv4 to IPv6 will take
 a very very long time, not a year or two even if it happens
 eventually.  Migration techniques like 6rd which are applicable to
 subscriber access in large-scale ISPs are discussed and being adopted
 as their service just around these few years.

 Some may have some different ideas about the transition, but at least
 there is a fact that many ISPs think some kind of automatic IPv4-IPv6
 tunneling is useful for their IPv6 deployment and investigating its
 implementability.  I am not sure how much useful the 6rd will be in
 the near future in reality.  However, I believe it is something worth
 implementing because I am sure that market of v4/v6 dual-stack CPE is
 rapidly growing, it is possible 6rd becomes one of its key
 techniques, and the market is where embedded FreeBSD systems can be
 visible.

 So, if we fail implementing ones that people want in a timely manner,
 we will lose our seat as a good networking OS vendor.  I agree that
 introducing additional complexity is not a good thing, but most of
 the techniques including 6rd can be implemented by using the existing
 code with small changes because after all they are ones to solve
 operational/administrative issues by some specific combinations of
 the basic IPv6 functionality.

 This is my thought in general.  If you have specific comments on the
 implementation which may lead to unacceptable maintenance cost or
 something bad, please let me know.

do> In contrast, the bit of my post that you snipped suggested that a
do> better course of action would be to focus on the areas of our v6 stack
do> that will be used for the lifetime of the protocol, like the
do> performance penalty that currently exists for the v6 loopback device.

 There is no trade-off between improving robustness/performance of the
 basic functionality and adding a new protocol in this case.  The
 negative impact of adding 6rd is quite small if any, and we have
 nothing to lose even if 6rd will be useless some day.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20101001/c1246189/attachment.pgp