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

From: <[email-masked]>
Date: Tue, 10 Feb 2004 10:26:07 +0100

See comments inline. 

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

Agreed, I will try to clarify. 

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

I think this is partially mentioned in 5.5 although nothing is mentioned
about filtering of traffic going to the customer.

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

Might be a good idea, we will look into this. 

/Mikael

---

From: Ronald van der Pol <[email-masked]>
Date: Tue, 10 Feb 2004 11:12:40 +0100

> about filtering of traffic going to the customer.

I was thinking about news, streaming, etc servers that are available
to customers only. This might be implemened with ACLs, giving access
only to traffic with source prefixes belonging to customers. If IPv6
has "allow all" default (e.g. no ACLs), anyone can reach these services
via IPv6 transport. Maybe this could be generalized with a recommendation:
"each IPv4 ACL should probably have its corresponding IPv6 ACL". The
difficult part is to keep both ACLs consistent :-)

	rvdp

---

From: Tim Chown <[email-masked]>
Date: Tue, 10 Feb 2004 10:20:36 +0000

> difficult part is to keep both ACLs consistent :-)

This is another one of those generic-to-all-four-scenarios things that
should probably instead be covered in Pekka's firewalling draft?

tim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 10 Feb 2004 13:54:21 +0200 (EET)

> should probably instead be covered in Pekka's firewalling draft?

It doesn't hurt mentioning it here, but I guess adding it to something
like draft-savola-v6ops-security-overview-00.txt might be appropriate
(the firewalling document might be slightly wrong place for this).

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