[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt
good document and work. quoted text provided with comments in <MB> and with
suggested text when appropriate.
Marc.
----------------------
It is also outside the scope of this document to describe different
types of access or network technologies.
<MB>to be more precise, suggesting:
s/of access or network technologies/of layer1-2 access or network
technologies/.
</MB>
...
3.2.1 Stage 1 Scenarios: Launch
...
The immediate first step consists of getting a prefix allocation
(typically a /32) from the appropriate RIR according to allocation
procedures.
<MB>while clearly a good advice, not sure really useful to discuss here
given the objective of the document.</MB>
The selection of one candidate depends largely on the presence or
absence of NATs between the two tunnel end-points and whether the
user's IPv4 tunnel end-point address is static or dynamic. In most
cases, 6to4 and ISATAP are incompatible with NATs, and UDP
encapsulation for configured tunnels has not been specified.
<MB>configured tunnels with tunnel brokers [TSP] is specified for
NAT traversal.
</MB>
However, NAT traversal can be avoided if the NAT supports
forwarding protocol-41 [PROTO41].
<MB>s/protocol-41/protocol-41 and configured to do so./</MB>
The connectivity mechanisms can be categorized as "managed" or
"opportunistic." The former consist of native service or a
configured tunnel (with or without a tunnel broker); the latter
include 6to4 and, e.g., Teredo; they provide "short-cuts" between
nodes using the same mechanisms and are available without contracts
with the ISP.
<MB>Teredo needs a Teredo server located outside of the NAT, which means
in the architecture presented in section 2, as customer connection network.
</MB>
Most interesting are the managed services. When dual-stack is not an
option, a form of tunneling must be used. When configured tunneling
is not an option (e.g., due to dynamic IPv4 addressing), some form of
automation has to be used. The options are basically either to deploy
an L2TP architecture (whereby the customers would run L2TP clients
and PPP over it to initiate IPv6 sessions) or to deploy a tunnel
configuration service. The prime candidates for tunnel configuration
are STEP [STEP] and TSP [TSP], which are not analyzed further in this
document.
<MB>would also add that these services are able to do NAT traversal.
Suggesting:
s/are STEP and TSP , providing tunnels with or without the presence of NAT./
</MB>
Note that when customers use dynamic IPv4 addresses, the
tunneling techniques may be more difficult to deploy at the ISP's
end, especially if a protocol including authentication (like PPP for
IPv6) is not used. This may need to be considered in more detail
with tunneling mechanisms.
<MB>disagree for TSP. TSP re-establish the tunnel automatically in the
event of a change of IPv4 address
Suggesting replacing text:
Note that when customers use dynamic IPv4 addresses, manually configured
tunneling techniques may be more difficult to deploy at the ISP's
end, especially if a protocol including authentication (like PPP for
IPv6) is not used. However, [TSP] does support automatic re-establishment
of the tunnel when the IPv4 address change.
</MB>
5.2 Access Control Requirements
When a provider does not wish to give its IPv4 customers
automatic access to IPv6 services, specific IPv6 access control must
be performed in parallel with the IPv4 access control. This does not
imply that different user authentication must be performed for IPv6,
but merely that the authentication process may lead to different
results for IPv4 and IPv6 access.
<MB>to add:
The [TSP] tunnel broker provides the AAA capabilities to manage this
access control if desired.
</MB>
Note that when the customer connection network is shared between the
users or the ISPs, and not just a point-to-point link, authenticating
the configuration of the parameters (esp. prefix delegation) requires
further study.
<MB>TSP does it. to add:
TSP tunnel broker does prefix delegation in this context
</MB>
This can be done, for example, by mapping a DHCP response to a
physical connection and storing this in a database. It can also be
done by assigning a static address or prefix to the customer.
<MB>to add: TSP Tunnel broker provides this binding between user and
address and prefix delegated.</MB>
8.1 Example 1
Customers (with some exceptions) are not connected using a tunnel
broker, because offering native service faster is considered more
important -- and then there will not be unnecessary parallel
infrastructures to tear down later on. However, a 6to4 relay is
provided in the meantime for optimized 6to4 connectivity.
<MB>don't understand that argument. if "offering native service faster
is considered more important, then why care about 6to4 at all?
6to4 relay should be considered similar to tunnel broker in terms
of ways to provide ipv6 through the not-yet-upgraded-ipv4 network.
</MB>
[V6SEC] P. Savola, "IPv6 Transition/Co-existence Security
Considerations"
Work in progress
<MB> adding tsp as reference
[TSP] M. Blanchet, "IPv6 Tunnel broker with Tunnel Setup
Protocol(TSP)",
work in progress, draft-blanchet-v6ops-tunnelbroker-tsp-00, feb 2004
</MB>
------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------