Subject: Re: Comments on draft-ietf-v6ops-assisted-tunneling-requirements-01

From: Florent Parent <[email-masked]>
Date: Mon, 08 Nov 2004 13:25:43 -0500

-- On Monday, November 08, 2004 00:31:17 +0000, Tim Chown wrote:

> Hi,
>
> Commenst on this draft are less numerous.   I think it reads better, and
> is much more nicely focused.
>
> The open question seems to be the relationship between this and ZCT, esp.
> since this has identical chunks of text in places to ZCT :)
>
>
>                 Goals for Registered Assisted Tunneling
>           draft-ietf-v6ops-assisted-tunneling-requirements-01
>
>
>>> There is a lot of overlap with ZCT; should these documents be
>    merged and authentication/TSP be made an extra requirement?
>    i.e. should we have one solution that has authentication/TSP
>    options, or two separate solutions?  (Or does that not matter?)
>    We should also be clear about the applicability to nodes and/or
>    networks by ZCT and this work.
>
>>> (there is a fair amount of text in here cut and pasted from ZCT)

Yes, there is. What happened is that we decided to move the non-registered 
assisted tunneling into the new "generic" zero-conf draft. Overlap is 
difficult to avoid.

>
> 1.  Goal and Scope of the Document
>
>
>    "Assisted tunneling" is used in this document to describe a
>    transition mechanism where the parameters to configure a
>    bi-directional tunnel between an end-node (or leaf network) and a
>    router in the core of an ISP are exchanged through a tunnel set-up
>    protocol.  Although this exchange can be automated, this remains
>    different from transition mechanisms like 6to4, Teredo or ISATAP.  In
>    particular, assisted tunneling enables explicit access control to the
>    tunneled IPv6 connectivity, where the other transion mechanisms have
>    to rely on other kinds of control (e.g., access control based on the
>    IPv4 address).  Also, assisted tunneling protocol negotiate the
>    tunnel parameters and does not depend on having the IPv4 address
>    inside the IPv6 address, for example.
>
>>> It should be clearer what the difference between this draft and the
>    ZCT draft is.  From the intro text, it seems to be the use of a
>    tunnel setup protocol, and thus the possibility of authentication
>    of users.

The basic difference is authentication prior establishing the tunnel. Will 
add that in this section.

>
>>> As per ZCT, does this draft apply to nodes or networks too?

yes.

>
>
> 2.  Applicability
>
>    o  The customer configuration may be diverse, and not necessarily
>       predictable by the ISP.  The protocol must be able to adapt to the
>       following cases, for example by choosing the most optimal tunnel
>       encapsulation depending on the presence of a NAT.
>
>       *  a single node,
>       *  a leaf network,
>       *  using a globally routable IPv4 address,
>       *  behind a NAT (customer or ISP owned),
>       *  using dynamic IPv4 address (internally or externally to the
>          NAT)
>
>>> So it is nodes and networks.  I think that's good for assisted
>    tunnelling, but ZCT should probably be nodes only?   Is this a
>    distinction to draw (assuming we keep the texts separate)?

ZCT as support for prefix delegation too. As stated above, the difference 
is really authentication.

>
>>> The NAT and dynamic IPv4 address support should be requirements?

Yes. Do you think they should not?

>
>    There are actually two cases where the IPv4 address of the customer
>    tunnel end point can be dynamic, and both must be supported:
>
>    o  The device used as tunnel end point is using a dynamic IPv4
>       address provided by the ISP.
>
>    o  The device used as tunnel end point is located behind a customer
>       owned NAT box that is also acting as a local DHCP server.  In that
>       case, the device IPv4 address may change after a reboot.
>
>>> This text is copied from the ZCT draft... how much else is copied?
>    (Just curious)

Actually copied from assisted-tunneling. Again, overlap is hard to avoid.

>
>    In the enterprise scenario [I-D.ietf-v6ops-ent-analysis], assisted
>    tunneling can be used to support remote users connecting to the
>    enterprise network (section 7.5.2).
>
>>> Or to connect IPv6 islands inside the network?  (I'm not convinced
>    it should be, but it could be)

Good point. Will add.

>
> 3.  Requirements for Simplicity
>
>    This protocol is a transition mechanism, thus does not need to be
>    perfect.  As a matter of fact, making it perfect would be counter
>    productive, at it would first delay its definition, then make its
>    deployment more cumbersome and, last but not least, diminish the
>    incentives to deploy native IPv6.
>
>>> I think this paragraph should be deleted.

Ok. Anyone object?

>
> 4.  Protocol Requirements
>
>    o  stay in touch with users
>
>>> And per-user accounting? (and users might like to see their v6 usage
>>>
>    too?)

already mentionned in 4.8 (accounting)

