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

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

-- Sunday, February 29, 2004 23:30:58 +0200 Pekka Savola
<pekkas@netcore.fi> wrote/a ecrit:

> Thanks for your feedback!
> 
> A few comments on your comments below.
> 
> 
>>    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.

I don't understand here. Why 6to4 and Teredo are analysed and not TSP and
STEP?

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

- agree if large number of manually configured tunnels.
- disagree if tunnels are managed by tunnel brokers. We have many operators
as customers who are using tunnel broker at this moment. Different
operators, I guess, different views.

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

Marc.