[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-v6ops-assisted-tunneling-requirements-01
-- 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