Subject: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna - 2nd version

From: Bob Fink <[email-masked]>
Date: Wed, 09 Jul 2003 07:23:27 -0700

IPv6 Operations WG (v6ops)
IETF-57, Vienna

Tuesday, July 15 at 1545-1800
Wednesday, July 16 at 1530-1730

================================

CHAIRS: Bob Fink <[email-masked]>
         Pekka Savola <[email-masked]>
         Margaret Wasserman <[email-masked]>

First Session:  Tuesday, July 15, 2003 at 1545-1800
===================================================
Introduction and agenda bashing - 5 mins, Margaret Wasserman

===
current status - 5 mins, Margaret/Pekka
<http://www.6bone.net/v6ops/v6ops_project-status.html>

===
UNMAN Analysis discussion - 25 mins, Christian Huitema
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-00.txt>

===
Forwarding Protocol 41 in NAT Boxes - 10 mins, Jordi Palet
<http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-00.txt>

===
IPv6-IPv4 Translators in 3GPP Networks - 10 mins, Karim El-Malki
<http://www.ietf.org/internet-drafts/draft-elmalki-v6ops-3gpp-translator-00.txt>

===
ISP Scenarios - 40 mins, Mikael Lind
<http://www.ietf.org/internet-drafts/draft-lind-v6ops-isp-scenarios-00.txt>

===
ENT Scenarios - 40 mins, Yanick Pouffary/Jim Bound
<http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-03.txt>

Second Session:  Wednesday, July 16, 2003 at 1530-1730
======================================================
v6-on-by-default - 25 mins, Alain Durand
5-10 mins presentation, remainder discussion
<http://www.ietf.org/internet-drafts/draft-roy-v6ops-v6onbydefault-01.txt>

===
threedegrees - 10 mins, Christian Huitema
<http://threedegrees.com/>

===
Security - discussion of what we should be doing - 45 mins, Chairs
<http://www.ietf.org/internet-drafts/draft-savola-v6ops-security-overview-00.txt>

===
NAT-PT Applicability Statement team report - 15 mins, Peter Barany
<no draft yet>

===
Writing IPv6 Applications report - 15 mins, Myung-ki Shin & Pekka Savola
<http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transition-01.txt>

===
Status report of IPv4 Survey drafts - 10 mins, Chairs
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-01.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-01.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-01.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-int-01.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-01.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-subip-01.txt>
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-01.txt>

-end

---

From: Alain Durand <[email-masked]>
Date: Fri, 11 Jul 2003 09:59:47 -0700

I would like to say that this -03 is in a much better shape than any of 
the previous version,
I think we are now on a much better track, and I would recommend to 
adopt it
as a working group item.

Detailed comments:
Section 3.1, network scenario: what is scenario 2? is it a typo or is 
scenario 2 missing?

Section 4 does not tell us anything new, and is actually part of the 
solution space,
not the scenario space.

Section 5 is actually redundant with section 3.2, network scenario 
characteristics.
If one of the scenario 1, (2?) and 3 say you need to map 1 to 1 the 
characteristics,
then section 6 is useless. If the scenario says some characteristics do 
not necessarily
need an equivalent in v6, section 6 may gets in the way.

In fact, I believe I would be happy with this document as it is with 
only section
1, 2, 3, 6 and up, deleting section 4 & 5.

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Fri, 11 Jul 2003 10:23:37 -0700

I'm a little confused by the direction this effort is taking...
Basically this document is telling us that ISP can start deploying
IPv6 at their core or at their edges or both at the same time.

I guess we all knew that for a long time...
Are future revision of this document going to address the pros and cons
of both approaches? Are we expecting a companion document that
will explain how to implement both approaches?

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Fri, 11 Jul 2003 10:39:01 -0700

Proto 41 redirection as explain in this document cannot be demultiplex
and only works for the same number of tunnels as the number of external
IPv4 addresses.
So, if there is only one external IPv4 address, only one tunnel can be 
set up.
Also, this obviously does not work very well in case of doubled-nated 
network.
(I just happen to sit on one right now)

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Fri, 11 Jul 2003 11:03:47 -0700

In case A, the extra cost in bandwidth in the tunnel broker solution 
versus Teredo
is due to the triangular routing induced by the tunnel server.
If the tunnel server is located within the ISP network, this overhead 
is almost zero.

So, I think the section 2.1.4 should recommend the deployment of
tunnel server within ISP as a first step for those ISP who'd like to 
offer IPv6 service
with minimal investment.

Also, I think that the comparison in terms of complexity is a little 
unfair.
The bubble mechanism is complex, and the tunnel broker solution
does not have to be made fully automatic. The real difference is then
that communications initiated by the outside prior to the tunnel 
establishment
will not work.

	- Alain.

---

From: Tim Chown <[email-masked]>
Date: Sat, 12 Jul 2003 21:38:21 +0100

But it's ideal for a home network.  Our students in residential DSL homes
use it for example.

Tim

---

From: "Jeroen Massar" <[email-masked]>
Date: Sat, 12 Jul 2003 23:13:40 +0200

Tim Chown wrote:

> But it's ideal for a home network.  Our students in 
> residential DSL homes use it for example.

I think the majority of 6bone connectivity is proto41 tunnels.

> > and only works for the same number of tunnels as the number 
> > of external IPv4 addresses.
> > So, if there is only one external IPv4 address, only one 
> > tunnel can be set up.
> > Also, this obviously does not work very well in case of 
> > doubled-nated network.

Then you might want to redirect it twice ;)
The other solution is digging vpn tunnels...

Greets,
 Jeroen

---

From: Carlos Friacas <[email-masked]>
Date: Mon, 14 Jul 2003 11:09:53 +0100 (WEST)

Hello All,

I have some questions:

[1, Introduction]

+ "routers or tunnel servers" ~= "tunnel brokers" ?

  "(...) with a manual configuration at the IPv6 router tunnel-end."
  It isnt feasible for a service you intend to sell. using manual
  configurations on routers simply isnt scalable.

+ reference to [3]

  I still dont understand why a project focused on
  Internet Exchanges (IXPs/NAPs/...) may have anything to do with NAT
  boxes and tunnels. End-users shouldnt be a topic. People managing
  networks, BGP and AS numbers should.

+ "big opportunity to rapidly deploy a huge number of nodes and networks"

  You mean, nodes of tunnel brokers?
  networks? ...using a router as a NAT client? it may seem as a good "hack
  idea" to use a laptop for this.
  a theoretical question -- does the community want rapid deployment? with
  high RTTs and high chance of self-denial-of-service ?
  ...or is it a way to kill IPv6 faster?

+ last paragraph

  You are listing the need to:
  - change tunnel brokers
  - change something in some operating systems (which ones?)
  Wouldnt be easier to v6-ize the NAT boxes? (dont know if it would be a
  good idea, as we dont need NAT boxes in the native IPv6 world...)

[4, Applicability]

+ "The most usual scope of application of this technology seems to be
   SOHO and home environments, but is not limited to these."
  Do you mind to specify more environments? I think it would be important
  to specify, if they exist.

[5, NAT design considerations]

+ "New firmware/software versions of the NAT implementations should
   ensure the support of protocol-41 forwarding."

  I would add: ", and the means for its administrator to turn it on and
  off".
  As an example, we wouldnt want anyone using a connection to a tunnel
  broker if native IPv6 is available on the wire/air.
  Mandatory support for protocol-41 forwarding seems unnappropriate, as
  tunnels usage will fade away (as a method of getting IPv6 connectivity).

[7, Security]

+ (more)

  The mechanism of forwarding protocol 41 might be considered a serious
  security issue in some organizations. Those wanting to restrict access
  to some applications/networks for instance. They can/do provide IPv4
  and native IPv6, but with a well-defined set of filtering rules. Using
  (standardizing) a mecanism that permits clients to override the set of
  rules seems dangerous. If vendors start(or continue) to permit
  forwarding of protocol 41 in their factory defaults (expressely or
  somewhat hidden) ops people can have a new plague to toy around, when
  native (and filtered) IPv6 is in place.

Regards,

./Carlos                                                "Networking is fun!"
--------------         [http://www.ip6.fccn.pt]           http://www.fccn.pt
<[email-masked]>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup
F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167
                [ See me @ h323:videoconf05.fccn.pt]
  "Internet is just routes (125953/461), naming (millions) and... people!"

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Tue, 15 Jul 2003 23:49:35 +0200

Carlos,

My comments in-line.

Regards,
Jordi

----- Original Message ----- 
From: "Carlos Friacas" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 14, 2003 12:09 PM
Subject: More comments on draft-palet-v6ops-proto41-nat-00.txt

>   configurations on routers simply isnt scalable.

I'm not implementing a service just describing an option to do it. Is a decision of the implementor how it should be.

>   networks, BGP and AS numbers should.

Well, I guess you shouldn't try to tell the "inventor" and technical responsible of a project what's the project scope. I can tell
you that Euro6IX scope is not ONLY the IXs, but also how they become useful to users, and whatever is needed to foster the
deployment of IPv6. This information is explained in the project documents, publicly available.

>   ...or is it a way to kill IPv6 faster?

I think the text is clear on this point, and again I don't need to consider how to implement the service, just offer a solution to
deploy it.

>   good idea, as we dont need NAT boxes in the native IPv6 world...)

I'm not specifying the tunnel brokers, and thus no need to indicate what scripts for what OS should be changed. This will be another
document.

No, not all the vendors are going to make the effort and investment in provide native IPv6, and not all the existing hardware
supports it.

>   to specify, if they exist.

Whatever where there is a NAT box ;-)

>   tunnels usage will fade away (as a method of getting IPv6 connectivity).

The only one that have access to the NAT boxes is the administrator (in most of the scenarios the owner/user = SOHO).

>   native (and filtered) IPv6 is in place.

Exactly the same security issues as you already have with any kind of tunnels. So, the mechanism to override the rules are already
here: Any kind of tunnel of VPN.

The question of what kind of filters or firewalls or whatever is deployed in IPv6 networks, isn't the scope of this document.

>   "Internet is just routes (125953/461), naming (millions) and... people!"

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

---

From: Carlos Friacas <[email-masked]>
Date: Wed, 16 Jul 2003 10:45:10 +0100 (WEST)

Hello.
Again, inline.

> I'm not implementing a service just describing an option to do it.
> Is a decision of the implementor how it should be.

Perhaps you should make a reference in your document, that this approach
will lead to manual configurations. It would be nice to have this explicit
-- you are documenting "testbed procedures".

> Well, I guess you shouldn't try to tell the "inventor" and technical
> responsible of a project what's the project scope.

I've read the documents publicly available at the project's site.
That was the reason i did the comment in the first place.

> I can tell you that Euro6IX scope is not ONLY the IXs, but also how they
> become useful to users,

IXs are interconnection points. They have a central role in avoiding
traffic from ISP A to ISP B in city X, from going to city Y.
IXs' issues are lower latency, redundancy, etc... in the end, they will
benefit users, but final users *DONT* connect to IXs.

Your projects' credibility would be significant if AMS-IX, LINX, DECIX and
others (real IXs) were a part of the project...

> and whatever is needed to foster the
> deployment of IPv6.

I can concurr with that. IPv6 deployment (and widespread) depends also
on the capability of ISPs connecting natively to their local IX (and
transit providers connecting to several IXs).

> This information is explained in the project
> documents, publicly available.

Yes, i've seen those.

> I think the text is clear on this point, and again I don't need to consider
> how to implement the service, just offer a solution to deploy it.

What i was trying to query, is your opinion on this being a *bad*
solution or not (considering the roundtrip, complexity, etc...).
In any case, huge number of nodes/networks connected to
tunnel brokers (in reality they are only a few...) should be documented
as a poor solution.

> I'm not specifying the tunnel brokers, and thus no need to indicate what scripts for what OS should be changed. This will be another

Its some sort of???: "I think IP will run better with 512 bits addresses
-- hey everyone: change all your applications to meet my view!"
I would wish to know more about what is needed on the tunnel brokers
end...

> No, not all the vendors are going to make the effort and investment in
> provide native IPv6, and not all the existing hardware
> supports it.

If they dont provide, customers will simply prefer other vendors...

> Whatever where there is a NAT box ;-)

So: "SOHO and Home".
Where can we think about using a NAT box with an environment that you can
name differently??? anyone?

> The only one that have access to the NAT boxes is the administrator
> (in most of the scenarios the owner/user = SOHO).

changing this draft to "informational" was good.

Regards,