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

From: Pekka Savola <[email-masked]>
Date: Fri, 6 Feb 2004 07:58:44 +0200 (EET)

Hi all,

This is a WG Last Call for comments on sending
draft-ietf-v6ops-isp-scenarios-analysis-01.txt, " Scenarios and
Analysis for Introducing IPv6 into ISP Networks" to the IESG for
consideration as BCP:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-isp-scenarios-analysis-01.txt

Please review these documents carefully, and send your feedback to the
list.  Please also indicate whether or not you believe that this document
is ready to go to the IESG.

There has been a lack of extensive reviews from the start, so 
reviewing this document would be especially welcome.

The last call will end in about 2.5 weeks, on 24th February.

Pekka & Jonne

---

From: Ronald van der Pol <[email-masked]>
Date: Mon, 9 Feb 2004 15:50:57 +0100

On Fri, Feb 06, 2004 at 07:58:44 +0200, Pekka Savola wrote:

> draft-ietf-v6ops-isp-scenarios-analysis-01.txt, ...

Overall, I think the document is "good enough". I have three minor
points.

Section 4.3.1 has this sentence in the fifth paragraph:
"Therefore, the use of same process is recommended especially for      
large ISPs intending to deploy, in the short-term, a fully dual-     
stack backbone infrastructure."
I needed to read it several times. I think it says: "when deploying
dual-stack in short-term, same process IS-IS is recommended." Maybe
the sentence could be rephrased slightly to make it easier to read.
Also, isn't same process IS-IS recommended in general because of
operational benefits? It is easier to manage one protocol and topology
than several. The need to run separate processes should be the exception.

In section 5.2 it might be useful to explicitly describe the situation
where a service is limited by ACLs to e.g. customers. When upgrading
this service to dual-stack, the corresponding IPv6 ACLs should be
added to avoid exposing the service worldwide. So, I am thinking
about prefix filtering and "allow all" defaults.

It would be useful to have a "recommendation" section which summarizes
the missing features, i.e. the items the IETF should work on. That's
the main purpose of this document, isn't it? I could only identify:
- STEP/TSP
- tunneling when dynamic IPv4 addresses are in use
- authenticating when the customer connection network is shared
- multi-homing

	rvdp

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 27 Feb 2004 01:27:46 -0500

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>

---

From: Pekka Savola <[email-masked]>
Date: Sun, 29 Feb 2004 23:30:58 +0200 (EET)

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 ?

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

> <MB>configured tunnels with tunnel brokers [TSP] is specified for

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

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

> in the architecture presented in section 2, as customer connection network.

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?

> s/are STEP and TSP , providing tunnels with or without the presence of NAT./

Seems to make sense to say that explicitly.

>    of the tunnel when the IPv4 address change.

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.

> access control if desired.

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

> TSP tunnel broker does prefix delegation in this context

Same as above.

> address and prefix delegated.</MB>

Likewise.

> of ways to provide ipv6 through the not-yet-upgraded-ipv4 network.

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?

> 	       work in progress, draft-blanchet-v6ops-tunnelbroker-tsp-00, feb 2004

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

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 29 Feb 2004 17:12:39 -0500

-- Sunday, February 29, 2004 23:30:58 +0200 Pekka Savola
<[email-masked]> wrote/a ecrit:

>>    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 don't understand here. Why 6to4 and Teredo are analysed and not TSP and
STEP?

> 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 

Marc.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 1 Mar 2004 00:25:43 +0200 (EET)

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

Because we don't want to repeat the same, generic arguments multiple 
times -- the same ones we're having with the unmanaged document.

Discussion should be added before the document is published though -- 
or we'll just publish a more generic document only.

6to4 and Teredo are a bit easier as there is no "competition".

> operators, I guess, different views.

Different operators certainly have different views -- these also 
extend to tunnel brokering.  Any infrastructure can be considered 
"bad".  Whether this is a real argument is different, of cours.e

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 1 Mar 2004 11:18:53 +0900

Hi Pekka,

I see your point.

As more routers I try, more I find when isn't needed to configure anything: Is forwarded the same way as ICMP or other protocols.

But of course, this depends on each manufacturer, and even it can change. I also find some where ICMP is disabled by default ;-)

I think this is clearly a generic configuration issue in any "network box". Even it may depend in who install the router. For example, some ISPs change the manufacturer's default configuration.

We will post an updated version most probably after this meeting, and will including a clarification on this.

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "Marc Blanchet" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, March 01, 2004 6:30 AM
Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt

> reference in the text.  Add STEP as well.

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.