Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt

[Marc Blanchet <Marc.Blanchet@hexago.com>]

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>