Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt

[Erik Nordmark <Erik.Nordmark@sun.com>]

> In the current document, /64 prefix allocation is not mandatory.
> Our opinion as author was that the non-authenticated mode
> was meant to be used in a try-out environment only and
> connecting only one node was enough.
> In our opinion, any more than that would require authentication.
> But this is only one opinion, I would like to get more feedback on this 
> point:
> 
> Would ISP be willing to deploy IPv6 tunnel service in this 
> non-authenticated mode
> on production networks?

I can see this depending on what other authentication is taking place.
For instance, if e.g. Radius authentication occurs before the IPv4 address
is assigned to the customer, the tunnel setup protocols does return
routability check, and the ISP protects the routing of their addresses
(e.g. using route filters at their edges) then why doesn't the IPv4 address
provide sufficient proof (after the return routability check) that
the user is indeed the user that was authenticated using Radius?

So it might be that explicit authentication of the tunnel
setup is only needed when
1) there wasn't authentication for the IPv4 setup, or the tunnel
   server can't extract the user id from system based on the IPv4 address
2) the infrastructure between the tunnel server and the client isn't
   trusted (which might be an argument for using IPsec tunnels in
   addition to authenticating the tunnel setup).

Thus it is far clear for me that what you call unauthenticated setup is
that limited (it is "not explicitly authenticated" IMHO since there
might be IPv4-related authentication that can be reused).

One other minor comment on the document;
In section 2 it talks about "customer owned NAT".
I think the issue applies whether the NAT is customer or ISP owned and
controlled. Even for an ISP owned and controlled NAT the ISP might not want
to upgrade the NAT to be more friendly to IPv6 (e.g. by supporting tunneling
on the NAT itself) since that might be expensive.
Thus I think it makes sense to state that the NAT might belong to the customer
or the ISP in section 2.

   Erik