Comments on draft-ietf-v6ops-assisted-tunneling-requirements-01

[Tim Chown <tjc@ecs.soton.ac.uk>]

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)

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.

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


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)?

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

   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)

   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)

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.

4.  Protocol Requirements

   o  stay in touch with users

>> And per-user accounting? (and users might like to see their v6 usage     
   too?)

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".

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...?

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

>> You mean "is" not "may be"?

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... :)

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?