>
> 4.4  Confidentiality
>
>    Protecting the tunneled data (IPv6 in this case) should be possible.
>    A possible usage scenario is when an enterprise's users is working
>    off-site and tunneling to the enterprise network (7.5.2
>    [I-D.ietf-v6ops-ent-analysis]).  Mechanisms do exist to make this
>    possible, such as using IPsec over IPv6 [RFC2401].
>    [I-D.tschofenig-v6ops-secure-tunnels] may be applicable here but is
>    not analysed further.
>
>>> Users may also VPN home with v4 and then tunnel; this kind of
>    approach is being used (e.g. with OpenVPN).   It's an interesting
>    question as to which approach is "better".

If you have a v4 VPN, a zero-conf approach can also be used.

>
> 4.5  Service Discovery
>
>    In order to facilitate deployment, the implementation should allow a
>    mechanism to discover the address of the server that will provide the
>    tunnel connectivity.
>
>    This discovery should be automatic when the protocol is used within
>    an ISP network.  There is no service discovery requirements when used
>    outside the provider network (roaming users, 3rd party ISP).
>
>>> But if I'm at the IETF, outside my university/ISP network, I really do
>    want to discover a tunnel end point automatically...?

Yes, which is why its written "no service discovery requirements when used 
outside the provider network".

>
>    Tunnel end-point discovery mechanism work
>    ([I-D.palet-v6ops-tun-auto-disc] may be applicable here.
>
>>> You mean "is" not "may be"?

ok.

>
> 4.6  NAT Traversal
>
>    NAT traversal is identified as a requirement in ISP scenarios
>    (section 5.1 [I-D.ietf-v6ops-isp-scenarios-analysis]) and unmanaged
>    scanarios (section 7, Recommendation 1 [RFC3904])
>
> 4.7  Firewall Traversal
>
>    Even if no NAT is in the tunnel path, there may be a firewall which
>    prohibits IP protocol 41.  In such case, the tunnel encapsulation
>    selection based on NAT detection (Section 5.2) will select a tunnel
>    that will not work.
>
>>> Another example of text cut and pasted from ZCT...
>
> 5.7  Extensibility
>
>    The protocol must be extensible to support tunnel encapsulation other
>    than IPv6 over IPv4 and IPv6 over transport over IPv4.  In
>    particular, encapsulation of IPv4 over IPv6 (section 7
>    [I-D.ietf-v6ops-isp-scenarios-analysis], section 7 [RFC3904], section
>    6 [I-D.ietf-v6ops-ent-analysis]) or IPv6 over IPv6 could be defined.
>
>>> The "must" is strong, but I would agree with it, if we want a
>    single mechanism to be applicable in the longer term.  But this is
>    likely to be contentious... :)

Ok. This can be moved to a should. But I would like to have other feedback

>
> 6.  Compatibility with other Transition Mechanisms
>
>    The tunnel set-up protocol is not required to be compatible with any
>    existing transition mechanism.  Although, a great deal of experience
>    can be drawn from the operation of tunnel brokers currently using the
>    TSP protocol [I-D.blanchet-v6ops-tunnelbroker-tsp].
>
>>> But are various TSPs compatible / interoperable with each other?

"various TSPs" = independent implementations?

Thanks Tim.

Florent

---

From: Tim Chown <[email-masked]>
Date: Mon, 8 Nov 2004 18:32:40 +0000

Hi Florent,

A couple of comments on comments.

> >>>As per ZCT, does this draft apply to nodes or networks too?

OK, I was just wondering if we wanted a quite lightweight solution whether
is should apply to nodes and/or networks.  If there is a distinction, then
it seems your work should handle both, while (the lighterweight) ZCT does 
nodes only.  But if we do end up with some (re)merger the generic solution 
should handle both.

> Yes. Do you think they should not?

I think they are certainly desirable :)   In ZCT, not so sure (since ZCT is
an intra-provider requirement, it seems).
 
> outside the provider network".

I guess I read it differently... as a user I would like automatic discovery
wherever I am; I think you are writing from the provider perspective?
 
> "various TSPs" = independent implementations?

How many TSP implementations are there? :)

Tim

---

From: Florent Parent <[email-masked]>
Date: Tue, 09 Nov 2004 17:44:44 -0500

-- On Monday, November 08, 2004 18:32:40 +0000, Tim Chown wrote:

>> Yes, which is why its written "no service discovery requirements when
>> used  outside the provider network".
>
> I guess I read it differently... as a user I would like automatic
> discovery wherever I am; I think you are writing from the provider
> perspective?

Should we remove this paragraph and let the scope of the discovery be 
worked out in another document (tun-auto-disc)?

This would then read:

4.5  Service Discovery

   Tunnel end-point discovery mechanism work
   ([I-D.palet-v6ops-tun-auto-disc] is applicable here.

Comments?

Florent