[LAC-TF] Re: POLL: SPs' IPv6 (tunnel) deployment requirements

JORDI PALET MARTINEZ jordi.palet at consulintel.es
Tue Nov 2 15:16:54 BRST 2004

Hi all,

Please see the email below sent from the v6ops IETF WG co-chair asking for
input from OPERATORS. If you're an operator, please, read and provide your
inputs (reply directly to pekkas at netcore.fi), as he will summarize.

This is extremely important, because will drive the way the standards may
take, and consequently how you will actually be able to deploy IPv6 in your
network in the future, if not already doing so.

Thanks in advance for your cooperation.


> ---------- Forwarded message ----------
> Date: Tue, 2 Nov 2004 12:59:00 +0200 (EET)
> From: Pekka Savola <pekkas at netcore.fi>
> To: nanog at nanog.org
> Subject: POLL: SPs' IPv6 (tunnel) deployment requirements
> Hi,
> (To avoid a lot of spamming on nanog, please send the replies to me off-list
> and I can summarize, or only to v6ops at ops.ietf.org if you think it deserves
> wider attention.)
> IPv6 Operations WG at IETF is considering requirements and scenarios for
> v6-in-[udp]v4 solutions, especially as would be deployed by ISPs.
> Unfortunately, there has been rather low amount of feedback from the
> operators, 
> and we'll need more to find solutions that are actually close to what the
> operators want.. so, I'm trying here.. Please respond within a week or so.
> A couple of questions (no need to answer to all if you don't want to):
> 1. have you yet made plans how to deploy IPv6 towards
>   (home) customers?
>   a/ If yes, have you planned to use (only) dual-stack?
>   b/ If yes, have you planned to use some form of tunneling?
>   c/ If yes, using both as appropriate?
> [[ The rest are relevant only with 1.b) or 1.c) ]]
> 2. are you currently using L2TP or some other infrastructure for
>    IPv4?
>   a/ Is that adaptable to IPv6 (e.g., by adding v6 support to PPP)?
>   b/ If yes, would it be a sufficient solution for your needs.  If
>      not, please elaborate?
> 3. in case L2TP is not done towards v4 customers now, have you
>    planned or would you be interested in deploying v6 tunneling
>    towards customers?
>   a/ for free? (added value, competitional advantage, etc.)
>   b/ for a fee?
> 4. what would be your requirements for 3)?  Please elaborate a bit.
>   For example, are some (which ones?) of the following relevant:
>   - need to be used for own customers only
>   - authentication based on IP addresses or similar
>   - must it be capable to offer service to non-customers or roaming
>     own customers through some registration process?
>   - capability for doing prefix delegation to the customers
>   - must work through a NAT (e.g., non-upgraded CPE)
>   - should be possible to deploy multiple boxes easily
>   - should be capable of v4-in-v6 tunneling also
> 5. any other comments or questions?
>   - shoot!
> ...
> The two existing requirements documents, for two slightly different problem
> spaces (first for "easy set-up within your access network", the second
> "registered, more complicated mode for more extensive use"), are the
> following:
> http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.
> txt
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requir
> ements-01.txt
> For a lengthier document describing BB ISP IPv6 deployment options, see:
> http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenar
> ios-01.txt
> Feedback on these is also welcome, of course!
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

More information about the LACTF mailing list