[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Pekka,

thank you very much for the very detailed and very constructive comments.
responses in-line.

- Alain.

On May 4, 2004, at 5:32 AM, Pekka Savola wrote:

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.

I would say a) and b). b) for interoperability reasons. While deploying it, you turn on or off any features
you like or not.


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.

If the ISP deploy the 'registered' mode and it has not been implemented in the client,
it does not work. That's why I think all implementations would have to support both
and the operation mode wo¨ld be decided by the ISP.

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

This is again an operational decision that can be made only by the ISP.
This is why, IMHO, the protocol and its implementations should support both
modes.


   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.

Why not. is it an IESG policy?

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

really? ;-)


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, [...]

ok.

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

ok

......

   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)

ok

(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. [...]

ok

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

As it seems that there is a (weak) consensus to leave the non-registered mode,
I agree with your suggestion.



....

   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.

ok

....

   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.

ok

....

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


Not sure. I think the protocol and its implementation MUST
support the detection, but the deployment MAY turn it off.
i should clarify this.


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

I hadn't thought of that... Is it the case that if proto-41 forwarding is in place
then the communication would be un-differentiable from a non nated one?


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

nothing to do with mobility but with the charging method (i.e. by the minute?).
But I agree, more text is needed.

6.7 Traceability

==> this is not really traceability, reword; maybe like
"Provides Enough Information about Usage"

Is this not the definition of traceability?


....

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.

neither do I. Does anybody else have an opinion?


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

No, this is not enough. Example: I may have a local router on my ethernet link that advertises
an internal prefix, but this does not mean that I can use it to get external
connectivity and have to give up my modem line.


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.

Yes. This is the concern I have, ISP now offer native, but the box is still configured
to use the tunnel.



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


I never understand what goes where... What is you rationale?

- Alain.