[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
My own personal comments are below.
On Fri, 30 Apr 2004, Pekka Savola wrote:
> The intent is to WG last call it after having been published as WG
> item, and reach WG consensus on the requirements within a month.
(The document uses the word "authenticated" which is inaccurate,
but that was already to be changed to "registered", so I don't
mention it again.)
substantial
-----------
The
tunnel set-up protocol must support both modes, however ISP deploying
it may choose to only support one mode of operation.
==> this should be probably be its own paragraph, but a more important
issue: is this a requirement for a) the protocol, or for b) the
implementation of the protocol, or c) its deployment?
It looks like a) and c) but I could be wrong.
My argument is that IMHO the simple mode should be a must for implement, the
registered mode a should; and whatever the operators do is up to them, but
we could recommend them to not turn off the simple mode to keep it
interoperable.
....
5.1. Address and Prefix Delegation
The authenticated mode must support delegation of a single address or
a whole prefix or a combination of both.
==> again, I've said this in the past, but IMHO prefix + address is not
interesting. This is definitely not a must or even a should, IMHO -- and
should be scrapped entirely. I assume the address would be assigned on the
point-to-point address (and such address is not even needed at all!).
...
note: not clear what should be the mandatory authentication method.
Clear text password is out. Digest-MD5 [2831] seems like a good
choice.
==> I don't have a strong opinion either, but Digest-MD5 is not acceptable
-- MD5 must not be used for new protocols due to its collision weakness.
Use SHA1 instead.
6.1 Scalability
The tunnel set-up protocol must be scalable.
==> We need a few more words than that to flesh out this requirement, I
think ;-)
semi-editorial/substantial
--------------------------
"Assisted tunneling" is used in this document to described 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 negotiated through a tunnel set-up
protocol. Although this negotiation phase can be automated, this
remains different from transition mechanisms like 6to4 that is fully
automatic or teredo/isatap which, once the IPv4 address of an initial
server/router is configured do not involve any further negotiation
phase.
==> first, it may be inaccurate to talk about "negotiation", as you don't
_need_ to negotiate at all (any more than you need to negotiate with Teredo or
ISATAP). The more controlled means may allow that, but it should not be
needed; therefore, I'd reword "negotiate" here, for example to like:
"Assisted tunneling" is used in this document to described 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, [...]
==> I still think this is slightly inaccurate. Teredo and ISATAP both
(practically) require more than configuring the v4 address of server/router:
they have to listen to the router advertisement from the server/router as
well. So, it's one round-trip instead of zero round-trips.
Maybe reword to:
Although this exchange can be automated, this
remains different from a transition mechanism like 6to4 that is fully
automatic. Teredo and ISATAP, on the other hand, practically require
receiving information about the available prefix or address from the
server/router, comparable to the most simple form of assisted
tunneling.
......
In particular, the 'authenticated' mode defined in section 5
enable access control to the IPv6 network where the other transion
mechanism have to rely on out of band access control.
==> this has two typos (in enable "enable" and "mechanism), but this seems
slightly inaccurate and could be reworded to be like:
In particular, the 'registered' mode defined in section 5
enables explicit access control to the tunneled IPv6 connectivity,
where other transition mechanisms have to rely on other kinds of control
(e.g., access control based on the IPv4 address).
(but I'm not sure if that's 100% accurate either as e.g. Teredo includes
this authentication/origin data which can be used to restrict access to the
Teredo servers.)
...
The tunnel established is "anonymous", the end-user does not provide
any authentication to the server.
==> this probably should be reworded a bit, to like:
The tunnel established is "anonymous" in a sense as the end-user does
not register explicitly to the server. [...]
(note that the user could provide e.g. a hash which could be mirrored by the
server to give a proof of a kind -- the point is that the word
"authentication" seems too ambiguous here.)
4.1. Address Allocation
This mode is used to provide IPv6 connectivity to a single host.
Allocation of an IPv6 address (/128) to the end-node must be
supported in this mode. This IPv6 address is "transient" and may
change, but one may implement a mechanism to provide IPv6 address
stability in this mode (e.g. cookie mechanism).
==> s/Allocation/Assignment/ (same later, also in section 6.9)
==> I see no reason to rule out sites from this, but we should not _require_
that from the protocol. In other words, reword to:
This mode is used to provide IPv6 connectivity to either a single host
or a network.
Assignment of an IPv6 address (/128) to the end-node must be
supported in this mode. This IPv6 address is "transient" and may
change, but one may implement a mechanism to provide IPv6 address
stability in this mode (e.g. cookie mechanism).
Assignment of an IPv6 prefix (e.g., /64 or /48) may be supported if
feasible.
....
The un-authenticated mode relies on out of band authentication. It
essentially offer the IPv6 service to any of its IPv4 customers.
==> s/un-authentication/non-registered/
==> "out of band authentication" is not clear: this refers to the
out-of-band with respect to IPv6 tunnel set-up session, but may be in-band
with respect to the IP connectivity; so reword:
The non-registered mode does not require explicit authentication of the
user. Access control may be performed using e.g., IPv4 address.
The mode essentially offers the IPv6 service to any of ISP's IPv4
customers.
....
In this mode, IPv4 return routability checks in the set-up phase of
the tunnels seems to be a way to avoid some of these problems at the
price of an extra round trip.
==> maybe add here:
As the threat is specific to the
ISP's ingress filtering deployment, the ISP should be able to specify
whether such a check needs to be performed.
....
However, as
NAT traversal usually requires an extra layer of encapsulation, the
tunnel set-up protocol must be able to detect automatically the
presence of one or more NAT boxes in the path.
==> s/must/should/ (this is what 4.3 and 5.3 have at least, and IMHO a
should is sensible.)
==> do we want to test for the presence of a proto-41 forwarding NAT box?
That would likely be complicated (would require extra transmission of
proto-41 packets)? If we put that in, it's a "may" at most.
6.5 Latency in Set-up Phases
In certain type of networks, keeping tunnels active all the time is
not possible or simply too expensive.
==> maybe spell out an example here or later in this section, like:
not possible (e.g., when the host is mobile) ....
6.7 Traceability
==> this is not really traceability, reword; maybe like
"Provides Enough Information about Usage"
....
Once IPv6 is available natively in the access network
connecting a customer, there is no reason to keep using tunnels. So
the tunnel-setup protocol must have a provision to enable the ISP to
signal the user to use native IPv6 instead.
==> I'd reword this "must" to a "should", but I don't feel too strongly
about this either way.
==> actually, this should probably be reworded as it's ambiguous.
Obviously, if the user sees a route advertisement on the native link (or the
like), that should be used instead. But is it the ISP's business to "stop"
the user to start using native v6 instead (if it doesn't work
automatically)? At most, the mechanism should provide a means to show the
user a message that ISP is also providing native v6 service (possible e.g.
if the user switched to new service class, or replaced the NAT box)
even though the user is not obtaining it at the moment.
[3053] A. Durand, P. Fasano, I. Guardini, D. Lento.,
"IPv6 Tunnel Broker", January 2001.
[ISP] Lind, M., "Scenarios and Analysis for Introducing IPv6
into ISP Networks",
draft-ietf-v6ops-isp-scenarios-analysis-01 (work in
progress), February 2004.
[UNMANAGED] Huitema, C., "Evaluation of Transition Mechanisms for
Unmanaged Networks", draft-ietf-v6ops-unmaneval-01 (work
in progress), February 2004.
==> these probably belong ot the normative references section.
editorial
---------
In an ISP network where IPv4 is dominant, some of the initial IPv6
deployment phases consists of getting a prefix allocation from the
RIR, and peering with other IPv6 ISP (or exchange points).
==> probably out of scope and could be removed?
- assisted tunneling infrastructure to early adopters,
- native IPv6 to customers where economically justified,
- native IPv6 to all customers.
==> s/-/1)/, s/-/2)/, etc?
Note that, as the addressing space used during the transition to
native remains the same the customer routing, filtering, accounting
[ISP, section 5.] stay the same, and there is no need to maintain any
kind of relay.
==> s/same the customer/same, the customers'/ ?
"Assisted tunneling" is used in this document to described a
==> s/described/describe/
This document analyze the requirements for such a tunnel set-up
==> s/analyze/analyzes/
- 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.
==> s/device/device's/
==> note that such behaviour is non-compliant with DHCP specs, but this is
not a hot issue for me.
This may be regarded as a feature, but deployment of the service with
this mode enable must be done carefully. In particular, security
==> s/enable// ?
connectivity, transforming effectively the ISP into a IPv6 transit
==> s/a/an/
authentication method must be supported. Other authentication MAY be
==> s/MAY/may/
As in sectoin 4.4, IPv4 return routability checks could help blocking
==> s/sectoin/section/
6.2 Service discovery requirements
==> s/discovery requirements/Discovery Requirements/ (same elsewhere where
applicable)
set-up protocol must be able to abort immediately and display the
customers a message explaining that no service is available.
==> s/customers//
A client MAY choose not to send those messages (for example on ISDN
==> s/MAY/may/
==> (actually, I'd recommend also starting a new paragraph from "A client
..."
There is a large number of Teredo clients already deployed, the
==> s/is/are/
==> s/,/, and/
should be manage on the client side instead of the server side, that
==> s/manage/managed/
Similar considerations as Teredo, section 7.2, applies to Isatap.
==> s/Isatap/ISATAP/
technology, where traffic can be redirected to go from one place to
another one.
==> s/another one/another/
9. Author Addresses
==> s/Author/Authors'/
11. Non Normative References
==> s/Non Normative/Informative/
[2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
==> not used and can be removed.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings