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

[Pekka Savola <pekkas@netcore.fi>]

Thanks for your feedback!

A few comments on your comments below.

Jordi, there is one comment on proto-41 forwardaring below which is
not IMHO clear -- could you check ?

On Fri, 27 Feb 2004, Marc Blanchet wrote:
> 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>

There have been a couple of comments to even expand this, so I think 
this is probably a good pointer to start with.. not something that 
can or should be fully discussed, through.

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

True, but the issue remains: [MECH] or MECH-v2 doesn't do UDP.

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

This is a point which I've tried to raise is that I think most 
protocol-41 forwarding implementations do automatically forward 
protocol-41 without any configuration -- just as they forward ICMP.

If setting up proto-41 forwarding requires manual set-up (as discussed 
in a few places in the proto-41 forwarding draft), then it certainly 
would not be an option.

Perhaps Jordi can clarify (and post an updated draft! :-)

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

Teredo server doesn't have to be near the customer, it can be anywhere 
at all -- I wouldn't expect any ISPs to deploy it, in the short term 
at least.  Suggested text?

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

Seems to make sense to say that explicitly.

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

I have to disagree with this -- STEP or TSP are not analyzed further 
in the document, at this point.  Of course, they might be in the 
future, and if so, the feature(s) of TSP would certainly be mentioned.

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

Similarly, at the moment, I think TSP/STEP/ISATAP/etc. -specific 
issues are out of scope.  This might change, based on this IETF 
though..

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

Same as above.

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

Likewise.

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

This has come through from a couple of operators.  They don't want to 
build tunnels etc. architecture because the difficult part about IPv6 
is considered to be the process/administrative issues, and it takes 
time to move from "hacks" to "real solutions" when the time comes -- 
so they're going to "real solutions" as the first step.  Of course, 
this could also be just an excuse :-).

6to4 relay can be used for two purposes:
 1) to optimize the return routing between the native IPv6 users in 
your network and 6to4 users [this example], and
 2) to optimize the use of 6to4 when your customers support it (this 
requires no support from the ISP, but offers the users better IPv6).  
This was not the main intent of the statement above, but comes in as a 
bonus.

Suggestions for clarification?

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

Right .. apparently these weren't added even though there is a 
reference in the text.  Add STEP as well.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings