[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
- To: IPv6 Operations <v6ops@ops.ietf.org>
- Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
- From: Brian E Carpenter <brc@zurich.ibm.com>
- Date: Wed, 28 Apr 2004 14:36:32 +0200
- In-reply-to: <200404211937.PAA10059@ietf.org>
- Organization: IBM
- References: <200404211937.PAA10059@ietf.org>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
http://www.ietf.org/internet-drafts/draft-palet-v6ops-auto-trans-00.txt
This is a very interesting concept, but I have some doubt about the goal
of spontaneously changing to a different mechanism without disruption.
I think it is over-ambitious. As pointed out in section 3.2, point 1,
this requires keeping the same address even if (for example) changing
from one tunnel provider to another - that's very unlikely to
work (unless of course we have a fully deployed multi6 solution
or use mobile IP exclusively). So I would be tempted to limit the scope
to choosing the best initial method.
One detail: Section 3.3.3 discusses "layer 4" tunnels but doesn't
list IPv6 over TLS/SSL - but that is a very real possibility (in fact
I use IPv4 over SSL very frequently, since it gets through certain NATs
that IPSEC over UDP cannot deal with). It looks like a better option
than IP over SSH to me, and certainly better than IP over HTTP.
I'm not sure that we should even list this class of solution
as discouraged. It should perhaps be lower on the list of
preferences, but whatever works is good.
Brian